Bug 589900 - virt-manager: error cannot creating qcow2 storage volume
Summary: virt-manager: error cannot creating qcow2 storage volume
Status: CLOSED DUPLICATE of bug 590713
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-manager
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Cole Robinson
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-07 09:08 UTC by Stefan Assmann
Modified: 2010-05-14 07:03 UTC (History)
2 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-05-13 18:12:25 UTC


Attachments (Terms of Use)

Description Stefan Assmann 2010-05-07 09:08:29 UTC
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 10:16:27 UTC
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 18:22:57 UTC
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 11:05:40 UTC
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 16:01:53 UTC
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 16:05:49 UTC
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 18:12:25 UTC
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.