Libxl error: unable to create nic devices, when sys-net uses a minimal template

[archpaladin1]

Qubes OS version:

4.0 (fully up-to-date)

Affected component(s):

Networking, Qube startup

---

Steps to reproduce the behavior:

1. Install the latest fedora-29-minimal template & install the packages required to allow it to be used as sys-net, as detailed here: https://www.qubes-os.org/doc/templates/fedora-minimal/
2. Install the latest mirage-firewall release (v0.4) and create a mirage-firewall qube - https://github.com/talex5/qubes-mirage-firewall/
3. Shut down all qubes
4. qvm-prefs sys-net template fedora-29-minimal
5. qvm-prefs mirage-firewall netvm sys-net
6. For another appvm: qvm-prefs appvm netvm mirage-firewall && qvm-prefs appvm template fedora-29-minimal
7. qvm-start appvm

Expected behavior:

The appvm should start.

Actual behavior:

The appvm fails to start. Qubes reports:
Start failed: internal error: libxenlight failed to create new domain 'appvm', see /var/log/libvirt/libxl/libxl-driver.log for details

On checking that log, you will find:

libxl: libxl_create.c:1512:domcreate_attach_devices: unable to add nic devices
libxl: libxl_device.c:1093:device_backend_callback: unable to remove device with path /local/domain/9/backend/vif/10/0
libxl: libxl.c:1669:devices_destroy_cb: libxl__devices_destroy failed for 10

If you switch sys-net to use some other template (eg. fedora-29), this error doesn't reproduce.

General notes:

I'm aware of this error being reported in #3696 and in there it is due to problems with sys-firewall. In that ticket the error appeared to be intermittent, but here it is consistent and survives reboots.

I also know that mirage-firewall isn't supported, and I'm not asking it to be. I'm just trying to find out why this error shows up when I use fedora-29-minimal as sys-net's template but not when I use some other fedora template, because it seems like the configuration for sys-net shouldn't matter at all.

If there's a discrepancy between fedora-29 and fedora-29-minimal that causes this bug, then the documentation for setting up the Fedora minimal templates should probably be adjusted.

---

Related issues:

#3696

[marmarek]

Does it also happen with non-mirage qube connected to it directly?
Take a look at QubesOS/updates-status#848 (comment) - does it help if you install those pacakges? I'd first try iproute (#4411, fix already in testing: QubesOS/updates-status#878).

[archpaladin1]

If the network diagram goes sys-net -> appvm, where both are fedora minimal templates, the error doesn't reproduce.

I installed iproute in the fedora-minimal template and now the problem also appears to be gone, even when using the mirage-firewall in between.

So it looks like there are other packages that should be included in the list required for the minimal template to be used for sys-net. Can the documentation be updated accordingly?

[andrewdavidwong]

I'd first try iproute (#4411, fix already in testing: QubesOS/updates-status#878).

But that's about Debian, not Fedora-minimal. I thought I remembered there being an issue for iproute missing from fedora-minimal, but I can't find one now.

If the network diagram goes sys-net -> appvm, where both are fedora minimal templates, the error doesn't reproduce.

I installed iproute in the fedora-minimal template and now the problem also appears to be gone, even when using the mirage-firewall in between.

So it looks like there are other packages that should be included in the list required for the minimal template to be used for sys-net. Can the documentation be updated accordingly?

iproute is already recommended for fedora-minimal qua FirewallVM, just not qua NetVM.
The documentation is a community effort, and everyone is welcome to contribute. (That's how things like this get updated!) So, if you'd like to get involved with the project, this is a great way to do it. You can read more about how to submit documentation changes here:

https://www.qubes-os.org/doc/doc-guidelines/

[marmarek]

iproute is already added as a dependency of qubes-core-agent-networking, so there is no need to update anything. Just wait a little until update lands in stable repo.

[archpaladin1]

Perfect, thanks!

I didn't know that about the documentation updates. I will feel free to contribute in the future. :)

[andrewdavidwong]

iproute is already added as a dependency of qubes-core-agent-networking, so there is no need to update anything. Just wait a little until update lands in stable repo.

I guess this is technically a duplicate of #4411 then. Closing.