This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 727548 - vbox should _not_ be default URI over qemu/kvm
vbox should _not_ be default URI over qemu/kvm
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: libvirt (Show other bugs)
15
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Daniel Veillard
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-02 08:42 EDT by Kamil Páral
Modified: 2011-08-04 08:31 EDT (History)
9 users (show)

See Also:
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: ---


Attachments (Terms of Use)
pools in virt-manager (70.45 KB, image/png)
2011-08-02 08:42 EDT, Kamil Páral
no flags Details

  None (edit)
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):
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>
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
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.
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

/etc/profile.d/libvirt.sh

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

Daniel
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...

Daniel
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,

Daniel

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