Bug 618521 - Guest paused during Guest installation and can not be resumed.
Summary: Guest paused during Guest installation and can not be resumed.
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: qemu-kvm   
(Show other bugs)
Version: 6.0
Hardware: All
OS: Linux
Target Milestone: rc
: ---
Assignee: Kevin Wolf
QA Contact: Virtualization Bugs
Keywords: TestBlocker
Depends On: 602209
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:
Story Points: ---
Clone Of: 602209
Last Closed: 2010-08-03 11:13:45 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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-

Actual Results :

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

ide-drive:test in qemu-kvm-,qemu-kvm- 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.