virt-manager/qemu FreeNAS virtio network doesn't load drivers

[jerrac]

I can't seem to get a virtio network card to work with my FreeNAS virtual machine.

I'm running libvirtd and qemu, configuring things via virt-manager. My host OS is Pop_OS 18.04, so basically Ubuntu 18.04.

I've successfully loaded the virtio modules in FreeNAS. But when I switch the NIC to virtio, I can't figure out how to make FreeNAS associate the device with the driver. I end up with the attached screenshot. As you can see, the Red Hat, Inc. Virtio network device is listed. And at the top, the last two lines of the grep output are from when I had the NIC set to virtio, they say "no driver attached".

If I run ifconfig, it just lists the 'lo' network.

Once I switch back to the 'rtl8139' device model for the NIC, it works just fine.

While drafting this post, I hit upon the idea of adding a second NIC for the virtio NIC, that let me ssh into the vm and copy out the output.

So, here's info I was able to gather:

Code:

root@xunlaichest[~]# ifconfig
re0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=8009b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,LINKSTATE>
    ether 52:54:00:7e:50:8e
    hwaddr 52:54:00:7e:50:8e
    inet 192.168.122.214 netmask 0xffffff00 broadcast 192.168.122.255
    nd6 options=9<PERFORMNUD,IFDISABLED>
    media: Ethernet autoselect (100baseTX <full-duplex>)
    status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    inet 127.0.0.1 netmask 0xff000000
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    groups: lo
root@xunlaichest[~]# grep -i ethernet /var/log/messages
Jun  9 15:18:23 xunlaichest re0: Ethernet address: 52:54:00:7e:50:8e
Jun  9 16:57:04 xunlaichest pci4: <network, ethernet> at device 0.0 (no driver attached)
Jun  9 17:13:37 xunlaichest pci4: <network, ethernet> at device 0.0 (no driver attached)
Jun  9 17:28:23 xunlaichest re0: Ethernet address: 52:54:00:7e:50:8e
Jun  9 17:40:52 xunlaichest pci4: <network, ethernet> at device 0.0 (no driver attached)
Jun  9 17:40:52 xunlaichest re0: Ethernet address: 52:54:00:7e:50:8e
root@xunlaichest[~]# lspci | grep -i virt
00:01.0 VGA compatible controller: Red Hat, Inc. QXL paravirtual graphic card (rev 04)
01:00.0 Communication controller: Red Hat, Inc. Virtio console (rev 01)
03:00.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory balloon (rev 01)
04:00.0 Ethernet controller: Red Hat, Inc. Virtio network device (rev 01)
root@xunlaichest[~]# kldload virtio
kldload: can't load virtio: module already loaded or in kernel
root@xunlaichest[~]# kldload vtnet
kldload: can't load vtnet: module already loaded or in kernel

I also checked ui/network/interfaces/add to see if I could find another NIC listed. It just had the re0 'rtl8139' device available, which was already configured. No sign of something for the virtio device.

FYI, I'm hoping the virtio network will give me more bandwidth. :) Not sure if it will, or not, when I can't test. :\

FreeNAS Version: FreeNAS-11.2-U4.1
16GB of RAM.

Since it's virtualized, is there a need for what kind of motherboard/cpu/etc?

Thanks in advance for any help. I hope I've included enough information. I did spend a good few hours, over multiple days, searching on the topic, both here, and via Google. This is the closest I could get.

 

[KrisBee]

Your screen shot shows (a) there's no need to load virtio drivers as they are in-built in FreeNAS & (b) the virtio NIC device of your VM is present. For your VM network to be usable you need to have configured a bridge on your host and configure the VM's NIC via the FreeNAS console screen options you see after booting the VM.

 

[jerrac]

For your VM network to be usable you need to have configured a bridge on your host...

Um, I have the default virt-manager network selected for both cards. See the attached screenshots. When I had only the virtio nic set up, it was set to use the default network. Since it works on the non-virtio nic, why wouldn't it work with the virtio nic?

I also just tried telling the virtio nic to use the virbr0 network bridge. It didn't help. The nic is still detected, but no driver is loaded for it.

With this setup, when I use option 1 from the console, it only lists the non-virtio network as an option.

I did try to create a new bridge network with virsh.

Code:

$ cat xunbr9.xml 
<network>
  <name>xunbr9</name>
  <bridge name="xunbr9" />
  <forward mode="route" />
  <ip address="192.168.122.1" netmask="255.255.255.0" />
</network>
$ virsh net-create xunbr9.xml
error: Failed to create network from xunbr9.xml
error: internal error: Network is already in use by interface virbr0

That's why I tried to tell the virtio nic to use the virbr0 bridge.

Would you mind giving me a bit more detail on what you think I need to do?

Thanks!

 

[KrisBee]

Not sure why you have two NICS attached to your VM. My comments refer to the simplest config where there's a bridge on the host with a host NIC and a virtual NIC as members. The virtual NIC is the one attached to your VM.

 

[jerrac]

Thanks for the replies. :)

2 nics let me ssh in via terminal and copy output from commands. Much easier than screenshotting or hand typing it.

I did try 1 virtio nic. If I configure it to use the default network (that works with the non-virtio nic) it does not work.

The only difference is virtio vs. not being virtio.

I'm pretty sure a 'network' is effectively just a virtual ethernet cable, so if an ethernet cable is plugged into a working network, but my pc can't access the net, then it's either the pc's network card, or the OS's driver having issues.

The default network is a bridge. See the attached screenshot.

So, from what I can see, the OS is not associating the virtio nic with the virtio driver. It loads the driver, and detects the nic, but doesn't make the two things work together.

Is there a manual method to associating a NIC with a driver?

(Sorry for any tone or comprehension issues, I'm home sick today. Not thinking that clearly...)

 

[KrisBee]

Let's try and clarify a few points so we're not talking at cross purposes. My example is using what kvm/qemu refers to as a "bridged network" and your example is using what is referred to as a "NAT-based network". ( See: https://jamielinux.com/docs/libvirt-networking-handbook/bridged-network.html & https://wiki.libvirt.org/page/VirtualNetworking )

FreeNAS has in-built drivers to support both qemu's virtio and e1000 NIC device models. All that should be necessary is to config in FreeNAS VM the NICs it detects. After an install use the FreeNAS VM console to do, otherwise you'd use the webUI. Surely you can ssh into your FreeNAS VM using just one virtual NIC? But can you reach the webUI of a FreeNAS VM using a "NAT-based network"?

 

[jerrac]

Ok, so I've tried configuring two additional networks. One with the Routed option, one with the Open option.

freebr0 (freebr0.png) is routed to my hosts nic.

freebr1 (freebr1.png) uses the "Open network" option.

When configured as the sole NIC using the virtio option, neither freebr0 (nic-freebr0-virtio-broken.png), nor freebr1 (nic-freebr1-virtio-broken.png), work. FreeNAS says "The web interface could not be accessed. Please check network configuration." If I try to configure network interfaces via option 1, no interfaces are listed.

When configured as the sole nic using the rtl8139 or e1000 options, freebr0 works just fine. FreeNAS detects and configures it automatically. I can access the Web UI via the ip address shown in the console after boot.

When configured as the sole nic using the rtl8139, freebr1 (the open network) is detected and configured, but the ip address shown after boot is 0.0.0.0. So, I'm not counting that as working.

As far as I can tell, between the default NAT network, and the freebr0 and freebr1 networks, I've covered every possible kind of virtual network. All three "work" if I don't use virtio. That is what makes me think something is wrong with how the virtio network driver is being loaded.

I did mess around with some kernel module related configuration files when I didn't know that the virtio drivers are built in. So maybe that messed something up? I'll try to dig in and find any remnants... Hmm....

 

[KrisBee]

Your problem is in Linux not FreeNAS. The case where FN IP is 0.0.0.0 after 1st boot is most likely because your VM couldn't access a DHCP server during boot, hence it needs manual config of any vtnet interface.

 

[jerrac]

That does not address the fact that the nic works just fine when configured with either the rtl8139 or e1000 options. If the FreeNAS vm couldn't access my DHCP server, then it wouldn't work with those options either, right?

Seriously, the point I keep getting stuck on here is that the rtl8139 or e1000 options work just fine. It's only the virtio option that has issues. How can my network config be bad when everything works unless I use virtio?

Sorry for being a bit difficult, I'm just really stuck on that. :\

 

[jerrac]

I had time today to trying and improve performance on my FreeNAS setup. While doing so I dug into this topics issue again. My web searching turned up this bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236922 It says that virtio has problems when the Q35 chipset is used instead of the i440FX chipset.

I've confirmed my vm is using the Q35 chipset. @KrisBee is your vm using the i440FX chipset?

Thanks!

 

[KrisBee]

i440FX

 

[jerrac]

Sorry for rezzing an old topic...

If I build a new FreeNAS vm using the i440FX chipset, with the same FreeNAS version as my current instance, attach my HDD's the same way, and then use System->General to upload a backup of my current FreeNAS config, will my zfs pool be set up proprely?

Or do I need rebuild the pool and restore my data from backups?

 

[jerrac]

Finally had time to just try it.

To answer my own question. You don't need to rebuild the pool and restore the data from backup. You need to backup your old system's config, import it to your new system, then use your pools recovery key to unlock the pool on the new system. Once that it done, everything should just work.

FYI, you can download your recovery key from the pools "Export/Disconnect" modal dialog.