I have been struggling to achieve what I thought was a very common way of connecting your virtual machines to your LAN: bridged networking but it turned out to be extremely laborious, mostly because non of the many online tutorials on the matter provided anything close to the solution. So I'm posting my solution (?) here to share but also to validate whether it actually is a good solution.
So I'm starting on a freshly installed OMV 5.5.3-1 (with proxmox kernel) and a KMV image that has previously been running on another machine. I was able import to the image into Cockpit and the VM has network connection when I choose "Direct attachment".
The problem is that "Direct attachment" implies that the VM can access the LAN and the LAN can access the VM but the VM cannot access the host. So bridge mode is what I want, which translates to "Bridge to LAN" in Cockpit. What Cockpit doesn't tell you is that if you choose "Bridge to LAN" as your interface type, your source must be an actual bridge, not an ethernet card or anything else. And, even worse, Cockpit (at least the version that OMV installs) doesn't seem to provide you any way of actually creating a bridge. Neither does OMV.
So I'm back to the command line but in order to find the right way of creating and managing a bridge, I need to know how OMV manages network devices. Is it via /etc/network/interfaces? It looks like it, because changes in that file (more correctly in /etc/network/interfaces.d will be picked up upon reboot. But that is also strange because OMV/Debian 10 is supposed to have switched to netplan and systemd.
So I decided to follow Major Hayden's famous tutorial on How to create a bridge for virtual machines using systemd-networkd (well, almost: I used DHCP instead of static IPs) and while it provided me with a br0 to select as a source for my VM in Cockpit the VM never received an IP from the router (despite ip a showing that it actually is connected to the bridge which itself did receive an IP). At some point I even managed to have the bridge get its own IP and the host get another. But the VM never got any.
So I figured that - for whatever reason - virtual machines are not per default allowed to properly join the club so I dug deeper into how systemd-networkd works and figured that I need to somehow tell systemd that any VM showing up should get its IP via DHCP. I found instructions on telling systemd that any ethernet card that shows up should be referred to the DHCP server (use en* as a selector under [Match] but I wasn't quite sure how to achieve the same for virtual machines but since vnet0 kept popping up in different places when the VM was running, I tried vnet* and... tadaaa it worked: my finally got an IP and was reachable from the LAN while it could also reach the host.
So, more specifically, in addition to Major Hayden's instructions, I also created a mydhcp.network (in /etc/systemd/network/) that looks like this:
This is not the end of the story yet, but let me pause here for a second and ask: am I the first one trying to run a VM in bridged mode? I don't think so. But why am I running into all these problems then, that no one else seems to run into? What am I doing wrong? Please let me know?
And please let me know whether there is a better way of doing this, because even though networking now works flawlessly (as far as I can tell), networkctl still thinks that things are not working as they should (see line 6/IDX 4):
# networkctl
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 enp0s31f6 ether degraded configured
3 br0 bridge routable configured
4 vnet0 ether degraded configuring
5 docker0 bridge routable unmanaged
7 vethdd5f630 ether degraded unmanaged
6 links listed.
So if things are working fine, why don't I just ignore that vnet0 is degraded and stuck in configuring? Well, because "someone" does care about vnet0 being stuck in configuring (or rather: being reported as being stuck in configuring) and that "someone" is systemd-network-wait-online which, in turn leads to cockpit not starting properly:
Apparently this is a bug in systemd (see https://github.com/systemd/systemd/issues/6441) but, again, if this is so (and if it exists since three years), why are apparently so few people affected by it? What am I doing differently?
And what is the best way of handling this bug? This answer suggests to mask the process, but I'm not sure I want to do that since the main reason I migrated to OMV is that I do not want to mess too much with the OS and let OMV take care of these things...
Edit: I solved this by doing my config in netplan instead of systemd. See this post below.