I’ve set up a VM with macvlan to give the VM its own MAC address so it can obtain a unique IP address in the greater network, but I want that VM to be able to talk to the host. (...eth0 nic nictype=macvlan parent=eth0)
On Proxmox, they have something cooked up so attaching a VM to their “bridge” gives it its own MAC address while still being able to talk to the host.
What is the best way to achieve “host and VM can talk, but VM has its own MAC address so it appears to be an independent device to the rest of the network”?
I’ve done a lot of reading but no path is clearly the right way, especially with the rise of the next generation of networking tools (ip and the like replacing the older ones). Thanks!
Shame that routed doesn’t have a unique MAC address, I’d rather have the router do all IP assignments than the device declare. But that can work, thanks for the link on it! I had forgotten to search “LXD” instead of “incus” for this.
I’ll leave it open in case someone has a way to get the functionality Proxmox has.
If you create your own bridge on the host and attach it to one of your physical interfaces, you can then use incus bridged networking using the host’s bridge as its parent. You would need to define the bridge with something like systemd-networkd or netplan. The only tricky part is that if you have your host’s ip address on the physical interface, you have to put the ip on the bridge.
Thank you @yokem55 and @jarrodu, those words were very useful to search my way through it. While Incus doesn’t have the ability to do it itself, it can interface with it easily.
For anyone finding this via search, here is what I did:
# Get default ethernet
# Don't use this if you've got multiple ethernet ports and you want to use a specific one.
# Will work for a single port just fine
MAIN_ETH=$(ip -o -4 route show to default | awk '{print $5}')
MAIN_ETH_MAC=$(ip -o link show "$MAIN_ETH" | awk '$2 != "lo:" {print $17}')
# Prep systemd-networkd to happen
sudo mv /etc/network/interfaces /etc/network/interfaces.save
sudo systemctl enable systemd-networkd
sudo systemctl disable NetworkManager
sudo mkdir -p /etc/systemd/network
# Set ethernet to go to the bridge
sudo sh -c "cat <<EOF > /etc/systemd/network/uplink.network
[Match]
Name=$MAIN_ETH
[Network]
Bridge=br0
EOF" || exit 1
# Set up bridge
sudo sh -c "cat <<EOF > /etc/systemd/network/br0.netdev
[NetDev]
Name=br0
Kind=bridge
MACAddress=$MAIN_ETH_MAC
EOF" || exit 1
# Set up bridge's network device
sudo sh -c 'cat <<EOF > /etc/systemd/network/br0.network
[Match]
Name=br0
[Network]
MulticastDNS=yes
DHCP=ipv4
[DHCP]
UseDomains=yes
EOF'
# System reboot required, starting then restarting systemctl restart systemd-networkd did not work
sudo reboot
After the reboot your new main network device (assuming one ethernet port) is now br0 and whatever your old main one was (enp2s1 or something) just chills. br0 gets the same MAC address as enp2s1 so to your network’s DHCP server it’s like nothing changed at all.
And I add the new br0 system bridge to the profile Hoss with:
sudo incus profile device add Hoss eth0 nic nictype=bridged parent=br0
You can of course add it to a container directly instead of a profile. Super similar syntax.
I went for systemd-networkd because Debian doesn’t come with netplan and NetworkManager had a weak CLI game; guides for NetworkManager referenced using the GUI for essential steps, not feasible on a CLI-only server.
And they only could figure out how to do that with the GUI. I couldn’t google myself out of that one, sadly, so I binned that route. I started with NetworkManager because Debian has it on by default.
And not to slander NetworkManager too much more, but I found that some commands want the device’s friendly name and some want the device’s actual name confusing - but clearly that setup is leaps and bounds better for using it (Wired Connection 1 is much more clear about what it is than ens2p0). I would’ve gone with it if I had a GUI to fall back on!