I have an openSUSE 13.1 (Bottle) (x86_64) with the Virtualization
repository:
jrc@skylon:~> uname -a
Linux skylon 3.11.6-4-xen #1 SMP Wed Oct 30 18:04:56 UTC 2013
(e6d4a27) x86_64 x86_64 x86_64 GNU/Linux
jrc@skylon:~> rpm -q virt-manager
virt-manager-0.9.5-6.1.3.x86_64
jrc@skylon:~> rpm -q -a | fgrep -i qemu
qemu-1.6.0-4.2.1.x86_64
qemu-sgabios-8-4.2.1.noarch
libvirt-daemon-qemu-1.1.2-8.1.x86_64
qemu-ipxe-1.0.0-4.2.1.noarch
qemu-tools-1.6.0-4.2.1.x86_64
qemu-vgabios-0.6c-4.2.1.noarch
qemu-seabios-1.7.2.2-4.2.1.noarch
libvirt-daemon-driver-qemu-1.1.2-8.1.x86_64
jrc@skylon:~>
but I have been unable to connect to localhost (QEMU) using Virtual
Machine Manager. The symptoms are that I click “connect”; a System
Policy dialog box appears; I enter the root password; and receive the
following response:
Error polling connection ‘qemu:///system’: An error occurred, but the
cause is unknown
None
I found this in /var/log/messages:
2013-12-19T10:26:26.447210+00:00 skylon polkitd[1331]: Operator of
unix-session:1 successfully authenticated as unix-user:root to gain
TEMPORARY authorization for action org.libvirt.unix.manage for
unix-process:6450:77874 [python
/usr/share/virt-manager/virt-manager.py] (owned by unix-user:jrc)
which suggests that the polkit authentication may have been sucessful.
However, there are also a large number of messages of the form:
2013-12-19T10:26:26.783822+00:00 skylon libvirtd[3432]: Cannot create
route - destination and gw are both 0/0
2013-12-19T10:26:26.785289+00:00 skylon libvirtd[3432]: Cannot create
route from netlink message: No such file or directory
Any suggestions as to what I need to do to fix this?
I saw something like what you describe in 12.3 and KVM awhile back.
May not help you, but my problems were resolved by
Running “zypper up” to get all latest updates before attempting to launch any kind of virtualization (patching is insufficient)
Force re-install (or the alternative uninstall/re-install) virtualization components (followed by zypper up)
Knock on wood, problems never had to be reported since none persisted so I felt were “individual” issues.
I seem to remember seeing similar syslog issues about being “unable to connect to local server”
Of course, I also went through searching for dependency services which might not have started but didn’t find any so IMO although it might still warrant a search I felt my efforts at the time were a waste of time.
I’m just hitting the same issue, after updating the machine with ‘zypper up’. (Previous one was on 2014-02-12)
There was one dependency conflict though, which might have something to do with it:
#### YaST2 conflicts list - generated 2014-03-20 19:05:32 ####
nothing provides grub2-x86_64-xen needed by vm-install-0.8.9-202.1.x86_64
] do not install vm-install-0.8.9-202.1.x86_64
] break vm-install-0.8.9-202.1.x86_64 by ignoring some of its dependencies
#### YaST2 conflicts list END ###
This is what I see in /var/log/messages after a ‘rclibvirtd restart’ and after starting the ‘virtual machine manager’:
2014-03-20T20:13:05.243315+01:00 vmhost systemd[1]: Cannot add dependency job for unit xencommons.service, ignoring: Unit xencommons.service failed to load: No such file or directory.
2014-03-20T20:13:05.243716+01:00 vmhost systemd[1]: Stopping Virtualization daemon...
2014-03-20T20:13:05.248053+01:00 vmhost systemd[1]: Starting Virtualization daemon...
2014-03-20T20:13:05.269466+01:00 vmhost systemd[1]: Started Virtualization daemon.
2014-03-20T20:13:05.349532+01:00 vmhost libvirtd[8016]: libvirt version: 1.2.2
2014-03-20T20:13:05.349882+01:00 vmhost libvirtd[8016]: Configured security driver "none" disables default policy to create confined guests
2014-03-20T20:13:34.543386+01:00 vmhost polkitd[1297]: Operator of unix-session:4 successfully authenticated as unix-user:root to gain TEMPORARY authorization for action org.libvirt.unix.manage for unix-process:8104:239704 [/usr/bin/python2 -tt /usr/share/virt-manager/virt-manager] (owned by unix-user:wilfred)
2014-03-20T20:20:17.868274+01:00 vmhost libvirtd[8016]: End of file while reading data: Input/output error
I’m already using the visualization repository and using qemu-kvm…
Can confirm !
It worked with the previous version vm-install-0.8.7-199.1
from the virtualization repository for me.
However, upgrading to version
vm-install-0.8.9-202.1
results in the error you describe.
I think SuSE has to do something about it.
(It somehow disappointing that one cannot rely on the consistency of the package bundling in the virtualization repo with the standard repos of Opensuse.)
But is your virtual machine manager still working? That’s my main problem.
I think SuSE has to do something about it.
(It somehow disappointing that one cannot rely on the consistency of the package bundling in the virtualization repo with the standard repos of Opensuse.)
See a comment on the bug I referenced in my previous post. They regard the virtualization repo as “bleeding edge”. If that is the case, why isn’t it marked as such? The name “Virtualization” doesn’t suggest any thing like that, and it’s a repository for a release version, not Factory! …
Today’s ‘zypper up’ fixed the dependency conflict. But the “Error polling connection ‘qemu:///system’: An error occurred, but the cause is unknown” remains when I start the virtual machine manager…
Sorry for a late answer. Actually, I did not test that. It may take some time, because I do not want to expose my productive KVM server into danger. So I have to make a copy of that machine or try it on a different Opensuse 13.1 installation. I come back when I have some results.
Some minutes ago I upgraded all virt-packages to the latest versions from the virtualization repository on an Opensuse 13.1 (x86_64) KVM host with the latest kernel from the upgrade repo. I used again “qemu-kvm” instead of “kvm”. I had some old KVM guests there with Opensuse 11.4 and 12.2. I could start virt-manager and from there I could also start the KVM guests. In addition it seems that I can install a new machine. So, strange … here it seems to work now.
wvv:
Just as an experiment : What happens if you deactivate Apparmor ? I remember that I had problems with Apparmor on the KVM host after the upgrade to OS 13.1. I had to uninstall and reinstall packages to get some services as Samba working. Especially the “apparmor-profiles” RPM had to be uninstalled and reinstalled. A simple update did not help.
There are Apparmor profiles for libvirtd and libvirt.virt-aa-helper in the default state “enforced”.
Apparmor was actually deactivated yesterday when I upgraded everything from the virtualization repo and tested virt-manager successfully. I activated Apparmor today. There seems to be no difference - but as I said it is a completely un- and reinstalled Apparmor with latest profiles.
I don’t know if this is connected but I have been trying to use xen-4.4.0_08-308.4 from the Virtualization repository and openSUSE 13.1 but haven’t managed to get it to work. I have Apparmor disabled. In YaST -> Software Management -> Repositories I switched system packages to the versions in repository *Virtualization. *I installed the Xen packages via YaST -> Virtualization -> Install Hypervisor and Tools. Rebooted to Xen and attempted to create a virtual machine using YaST -> Virtualization -> Create Virtual Machines for Xen and KVM. Result: Error polling connection ‘xen:///’: An error occurred, but the cause is unknown.
I then tried** virsh -c xen:/// list** which failed because it couldn’t find /usr/lib64/pkcs11/gnome-keyring-pkcs11.so. Somehow gnome-keyring-3.10.1-1.1.i586 had been installed not gnome-keyring-3.10.1-1.1.x86_64. I installed the x86_64 version which allowed **virsh -c xen:/// list **to run without error. However, all attempts to create a virtual machine using YaST -> Virtualization -> Create Virtual Machines for Xen and KVM still result in Error polling connection ‘xen:///’: An error occurred, but the cause is unknown.
I then tried
# virsh -c qemu:///system list
error: failed to connect to the hypervisor
error: no connection driver available for qemu:///system
#
I found these lines in /var/log/messages:
2014-03-27T15:22:56.105828+00:00 skylon libvirtd[5409]: End of file while reading data: Input/output error
2014-03-27T15:33:48.087493+00:00 skylon libvirtd[5409]: no connection driver available for qemu:///system
2014-03-27T15:33:48.092253+00:00 skylon libvirtd[5409]: End of file while reading data: Input/output error
Noticed that the file /usr/lib64/libvirt/connection-driver/libvirt_driver_qemu.so was missing so I installed** libvirt-daemon-driver-qemu-1.2.2-379.2.x86_64**. A missing dependency somewhere?
Now /usr/sbin/libvirtd is failing:
# libvirtd -l
2014-03-27 17:26:09.886+0000: 8365: info : libvirt version: 1.2.2
2014-03-27 17:26:09.886+0000: 8365: warning : virDriverLoadModule:73 : Module /usr/lib64/libvirt/connection-driver/libvirt_driver_lxc.so not accessible
2014-03-27 17:26:09.887+0000: 8365: warning : virDriverLoadModule:73 : Module /usr/lib64/libvirt/connection-driver/libvirt_driver_uml.so not accessible
2014-03-27 17:26:09.887+0000: 8365: warning : virDriverLoadModule:73 : Module /usr/lib64/libvirt/connection-driver/libvirt_driver_vbox.so not accessible
2014-03-27 17:26:10.239+0000: 8376: error : virGetUserID:908 : invalid argument: Failed to parse user 'qemu'
2014-03-27 17:26:10.239+0000: 8376: error : virStateInitialize:749 : Initialization of QEMU state driver failed: invalid argument: Failed to parse user 'qemu'
2014-03-27 17:26:10.239+0000: 8376: error : daemonRunStateInit:920 : Driver state initialization failed
#
Assume I can ignore the warnings but not sure how to work around the errors …
The user qemu didn’t exist. It is created by the preinstall scriptlet in qemu-1.7.90-221.1.x86_64 which I have now installed.
However, this takes me back to YaST -> Virtualization -> Create Virtual Machines for Xen and KVM producing Error polling connection ‘xen:///’: An error occurred, but the cause is unknown. The following appears in **/var/log/messages *2014-03-27T22:36:54.235092+00:00 skylon libvirtd[5464]: End of file while reading data: Input/output error. This page libvirt: Failed to connect to the hypervisor suggests that error message is because * the user you are using to access the server does not belong to the proper group. There is a **libvirt **group with no members. This page libvirt: How to configure management access to libvirt through SSH suggests that *openSUSE 11.2 onwards uses PolicyKit for management access to libvirt.
Hello,
i defined manually the user qemu as member of group root and qemu (id group 80); It worked on Opensuse 12.3.and 13.1.(tumbleweed)
I have now a new system and I have not yet be able to restore the VM.
I cannot say much about Xen as I do no use it any more. I did in the past, but found the installation process with KVM much simpler the last year. And paravirtualized Xen was more difficult to test as you had to boot a special XEN kernel environment. This can induce further possible problems. And right now there is again a dependency error with the latest packages in the virtualization repo … [KVM with virtio drivers provides a sufficient performance - though I admit that XEN paravirtualized may be a bit better].
Just as a suggestion and for comparison reasons: Maybe it helps to test KVM first to clarify general libvirt/qemu-installation problems and then switch to Xen ? You could a least test whether virt-manager and the creation of virtual KVM machines is working in a standard kernel environment. I have two productive KVM servers working under Opensuse 13.1 x86_64 - on different hardware (CPUs: Q9550 and i7 950). One with the packages that were delivered together with the “4.4.0_08-308.4”-xen packages you want to use. See the package list at the end. I just used YaST to install basic packages and to provide the bridged network interfaces br0 and br1 (for eth0 and eth1). Afterwards I could start and use virt-manager directly from the command line. Then I could also setup new machines or start already existing KVM machines.
For a comparison of involved users and groups :
users:
qemu | member of groups: kvm, qemu
**
groups:
** kvm | has member qemu [on one machine I have added root - I don’t remember why - should not at all be a requirement]
libvirt | no members
qemu | has member qemu
Today’s ‘zypper up’ (+reboot) finally fixed this problem. My previous ‘zypper up’ was 1 week ago, so an update of the last week in the Virtualization repo probably fixed it.