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

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

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.

  • schizo@forum.uncomfortable.businessEnglish
    4·
    3 months ago

    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?

    • baseless_discourse@mander.xyzOPEnglish
      1·
      3 months ago

      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.

      • schizo@forum.uncomfortable.businessEnglish
        2·
        3 months ago

        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

        • baseless_discourse@mander.xyzOPEnglish
          1·
          3 months ago

          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?

          • schizo@forum.uncomfortable.businessEnglish
            1·
            3 months ago

            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)

            • baseless_discourse@mander.xyzOPEnglish
              1·
              3 months ago

              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.

              • schizo@forum.uncomfortable.businessEnglish
                2·
                3 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.

  • just_another_person@lemmy.worldEnglish
    3·
    3 months ago

    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?

    • baseless_discourse@mander.xyzOPEnglish
      1·
      3 months ago

      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.

  • baseless_discourse@mander.xyzOPEnglish
    1·
    3 months ago

    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.