I have figured out the problem. Turns out although in ip a, the MAC is the same, yet in the vm, the MAC is different.
As for being assigned the same IP, it is just my stupid router... Getting a new MAC (creating a new VM) fixes the issue.
this post was submitted on 10 Aug 2024
8 points (90.0% liked)
homeassistant
11984 readers
6 users here now
Home Assistant is open source home automation that puts local control and privacy first. Powered by a worldwide community of tinkerers and DIY enthusiasts. Perfect to run on a Raspberry Pi or a local server. Available for free at home-assistant.io
founded 1 year ago
MODERATORS
That's a configuration problem you've made somewhere: you shouldn't be assigning an IP to the bridge and it's constituent interfaces.
You should take a look at your network config, and run (I'm assuming) dhcp only for br0.
Once you define the bridge network in virsh, and use that to make your VMs, kvm/qemu will assign unique MAC addresses to the VMs, so all you really need to sort out is getting your host OS to only assign an IP for the bridge.
Edit: also checked and yeah, eno2 and br0 and virbr0 are all different MAC addresses; did you maybe pick an option that forces them to inherit a MAC or something?
Hi, thank you for your reply.
Did you make sure that eno2 is enslaved by br0? When br0 is created, it indeed have a unique MAC, but once it enslaves the hardware, it inherits the hardware address.
I have not tried to get the bridge going with virsh, but I was unsuccessful with the virt-manager ui. And I assume they use the same system?
It is possible I have accidentally disabled some network virtualization kernel component during setup, as I have implemented some mods from secureblue. I will try to reset everything to default, and try again.
Do you have a tutorial for making bridge via virsh that you can share.
My nas isn't running fedora and thus isn't using whatever fedora uses for network definitions, but is netplan under ubuntu.
I mean, probably the same thing, but it was shockingly trivial to configure:
network:
ethernets:
enp0s31f6:
dhcp4: no
dhcp6: no
version: 2
bridges:
br0:
interfaces: [enp0s31f6]
addresses: [x.x.x.x/24]
gateway4: x.x.x.x
nameservers:
addresses: [x.x.x.x, 8.8.8.8]
parameters:
stp: true
forward-delay: 0
dhcp4: no
dhcp6: no
Disabled addresses on the physical interface, added the bridge section and told it which interface(s) to bridge - in this case it'd be the real interface and whatever gets added later by qemu/kvm, and then defined the IP address info.
the virsh network xml file was also straightforward, just make a xml file similar to:
<network>
<name>host-bridge</name>
<forward mode='bridge'/>
<bridge name='br0'/>
</network>
and then it's just
virsh net-define your.xml.file.here
virsh net-start the-name-you-used-in-the-xml
virsh net-autostart the-name-you-used-in-the-xml
virsh net-list --all
Should show up in the net list, and be selectable by name when making a VM
Thank you for the configuration. I wonder, because you have turn dhcp off for the host, will this prevent the host from getting an ip address?
No, because the bridge interface becomes the primary interface as far as Linux is concerned.
You'd just use dhcp to assign an IP to br0 instead of the physical ethernet device, though for a server a static IP is probably a better choice (so that it doesn't bounce around on your local network making it harder to access)
Sorry, a stupid question.
If the bridge is the primary interface on host, and the homeassistant KVM also uses this bridge, will this cause them to get the same IP again?
Thank you for your patience.
Unless there's something wonky with your virsh configuration, no.
This is a shitty explanation and if anyone would like to explain it better feel free, but the bridge interface acts as sorta like a network switch that can forward packets as well as be used for an interface, if configured.
What that means is, essentially, your VMs will be attaching their ethernet devices to a "switch" that then routes the packets out to the local LAN as if it were, well, a nic plugged into a switch.
virsh shouldn't assign an in-use MAC, as it generates a random one (and I have no idea what you'd have to do to make them not do that) so everything should... just work.
The bridged adapter can't have the same MAC address. Two of the same MAC address can't exist in the same IP space, else the router can't route packets to them. Just change the bridged adapter's MAC address to something else.
Is there an issue with using Docker for this? Seems like an easier route.
Edit: I'd venture a guess that if in NAT mode, the MAC address might stay the same, which wouldn't be an issue. Are you positive it's actually using bridged mode?
Two of the same MAC address can't exist in the same IP space, else the router can't route packets to them.
Yes, this seems to be my problem, both the host and the vm got the same IP, and I think I cannot send any traffic to either my host or vm. So my router is probably confused, as you suggested.
Is there an issue with using Docker for this?
I forgot to mention this, docker indeed work. However, ha requires a privileged docker running as root, which means ha essentially runs as root on the host.
This is fine on dedicated hardware, but as my server have other infrastructure on there, running ha as root can be a security risk.