Hi Michael!
On 11 September 2014 14:13, Michael Chapman <mike(a)very.puzzling.org> wrote:
Why is RBD is handled specially in this function? The current logic
is that
an RBD-backed disk is safe to be migrated even if it's got caching enabled,
but I'm not sure how RBD is different from other backends in this regard.
I recall this has was discussed before but am having trouble finding
the thread. I think the gist of it was that the rbd integration was
just lucky, but it wasn't using the appropriate interfaces defined by
libvirt for flushing.
And I think Debian patches away the qemuMigrationIsSafe pass for RBD,
so it'll only pass for cache=none.
A problem arises with RBD disks that have caching enabled. According
to
qemuMigrationIsSafe, these disks are "safe" to be migrated. However in
either the NBD or the non-NBD case, the RBD disk will be copied. This is
clearly not desirable. If RBD is a special case in qemuMigrationIsSafe, does
it also need to be a special case when configuring the NBD server? Or, if an
NBD server is not going to be used, should the migration be considered
"unsafe" if an RBD disk is present?
A related problem arises mixing RBD and local disks when
drive-mirroring / block-migrating - the RBDs get migrated too, volume
round trips out of ceph -> into source hypervisor -> into dest
hypervisor -> back into ceph. Not great!
This patch fixes that issue (but thus far I've only tested against
1.1.1 on Precise - will do with 1.2 on Trusty next week)
=====
qemuMigrationDriveMirror(virQEMUDriverPt
virDomainBlockJobInfo info;
/* skip shared, RO and source-less disks */
- if (disk->shared || disk->readonly || !disk->src)
+ if (disk->shared || disk->readonly || !disk->src ||
+ (disk->type == VIR_DOMAIN_DISK_TYPE_NETWORK &&
+ disk->protocol == VIR_DOMAIN_DISK_PROTOCOL_RBD))
continue;
VIR_FREE(diskAlias);
=====
So interested in feedback on this and whether it should be pushed up...
--
Cheers,
~Blairo