With diablo plus some of our own changes, we've discovered our compute nodes in some of our test nova environments are littered with orphaned /dev/mapper/nbd* links to /dev/dm-* devices that are holding the respective nbd devices. Of course, this causes injection failure for VMs that attempt to reuse those wedged nbd devices that appear available by the method that nova uses to determine nbd device availability.
This could well be self-inflicted, and we haven't gotten down to the root cause. However, in looking at it, we're wondering why the compute manager uses kpartx, specifically atop nbd device. It does appear to be rather fragile and nbd devices do support partitioned images if the module is installed with max_part > 0, where zero is the unfortunate default. We're thinking that maybe we can dispense with kpartx and, ensuring that the nbd module is installed with max_part > 0 on our compute nodes, use the resulting /dev/nbdXpY devices directly. But, before we charge off down that path, we want to understand the rationale for using kpartx atop nbd. We've searched the wiki and git logs and the wider 'net for enlightenment. Finding none, we turn to the collective wisdom of the Community. Is there some problem with qemu-nbd and partitioned images that argues against this approach? Perhaps qemu-nbd doesn't recognize/support all of the partition table types that kpartx does? Something more insidious? Anyone know? Regards, Lee Schermerhorn _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
