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

Re: [Libvir] save/restore support for KVM

On Thu, Aug 09, 2007 at 10:55:10PM +0100, Daniel P. Berrange wrote:
> On Thu, Aug 09, 2007 at 05:26:43PM -0400, Jim Paris wrote:
> > Hi,
> > 
> > I've implemented save/restore support for KVM using the live migration
> > feature.  First, a few patches to KVM to fix bugs:

  Very cool :-)

> > Then, another patch to KVM to support inbound migration from a
> > filename.  It already supports migration from stdin, but adding this
> > seemed easier from a libvirt perspective.
> > 
> >   Subject: [PATCH] qemu: accept filename for incoming migration
> >   http://article.gmane.org/gmane.comp.emulators.kvm.devel/5590
> Just been committed to KVM repos I see. Should be an easy patch to backport
> too. As long as we can detect failure if this is missing & report it back 
> then I'm fine depending on this.

  Would checking for the kvm version from the console sufficient ? Since KVM
makes even more releases than libvirt in average I guess that would be 

> > Finally, the libvirt side.  Some notes:
> > 
> > - Arbitrary decisions about VM status: I pause the VM before starting
> >   migration, and destroy it once it's finished.  Neither is required
> >   by KVM but I'd be concerned about the disk image state otherwise.
> >   Also, after resuming, the VM is still paused.  I don't know how Xen
> >   behaves in this regard but the behavior here is easy enough to
> >   change.
> Xen doesn't mind whether the VM is running or paused when saving it. Pausing
> it seems reasonable - its going to be stopped shortly anyway, so letting it
> continue running just increases the saved image size by having to process
> dirtied memory. As for restore, I'd be inclined to leave it running after 
> restore to match our Xen driver.

  I must admit I feel more comfortable with pausing, reduces the complexity
of the operation and could avoid nasty bugs near impossible to track.

> > 
> > - I append the domain's UUID at the end of the migration image. 
> >   This doesn't affect KVM at all (it ignores the extra data).
> >   Does that seem reasonable?  It's unclear how the saved image
> >   is supposed to get associated with a particular VM configuration
> >   without doing something like this.
> Actually I'd store the entire XML config appended to the end of the image.
> Its quite possible the saved image may be restored on a different machine
> so libvirt will need the XML config there & its not much work to automatically
> append it all & use it when restoring later.

  +1 . The only problem is that the XML has no predefined size, so it may be
hard to stack more stuff behind it. I would ask first on the KVM list to check
if it's okay to add a variable lenght data structure at the end, they might
want to extend it in the future and that would be hard to handle.


Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/

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