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

Re: [Libvir] Next features and target for development

DB> That's a good question really. There's definitely an argument to
DB> be made that the guest shoud be undefined on the source to prevent
DB> its accidental restart.

Right, given that migration implies shared storage, starting a domain
in two places would be catastrophic.

DB> If we wanted to make undefining after migrate compulsory, then
DB> doing it as part of the virDomainMigrate call would make sense. If
DB> it was an optional thing though, one could make use of a flag to
DB> virDomainMigrate, or simply call virDomainUndefine explicitly.

In the case of a flag, or the case of an explicit undefine, how do you
handle a new virtualization technology that enforces this behavior?  I
think assuming this level knowledge of the underlying platform (which
could change in Xen at some point, too) would be a bad idea.

DB> Then again Xen is starting to get support for checkpointing of VMs
DB> - where the original VM is left running after it has been saved
DB> (assume the disk is snapshotted at time of save too). If you apply
DB> the concept of checkpoints to migrate (which is using all the same
DB> code as save/restore in XenD), then you could have this idea of
DB> migrating the VM & leaving it on the original host too.

Sure, but wouldn't it make sense to have a separate API for
checkpoint-like behavior?  Even if this means a function like
virDomainMigratePreserve(), you could easily have this return "not
implemented" or "not supported" for a given platform in a sensible
way.  You could do this in the flag case, as well, but I think it
would be cleaner to define this as a separate action.


Dan Smith
IBM Linux Technology Center
Open Hypervisor Team
email: danms us ibm com

Attachment: pgpmdgYrHEPVi.pgp
Description: PGP signature

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