WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] live saving of domU

Jayesh Salvi wrote:


On 5/10/06, *Anthony Liguori* <aliguori@xxxxxxxxxx <mailto:aliguori@xxxxxxxxxx>> wrote:

    Guests are aware of the physical addresses of the memory that's been
    allocated to them.  Because of this, to save a domain's state in a
    restorable way you need the guest to "canonicalize" itself.  The only
    way to do this today is through a suspend operation which happens
    to be
    a subop of shutdown.  Shutdowns are non-recoverable so you cannot use
    this as a snapshotting mechanism.


Thanks, that was informative. But the shutdown you are refering to here is not the traditional shutdown of domU right? I mean 'xm shutdown' will do proper shutdown of domU OS, the shutdown you are referring while doing 'xm save' is different from that, I hope!

From the perspective of the hypervisor, there isn't a significant difference between doing an "xm shutdown" or an "xm save". Don't read too much into that though b/c the vast majority of both operations are performed in userspace. Unfortunately, this lack of distinction in the hypervisor is what currently prevents light weight check pointing.

You could, theoritically, add another entry point in the guest kernel and use some xenstore magic to force the domain to spin in a loop after canonicalizing, pause it, switch a register value, then unpause it. Something like (in psuedo-code):

while (eax == 0) halt;

Right after canonicalizing. Then pause, and do a getvcpuinfo/setvcpuinfo to change eax to 1. Then unpause. If you added another suspend entry point you could probably even avoid tearing down the devices...

Regards,

Anthony Liguori

    The closest thing you can achieve is a localhost migration.  There are
    some caveats to this, of course.  The first is that you need to
    have as
    much memory as the domain has available since you'll have a copy
    of the
    domain created briefly while the migration takes
    place.  Migrations are
    also quite intrusive since they involve tearing down and bringing
    up all
    the devices.

    I've gotten a lot of requests for light weight checkpointing.  AFAIK,
    noone is actually working on it though.

    Regards,

    Anthony Liguori

    > If you had a way to snapshot the storage at the same time as the
    VM, then you
    > could make live snapshotting of VMs work properly.  As it is,
    this is not
    > integrated into Xend at the moment, and not supported because of
    the danger of
    > filesystem corruption if you don't know what you are doing.
    >
    > Ewan.
    >
    > _______________________________________________
    > Xen-devel mailing list
    > Xen-devel@xxxxxxxxxxxxxxxxxxx <mailto:Xen-devel@xxxxxxxxxxxxxxxxxxx>
    > http://lists.xensource.com/xen-devel
    >




--
Jayesh
------------------------------------------------------------------------
Everything you can imagine is real


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