Hello again, I did some further tests on this issue with the qcow2 image, the qcow2 image converted to raw and the _blank (raw) image from the UEC tar archive.
I loaded nbd with $ sudo modprobe nbd max_part=8 *** qcow2 image *** $ k$ md5sum cirros-0.3.0-x86_64-disk.img 50bdc35edb03a38d91b1b071afb20a3c cirros-0.3.0-x86_64-disk.img $ qemu-img info cirros-0.3.0-x86_64-disk.img image: cirros-0.3.0-x86_64-disk.img file format: qcow2 virtual size: 39M (41126400 bytes) disk size: 9.3M cluster_size: 65536 $ sudo qemu-nbd -c /dev/nbd15 $PWD/cirros-0.3.0-x86_64-disk.img That creates the device /dev/nbd15p1 kpartx on top of that: $ sudo kpartx -a /dev/nbd15 device-mapper: resume ioctl failed: Invalid argument create/reload failed on nbd15p1 $ sudo qemu-nbd -d /dev/nbd15 /dev/nbd15 disconnected *** UEC image *** $ qemu-img info cirros-0.3.0-x86_64-blank.img image: cirros-0.3.0-x86_64-blank.img file format: raw virtual size: 24M (25165824 bytes) disk size: 24M $ sudo qemu-nbd -c /dev/nbd15 $PWD/cirros-0.3.0-x86_64-blank.img That DOES NOT create the device /dev/nbd15p1 kpartx on top of that: $ sudo kpartx -a /dev/nbd15 kpartx executes without error $ sudo qemu-nbd -d /dev/nbd15 /dev/nbd15 disconnected *** raw image *** $ qemu-img convert -p -O raw cirros-0.3.0-x86_64-disk.img cirros-0.3.0-x86_64-disk_raw.img $ qemu-img info cirros-0.3.0-x86_64-disk_raw.img image: cirros-0.3.0-x86_64-disk_raw.img file format: raw virtual size: 39M (41126400 bytes) disk size: 12M $ sudo qemu-nbd -c /dev/nbd15 $PWD/cirros-0.3.0-x86_64-disk_raw.img That creates the device /dev/nbd15p1 kpartx on top of that: $ sudo kpartx -a /dev/nbd15 device-mapper: resume ioctl failed: Invalid argument create/reload failed on nbd15p1 $ sudo qemu-nbd -d /dev/nbd15 /dev/nbd15 disconnected So, the issue is not with the qcow2 vs raw image formats. Instead kpartx only executes without error provided that the device /dev/nbd15p1 is not created. When p1 is created by qemu-nbd, kpartx is not needed to mount the image device, but the problem is qemu-nbd does not create p1 in all cases. I have not checked the details of the OpenStack code, but an (ugly) work around could be to only execute kpartx when it is needed. Best Regards, Fredric -----Original Message----- From: openstack-bounces+fredric.morenius=ericsson....@lists.launchpad.net [mailto:openstack-bounces+fredric.morenius=ericsson....@lists.launchpad.net] On Behalf Of Vishvananda Ishaya Sent: den 10 juni 2012 22:22 To: Pádraig Brady Cc: igor.lask...@gmail.com; openstack Subject: Re: [Openstack] File injection support On Jun 8, 2012, at 9:03 AM, Pádraig Brady wrote: > >> $ qemu-img info cirros-0.3.0-x86_64-disk.img >> image: cirros-0.3.0-x86_64-disk.img >> file format: qcow2 >> virtual size: 39M (41126400 bytes) >> disk size: 11M >> cluster_size: 65536 >> $ sudo qemu-nbd -c /dev/nbd15 $PWD/cirros-0.3.0-x86_64-disk.img $ ls >> -l /dev/nbd15* >> brw-rw---- 1 root disk 43, 240 Jun 8 11:32 /dev/nbd15 >> brw-rw---- 1 root disk 43, 241 Jun 8 11:32 /dev/nbd15p1 > > Very interesting. I don't get the ...p1 device here on a > 3.3.7.fc17.x86_64 kernel did you modrpobe nbd with max_part=8 or some such? It won't detect partitions automatically unless you do so. We really should stop using kpartx and force people to modprobe nbd with max_part=X There seem to be various issues with kpartx Vish > > cheers, > Pádraig. > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp