virt-manager creates wrong defaults on first boot if libvirt is not running
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
virt-manager (Ubuntu) |
Fix Released
|
Low
|
Unassigned |
Bug Description
Binary package hint: virt-manager
it's difficult to get virt-manager to connect to the root-owned libvirtd instance (ie: the one started from the init scripts with its socket in /var/run).
when i try to add machines via the UI i have 4 options. the "local" one seems to be activating (dbus?) a libvirt instance for my user that stores its stuff in ~/.libvirt/. the other 3 require me to setup some sort of authentication (like ssh, etc).
i have access to the socket in /var/run (i'm in the group for it).
virsh and the other tools communicate with the system daemon just fine.
i was able to get it to work by going into gconf and manually setting up the url of qemu:///system, but it really should be easier than this. some sort of "connect to system socket" option in the interface would be sweet.
summary: |
- virt-manager has a hard time connecting to root-owned libvirtd + virt-manager creates wrong defaults on first boot if libvirt is not + running |
Changed in virt-manager (Ubuntu): | |
status: | New → Confirmed |
importance: | Undecided → Low |
Hm... We used to carry a patch that would automatically add
qemu:///system to the list if you had access to the UNIX socket. I
wonder what happened to that.