Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
(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.
(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.
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)
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.