XEN VM fails to start

phil524 · April 22, 2018, 10:25am

Hello,

I have a server with a XEN VM: it worked without problem but after last update (via zypper dup) I cannot start the VM via virt_manager. I receive the next error when executing
"hpprol2:~ # virt-manager & "

Error starting domain: internal error: libxenlight failed to create new domain 'vmsamba'

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/libvirtobject.py", line 82, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/domain.py", line 1508, in startup
    self._backend.create()
  File "/usr/lib64/python3.6/site-packages/libvirt.py", line 1069, in create
    if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirt.libvirtError: internal error: libxenlight failed to create new domain 'vmsamba'

I forced a reinstall of all libvirt, qemu and Xen packages without success.

In journalctl if see this

Apr 22 10:06:30 hpprol2 libvirtd[1592]: 2018-04-22 08:06:30.455+0000: 1654: error : virConnectGetCPUModelNames:1035 : this function is not supported by the connection driver: virConnectGetCPUModelNames
Apr 22 10:06:30 hpprol2 libvirtd[1592]: 2018-04-22 08:06:30.920+0000: 1653: error : virDomainGetMetadata:8053 : this function is not supported by the connection driver: virDomainGetMetadata
Apr 22 10:06:30 hpprol2 libvirtd[1592]: 2018-04-22 08:06:30.965+0000: 1654: error : virDomainListAllSnapshots:520 : this function is not supported by the connection driver: virDomainListAllSnapshots
Apr 22 10:06:31 hpprol2 wicked[3170]: ifcfg-br1: bridge validation: bridge forward-delay is out of supported range (2.0-30.0)
Apr 22 10:06:31 hpprol2 wicked[3180]: ifcfg-br1: bridge validation: bridge forward-delay is out of supported range (2.0-30.0)
Apr 22 10:06:31 hpprol2 wicked[3189]: ifcfg-br1: bridge validation: bridge forward-delay is out of supported range (2.0-30.0)
Apr 22 10:06:31 hpprol2 wicked[3197]: ifcfg-br1: bridge validation: bridge forward-delay is out of supported range (2.0-30.0)
....
Apr 22 10:06:44 hpprol2 root[3256]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/2/2112
Apr 22 10:06:44 hpprol2 root[3252]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/2/2080
Apr 22 10:06:44 hpprol2 root[3254]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/2/2096
Apr 22 10:06:44 hpprol2 root[3264]: /etc/xen/scripts/block: add XENBUS_PATH=backend/vbd/2/2128
Apr 22 10:06:44 hpprol2 root[3391]: /etc/xen/scripts/block: Writing backend/vbd/2/2112/physical-device 8:22 to xenstore.
Apr 22 10:06:44 hpprol2 root[3393]: /etc/xen/scripts/block: Writing backend/vbd/2/2112/physical-device-path /dev/sdc2 to xenstore.
Apr 22 10:06:44 hpprol2 root[3395]: /etc/xen/scripts/block: Writing backend/vbd/2/2112/hotplug-status connected to xenstore.
Apr 22 10:06:45 hpprol2 root[3457]: /etc/xen/scripts/block: Writing backend/vbd/2/2096/physical-device 8:23 to xenstore.
Apr 22 10:06:45 hpprol2 root[3459]: /etc/xen/scripts/block: Writing backend/vbd/2/2096/physical-device-path /dev/sdc3 to xenstore.
Apr 22 10:06:45 hpprol2 root[3461]: /etc/xen/scripts/block: Writing backend/vbd/2/2096/hotplug-status connected to xenstore.
Apr 22 10:06:46 hpprol2 root[3521]: /etc/xen/scripts/block: Writing backend/vbd/2/2128/physical-device 8:24 to xenstore.
Apr 22 10:06:46 hpprol2 root[3523]: /etc/xen/scripts/block: Writing backend/vbd/2/2128/physical-device-path /dev/sdc4 to xenstore.
Apr 22 10:06:46 hpprol2 root[3525]: /etc/xen/scripts/block: Writing backend/vbd/2/2128/hotplug-status connected to xenstore.
Apr 22 10:06:46 hpprol2 root[3583]: /etc/xen/scripts/block: Writing backend/vbd/2/2080/physical-device 8:21 to xenstore.
Apr 22 10:06:46 hpprol2 root[3585]: /etc/xen/scripts/block: Writing backend/vbd/2/2080/physical-device-path /dev/sdc1 to xenstore.
Apr 22 10:06:46 hpprol2 root[3587]: /etc/xen/scripts/block: Writing backend/vbd/2/2080/hotplug-status connected to xenstore.
Apr 22 10:06:47 hpprol2 root[3620]: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/2/2080
Apr 22 10:06:47 hpprol2 root[3630]: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/2/2096
Apr 22 10:06:47 hpprol2 root[3640]: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/2/2112
Apr 22 10:06:47 hpprol2 root[3651]: /etc/xen/scripts/block: remove XENBUS_PATH=backend/vbd/2/2128
Apr 22 10:06:49 hpprol2 libvirtd[1592]: 2018-04-22 08:06:49.338+0000: 1653: error : libxlDomainStart:1315 : internal error: libxenlight failed to create new domain 'vmsamba'

and command ifconfig doesn’t show any problem the bridge is present and works

hpprol2:~ # ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.120  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 9c:8e:99:5b:48:12  txqueuelen 1000  (Ethernet)
        RX packets 4417  bytes 3466350 (3.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4783  bytes 662774 (647.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

br0:100: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.100  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 9c:8e:99:5b:48:12  txqueuelen 1000  (Ethernet)

br0:101: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.101  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 9c:8e:99:5b:48:12  txqueuelen 1000  (Ethernet)

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 9c:8e:99:5b:48:12  txqueuelen 1000  (Ethernet)
        RX packets 5377  bytes 3640866 (3.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4800  bytes 686174 (670.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 1189  bytes 260442 (254.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1189  bytes 260442 (254.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 192.168.90.1  netmask 255.255.255.0  broadcast 192.168.90.255
        ether 52:54:00:3c:cc:26  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Any idea or do i need to open a new bug report?

tsu2 · April 22, 2018, 4:17pm

I see all sorts of errors that IMO probably aren’t related to a package upgrade, and are more likely related to possible User error… Like trying to connect to br1 (which doesn’t exist, you have br0 and some spanned bridges to that, and a virbr1), and some Domain access(The name of your Guest) problems.

I guess I’d ask whether you’re shutting down your Guest completely before you shut down your HostOS, or if you are suspending your Guest from within the Guest (a big User Error problem if you’re doing that… Which should never be done. Only suspend using your Virtualization tools). If this is what you have been doing, it’s likely the major cause of your Guest corruption and sometimes I just re-create the Guest rather than try to fix the corruption.

A basic Golden Rule for all virtualization technologies…
Never shut down the HostOS before your Guests are all properly either shutdown(powered off virtually) or Suspended by Libvirt or whatever virtualization manager/technology you are using. Never, ever suspend the Guest from within as you would on a physical machine.

TSU

phil524 · April 23, 2018, 6:43pm

Thanks Tsu,

When I do a shutdown I close the VM before; Still possible that I forget it this time; I 'll try to recreate the guest;

Regards
Philippe

tsu2 · April 23, 2018, 7:12pm

Although I haven’t had a personal need for a long time(It’s pretty hard to forget with what I currently deploy),
Once upon a time I felt this was such an important requirement in a Production environment that I scripted my shutdown to make sure that no accident could happen.

TSU