can't Open guests with Virtual Machine Manager

Virtual Machine Manager doesn’t allow me to Open guests anymore to see display output or modify the guest configuration. I believe it may be some kind of locking issue as sometimes it does work properly when opening VM Manager locally, but then errors out on a remote session or vice versa. I’m unable to find what to do to not have this issue (disconnecting from QEMU and logging off all other sessions for example doesn’t help). The error I’m getting is

Error launching details: Configuration server couldn't be contacted: D-BUS error: Unable to store a value at key '/apps/virt-manager/details/show-toolbar', as the configuration server has no writable databases. There are some common causes of this problem: 1) your configuration path file /etc/gconf/2/path doesn't contain any databases or wasn't found 2) somehow we mistakenly created two gconfd processes 3) your operating system is misconfigured so NFS file locking doesn't work in your home directory or 4) your NFS client machine crashed and didn't properly notify the server on reboot that file locks should be dropped. If you have two gconfd processes (or had two at the time the second was launched), logging out, killing all copies of gconfd, and logging back in may help. If you have stale locks, remove ~/.gconf*/*lock. Perhaps the problem is that you attempted to use GConf from two machines at once, and ORBit still has its default configuration that prevents remote CORBA connections - put "ORBIIOPIPv4=1" in /etc/orbitrc. As always, check the user.* syslog for details on problems gconfd encountered. There can only be one gconfd per home directory, and it must own a lockfile in ~/.gconfd and also lockfiles in individual storage locations such as ~/.gconf

Sorry for the wall of text. Full log can be found here, screenshot of error TIA!

I’m not certain if this is related but when I connect to QEMU in Virtual Machine Manager the following errors are constantly repeated in messages:

2014-04-24T10:54:46.671990+01:00 kvmhost libvirtd[3030]: Cannot create route - destination and gw are both 0/0
2014-04-24T10:54:46.672142+01:00 kvmhost libvirtd[3030]: Cannot create route from netlink message: No such file or directory

libvirtd.conf was left as-is except for enabling TCP communication without authentication

listen_tcp = 1
auth_tcp = "none"

QEMU is running its processes as root, in qemu.conf

user = "root"
group = "root"

You’ll need to provide more information, eg
Always start with a full description of your machine when posting to the Forums. In this Virtualization Forum, if relevant describe both the Guest(s) and Host.
What virtualization are you running, eg both KVM and Xen will use QEMU so you need to specify.
What version of libvirt are you running?

zypper info libvirt

Have you updated your system?

zypper up

Is this a brand new install where VMM has never worked, or is it an older install where it worked before but now doesn’t? And, if it did work before, can you recall what you did recently since when it worked?
If you understand the errors you posted, have you tried to investigate those suggestions in your errors or do you need help with that?


Hi Tsu, thanks for your reply. The host is running OpenSUSE 13.1 with kernel 3.11, fully updated and using KVM virtualization. I can’t tell whether the issue was always there. The issue happens with all guests and resembles a kind of locking issue.

libvirt info is as follows:

Information for package libvirt:
Repository: openSUSE-13.1-Update
Name: libvirt
Version: 1.1.2-2.18.3
Arch: x86_64
Vendor: openSUSE
Installed: Yes
Status: up-to-date
Installed Size: 106 B

It’s a very annoying issue when I need to access VMM over a VNC session and it happens to allow only local access at that point. Next session around it may be the otherway around and I haven’t found a mechanism to “release the lock” (e.g. disconnecting from QEMU before closing VMM, always logging out the session, …).

I’ve tried to follow the suggestions in the error message before posting here. There doesn’t seem to be an /etc/gconf2 folder. I did find a .config/gconf/virt-manager in home/user and went as far as to remove it, which didn’t help to resolve this. Any pointers are welcome. Thanks.

If you’re saying your problem is happening intermittently,

Then you’ll need to capture relevant information <at the moment it’s happening>.
The chances of analyzing something when it’s not happening is slim and none.

If you experience a problem connecting, oftentimes information is logged to the syslog.


Hi Tsu, for clarity, the problem is as follows

  1. I’m logged in locally. I can open VMM, connect and manage the VM without an issue. I can Open the VM, manage its properties, see the display output, etc.

  2. Next I log in remotely with the same user using VNC to one of the displays enabled (:1 and :2, similar except for display resolution). I can open VMM, connect, the guests show up but I can’t click on Open to manage a guest, this gives the error shown above. This happens seemingly regardless of whether I disconnect VMM in the local session or log out the local session or not.

  3. Next time around the situation can be reversed - I can connect remotely through one of the VNC sessions, but not locally or through the other VNC connection. I have no way of predicting from which session I will be able to connect VMM and as I don’t know what the root cause is I’m groping in the dark how to resolve or workaround. I hope I’m explaining this clearly enough.

There is no information in the syslog, the only error output I find is in home/user/.virt-manager/virt-manager.log of which I’ve uploaded to pastebin, linked above Any feedback is more than welcome. I’ve tried to investigate as much as I can on my own before posting here (looking into the logs, different ways of attempting to work around this, looking into the error message, …) but I don’t manage to find the problem here. Thanks!

This persisted after a full reinstallation but in the mean time it looks to be some kind of permission issue for the user lauching virt-manager, so this is partially [SOLVED]. When running virt-manager as root the issue is not there. Would need to look into further. Thanks Tsu for chiming in before.