Bug 618521

Can you explain why is that a bug, it is clearly ENOSPACE issue.

(In reply to comment #1)
> Can you explain why is that a bug, it is clearly ENOSPACE issue.    

Hi, Dor

If I make this 40G qcow2 images called rhel5.qcow2(Avliable space in the host is 120G) to be Backing store of iscsi-target.

After connected by iscsi-initiator,A new disk will find like /dev/sdc in the initiator host.
# qemu-img info /dev/sdc
image: /dev/sdc
file format: qcow2
virtual size: 40G (42949672960 bytes)
disk size: 0
cluster_size: 65536

I installed guest with -drive file=/dev/sdc instead of file=rhel5.qcow2. I think 40G is enough for RHEL5.5 64 bit Guest installaion. ENOSPACE shouldn't be reported.
And another issue is the Guest stopped during virtual disk being re-initiallze.This means the disk images have not been written anything yet.

What's the size of the iscsi backing file?
The about 40G of qcow2 are sparse and the disk size is 0.

(In reply to comment #3)
> What's the size of the iscsi backing file?
> The about 40G of qcow2 are sparse and the disk size is 0.    

Test this in 2 ways;
1 dd a 100G file as iscsi backing file and then make it to be 90G qcow2 image
eg:dd if=/dev/zero of=/RHEL5 bs=1m count=102400
qemu-img create -f qcow2 /RHEL5 90G
then add /RHEL5 to iscsi backing file

2.According to Amit's advice ,make it 50GB qcow2 image directly to be iscsi backing file
qemu-img create -f qcow2 /RHEL5_test 50G
then add /RHEL5_test to iscsia backing file

This two ways are all hit this issue.

Might be related to bug 618901 which appears to be fixed in current qemu-kvm. Mike is going to retest this with a more recent qemu-kvm.

Virtio-blk:test in qemu-kvm-0.12.1.2-2.104.el6.x86_64

Actual Results :

Guest paused and can not resumed ,still hit this issue.


ide-drive:test in qemu-kvm-0.12.1.2-2.99.el6.x86_64,qemu-kvm-0.12.1.2-2.104.el6.x86_64. Got the same result.

Actual Results:
Guest paused during guest installation (screen dump1).
the Guest can be continued,but can not find drive in the next step(screen dump2)

Created attachment 435508 [details]
Screen dump1

Created attachment 435515 [details]
Screen dump2

bug review meeting. Dor doesn't think its a problem as likely already fixed. he wants it to be retested and review change log that fixed to understand why previous bug was fixed. Dor targeting this review by end of this week

Okay, an IRC talk later it's clear what happened:

1. Create an image /home/mike that is exported via iscsi and appears as a block device /dev/sdx on the host running qemu-kvm
2. qemu-img create -f qcow2 /home/mike 16G - note that the qcow2 image is not created on the block device /dev/sdx but on the image backing this. So /home/mike is now a very small file containing not much more than the qcow2 header. The block device /dev/sdx is a very small one now
3. Start installation. The very first write to the disk needs to allocate a new cluster. /dev/sdx is too small to contain another cluster, and as it's a block device it can't grow. VM stops with ENOSPC.

If you take care that the image file /home/mike stays large (e.g. by accessing it via /dev/sdx or by using a block device instead of a regular file) the problem doesn't exist. Mike did confirm this in his setup.

So we're seeing entirely expected behaviour. Closing the bug.