[Libvir] save/restore support for KVM
Daniel Veillard
veillard at redhat.com
Fri Aug 10 10:26:52 UTC 2007
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
fine.
> > 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.
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
More information about the libvir-list
mailing list