[Libvir] Re: Next features and target for development

[Dan Smith]

AL> For KVM, the guest isn't destroyed explicitly after a migration is
AL> successful.  Instead, the source guest is left in a paused state.
AL> The main reason for not destroying the guest was so that a
AL> management tool could still interact with the guest's monitor to
AL> obtain statistics on the migration.  It's expected that the
AL> management tool will destroy the domain on the source machine
AL> whenever it is done working with it.

That seems entirely different than the Xen case, and entirely more
useful :)

AL> The KVM source guest is still resumable too so this doubles as a
AL> mechanism for forking VMs.  I think these are useful semantics that
AL> ought to be exposed.  With KVM, live migration is more generic.  You
AL> can use it to do light-weight checkpointing.

I agree that it should be exposed, as should any future Xen
checkpointing capability.  However, "migration" means moving a domain
to me, which is (at least at a higher level) different from
checkpointing or forking.  I think that most checkpoint
implementations will be largely similar to the migration for that
platform, but it seems like it should be exposed out of libvirt as a
different operation, no matter how it is implemented.

-- 
Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms at us.ibm.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070710/1df1096a/attachment-0001.sig>