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: > > Subject: [PATCH 1/3] qemu: fix freed pointer dereference > http://article.gmane.org/gmane.comp.emulators.kvm.devel/5572 > > Subject: [PATCH 2/3] qemu: don't start a new migration if one is already in progress > http://article.gmane.org/gmane.comp.emulators.kvm.devel/5575 > > Subject: [PATCH 3/3] qemu: reset buffer pointers after CR/LF > http://article.gmane.org/gmane.comp.emulators.kvm.devel/5573 > > (If compatibility with old KVM is wanted, it might be possible to work > around the kvm bugs in other ways, but I'm not sure). These are all genuine bugs so its not unreasonable to require that anyone using save/restore ensure they're patched. > 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. > 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 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. > - I added the migrateFrom field to the qemu_vm struct. Dunno > if that's the best place. Could also add put it in qemu_vm_def, > or add parameters to qemudStartVMDaemon, etc.. Seems reasonable place for now - its not really permanent data so the main 'qemu_vm' struct is more appropriate than 'qemu_vm_def'. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list