1. The Ubuntu KVM community wiki doesn't say fuck-all about connecting remotely. It assumes the user is running it all on their local system.
2. The error message gives advice that could mislead the user to install crap on the client side that they do not need, but in either case, has nothing to do with the problem. The "Details" text is so generic and unhelpful (you will get the same error message when the network is unavailable) that it leaves the user searching endlessly for the right bug to mach the problem.
The (useless and misleading) Error Message Advice
Unable to open a connection to the libvirt management daemon.
Verify that:
- The 'libvirt-bin' package is installed
- The 'libvirtd' daemon has been started
- That you have access to '/var/run/libvirt/libvirt-sock'
The (Unhelpful) Details Text
Unable to open connection to hypervisor URI ...
<class 'libvirt.libvirtError'> virConnectOpenReadOnly() failed
Connection reset by peer
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/connection.py", line 332, in
_open_thread
self.vmm = libvirt.openReadOnly(self.uri)
File "/usr/lib/python2.5/site-packages/libvirt.py", line 144, in
openReadOnly
if ret is None:raise libvirtError('virConnectOpenReadOnly() failed')
libvirtError: virConnectOpenReadOnly() failed Connection reset by peer
The Fixes:
(This was done using Ubuntu Hardy (8.04) in virtualbox, but I have seen the same problem with Ubuntu version 12.04, so this seems to apply across many versions of Ubuntu)So, you installed the KVM packages, or you selected the "Virtualization" option while installing a Ubuntu server, and by default it won't work. You've played around with the virt-manager interface on your desktop system and that already works, but now you want to manage the server from your desktop. Here's what is missing and/or hard to find:
1. You must add your user to the libvirtd group in the file /etc/group, on the server. "user" is the name of your user on your Desktop system, so the names need to match or you'll have to figure out something extra to make it work.
2. To connect succussfully using the ssh method, you must have created a pair of ssh key files (id_rsa, id_rsa.pub) on your Desktop system (using the command ssh-keygen, and NO PASSPHRASE)
Then you would need to copy the .pub file from the Desktop system at /home/<username>/.ssh/id_rsa.pub under a new name as /home/<username>/.ssh/authorized_keys on the server.
virt-manager will not ask you for your password in the normal ssh connection method, it will just fail with the stupid message you see at the top of this page.
Furthermore, if you followed the advice of using "sudo virt-manager" on the client or server as it's first run, it will not be able to start because your home folder will have the config directory ".virt-manager/" owned by root. In which case, use:
$ sudo chown -R <user>:<user> /home/<user>/.virt-manager/
From there, you will be able to run the virt-manager without having to be root.
Finally, I just wanted to comment that I originally installed virt-manager on the server, pulling tons of packages into it and essentially installing a whole desktop just to use it. This way I could get around the problem by connecting with "ssh -X" and remotely using virt-manager. It was a fucking waste of time.
