Created attachment 516317 [details] pools in virt-manager Description of problem: # virsh pool-refresh default; virsh pool-refresh lvm error: failed to get pool 'default' error: Unknown failure error: failed to get pool 'lvm' error: Unknown failure This used to work in Fedora 14. # virsh find-storage-pool-sources dir error: Failed to find any dir pool sources error: this function is not supported by the connection driver: virConnectFindStoragePoolSources # virsh find-storage-pool-sources lvm error: Failed to find any lvm pool sources error: this function is not supported by the connection driver: virConnectFindStoragePoolSources But in virt-manager I can access the pools and refresh them just fine. Version-Release number of selected component (if applicable): libvirt-0.8.8-7.fc15.x86_64 libvirt-client-0.8.8-7.fc15.x86_64 libvirt-python-0.8.8-7.fc15.x86_64 python-virtinst-0.500.6-2.fc15.noarch virt-manager-0.8.7-4.fc15.noarch virt-top-1.0.5-2.fc15.x86_64 virt-viewer-0.3.1-1.fc15.x86_64 How reproducible: always Steps to Reproduce: 1. run 'virsh pool-refresh default' 2. doesn't work 3. Actual results: virsh can't refresh pools Expected results: virsh can refresh pools Additional info: # cat /etc/libvirt/storage/default.xml <pool type='dir'> <name>default</name> <uuid>0a29c1b5-8d12-1641-daac-f81460320004</uuid> <capacity>0</capacity> <allocation>0</allocation> <available>0</available> <source> </source> <target> <path>/var/lib/libvirt/images</path> <permissions> <mode>0774</mode> <owner>500</owner> <group>500</group> </permissions> </target> </pool> # cat /etc/libvirt/storage/lvm.xml <pool type='logical'> <name>lvm</name> <uuid>251b56ea-aadb-151f-062e-26a8bfa8498b</uuid> <capacity>0</capacity> <allocation>0</allocation> <available>0</available> <source> <name>vg</name> <format type='lvm2'/> </source> <target> <path>/dev/vg</path> <permissions> <mode>0700</mode> <owner>-1</owner> <group>-1</group> </permissions> </target> </pool>
virt-manager is probably connecting to qemu:///system while your virsh commands are connecting to qemu:///session which won't have the same storage pools listed anyways. Please confirm by showing the output of 'virsh uri' That said, libvirt should be giving a proper error message here (or not failing at all since session can still do storage management)
Ah, what a surprise: # virsh uri vbox:///system I recently installed VirtualBox, I guess this is the reason. Is it an expected behavior to change the default hypervisor just like that? I checked and I don't have any VIR* or LIBVIR* environment variables set. If this is all my fault, I apologize for the bug report. But still I am quite surprised that installing VirtualBox could change my default environment in libvirt.
It's expected behavior but I agree that it's a bad default. Unfortunately it's not a straightforward fix given how this bit of libvirt is architected. Changing title to reflect this issue
Ok, thanks. One more question - the easiest workaround is to put export LIBVIRT_DEFAULT_URI=qemu:///system into my ~/.bashrc, right? Or is there another way that's better?
That sounds a good way to make it the default only for this user To make it a system wide default the best would be to make a /etc/profile.d/libvirt.sh setting up the environment variable, look for similar files in that directory, Daniel
Thanks. I am not sure why this was closed as NOTABUG? (when looking at comment#3)
Because it's the expected behaviour. You have 2 hypervisors available on your system, you don't give a hint about which one should be used then libvirt chooses. If you tell libvirt which one to pick it will do the right thing, if not then that would be a bug... Daniel
Oh, I supposed that vbox is a bad default. It is also confusing that the act of installing a package may change the default. I would suspect the setting to be remembered and changed only if asked explicitly. (That I see as a bug, from my end-user perspective.) I'm not going to argue though.
well it could be argued that for virsh the command line tool, the last good URI could be used if LIBVIRT_DEFAULT_URI is not set. But at the library API level, I don't think we could introduce that change really, Daniel