homeassistant

12013 readers

106 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

[email protected]

[Question] Setting up a bridged network for HomeAssistant in KVM Fedora (mander.xyz)

submitted 2 months ago* (last edited 2 months ago) by [email protected] to c/[email protected]

11 comments fedilink hide all child comments

cross-posted from: https://mander.xyz/post/16531247

I have tried to follow several tutorial to setup using either ip or nmtui:

https://linuxconfig.org/how-to-use-bridged-networking-with-libvirt-and-kvm

https://www.redhat.com/sysadmin/setup-network-bridge-VM

However, the bridge inherits the MAC address of host after enslaving the host hardware enp1s0.... This causes my router to give both the host and the bridge the same ip address, making the ha instance inaccessible.

The red hat tutorial clearly show that the bridge and the host have different IP, so I was wondering if I am doing something wrong.

alternatively, I can set the home assistant vm to run in NAT and port forward from host, but I have several device that communicate over different ports. So it would be annoying to forward all these ports. Not to mention, many appliances don't have documentation about the ports they use.

I can also potentially use virtualbox, but it is not well supported on silverblue, especially with secureboot enabled.

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 2 points 2 months ago (1 children)

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

[–] [email protected] 1 points 2 months ago (1 children)

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?

[–] [email protected] 1 points 2 months ago (1 children)

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)

[–] [email protected] 1 points 2 months ago (1 children)

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.

[–] [email protected] 2 points 2 months ago

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.