[libvirt] Enhancing block/disk migration in libvirt

[Tony Breeds]

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?

Yours Tony.
[1] I'm happy to be corrected / pointed at community guidelines that I may
    have missed.
[2] https://bugs.launchpad.net/nova/+bug/1246201
[3] https://bugs.launchpad.net/nova/+bug/1334398
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150216/3f43f587/attachment-0001.sig>