On Wed, May 11, 2011 at 10:09:47 +0100, Daniel P. Berrange wrote: > The problems with this [migration v2] are: > > - Since the first step is a generic 'DumpXML' call, we can't > add in other migration specific data. eg, we can't include > any VM lease data from lock manager plugins > - Since the first step is a generic 'DumpXML' call, we can't > emit any 'migration begin' event on the source, or have > any hook that runs right at the start of the process > - Since there is no final step on the source, if the Finish > method fails to receive all migration data & has to kill > the VM, then there's no way to resume the original VM > on the source Sorry for not noticing it earlier but I think we have another problem with our current migration schema (and this v3 as well). Domain XML may contain some data (such as /domain/devices/graphics/@listen) that an application may wish to change when migrating a domain. What would be the best way to implement the ability to modify domain XML that is passed to target libvirtd? A callback parameter for virDomainMigrate API or something else perhaps? Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list