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
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(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/