Closed Ramblurr closed 3 months ago
There are many ways to do this. So far, I've been solving this with systemd-networkd.
Sure, we already support qemu's bridge helper but I fear that modelling too much host network configuration is broadening the scope too much for this VM abstraction project.
As a compromise I'm open to make this extensible with a script option.
but I fear that modelling too much host network configuration is broadening the scope too much for this VM abstraction project.
I agree with this 💯.
Instead of providing extra options for the existing systems sibling services that setup host networking, if you exposed a module options for users to include their own required systems services? On the other hand it's relatively simple to override that, so maybe that also isn't necessary.
Actually this is likely a case of PEBKAC, I missed one bit in my host's networkd config (I already had the bridge existing so I didn't bother changing it).
That is I forgot to edit the matchConfig.Name
to include the microvms' ifaces, which you've already clearly documented:
I followed the simple networking docs, but had the experience that the tap network was not working out of the box.
My host's bridge device is
brprim4
. This was my interfaces config for the guest:I inspected the
microvm-tap-interfaces@
service and saw that it wasn't setting the master iface (my bridge) for the tuntap device.Workaround
So I overrode the service's script with:
Then I restarted
my-microvm
and networking to the guset worked as advertised!In the working case,
ip link
shows:.. notice the
master brprim4
option, that is the bridge on my host.Compare that to what
ip link
shows when themaster
option isn't set:Why Me?
Why is this happening to me and not others following the docs?
I suspect because I have a more complicated network setup on my host. I have several vlans and other bridges for other activities. But I'm also not sure, I've never created a tuntap device and not specified a master, so I'm not sure what the default behavior is.
Proposal
I would propose adding a
tap.link
(ortap.master
?) option to the tap config, similiar tomacvtap.link
for themacvtap
type. For example: