Open Stack

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.com at lists.launchpad.net [mailto:openstack-bounces+fredric.morenius=ericsson.com at lists.launchpad.net] On Behalf Of Vishvananda Ishaya
Sent: den 10 juni 2012 22:22
To: Pádraig Brady
Cc: igor.laskovy at 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 at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp


_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp