Help Needed - Qubes Ethernet Adapter Not Supported in VMs


I hope this post finds you well. I am currently facing a significant issue with my Qubes OS setup and I am seeking guidance from the experienced members of this community.

I recently installed Qubes OS on my system and have been thrilled with its security features and compartmentalization capabilities. However, I’ve run into a roadblock when it comes to setting up Ethernet connections for my VMs.

It appears that the Ethernet adapter is not being recognized or supported within the virtual machines (VMs). I’ve tried setting up various VMs (Fedora, Debian, Whonix) and have faced the same issue across all of them. I’ve ensured that the VMs are configured to use the Qubes-provided network settings, but the Ethernet adapter remains inactive within the VMs.

I’ve also attempted the following steps without success:

1.Reinstalling VMs:I tried creating new VMs from scratch, thinking that the initial setup might have been flawed, but the problem persists.
2.Updating Qubes and VMs: I made sure that Qubes OS and all VMs are up to date with the latest updates and patches.
3.Checking BIOS Settings: I ensured that my BIOS settings are properly configured for virtualization support.
4.Ethernet Drivers:I researched if there are specific Ethernet drivers required for Qubes VMs, but couldn’t find any conclusive information.

Thank you in advance for your time and assistance.

Best regards,

Hi @devinmarco, welcome to the forum. I am not sure if you are aware, so allow me to start from the very basics:

In Qubes OS your Ethernet adapter is normally assigned to a special qube (VM) called sys-net. This qube is of the type HVM and PCI devices like your Ethernet adapter can be assigned to it. This is normally done for you by the installer.

Also standard is to have a second qube called sys-firewall. This qube get’s its connectivity from sys-net. This is achieved by setting the ‘netvm’ property of sys-firewall to sys-net. The purpose of this qube is to enforce firewall rules of the qubes that get connected to it.

So any qube you want to use with network connectivity, needs to have it’s ‘netvm’ property set to a so-called proxy qube (like sys-net or sys-firewall). It is advisable to always use sys-firewall unless and until you understand what’s happening in detail and make your own proxy qubes (e.g. for use with a VPN or TOR).

Here are two questions for your to answer that will hopefully help us help you quickly:

  1. Please open a Terminal for dom0 (Terminal Emulator in the start menu) and run qvm-pci | grep Ethernet and post the result. This is to find out what device you have and if it is assigned to sys-net. The output should look something like this:
[user@dom0 ~]$ qvm-pci | grep Ethernet
dom0:00_19.0  Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (Lewisville)          sys-net
  1. Open a terminal in sys-net (click on the qube in the tray, select sys-net, select Run Terminal) and run ip link show and post the result. This will show us which devices are detected and active in your sys-net.
1 Like

Last week I needed ethernet and was unable to access in such a simple fashion. The net qube would fail to start, stating that it will not reset the pci device. BTW this was a Lenovo Thinkpad T14 G1 AMD system.

The workaround I used was based on the related devices I saw in lspci

02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 0e)
02:00.1 Serial controller: Realtek Semiconductor Co., Ltd. RTL8111xP UART #1 (rev 0e)
02:00.2 Serial controller: Realtek Semiconductor Co., Ltd. RTL8111xP UART #2 (rev 0e)
02:00.3 IPMI Interface: Realtek Semiconductor Co., Ltd. RTL8111xP IPMI interface (rev 0e)
02:00.4 USB controller: Realtek Semiconductor Co., Ltd. RTL811x EHCI host controller (rev 0e)

Some of all of these devices appear to be closely integrated with the ethernet port enough to require including them together in sys-net’s device list. I simply added all of these related 2.00.x devices and it worked.

Probably, you could figure out the one other device that was needed without including them all; there may also be xen/linux passthrough options that could also make it work without including all (but maybe not).

@tasket--option no-strict-reset=true didn’t work?

Yes, that also works. It is necessary to remove the device from the list first, then run the qvm-pci cmd with that option and also --persistent.