Re: [Libvir] save/restore support for KVM
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 -=|