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.

Bug 927257

Summary: AttributeError: 'NoneType' object has no attribute 'storagePoolLookupByName'
Product: Red Hat Enterprise Linux 6 Reporter: Jaroslav Henner <jhenner>
Component: virt-managerAssignee: Giuseppe Scrivano <gscrivan>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.4CC: dyuan, jbainbri, jgalipea, jhenner, juzhou, lcui, mjenner, mkletzan, mzhan, rbalakri, tzheng
Target Milestone: rcFlags: jhenner: needinfo-
jhenner: needinfo-
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: virt-manager-0.9.0-20.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1043150 (view as bug list) Environment:
Last Closed: 2014-10-14 06:26:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1043150    

Description Jaroslav Henner 2013-03-25 13:50:24 UTC
Description of problem:
When creating space on remote libvirtd (tcp) on LVM for my VM, I got

Error creating vol: 'NoneType' object has no attribute 'storagePoolLookupByName'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createvol.py", line 243, in _async_vol_create
    newpool = newconn.storagePoolLookupByName(self.parent_pool.get_name())
AttributeError: 'NoneType' object has no attribute 'storagePoolLookupByName'


The virt-manager was running quite a while, I was roaming over several networks (WiFi, Ethernet, ...) when it was running.

After reconnecting the remote, the problem persisted.

After restarting the Virt-Manager, I got:
Error creating vol: Storage pool not found: no pool with matching name 'vg_virt'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createvol.py", line 243, in _async_vol_create
    newpool = newconn.storagePoolLookupByName(self.parent_pool.get_name())
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3037, in storagePoolLookupByName
    if ret is None:raise libvirtError('virStoragePoolLookupByName() failed', conn=self)
libvirtError: Storage pool not found: no pool with matching name 'vg_virt'

But it is there:
[root@master-01 ~]# vgs
  VG        #PV #LV #SN Attr   VSize  VFree 
  vg_system   1   2   0 wz--n-  9,97g     0 
  vg_virt     1   3   2 wz--n- 46,57g 31,92g



Version-Release number of selected component (if applicable):
local:
virt-manager-0.9.4-3.fc17.noarch
libvirt-0.9.11.9-1.fc17.x86_64

remote:
libvirt-0.10.2-18.el6.x86_64

How reproducible:
unknown

Steps to Reproduce:
unknown

  
Actual results:
Unable to allocate LVM


Expected results:


Additional info:

Comment 1 Jaroslav Henner 2013-03-25 14:06:21 UTC
When creating the space as part of creation of the VM, it fails.
When creating the space trough Connection Details, it succeeds.

Comment 2 Jaroslav Henner 2013-03-26 11:01:27 UTC
I have some news how to reproduce:

1) Have several hosts.
2) On each host, have a LVM storage pool. Use same name for all pools.
3) Try creating an image on one of them. It happens that it gets created on another host.
4) Disconnect the host that image got created on. Try creating the storage same way as 3). You will get:

Error creating vol: 'NoneType' object has no attribute 'storagePoolLookupByName'

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createvol.py", line 243, in _async_vol_create
    newpool = newconn.storagePoolLookupByName(self.parent_pool.get_name())
AttributeError: 'NoneType' object has no attribute 'storagePoolLookupByName'

Comment 3 Martin Kletzander 2013-03-26 15:26:51 UTC
Thanks for submitting the bug.  I have to check how the storage pools are internally identified.

Comment 4 CongDong 2013-04-03 05:20:27 UTC
(In reply to comment #2)
> I have some news how to reproduce:
> 
> 1) Have several hosts.
> 2) On each host, have a LVM storage pool. Use same name for all pools.
> 3) Try creating an image on one of them. It happens that it gets created on
> another host.
> 4) Disconnect the host that image got created on. Try creating the storage
> same way as 3). You will get:
> 
> Error creating vol: 'NoneType' object has no attribute
> 'storagePoolLookupByName'
> 
> Traceback (most recent call last):
>   File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in
> cb_wrapper
>     callback(asyncjob, *args, **kwargs)
>   File "/usr/share/virt-manager/virtManager/createvol.py", line 243, in
> _async_vol_create
>     newpool = newconn.storagePoolLookupByName(self.parent_pool.get_name())
> AttributeError: 'NoneType' object has no attribute 'storagePoolLookupByName'

I can't reproduce this, and the step 3 didn't happen.
By the way, your local and remote system are both RHEL6.4?

Comment 5 CongDong 2013-04-07 10:23:17 UTC
The two hosts should add connection to each other? 

I can't reproduce with setps:

1. Two hosts add connection to each other.
2. create LVM storage pool on both hosts with same name, create image on both of them
3. Disconnect the connection ,and create image on both of them

Comment 6 Jaroslav Henner 2013-04-08 14:00:24 UTC
(In reply to comment #5)
> The two hosts should add connection to each other? 
You probably didn't understand. The topology is

Host A                                  Host B
-------------+        +-----------+     +-------------
libvirt      |------- |VirtManager| ----|libvirt
vg_virt pool |        +-----------+     |vg_virt pool
-------------+                          +--------------

1)
First you have to check what is the host that VM happens to be created on:

Try creating a VM on B, for example. In the VM creation dialog, you will be asked to create an image, use vg_virt. If it gets created on A (bad behavior), goto 3). If it gets created on B, continue.

2) Now try it over again, but on host A. But will get it on B (bad behavior).

3) Now disconnect the host which the image happens to be created on (virt-manager doesn't care where you really wanted it).

4) Try creating the VM on the other host again. You will get an error as VirtManager tries to use disconnected connection object.

> 
> I can't reproduce with setps:
> 
> 1. Two hosts add connection to each other.
> 2. create LVM storage pool on both hosts with same name, create image on
> both of them
> 3. Disconnect the connection ,and create image on both of them

Comment 7 Jaroslav Henner 2013-04-08 14:03:32 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > I have some news how to reproduce:
> > 
> > 1) Have several hosts.
> > 2) On each host, have a LVM storage pool. Use same name for all pools.
> > 3) Try creating an image on one of them. It happens that it gets created on
> > another host.
> > 4) Disconnect the host that image got created on. Try creating the storage
> > same way as 3). You will get:
> > 
> > Error creating vol: 'NoneType' object has no attribute
> > 'storagePoolLookupByName'
> > 
> > Traceback (most recent call last):
> >   File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in
> > cb_wrapper
> >     callback(asyncjob, *args, **kwargs)
> >   File "/usr/share/virt-manager/virtManager/createvol.py", line 243, in
> > _async_vol_create
> >     newpool = newconn.storagePoolLookupByName(self.parent_pool.get_name())
> > AttributeError: 'NoneType' object has no attribute 'storagePoolLookupByName'
> 
> I can't reproduce this, and the step 3 didn't happen.
> By the way, your local and remote system are both RHEL6.4?

no.

VIRT manager node is fedora17
virt-manager-0.9.4-3.fc17.noarch
libvirt-0.9.11.9-1.fc17.x86_64

2 or more host nodes are RHEL6.4:
libvirt-0.10.2-18.el6.x86_64

Comment 9 Jamie Bainbridge 2013-10-23 05:00:44 UTC
I'm also getting this on a RHEL64 host with libvirt-0.10.2-18.el6_4.14.x86_64 which is connected to another RHEL64 host with the same version. Both my image pools have different names, however both hosts also have the "default" pool.

The solution for me was to delete both the "default" pools. The issue appeared if virt-manager was connected to both hosts at the same time, and even if virt-manager was not connected to one of the hosts. I'm not using the default pools at all, so this was fine for me.

I haven't clean-reinstalled both my systems to test reproduce steps, but here are the conditions I saw the error under:

* RHEL64 system "host1" with libvirt-0.10.2-18.el6_4.14.x86_64
 - storage pool "default"
 - storage pool "qemu"
* RHEL64 system "host2" with libvirt-0.10.2-18.el6_4.14.x86_64
 - storage pool "default"
 - storage pool "libvirt"
* host1 is graphical (it's my laptop) and host2 is a headless box in runlevel 3
* virt-manager is running on host1 with the local qemu connection, plus ssh (passwordless ssh key) authentication to root@host2

Like Comment 1 says, creating a new image in the Host Details works fine, but creating an image as part of a new guest creation would bring up the error. I was able to create an image in the Host Details, then attach the image whilst creating a new guest.

Hope this helps.

Comment 13 CongDong 2014-02-19 09:58:04 UTC
Hi jhenner:

I test with:
# rpm -qa virt-manager libvirt
virt-manager-0.9.0-19.el6.x86_64
libvirt-0.10.2-29.el6.x86_64

1. Prepare  lvm pool on each host with same name
2. On host B open virt-manager and connect host A like comment 6
Host A                                  Host B
-------------+        +-----------+     +-------------
libvirt      |------- |VirtManager| ----|libvirt
lv01 pool    |        +-----------+     |lv01 pool
-------------+                          +--------------
3. Install vm "new" on A, create the image "new.img" when create vm.
4. After the vm is running, try to install a vm on B with the same name.
Create the image "new.img" when create vm.

Result:
step4, got error:
Error creating vol: Storage volume not found: storage vol already exists

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 44, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/createvol.py", line 249, in _async_vol_create
    self.vol.install(meter=meter)
  File "/usr/lib/python2.6/site-packages/virtinst/Storage.py", line 1213, in install
    vol = self.pool.createXML(xml, 0)
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 2298, in createXML
    if ret is None:raise libvirtError('virStorageVolCreateXML() failed', pool=self)
libvirtError: Storage volume not found: storage vol already exists



As the result, it's not the same with yours.
And when I downgrade the libvirt to libvirt-0.10.2-18.el6.x86_64,
I still got the error.
Can you help me to check my steps and can you reproduce this now?

Comment 15 zhoujunqin 2014-05-07 08:03:41 UTC
Hi, Jaroslav Henner

when i try to reproduced with package virt-manager-0.9.0-19.el6.x86_64
but get the same error info as Comment 13.

Then update to the lateste package:
virt-manager-0.9.0-21.el6.x86_64

Steps:
1. Host1 with default pool and a LVM pool lv01.
2. Host2 with default pool and a LVM pool lv01.
3. Add host2 by new connection on host1, create a vm on host1 in the pool lv01. The image is created correctly.
4. Create a vm on host2 in the pool lv01. The image is created correctly on host2. 
5. Disconect the connection and create VM on the exsiting connection.
6. Delete the default pool on host1.

There's no error pops up for each steps.

can you help check with the latest "virt-manager" version, thanks?

Comment 16 Giuseppe Scrivano 2014-05-23 06:17:25 UTC
is there anything blocking this?  If the problem cannot be reproduced, then let's just close this.

Comment 17 Cui Lei 2014-05-26 05:53:13 UTC
According to comment 15, there is no problem on package virt-manager-0.9.0-21.el6.x86_64. So change the status from 'ON_QA' to 'VERIFIED'.
As QE could not reproduce the original issue, keep the needinfo to bug reporter.
@Jaroslav Henner, if issue could be reproduced in your env with latest version of virt-manager, please update the details in bug and feel free to open it.

Comment 18 errata-xmlrpc 2014-10-14 06:26:04 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1447.html