Re: [libvirt] Enhancing block/disk migration in libvirt

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.