Bug 727548

Summary: vbox should _not_ be default URI over qemu/kvm
Product: [Fedora] Fedora Reporter: Kamil Páral <kparal>
Component: libvirtAssignee: Daniel Veillard <veillard>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 15CC: aquini, berrange, clalance, crobinso, itamar, jforbes, laine, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-03 21:43:02 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
pools in virt-manager none

Description Kamil Páral 2011-08-02 08:42:16 EDT
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):

How reproducible:

Steps to Reproduce:
1. run 'virsh pool-refresh default'
2. doesn't work
Actual results:
virsh can't refresh pools

Expected results:
virsh can refresh pools

Additional info:

# cat /etc/libvirt/storage/default.xml 
<pool type='dir'>

# cat /etc/libvirt/storage/lvm.xml 
<pool type='logical'>
    <format type='lvm2'/>
Comment 1 Cole Robinson 2011-08-02 10:47:06 EDT
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)
Comment 2 Kamil Páral 2011-08-02 11:01:49 EDT
Ah, what a surprise:

# virsh uri

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.
Comment 3 Cole Robinson 2011-08-02 11:49:13 EDT
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
Comment 4 Kamil Páral 2011-08-02 12:03:14 EDT
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?
Comment 5 Daniel Veillard 2011-08-03 21:43:02 EDT
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


setting up the environment variable, look for similar files in that

Comment 6 Kamil Páral 2011-08-04 04:10:56 EDT
Thanks. I am not sure why this was closed as NOTABUG? (when looking at comment#3)
Comment 7 Daniel Veillard 2011-08-04 07:01:50 EDT
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...

Comment 8 Kamil Páral 2011-08-04 07:19:49 EDT
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.
Comment 9 Daniel Veillard 2011-08-04 08:31:43 EDT
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,