[Libvir] Next features and target for development

[Dan Smith]

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.

Thoughts?

-- 
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/84f97eb2/attachment-0001.sig>