First class support for alternative NIC drivers?

LXD
,
#1

So, is there any first class support for alternative NIC drivers in a VM? I’m using the snap which has zero additional NIC roms from what I can tell so I’m guessing no. Adding a second, different NIC to the VM would work if that’s a thing.

I see it may be possible to use the raw.qemu.conf override capability to change some of the drivers that get used in a VM but also noticed the documentation mentions use of raw keys could break LXD in non-obvious ways.

Of course I can do this with a number of other hypervisors but I like LXD and want to use it for as much as possible.

These roms seem to come default with qemu but I dont’ really see a way to use them along with the LXD snap.

~$ qemu-system-x86_64 -net nic,model=help
Supported NIC models:
e1000
e1000-82544gc
e1000-82545em
e1000e
i82550
i82551
i82557a
i82557b
i82557c
i82558a
i82558b
i82559a
i82559b
i82559c
i82559er
i82562
i82801
ne2k_pci
pcnet
pvrdma
rocker
rtl8139
tulip
virtio-net-pci
virtio-net-pci-non-transitional
virtio-net-pci-transitional
vmxnet3
#2

We purposefully don’t include those in the QEMU builds coming as part of the snap.
The reason is that the vast majority of security issues found in QEMU come from those virtualized network devices. As LXD sets itself as a safe and modern VM manager, we don’t see the need to risk this kind of security exposure when all systems that we provide images for have native virtio-net support.

That said, you can certainly make it work by using the raw config keys combined with a bunch of mount mangling to trick the snap into seeing alternative firmwares.

/snap/lxd/current/share/qemu/ is where the firmwares are stored.
Of course as a snap, those are read-only, but you could make a copy of that directory and mount it over /snap/lxd/current/share/qemu/ which followed with a reload of LXD would have LXD use your copies rather than the original.

Obviously we wouldn’t be supporting such an environment though.

#3

Thank you @stgraber for the response and path forward. I imagine the mount mangling trick would lead to other complications with updates to the LXD Snap from that point forward. If I were to proceed, after getting the correct firmware into /snap/lxd/current/share/qemu/, would it be enough to add something like this to the “config:” section of the profile for the VM?

 raw.qemu.conf: |-
   [device "qemu_nic"]
   driver = "vmxnet3"

Not sure how to reference the “device”. Is it “qemu_nic”, “qemu_eth0”, something else? Didn’t see any clues to that in Qemu or LXD docs.

Seems the ability reference an absolute driver/rom/firmware path here could remove the need for the snap mount mangling.

#4

I don’t believe qemu lets us pass in a full path unfortunately.

As for the exact syntax, you’d normally want to look at /var/snap/lxd/common/lxd/logs/NAME/qemu.conf and then see what changes you want to perform there.

Though for both NICs and disks, I don’t believe we have anything left in qemu.conf at this point as both are handled through QMP.

This means that you won’t be able to override any NIC that’s managed by LXD, but you should be able to define additional ones using whatever driver you want.