[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libvir] Re: Next features and target for development

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 us ibm com

Attachment: pgpN8lV9mqgM1.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]