[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Fix restore handling checks



Okay, hopefully someone will be able to Ack this patch with better knwoledge
of xend than me.

 -- Keir


On 22/06/2010 07:11, "Michal Novotny" <minovotn@xxxxxxxxxx> wrote:

> On 06/22/2010 07:43 AM, Michal Novotny wrote:
>> On 06/21/2010 08:04 PM, Keir Fraser wrote:
>>> On 21/06/2010 17:30, "Michal Novotny"<minovotn@xxxxxxxxxx>  wrote:
>>> 
>>>> Hi,
>>>> this is the patch to fix restore handling to implement some more checks
>>>> to support more checks than for UUID and name duplicity. This patch
>>>> basically disallows the migration/restore of IDE drives with the
>>>> read-only flag since this is not supported according to the ATAPI/IDE
>>>> specifications so we should disallow this for both domain creation and
>>>> domain migration/restore.
>>> What about CD-ROMs? This would break my test domain config, for example.
>>> 
>> 
>> Right, there's the exception for CD-ROMs according to the spec. I
>> should implement this as well but read-only IDE disk devices are not
>> supported according to the IDE specs.
> 
> 
> This is the updated version of my patch to allow read-only CD-ROM
> devices as you had a good point that read-only is supported for CD-ROM
> IDE drives (but only for them).
> 
> 
>> 
>>>> This patch implements it for both create and
>>>> restore/migrate functionality.
>>>> 
>>>> Also, the check whether the host machine does have enough memory
>>>> available for the guest has been implemented which can be the real
>>>> issue
>>>> when you try to migrate a guest from one machine to another that is not
>>>> having enough memory for this guest. The guest memory gets transferred
>>>> but it fails to run so it's not running on either of those machines
>>>> (i.e. domain is not on the destination nor source host machine).
>>> Failed restore should get reported back to the host that is saving
>>> the guest
>>> state, and cause that machine to resume execution of the original VM.
>>> Does
>>> that not work for you?
>>> 
>>> Possibly checking up front for available memory on the target is a good
>>> idea, but it shouldn't be *essential* if the error handling is up to
>>> par.
>>> 
>>>   -- Keir
>> 
> 
> I was able to make it working now and this functionality seems to be
> working now however I think that the preliminary check before the
> transfer itself is a good idea. As far as I had it implemented already I
> just did some modifications to allow CD-ROM IDE read-only drives and
> this is the updated version.
> 
> Michal
> 
>> 
>>>> I did try it with restore functionality now since I've been able to
>>>> make
>>>> it working for save once so I'm currently using one save image for the
>>>> testing but unfortunately I'm having many issues with the common
>>>> migration and save functionality since I've been able to make it
>>>> working
>>>> once to save it correctly. Fortunately the restores for this one
>>>> particular save image is working fine. I was also thinking about 2
>>>> concurrent migrations to the guest and/or save with the concurrent
>>>> migration and it should be the issue (although it's not been tested
>>>> because of reasons described above) since the domain gets created and
>>>> it's available in the XendDomain list (i.e. xc.domain_getinfo()
>>>> list) so
>>>> it shouldn't be an issue here.
>>>> 
>>>> Michal
>>>> 
>>>> Signed-off-by: Michal Novotny<minovotn@xxxxxxxxxx>
>>> 
>> 
>> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.