Hi Michael! On 11 September 2014 14:13, Michael Chapman <mike@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