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
Attachment:
pgpi9D4hfXoqN.pgp
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list