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@xxxxxxxxxx
Attachment:
pgpsLeKuLIFhJ.pgp
Description: PGP signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list