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@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list