libvirt/libxl: Upgrading to 20181116-0 busted virtual networking: Backend interfaces not brought up


After upgrading the distro from 20181110-0 to 20181116-0 the virtual networking started to go haywire. Although I haven’t changed anything in my configuration (both the network definitions and the definition of my domU are completely unchanged) the backend interface of my virtual network refuses to get attached to the bridge that I have set up to act as a virtual hub.
When checking the logs the following shows up in /var/log/messages:

2018-11-19T09:39:07.033763+01:00 gagazet root: /etc/xen/scripts/vif-bridge: online type_if=vif XENBUS_PATH=backend/vif/6/0
2018-11-19T09:39:07.104544+01:00 gagazet root: /etc/xen/scripts/vif-bridge: No device details in backend/vif/6/0, exiting.
2018-11-19T09:39:07.226761+01:00 gagazet root: /etc/xen/scripts/vif-bridge: add type_if=tap XENBUS_PATH=backend/vif/6/0
2018-11-19T09:39:07.354079+01:00 gagazet root: /etc/xen/scripts/vif-bridge: No device details in /local/domain/0/backend/vif/6/0, exiting.

The problem is that vif6.0 (as per this example) exists and can manually be attached to the bridge and brought up, thereby restoring connectivity between dom0 and the domU, however, for some strange reason /etc/xen/scripts/vif-bridge doesn’t find anything.
The xen-tools installed are version 4.11.0_09-2.1

The way I take it searching for backend/vif/6/0 doesn’t turn up anything remotely connected to Xen or libvirt (a search for backend turned up something entirely different) - maybe the path in XENBUS_PATH is plain wrong?

EDIT: Just poked around in the fs a bit and found that a crucial tool is missing (/bin/domu-xenstore not found although a bunch of symlinks point to exactly that one). As it seems, the package xen-tools is likely to be broken.

Try force re-installing your xen-tools with the following command

zypper in -f xen-tools

You can then test for, or look for your xenstore a number of ways.
If it’s still missing, check whether it’s in your current xen-tools package with the following command, and verify its path

rpm -ql sen-tools | grep xenstore

If that solves your problem, then it may forever remain a mystery how that part of xen-tools might have become missing…
Else, if xenstore is really missing from current xen-tools, then unless someone else comes up with more info, you will want to submit a bug to

Info about xenstore, xenstored and related user-mode command lines can be found starting from the following link


Unfortunately reinstalling the package won’t help, because said file isn’t even listed in the package (and therefore the file isn’t present).
I’ve nevertheless tried the reinstall, but I’m getting the exact same result.

I’ve already filed a bug report on this since xen-tools definitely is broken.

When I took a closer look at senstore, it’s not part of xen-tools, it’s likely provided as an independent library related to the xen kernel, and not part of xen-tools

# zypper se --provides xenstore
Loading repository data...
Reading installed packages...

S  | Name             | Summary                                                   | Type   
i+ | openSUSE-release | openSUSE Tumbleweed                                       | package
   | xen-devel        | Xen Virtualization: Headers and libraries for development | package
i  | xen-libs         | Xen Virtualization: Libraries                             | package
   | xen-libs-32bit   | Xen Virtualization: Libraries 

And, if you want to display the contents of senstore, you can install and run the following command


You should try running “zypper dup” again to see if a new kernel is available, and if it’s broken you should be able to resolve by booting your previous kernel. The package xen-tools probably is not related to your problem.