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.
Bug 618521 - Guest paused during Guest installation and can not be resumed.
Summary: Guest paused during Guest installation and can not be resumed.
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On: 602209
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-07-27 07:28 UTC by Mike Cao
Modified: 2013-01-09 22:56 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 602209
Environment:
Last Closed: 2010-08-03 11:13:45 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Screen dump1 (124.69 KB, image/png)
2010-07-30 09:20 UTC, Mike Cao
no flags Details
Screen dump2 (108.36 KB, image/png)
2010-07-30 09:25 UTC, Mike Cao
no flags Details

Comment 1 Dor Laor 2010-07-27 11:11:28 UTC
Can you explain why is that a bug, it is clearly ENOSPACE issue.

Comment 2 Mike Cao 2010-07-28 01:47:56 UTC
(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.

Comment 3 Dor Laor 2010-07-28 11:37:45 UTC
What's the size of the iscsi backing file?
The about 40G of qcow2 are sparse and the disk size is 0.

Comment 4 Mike Cao 2010-07-29 02:16:02 UTC
(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.

Comment 5 Kevin Wolf 2010-07-29 10:11:42 UTC
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.

Comment 6 Mike Cao 2010-07-30 09:18:16 UTC
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)

Comment 7 Mike Cao 2010-07-30 09:20:43 UTC
Created attachment 435508 [details]
Screen dump1

Comment 8 Mike Cao 2010-07-30 09:25:15 UTC
Created attachment 435515 [details]
Screen dump2

Comment 11 Tim Burke 2010-08-02 13:40:23 UTC
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

Comment 12 Kevin Wolf 2010-08-03 11:13:45 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.