openSUSE 13.1 -> 13.2 upgrade issues with xen, libvirt, and virt-manager.

English Virtualization
1

Greetings!

This thread is a followup to a previous thread, picking up from where I left off post the next openSUSE upgrade. Here is a link to the previous thread; https://forums.opensuse.org/showthread.php/501926-openSUSE-12-3-gt-13-1-upgrade-XEN-unable-to-connect-VMM.

After the upgrade I went poking around. Found virt-manager showing 2 of my vm’s running, and 1 not. Next post we’ll look closer to the issues with libvirt and virt-manager.

So I went back to what worked before;


# xl create /etc/xen/vm/Win7
Parsing config from /etc/xen/vm/Win7
libxl: error: libxl_create.c:619:libxl__domain_make: cannot change hotplug execution option once set, please shutdown all guests before changing it
libxl: error: libxl_create.c:762:initiate_domain_create: cannot make domain: -3
libxl: error: libxl_dm.c:1494:kill_device_model: unable to find device model pid in /local/domain/5/image/device-model-pid
libxl: error: libxl.c:1442:libxl__destroy_domid: libxl__destroy_device_model failed for 5

which means there is something wrong with my config.


cat /etc/xen/vm/Win7
name="Win7"
description="Windows 7 Professional"
uuid="a6b238f8-3daa-6595-38f5-aa887c08003e"
memory=2048
maxmem=2048
vcpus=2
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
localtime=1
keymap="en-us"


builder="hvm"
boot="c"
disk= 'phy:/dev/server/Win7,hda,w', 'phy:/dev/sr0,hdc:cdrom,r', ]
vif= 'mac=00:16:3e:20:c2:c8,bridge=xenbr0,model=rtl8139', ]






stdvga=1
videoram=16
vnc=1
vncunused=1
soundhw="ac97"


viridian=0
usb=1
acpi=1
pae=1


usbdevice='tablet'


serial="pty"

So that’s where I’m starting today.

Wil on a Dell

Precision T5500 Workstation

2

Sorry, let me add some basics.

uname -a

Linux VERN 3.16.6-2-xen #1 SMP Mon Oct 20 13:47:22 UTC 2014 (feb42ea) x86_64 x86_64 x86_64 GNU/Linux

rpm -qa | egrep -i ‘xen|qemu|virt’ | sort

grub2-x86_64-xen-2.02~beta2-20.5.1.x86_64
kernel-xen-3.11.10-21.1.x86_64
kernel-xen-3.11.6-4.1.x86_64
kernel-xen-3.16.6-2.1.x86_64
libvirt-1.2.9-1.3.x86_64
libvirt-client-1.2.9-1.3.x86_64
libvirt-daemon-1.2.9-1.3.x86_64
libvirt-daemon-config-network-1.2.9-1.3.x86_64
libvirt-daemon-config-nwfilter-1.2.9-1.3.x86_64
libvirt-daemon-driver-interface-1.2.9-1.3.x86_64
libvirt-daemon-driver-libxl-1.2.9-1.3.x86_64
libvirt-daemon-driver-lxc-1.2.9-1.3.x86_64
libvirt-daemon-driver-network-1.2.9-1.3.x86_64
libvirt-daemon-driver-nodedev-1.2.9-1.3.x86_64
libvirt-daemon-driver-nwfilter-1.2.9-1.3.x86_64
libvirt-daemon-driver-qemu-1.2.9-1.3.x86_64
libvirt-daemon-driver-secret-1.2.9-1.3.x86_64
libvirt-daemon-driver-storage-1.2.9-1.3.x86_64
libvirt-daemon-driver-uml-1.2.9-1.3.x86_64
libvirt-daemon-driver-vbox-1.2.9-1.3.x86_64
libvirt-daemon-driver-xen-1.2.9-1.3.x86_64
libvirt-daemon-lxc-1.2.9-1.3.x86_64
libvirt-daemon-xen-1.2.9-1.3.x86_64
libvirt-doc-1.2.9-1.3.x86_64
libvirt-glib-1_0-0-0.1.9-2.1.4.x86_64
libvirt-login-shell-1.2.9-1.3.x86_64
libvirt-python-1.2.9-1.2.x86_64
patterns-openSUSE-xen_server-20141007-2.1.x86_64
perl-Sys-Virt-1.2.9-1.1.x86_64
qemu-2.1.0-2.9.x86_64
qemu-block-curl-2.1.0-2.9.x86_64
qemu-ipxe-1.0.0-2.9.noarch
qemu-ksm-2.1.0-2.9.x86_64
qemu-seabios-1.7.5-2.9.noarch
qemu-sgabios-8-2.9.noarch
qemu-tools-2.1.0-2.9.x86_64
qemu-vgabios-1.7.5-2.9.noarch
qemu-x86-2.1.0-2.9.x86_64
soprano-backend-virtuoso-2.9.4-2.1.4.x86_64
typelib-1_0-LibvirtGLib-1_0-0.1.9-2.1.4.x86_64
virt-install-1.0.1-14.4.1.noarch
virt-manager-1.0.1-14.4.1.noarch
virt-manager-common-1.0.1-14.4.1.noarch
virtuoso-drivers-6.1.6-9.1.3.x86_64
virtuoso-server-6.1.6-9.1.3.x86_64
virt-utils-1.1.9-11.1.2.x86_64
virt-viewer-1.0-2.1.4.x86_64
xen-4.4.1_06-3.3.x86_64
xen-doc-html-4.4.1_06-3.3.x86_64
xen-kmp-desktop-4.3.0_14_k3.11.6_4-1.3.x86_64
xen-kmp-desktop-4.3.2_02_k3.11.10_21-27.1.x86_64
xen-kmp-desktop-4.4.1_06_k3.16.6_2-3.3.x86_64
xen-libs-32bit-4.4.1_06-3.3.x86_64
xen-libs-4.4.1_06-3.3.x86_64
xen-tools-4.4.1_06-3.3.x86_64
xen-xend-tools-4.4.1_06-3.3.x86_64

3

Filtered on xen in syslog

2014-11-07T22:58:57.628290-05:00 VERN kernel: 20.374679] xenbr0: port 1(eth0) entered forwarding state
2014-11-07T22:58:57.628292-05:00 VERN kernel: 20.374693] xenbr0: port 1(eth0) entered forwarding state
2014-11-07T22:58:57.628294-05:00 VERN kernel: 20.374728] IPv6: ADDRCONF(NETDEV_CHANGE): xenbr0: link becomes ready
2014-11-07T22:58:57.633562-05:00 VERN avahi-daemon[1142]: Joining mDNS multicast group on interface xenbr0.IPv4 with address 192.168.1.3.
2014-11-07T22:58:57.633931-05:00 VERN avahi-daemon[1142]: New relevant interface xenbr0.IPv4 for mDNS.
2014-11-07T22:58:57.634179-05:00 VERN avahi-daemon[1142]: Registering new address record for 192.168.1.3 on xenbr0.IPv4.
2014-11-07T22:58:58.744525-05:00 VERN avahi-daemon[1142]: Joining mDNS multicast group on interface xenbr0.IPv6 with address fe80::225:64ff:fe94:613b.
VERN avahi-daemon[1142]: New relevant interface xenbr0.IPv6 for mDNS.
2014-11-07T22:58:58.745375-05:00 VERN avahi-daemon[1142]: Registering new address record for fe80::225:64ff:fe94:613b on xenbr0.*.
2014-11-07T22:58:59.229939-05:00 VERN logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/768
2014-11-07T22:58:59.280893-05:00 VERN logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/1/5632
2014-11-07T22:58:59.652119-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/1/768/physical-device fd:1 to xenstore.
2014-11-07T22:58:59.660836-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/1/768/hotplug-status connected to xenstore.
2014-11-07T22:58:59.725976-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/1/5632/physical-device b:0 to xenstore.
2014-11-07T22:58:59.731878-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/1/5632/hotplug-status connected to xenstore.
2014-11-07T22:59:00.553442-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/console/1/0
2014-11-07T22:59:00.803183-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vfb/1/0
2014-11-07T22:59:00.815637-05:00 VERN logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/1/768
2014-11-07T22:59:00.818733-05:00 VERN logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/1/5632
2014-11-07T22:59:00.844758-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/1/768
2014-11-07T22:59:00.847625-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/1/5632
2014-11-07T22:59:08.071772-05:00 VERN wicked[1296]: xenbr0 up
2014-11-07T22:59:08.944128-05:00 VERN logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/2/51712
2014-11-07T22:59:08.978388-05:00 VERN logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/2/51728
2014-11-07T22:59:09.066576-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/2/51712/physical-device fd:3 to xenstore.
2014-11-07T22:59:09.188584-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/2/51712/hotplug-status connected to xenstore.
2014-11-07T22:59:09.198518-05:00 VERN logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/2/0
2014-11-07T22:59:09.257975-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/2/51728/node /dev/loop0 to xenstore.
2014-11-07T22:59:09.260208-05:00 VERN kernel: 32.007362] xenbr0: port 2(vif2.0) entered forwarding state
2014-11-07T22:59:09.263136-05:00 VERN logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif2.0, bridge xenbr0.
2014-11-07T22:59:09.266203-05:00 VERN logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/2/0/hotplug-status connected to xenstore.
2014-11-07T22:59:09.266990-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/2/51728/physical-device 7:0 to xenstore.
2014-11-07T22:59:09.272425-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/2/51728/hotplug-status connected to xenstore.
2014-11-07T22:59:18.784010-05:00 VERN logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/3/51712
2014-11-07T22:59:18.840478-05:00 VERN logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/3/51728
2014-11-07T22:59:18.934062-05:00 VERN logger: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/3/0
2014-11-07T22:59:18.946302-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/3/51712/physical-device fd:2 to xenstore.
2014-11-07T22:59:18.952434-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/3/51712/hotplug-status connected to xenstore.
2014-11-07T22:59:18.988216-05:00 VERN kernel: 41.733988] xenbr0: port 3(vif3.0) entered forwarding state
2014-11-07T22:59:18.988218-05:00 VERN kernel: 41.734001] xenbr0: port 3(vif3.0) entered forwarding state
2014-11-07T22:59:18.990423-05:00 VERN logger: /etc/xen/scripts/vif-bridge: Successful vif-bridge online for vif3.0, bridge xenbr0.
2014-11-07T22:59:18.994516-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/3/51728/node /dev/loop1 to xenstore.
2014-11-07T22:59:18.994946-05:00 VERN logger: /etc/xen/scripts/vif-bridge: Writing backend/vif/3/0/hotplug-status connected to xenstore.
2014-11-07T22:59:19.035391-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/3/51728/physical-device 7:1 to xenstore.
2014-11-07T22:59:19.173667-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/3/51728/hotplug-status connected to xenstore.
2014-11-07T22:59:31.635487-05:00 VERN xendomains[2303]: Restoring Xen domains: Citadel Webster
2014-11-07T22:59:31.685106-05:00 VERN xendomains[2303]: Starting auto Xen domains: Citadel(skip) Webster(skip) Win7(skip)…done
2014-11-07T23:04:16.406582-05:00 VERN logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/4/768
2014-11-07T23:04:16.432129-05:00 VERN logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/4/5632
2014-11-07T23:04:16.537639-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/4/768/physical-device fd:1 to xenstore.
2014-11-07T23:04:16.544778-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/4/768/hotplug-status connected to xenstore.
2014-11-07T23:04:16.631106-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/4/5632/physical-device b:0 to xenstore.
2014-11-07T23:04:16.638425-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/4/5632/hotplug-status connected to xenstore.
2014-11-07T23:04:17.109658-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/console/4/0
2014-11-07T23:04:17.134534-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vfb/4/0
2014-11-07T23:04:17.147197-05:00 VERN logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/4/768
2014-11-07T23:04:17.149589-05:00 VERN logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/4/5632
2014-11-07T23:04:17.180351-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/4/768
2014-11-07T23:04:17.182025-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/4/5632
2014-11-08T06:13:48.483403-05:00 VERN systemd-udevd[8483]: failed to execute ‘/usr/lib/udev/socket:/org/xen/xend/udev_event’ ‘socket:/org/xen/xend/udev_event’: No such file or directory
2014-11-08T06:13:49.868623-05:00 VERN systemd-udevd[8486]: failed to execute ‘/usr/lib/udev/socket:/org/xen/xend/udev_event’ ‘socket:/org/xen/xend/udev_event’: No such file or directory
2014-11-08T07:12:29.285910-05:00 VERN logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/12/768
2014-11-08T07:12:29.317358-05:00 VERN logger: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/12/5632
2014-11-08T07:12:29.407485-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/12/768/physical-device fd:1 to xenstore.
2014-11-08T07:12:29.413766-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/12/768/hotplug-status connected to xenstore.
2014-11-08T07:12:29.500373-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/12/5632/physical-device b:0 to xenstore.
2014-11-08T07:12:29.506254-05:00 VERN logger: /etc/xen/scripts/block: Writing backend/vbd/12/5632/hotplug-status connected to xenstore.
2014-11-08T07:12:30.076428-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/console/12/0
2014-11-08T07:12:30.101087-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vfb/12/0
2014-11-08T07:12:30.113153-05:00 VERN logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/12/768
2014-11-08T07:12:30.115517-05:00 VERN logger: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/12/5632
2014-11-08T07:12:30.145851-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/12/5632
2014-11-08T07:12:30.148263-05:00 VERN logger: /etc/xen/scripts/xen-hotplug-cleanup: XENBUS_PATH=backend/vbd/12/768
2014-11-08T08:08:46.807091-05:00 VERN systemd-udevd[26945]: failed to execute ‘/usr/lib/udev/socket:/org/xen/xend/udev_event’ ‘socket:/org/xen/xend/udev_event’: No such file or directory
2014-11-08T08:09:28.883718-05:00 VERN systemd-udevd[27101]: failed to execute ‘/usr/lib/udev/socket:/org/xen/xend/udev_event’ ‘socket:/org/xen/xend/udev_event’: No such file or directory
014-11-08T08:09:28.885567-05:00 VERN systemd-udevd[27102]: failed to execute ‘/usr/lib/udev/socket:/org/xen/xend/udev_event’ ‘socket:/org/xen/xend/udev_event’: No such file or directory
2014-11-08T08:09:28.887152-05:00 VERN systemd-udevd[27103]: failed to execute ‘/usr/lib/udev/socket:/org/xen/xend/udev_event’ ‘socket:/org/xen/xend/udev_event’: No such file or directory
2014-11-08T08:14:37.977748-05:00 VERN systemd-udevd[27883]: failed to execute ‘/usr/lib/udev/socket:/org/xen/xend/udev_event’ ‘socket:/org/xen/xend/udev_event’: No such file or directory
2014-11-08T08:14:37.980233-05:00 VERN systemd-udevd[27884]: failed to execute ‘/usr/lib/udev/socket:/org/xen/xend/udev_event’ ‘socket:/org/xen/xend/udev_event’: No such file or directory
2014-11-08T08:14:38.969307-05:00 VERN systemd-udevd[27887]: failed to execute ‘/usr/lib/udev/socket:/org/xen/xend/udev_event’ ‘socket:/org/xen/xend/udev_event’: No such file or directory
2014-11-08T08:14:38.971324-05:00 VERN systemd-udevd[27888]: failed to execute ‘/usr/lib/udev/socket:/org/xen/xend/udev_event’ ‘socket:/org/xen/xend/udev_event’: No such file or directory
2014-11-08T09:15:43.619874-05:00 VERN systemd[1]: xend.service: Supervising process 1316 which is not our child. We’ll most likely not notice when it exits.
2014-11-08T09:15:43.864082-05:00 VERN systemd[1]: xend.service: Supervising process 1316 which is not our child. We’ll most likely not notice when it exits.

4

Some progress to report. This is pretty much just a home setup, to learn where I can.

2 pv’s and 1 hvm running under xl, which is where I sort of left off.

Still getting an error on re/starting libvirtd;

systemctl status -l libvirtd

libvirtd.service - Virtualization daemon
Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
Active: active (running) since Sat 2014-11-08 21:52:44 EST; 9s ago
Docs: man:libvirtd(8)
http://libvirt.org
Main PID: 439 (libvirtd)
CGroup: /system.slice/libvirtd.service
└─439 /usr/sbin/libvirtd --listen

Nov 08 21:52:44 VERN libvirtd[439]: libvirt version: 1.2.9
Nov 08 21:52:44 VERN libvirtd[439]: internal error: Child process (/usr/sbin/xend status) unexpected exit status 3
Nov 08 21:52:44 VERN libvirtd[439]: Failed to query host NUMA topology, disabling NUMA capabilities
Nov 08 21:52:44 VERN libvirtd[439]: Failed to get host CPU
Nov 08 21:52:44 VERN libvirtd[439]: Failed to query host NUMA topology, disabling NUMA capabilities
Nov 08 21:52:44 VERN libvirtd[439]: Failed to query host NUMA topology, disabling NUMA capabilities

Then there is this that bothers me in virt-manager on the localhost Connection Details.

http://www.go2wha.com/vmmlocaldetails.jpeg

Since my bridge interface is;

brctl show

bridge name bridge id STP enabled interfaces
xenbr0 8000.00256494613b no eth0
vif13.0
vif13.0-emu
vif2.0
vif3.0

Where can I change this?

Any suggestions?

Wil

5

Noticed an update today for virt-manager. And I’ve noticed some changes. most noticeable was the xend daemon running again.

ps -A | egrep -i ‘xen|qemu|virt’ | sort

121 ? 00:00:00 xenwatch
122 ? 00:00:00 xenbus
1245 ? 00:00:00 xen_pciback_wor
1276 ? 00:00:00 xenstored
1285 ? 00:00:00 xenconsoled
1332 ? 00:00:00 qemu-system-i38
1362 ? 00:00:00 xend
1366 ? 00:00:01 xend
2163 ? 00:00:00 libvirtd
2908 ? 00:00:00 qemu-system-i38
3026 ? 00:01:32 qemu-system-i38
3190 ? 00:00:01 qemu-system-i38

When opening virt-manager as a user, I no longer get prompted for admin password, it also errors out as follows.

Unable to connect to libvirt.

Failed to connect socket to ‘/var/run/libvirt/libvirt-sock’: Permission denied

Verify that:

  • A Xen host kernel was booted
  • The Xen service has been started

In Details:
Unable to connect to libvirt.

Failed to connect socket to ‘/var/run/libvirt/libvirt-sock’: Permission denied

Verify that:

  • A Xen host kernel was booted
  • The Xen service has been started

Libvirt URI is: xen:///

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/connection.py”, line 1054, in _open_thread
self._backend.open(self._do_creds_password)
File “/usr/share/virt-manager/virtinst/connection.py”, line 158, in open
open_flags)
File “/usr/lib64/python2.7/site-packages/libvirt.py”, line 105, in openAuth
if ret is None:raise libvirtError(‘virConnectOpenAuth() failed’)
libvirtError: Failed to connect socket to ‘/var/run/libvirt/libvirt-sock’: Permission denied

However if I launch virt-manager as root from a shell or when logged in as root, it connects and shows the running vm’s that I started manually. However if I try to connect to a running machine I get the following;

Error launching details: ‘gi.repository.Vte’ object has no attribute ‘TerminalCursorBlinkMode’

Details:
rror launching details: ‘gi.repository.Vte’ object has no attribute ‘TerminalCursorBlinkMode’

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/engine.py”, line 828, in _show_vm_helper
details.activate_default_page()
File “/usr/share/virt-manager/virtManager/details.py”, line 1405, in activate_default_page
self.activate_default_console_page()
File “/usr/share/virt-manager/virtManager/details.py”, line 1399, in activate_default_console_page
self.console.activate_default_console_page()
File “/usr/share/virt-manager/virtManager/console.py”, line 1619, in activate_default_console_page
self._show_serial_tab(name, serialidx)
File “/usr/share/virt-manager/virtManager/console.py”, line 1678, in _show_serial_tab
serial = vmmSerialConsole(self.vm, target_port, name)
File “/usr/share/virt-manager/virtManager/serialcon.py”, line 319, in init
self.init_terminal()
File “/usr/share/virt-manager/virtManager/serialcon.py”, line 329, in init_terminal
self.terminal.set_cursor_blink_mode(Vte.TerminalCursorBlinkMode.ON)
File “/usr/lib64/python2.7/site-packages/gi/module.py”, line 320, in getattr
return getattr(self._introspection_module, name)
File “/usr/lib64/python2.7/site-packages/gi/module.py”, line 139, in getattr
self.name, name))
AttributeError: ‘gi.repository.Vte’ object has no attribute ‘TerminalCursorBlinkMode’

libvirtd started in this condition.

systemctl status -l libvirtd

libvirtd.service - Virtualization daemon
Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
Active: active (running) since Mon 2014-11-10 22:52:42 EST; 9min ago
Docs: man:libvirtd(8)
http://libvirt.org
Main PID: 2163 (libvirtd)
CGroup: /system.slice/libvirtd.service
└─2163 /usr/sbin/libvirtd --listen

Nov 10 22:52:43 VERN libvirtd[2163]: Failed to query host NUMA topology, disabling NUMA capabilities
Nov 10 22:52:43 VERN libvirtd[2163]: Failed to get host CPU
Nov 10 22:52:43 VERN libvirtd[2163]: Failed to query host NUMA topology, disabling NUMA capabilities

And xend:

systemctl status -l xend

xend.service - Xend - Starts and stops the Xen management daemon
Loaded: loaded (/usr/lib/systemd/system/xend.service; enabled)
Active: active (running) since Mon 2014-11-10 22:52:29 EST; 50min ago
Process: 1212 ExecStart=/usr/sbin/xend start (code=exited, status=0/SUCCESS)
Process: 1178 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
Main PID: 1366 (xend)
CGroup: /system.slice/xend.service
├─1362 /usr/bin/python /usr/sbin/xend start
├─1364 blktapctrl
└─1366 /usr/bin/python /usr/sbin/xend start

Nov 10 22:52:29 VERN systemd[1]: xend.service: Supervising process 1366 which is not our child. We’ll most likely not notice when it exits.

After the failed attempt of virt-manager launched as a user, and again as root from libvirtd;

systemctl status -l libvirtd

libvirtd.service - Virtualization daemon
Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
Active: active (running) since Mon 2014-11-10 22:52:42 EST; 45min ago
Docs: man:libvirtd(8)
http://libvirt.org
Main PID: 2163 (libvirtd)
CGroup: /system.slice/libvirtd.service
└─2163 /usr/sbin/libvirtd --listen

Nov 10 23:25:33 VERN wicked[4329]: ifcfg-eth0: ignoring unspecified ip address 0.0.0.0
Nov 10 23:25:33 VERN wicked[4337]: ifcfg-eth0: ignoring unspecified ip address 0.0.0.0
Nov 10 23:25:33 VERN wicked[4345]: ifcfg-eth0: ignoring unspecified ip address 0.0.0.0
Nov 10 23:25:33 VERN wicked[4353]: ifcfg-eth0: ignoring unspecified ip address 0.0.0.0
Nov 10 23:25:33 VERN wicked[4361]: ifcfg-eth0: ignoring unspecified ip address 0.0.0.0
Nov 10 23:25:33 VERN libvirtd[2163]: this function is not supported by the connection driver: virConnectListAllDomains
Nov 10 23:25:33 VERN libvirtd[2163]: this function is not supported by the connection driver: virDomainGetMetadata
Nov 10 23:25:33 VERN libvirtd[2163]: this function is not supported by the connection driver: virDomainMemoryStats
Nov 10 23:25:34 VERN wicked[4414]: ifcfg-eth0: ignoring unspecified ip address 0.0.0.0
Nov 10 23:34:17 VERN libvirtd[2163]: this function is not supported by the connection driver: virDomainListAllSnapshots

Wil

6

Well I’ve been seeing little patches/updates coming down through the system, and some things have changed. After rebooting the system, xend no longer shows the previously posted error. :slight_smile:

I know there are some .xml files that we’re a part of this configuration. Is there say a virsh command that would back port to these files so everything is in sync with what’s running?

Wil

7

I have a lot issues with openSuSe 13.2 and Virtualization under LXC, its seems that networking is completely broken !
When trying to attach default network(which is running) got following error:

Error starting domain: An error occurred, but the cause is unknown

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/asyncjob.py”, line 125, in tmpcb
callback(*args, **kwargs)
File “/usr/share/virt-manager/virtManager/domain.py”, line 1358, in startup
self._backend.create()
File “/usr/lib64/python2.7/site-packages/libvirt.py”, line 1003, in create
if ret == -1: raise libvirtError (‘virDomainCreate() failed’, dom=self)
libvirtError: An error occurred, but the cause is unknown

When starting the LXC containt using Libviirt / Virtuam Machine Manager without any interfaces it can see all interfaces from the main operating system.

It sucks, for know I stick with opensuse 13.1 and libvirt 1.1.2.

This distribution in my opinion is the worst ever! Including ****** Grub2 theme (bleh) plus a lot of bugs!

8

You should start a new thread when posting a new topic.
Hijacking an existing thread won’t get you anywhere…

TSU

9

WilNix, TSU… have you guys been able to make any more headway? I know it’s only been a week since your last post, but this thread and the previous one helped me out tremendously.

I’m in a similar boat as you, but slightly closer to the goal (I think):

  • I upgraded from a 12.3 working system with dom0 and 1 domU.
  • It used xend and libvirtd happily
  • Took me a while to figure out xm & xend were deprecated, to learn of the existence of xl and to figure out what xencommons does.
  • I’m at a point now where xencommons et al. start up and libvirtd starts up, all without errors.
  • However, doing virsh list gives me back nothing, not even the dom0.
  • “xl list” shows the running dom0

Thanks to one of your posts, I used “xl create” on my old server configuration and successfully started the VM.

Now dom0 and domU are running and show up in “xl list”, but “virsh list” is still empty.

Here’s where it gets interesting. Back in virt-manager, I’m staring at a blank list. So I created a test VM image and voila. Like magic the new VM was created without error.

Strangely, it is now the only thing that appears in virt-man or in virsh list. But “xl list” shows all 3: dom0, the old domU and the new domU.

So xl seems to be working just fine for me, but something is missing that prevents the older servers from showing up in libvirt clients.

Is there another migration that needs to be run?

G

10

Glad I/we helped!

One can hope;-) But certainly shouldn’t hurt to put our heads together on it.

Very good!

  • Did you incrementally upgrade to 13.2 or leap to it from your working version?
  • Did you have to edit anything to get xencommons and (?) et al to startup? especially libvirtd running without errors? (I never looked at xencommons since xen appeared to work with the xl commands.)

However I do see my vm’s in virsh.

I also am seeing my xl launched vm’s in virt-manager.

No other progress since my last post.

Errors pretty much remain the same.

Wil

11

Yes, I made sure to do the dist upgrades incrementally… 12.3 -> 13.1 -> 13.2.

When I was at 13.1 I tested the hypervisor and got the infamous “User qemu does not exist”. Just before foolishly installing kvm to get this user as posts suggested, I did the final 13.1 -> 13.2 upgrade and the problem went away and was replaced with libvirtd failing to start due to what I thought had to do with “NUMA” errors until I learned that was a red herring.

In my haste to get a mission critical VM back up, I rushed to install xen-xend-tools package which provides xend all the while thinking, “How could the opensuse maintainers be so daft as to leave out the xen daemon!!”. With xend running I was able to get the VMs started as well as libvirtd AND virsh list showed both dom0 or that original domU.

Coming back to the problem with a little more time on my hands I learned all about the deprecation of xend/xm and the new world of xl and the fact that xencommons exists, I shut down everything and removed xen-xend-tools and when about getting xencommons and all the other xen* services (and libvirtd) started:

  • xencommons
  • xendomains
  • xen-watchdog
  • libvirtd

There wasn’t anything special I really needed to do to get all these working except understand that xencommons and xendomains are always in “status (exited)” when running a “service * status” on them due to the fact that they are really just wrappers to running other daemons. There was some trickiness in getting everything to start in the right order because I was doing it manually. I also think there was some **** from xend left behind so without wasting too much time applied the sledgehammer remedy and restarted the machine and all the services in the list above started up just fine.

So I’m still left here with the same problem… I can’t see dom0 and that one domU in virsh list. Any VM created after that shows just fine.

Another thing I tried was doing “Install VM Tools” in yast… not sure if this helped at all, but I guess it doesn’t hurt to try that. But I think I remember reading that you’ve already done so.

Anyway, the hunt continues.

G

12

Wil,

I went and re-read this thread and I’ve got a suggestion for you to try:

  1. Try stopping xend and then zypper remove xen-xend-tools.
  2. Use Yast or chkconfig --load to make sure the following services are set to start in runlevels 3 and 5:

  • xencommons

  • xendomains

  • xen-watchdog

  • libvirtd

  1. Reboot
  2. Run Yast and do the Install VM Tools (you might get some errors or a hung wizard like I did)
  3. Reboot again
  4. Now do a “service {service-name} status” on each of the above and make sure you don’t any errors.

Then try “xl list” and “virsh list” and let us know what happens.

G

13

Something else I just ran across:

The libxl driver only supports Xen >= 4.2. The legacy Xen driver should be used on earlier versions of Xen, or installations where the xend toolstack is used. In fact, if xend is running, the libxl driver won’t even load. So if you want to use the libxl driver but have xend running, xend must be shutdown followed by a restart of libvirtd to load the libxl driver. Note that if xend is not running, the legacy Xen driver will not load.

G

14 

# systemctl status xencommons
xencommons.service - Xencommons - Script to start and stop xenstored and xenconsoled
   Loaded: loaded (/usr/lib/systemd/system/xencommons.service; enabled)
   Active: active (exited) since Thu 2014-11-27 20:41:11 EST; 45min ago
  Process: 1078 ExecStart=/etc/init.d/xencommons start (code=exited, status=0/SUCCESS)
  Process: 1039 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
 Main PID: 1078 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/xencommons.service
           ├─1171 /usr/sbin/xenstored --pid-file /var/run/xenstored.pid
           ├─1185 /usr/sbin/xenconsoled --pid-file=/var/run/xenconsoled.pid
           └─1223 /usr/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xen...


Nov 27 20:41:08 VERN xenstored[1171]: Checking store ...
Nov 27 20:41:08 VERN xenstored[1171]: Checking store complete.
Nov 27 20:41:08 VERN xencommons[1078]: Starting C xenstored...
Nov 27 20:41:08 VERN xencommons[1078]: Setting domain 0 name and domid...
Nov 27 20:41:08 VERN xencommons[1078]: Starting xenconsoled...
Nov 27 20:41:08 VERN xencommons[1078]: Starting QEMU as disk backend for dom0

# systemctl status xendomains
xendomains.service - Xendomains - start and stop Xen VMs on boot and shutdown
   Loaded: loaded (/usr/lib/systemd/system/xendomains.service; enabled)
   Active: active (exited) since Thu 2014-11-27 20:41:22 EST; 52min ago
  Process: 1940 ExecStart=/etc/init.d/xendomains start (code=exited, status=0/SUCCESS)
  Process: 1924 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
 Main PID: 1940 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/xendomains.service


Nov 27 20:41:22 VERN xendomains[1940]: Restoring Xen domains:
Nov 27 20:41:22 VERN xendomains[1940]: ..done



# systemctl status xen-watchdog
xen-watchdog.service - Xen-watchdog - run xen watchdog daemon
   Loaded: loaded (/usr/lib/systemd/system/xen-watchdog.service; enabled)
   Active: active (running) since Thu 2014-11-27 20:41:08 EST; 54min ago
  Process: 1045 ExecStart=/usr/sbin/xenwatchdogd 30 15 (code=exited, status=0/SUCCESS)
 Main PID: 1046 (xenwatchdogd)
   CGroup: /system.slice/xen-watchdog.service
           └─1046 /usr/sbin/xenwatchdogd 30 15

# systemctl status -l libvirtd
libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Thu 2014-11-27 20:41:22 EST; 54min ago
     Docs: man:libvirtd(8)
           http://libvirt.org
 Main PID: 1930 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           └─1930 /usr/sbin/libvirtd --listen


Nov 27 20:41:23 VERN libvirtd[1930]: Failed to query host NUMA topology, disabling NUMA capabilities
Nov 27 20:41:23 VERN libvirtd[1930]: Failed to query host NUMA topology, disabling NUMA capabilities
Nov 27 20:41:23 VERN libvirtd[1930]: Failed to query host NUMA topology, disabling NUMA capabilities
Nov 27 21:02:40 VERN libvirtd[1930]: internal error: libxenlight failed to create new domain 'Webster'
Nov 27 21:03:26 VERN libvirtd[1930]: internal error: libxenlight failed to create new domain 'Citadel'
Nov 27 21:05:02 VERN libvirtd[1930]: internal error: libxenlight failed to create new domain 'Win7'

# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0 21715    16     r-----    1300.4

# virsh list
 Id    Name                           State
----------------------------------------------------

Cannot start existing vm’s as you can see from the libvirtd errors, though those entries were created when trying to start them with virsh. Attempting to start them with the xl command/s had them failing with what was looking like drive failures, or lack of hypervisor control.

I’m now gonna try and go back to xend to see if things go back to as they were.:wink:

Wil

15

Well to no avail.

Attempted to try xend again, and although all looks like it did, I cannot recreate the guests. Appears to be an unexpected inconsistency with the file system, dumps to single user mode and drops the vnc connection, and dies, on the pv’s. the hv win7 thing acts similarly but just keeps restarting till I destroy it.

Gone back to experimenting without xend, maybe someone can help with the errors?


xencommons.service - Xencommons - Script to start and stop xenstored and xenconsoled
   Loaded: loaded (/usr/lib/systemd/system/xencommons.service; enabled)
   Active: active (exited) since Fri 2014-11-28 10:10:25 EST; 4min 25s ago
  Process: 1089 ExecStart=/etc/init.d/xencommons start (code=exited, status=0/SUCCESS)
  Process: 1049 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
 Main PID: 1089 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/xencommons.service
           ├─1179 /usr/sbin/xenstored --pid-file /var/run/xenstored.pid
           ├─1194 /usr/sbin/xenconsoled --pid-file=/var/run/xenconsoled.pid
           └─1234 /usr/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile /var/run/qemu-dom0.pid


Nov 28 10:10:23 VERN xenstored[1179]: Checking store ...
Nov 28 10:10:23 VERN xenstored[1179]: Checking store complete.
Nov 28 10:10:23 VERN xencommons[1089]: Starting C xenstored...
Nov 28 10:10:23 VERN xencommons[1089]: Setting domain 0 name and domid...
Nov 28 10:10:23 VERN xencommons[1089]: Starting xenconsoled...
Nov 28 10:10:23 VERN xencommons[1089]: Starting QEMU as disk backend for dom0


xendomains.service - Xendomains - start and stop Xen VMs on boot and shutdown
   Loaded: loaded (/usr/lib/systemd/system/xendomains.service; enabled)
   Active: active (exited) since Fri 2014-11-28 10:10:49 EST; 4min 1s ago
  Process: 1969 ExecStart=/etc/init.d/xendomains start (code=exited, status=0/SUCCESS)
  Process: 1955 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
 Main PID: 1969 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/xendomains.service


Nov 28 10:10:49 VERN xendomains[1969]: xc: error: 0-length read: Internal error
Nov 28 10:10:49 VERN xendomains[1969]: xc: error: rdexact failed (read rc: 0, errno: 0): Internal error
Nov 28 10:10:49 VERN xendomains[1969]: xc: error: read: p2m_size (0 = Success): Internal error
Nov 28 10:10:49 VERN xendomains[1969]: libxl: error: libxl_create.c:959:libxl__xc_domain_restore_done: restoring domain: Success
Nov 28 10:10:49 VERN xendomains[1969]: libxl: error: libxl_create.c:1041:domcreate_rebuild_done: cannot (re-)build domain: -3
Nov 28 10:10:49 VERN xendomains[1969]: libxl: error: libxl.c:1405:libxl__destroy_domid: non-existant domain 1
Nov 28 10:10:49 VERN xendomains[1969]: libxl: error: libxl.c:1369:domain_destroy_callback: unable to destroy guest with domid 1
Nov 28 10:10:49 VERN xendomains[1969]: libxl: error: libxl_create.c:1340:domcreate_destruction_cb: unable to destroy domain 1 following failed creation
Nov 28 10:10:49 VERN xendomains[1969]: !
Nov 28 10:10:49 VERN xendomains[1969]: ..done


xen-watchdog.service - Xen-watchdog - run xen watchdog daemon
   Loaded: loaded (/usr/lib/systemd/system/xen-watchdog.service; enabled)
   Active: active (running) since Fri 2014-11-28 10:10:22 EST; 4min 28s ago
  Process: 1052 ExecStart=/usr/sbin/xenwatchdogd 30 15 (code=exited, status=0/SUCCESS)
 Main PID: 1058 (xenwatchdogd)
   CGroup: /system.slice/xen-watchdog.service
           └─1058 /usr/sbin/xenwatchdogd 30 15


xend.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)


libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Fri 2014-11-28 10:10:37 EST; 4min 13s ago
     Docs: man:libvirtd(8)
           http://libvirt.org
 Main PID: 1961 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           └─1961 /usr/sbin/libvirtd --listen


Nov 28 10:10:37 VERN libvirtd[1961]: libvirt version: 1.2.9
Nov 28 10:10:37 VERN libvirtd[1961]: Configured security driver "none" disables default policy to create confined guests
Nov 28 10:10:37 VERN libvirtd[1961]: Failed to query host NUMA topology, disabling NUMA capabilities
Nov 28 10:10:37 VERN libvirtd[1961]: Failed to get host CPU
Nov 28 10:10:38 VERN libvirtd[1961]: Failed to query host NUMA topology, disabling NUMA capabilities


libvirt-guests.service - Suspend Active Libvirt Guests
   Loaded: loaded (/usr/lib/systemd/system/libvirt-guests.service; enabled)
   Active: active (exited) since Fri 2014-11-28 10:10:37 EST; 4min 13s ago
     Docs: man:libvirtd(8)
           http://libvirt.org
  Process: 2038 ExecStart=/usr/lib64/libvirt/libvirt-guests.sh start (code=exited, status=0/SUCCESS)
 Main PID: 2038 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/libvirt-guests.service

Still no running vm’s:(

Just not my holiday I guess.

Wil

16

More tweaking, backed up saved xl command file that xendomains was trying to restore.


xencommons.service - Xencommons - Script to start and stop xenstored and xenconsoled
   Loaded: loaded (/usr/lib/systemd/system/xencommons.service; enabled)
   Active: active (exited) since Fri 2014-11-28 10:54:59 EST; 10min ago
  Process: 1083 ExecStart=/etc/init.d/xencommons start (code=exited, status=0/SUCCESS)
  Process: 1044 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
 Main PID: 1083 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/xencommons.service
           ├─1169 /usr/sbin/xenstored --pid-file /var/run/xenstored.pid
           ├─1184 /usr/sbin/xenconsoled --pid-file=/var/run/xenconsoled.pid
           └─1225 /usr/lib/xen/bin/qemu-system-i386 -xen-domid 0 -xen-attach -name dom0 -nographic -M xenpv -daemonize -monitor /dev/null -serial /dev/null -parallel /dev/null -pidfile /var/run/qemu-dom0.pid


Nov 28 10:54:56 VERN xenstored[1169]: Checking store ...
Nov 28 10:54:56 VERN xenstored[1169]: Checking store complete.
Nov 28 10:54:56 VERN xencommons[1083]: Starting C xenstored...
Nov 28 10:54:56 VERN xencommons[1083]: Setting domain 0 name and domid...
Nov 28 10:54:56 VERN xencommons[1083]: Starting xenconsoled...
Nov 28 10:54:56 VERN xencommons[1083]: Starting QEMU as disk backend for dom0


xendomains.service - Xendomains - start and stop Xen VMs on boot and shutdown
   Loaded: loaded (/usr/lib/systemd/system/xendomains.service; enabled)
   Active: active (exited) since Fri 2014-11-28 10:55:10 EST; 10min ago
  Process: 1941 ExecStart=/etc/init.d/xendomains start (code=exited, status=0/SUCCESS)
  Process: 1926 ExecStartPre=/bin/grep -q control_d /proc/xen/capabilities (code=exited, status=0/SUCCESS)
 Main PID: 1941 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/xendomains.service


Nov 28 10:55:10 VERN xendomains[1941]: Restoring Xen domains:
Nov 28 10:55:10 VERN xendomains[1941]: ..done

xen-watchdog.service - Xen-watchdog - run xen watchdog daemon
   Loaded: loaded (/usr/lib/systemd/system/xen-watchdog.service; enabled)
   Active: active (running) since Fri 2014-11-28 10:54:56 EST; 10min ago
  Process: 1049 ExecStart=/usr/sbin/xenwatchdogd 30 15 (code=exited, status=0/SUCCESS)
 Main PID: 1052 (xenwatchdogd)
   CGroup: /system.slice/xen-watchdog.service
           └─1052 /usr/sbin/xenwatchdogd 30 15


xend.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)


libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib/systemd/system/libvirtd.service; enabled)
   Active: active (running) since Fri 2014-11-28 10:55:10 EST; 10min ago
     Docs: man:libvirtd(8)
           http://libvirt.org
 Main PID: 1932 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           └─1932 /usr/sbin/libvirtd --listen


Nov 28 10:55:11 VERN libvirtd[1932]: libvirt version: 1.2.9
Nov 28 10:55:11 VERN libvirtd[1932]: Configured security driver "none" disables default policy to create confined guests
Nov 28 10:55:11 VERN libvirtd[1932]: Failed to query host NUMA topology, disabling NUMA capabilities
Nov 28 10:55:11 VERN libvirtd[1932]: Failed to get host CPU
Nov 28 10:55:11 VERN libvirtd[1932]: Failed to query host NUMA topology, disabling NUMA capabilities

libvirt-guests.service - Suspend Active Libvirt Guests
   Loaded: loaded (/usr/lib/systemd/system/libvirt-guests.service; enabled)
   Active: active (exited) since Fri 2014-11-28 10:55:10 EST; 10min ago
     Docs: man:libvirtd(8)
           http://libvirt.org
  Process: 2049 ExecStart=/usr/lib64/libvirt/libvirt-guests.sh start (code=exited, status=0/SUCCESS)
 Main PID: 2049 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/libvirt-guests.service

Found this in syslog


2014-11-28T10:55:11.063881-05:00 VERN kernel:    30.824614] audit: type=1400 audit(1417190111.056:49): apparmor="DENIED" operation="capable" profile="/usr/sbin/libvirtd" pid=2046 comm="libvirtd" capability=14  capname="ipc_lock"

2014-11-28T10:55:11.063886-05:00 VERN kernel:    30.825480] audit: type=1400 audit(1417190111.056:50): apparmor="DENIED" operation="capable" profile="/usr/sbin/libvirtd" pid=2046 comm="libvirtd" capability=14  capname="ipc_lock"

Might have something to do with libvirtd errors?

Wil

17
  1. At each stage when you upgraded to a major version, did you execute a full re-installation after upgrading? Although not mentioned in any official guide I know of, a previous thread suggested this which I find entirely logical.
zypper dup
  1. Especially if you didn’t do a full re-installation did you do a system update to pull down all latest packages with fixes and improvements? Absolutely critical to a functioning system.
zypper up
  1. Did you try force re-installing libvirt packages?
    Step one - List the existing installed libvirt files
zypper se -i libvirt

Step two - Force re-install the libvirt packages, which hopefully should re-apply policies and configurations as well

zypper in -f <list all packages, each separated by a space>

TSU

18

Yes to all numerous times, sometimes with yast.

Will

19

Ok, beside the issues with the virtualization, these vm’s used their own logical volume to build their file systems on. The two pv’s are seeing unexpected inconsistencies which flips the os into single user mode and disconnects the vnc when launching using “xl create /path/to/guest/config -V”. Can I somehow mount the lv’s and run fsck or something to fix the these issues?

If this is the wrong place to ask please point me in the right direction.

Thanks,

Wil

20

G,

Reread the following again.

And then reread it again.

It explained why you see somethings in xl list, and not in virsh list, and vice versa, or both. I believe (since I can’t test it) You should be able run previously running domains in virt-manager using the vm-install to add domains that you have disks or images already built/installed. In your case where you have the domains running under xl, did you try starting them with virsh create? However try the GUI first! Just make sure you have nothing running in xl list except Domain-0. Good place to start is a reboot. You want no guests running.

Note: I may have done damage to my guests file systems by not running them with all the appropriate settings that would have been passed by the management app/s. (Using xl create or even virsh create alone. virt-manager may have used settings that may not have been saved to the xen/d config files for the guests. Time will tell.


# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0 24057    16     r-----    6225.6

If they fail they will likely show as (null) with xl list and not at all with virsh list. In the following example the existing domains are listed in virt-manager shut down, after attempting to install them as previously noted. I then tried to start the first, knowing it will fail because of media errors.


# xl list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0 23013    16     r-----    6352.0
(null)                                       1     0     0     --p---       0.0

# virsh list
 Id    Name                           State
----------------------------------------------------

Else if everything is good, you should be up under virt-manager Hope you remember how it was configured previously;-) I’ll have more on this as I build my “vmRESCUE-123” guest. More on that in my next post.

Wil