This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 589900 - virt-manager: error cannot creating qcow2 storage volume
virt-manager: error cannot creating qcow2 storage volume
Status: CLOSED DUPLICATE of bug 590713
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-manager (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Cole Robinson
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-07 05:08 EDT by Stefan Assmann
Modified: 2010-05-14 03:03 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-13 14:12:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Stefan Assmann 2010-05-07 05:08:29 EDT
Description of problem:
Tried to add a new storage volume in virt-manager. Clicked on "New Volume" filled the fields but when I click on "finish" nothing gets created.
Started virt-manager with --debug and captured the following log:
2010-05-07 10:59:06,342 (connection:212): Using libvirt API for netdev enumeration
2010-05-07 10:59:06,344 (connection:251): Using libvirt API for mediadev enumeration
2010-05-07 10:59:10,714 (engine:628): window counter incremented to 2
2010-05-07 10:59:12,043 (engine:632): window counter decremented to 1
2010-05-07 10:59:13,088 (create:715): Guest type set to os_type=hvm, arch=x86_64, dom_type=kvm
2010-05-07 10:59:19,003 (config:588): get_default_directory(media): returning /extern/ISOs
2010-05-07 10:59:27,849 (config:596): set_default_directory(media): saving /extern/ISOs
2010-05-07 10:59:39,049 (DistroInstaller:119): DistroInstaller location is a local file/path: /extern/ISOs/RHEL6.0-20100428.3-snap2-Workstation-x86_64-DVD1.iso
2010-05-07 10:59:53,153 (createvol:212): Creating volume with xml:
<volume>
  <name>RHEL6.img</name>
  <capacity>10485760000</capacity>
  <allocation>0</allocation>
  <target>
    <format type='qcow2'/>
  </target>
</volume>

2010-05-07 10:59:53,173 (createvol:244): Starting backround vol creation.
2010-05-07 10:59:53,173 (Storage:1137): Creating storage volume 'RHEL6.img' with xml:
<volume>
  <name>RHEL6.img</name>
  <capacity>10485760000</capacity>
  <allocation>0</allocation>
  <target>
    <format type='qcow2'/>
  </target>
</volume>

2010-05-07 10:59:53,374 (Storage:1193): Couldn't lookup storage volume in prog thread.

Looks like this is qcow2 related, as it works when I select RAW!

Version-Release number of selected component (if applicable):
virt-manager-0.8.4-1.el6.noarch

How reproducible:
always
  
Actual results:
cannot add new storage volume

Expected results:
able to add new storage volume

Additional info:
Comment 2 RHEL Product and Program Management 2010-05-07 06:16:27 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 3 Cole Robinson 2010-05-11 14:22:57 EDT
Are you missing a portion of the error output? I don't see anything here about not being able to create the storage volume. There is the message:

2010-05-07 10:59:53,374 (Storage:1193): Couldn't lookup storage volume in prog
thread.

But that is harmless in this case and shouldn't have interrupted anything. Can you be more specific?
Comment 4 Stefan Assmann 2010-05-12 07:05:40 EDT
I turned selinux to "permissive" and after that I got the following message:
2010-05-12 12:55:35,837 (createvol:244): Starting backround vol creation.
2010-05-12 12:55:35,838 (Storage:1137): Creating storage volume 'test.img' with xml:
<volume>
  <name>test.img</name>
  <capacity>1048576000</capacity>
  <allocation>0</allocation>
  <target>
    <format type='qcow2'/>
  </target>
</volume>

2010-05-12 12:55:35,935 (virt-manager:173): Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/host.py", line 651, in refresh_current_pool
    cp = self.current_pool()
  File "/usr/share/virt-manager/virtManager/host.py", line 662, in current_pool
    return self.conn.get_pool(curruuid)
  File "/usr/share/virt-manager/virtManager/connection.py", line 661, in get_pool
    return self.pools[uuid]
KeyError: '63dcf4c1-cb5a-d6f1-196d-cccde7615769'
None
Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/host.py", line 651, in refresh_current_pool
    cp = self.current_pool()
  File "/usr/share/virt-manager/virtManager/host.py", line 662, in current_pool
    return self.conn.get_pool(curruuid)
  File "/usr/share/virt-manager/virtManager/connection.py", line 661, in get_pool
    return self.pools[uuid]
KeyError: '63dcf4c1-cb5a-d6f1-196d-cccde7615769'
2010-05-12 12:55:36,041 (Storage:1193): Couldn't lookup storage volume in prog thread.

Additional note: I've added a second storage pool in virt-manager and the problem only occurs if I try to add a qcow2 image there. Works in the primary storage pool.

Adding a qcow2 image to the primary storage pool looks like this:
2010-05-12 13:03:53,807 (createvol:244): Starting backround vol creation.
2010-05-12 13:03:53,808 (Storage:1137): Creating storage volume 'test.img' with xml:
<volume>
  <name>test.img</name>
  <capacity>1048576000</capacity>
  <allocation>0</allocation>
  <target>
    <format type='qcow2'/>
  </target>
</volume>

2010-05-12 13:03:53,847 (Storage:1160): Storage volume 'test.img' install complete.
2010-05-12 13:03:54,012 (Storage:1193): Couldn't lookup storage volume in prog thread.
Comment 5 Cole Robinson 2010-05-13 12:01:53 EDT
Okay, I'm still confused. Can you provide the following info:

- How many pools do you have?
- The XML output of all the pools (using virsh pool-dumxpml $poolname)
- Can you consistently reproduce?
- Is the error only harmless backtraces in the logs, or is an actual error dialog popping up?
- Does selinux permissive vs. enforcing change the results at all?

If you can consistently reproduce, please provide the full --debug output from a run, and the exact steps you take to reproduce, as well as the above info.
Comment 6 Daniel Berrange 2010-05-13 12:05:49 EDT
If SELinux is running in enforcing mode, then it could be a dup of bug 590713. libvirt uses qemu-img to create the qcow2 file and qemu-img had wrong security labelling preventing it working.
Comment 7 Cole Robinson 2010-05-13 14:12:25 EDT
Sounds like that might be the issue, closing as a dup, Stefan please reopen if this issue seems separate.

*** This bug has been marked as a duplicate of bug 590713 ***

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