[libvirt] Enhancing block/disk migration in libvirt

[Michal Privoznik]

On 16.02.2015 11:16, Daniel P. Berrange wrote:
> On Mon, Feb 16, 2015 at 01:42:13PM +1100, Tony Breeds wrote:
>> Hello all,
>>     I'm new to both openstack and libvirt so I may get some of this slightly
>> wrong[1].
>>
>> Here is some context form the openstack world (which at least some of you are
>> aware of).  There are at least 2 open bug against openstack (nova) in the area
>> of block/disk migration.
>>
>> 1) Live migration fails when the instance has a config-drive[2]
>>    Here openstack(nova) fails because a drive that nova expects to be migrated
>>    isn't migrated.
>>
>> 2) libvirt live_snapshot periodically explodes on libvirt 1.2.2 in the gate[3]
>>    Here openstack(nova) fails because a drive that nova expects NOT to be
>>    migrated is migrated.
>>
>> To me these are essentially the same bug/issue.  There is no way to communicate with
>> libvirt the users expectations around block/disk mirgration.
>>
>> My idea so far would be to add an options element to the 'disk' XML node.
>> This element could start with 3 possible states
>>
>> block_migration="default": Let libvirt decide
>> block_migration="yes":     This device should be block migrated
>> block_migration="no":      This device should *NOT* be block migrated
>>
>> The absence of this element would be treated as "default" above.
>>
>> This would mean that all existing domain XML would still be valid and have the
>> expected behaviour and  users (such as opensatck) can be explicit about deviced
>> that do/do not need to be block migrated.
>>
>> While I'm certainly open to discussing the finer points of the implementation,
>> right now I'm interested in getting a feel for is this idea generally ok?
> 
> This doesn't really belong in the XML. The XML configs are for controlling
> the guest configuration, not functional behaviour of the APIs. So we need
> to fit any neccessary information into the migration API parameters instead,
> or define a new migration API for it. At minimum we just want a list of
> disks to be migrated.

We have a migrate API that takes an array of virTypedParameter. We can
use that to let users pass a list of disks to migrate.

Michal