Re: [PATCH 01/16] Introduce yet another migration version in API.

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

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]