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: [EMAIL PROTECTED]
pgp6C81dgBGO6.pgp
Description: PGP signature
-- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
