Install Home Assistant OS with KVM on Ubuntu headless (CLI only)

@hasst passing the NIC directly into the vm should work. don’t know how you do it manually. I achieved it once using cockpit and its kvm addon.

What software do you use to connect to your router? systemd? NetworkManager? this should work pretty straightforward as long as you disable the netfilter

@Aephir instead of disabling bridge filtering there’s more elegant way that may not break some of docker features, assuming vmbr0 is the bridge for KVM, took me some time to find this out to make it proper instead of disabling bridge filtering

sudo systemctl edit docker.service

paste the following snippet

ExecStartPost=/usr/sbin/iptables -I DOCKER-USER -i vmbr0 -o vmbr0 -j ACCEPT
sudo systemctl daemon-reload
sudo systemctl restart docker
1 Like

@MrksHfmn I’m using systemd with netplan and edited /etc/netplan/00-installer-config.yaml as described in the first post, like so:

# This is the network config written by 'subiquity'
  version: 2
      dhcp6: no
      dhcp4: no
#        addresses: []
#        gateway4:
#        nameservers:
#            addresses: [,,]
      dhcp4: true
      optional: true
      interfaces: [ enp2s0 ]
      addresses: [ ]
        addresses: [,, ]
        stp: true
        forward-delay: 4
      dhcp4: no
      dhcp6: no

I suspect netfilter is still active as DHCP requests are making it out to my router but the VM doesn’t get the response. I double-checked those settings with:

# sysctl -a | grep brid
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-filter-pppoe-tagged = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
net.bridge.bridge-nf-pass-vlan-input-dev = 0

And it seems like netfilter is turned off so I don’t understand why the DHCP response isn’t making it back. I have it on a regular LAN as the host which gets traffic fine. Any idea?

@hasst I’m not familiar with netplan, but reading this yaml I found two issues:
enp3s0 is your normal NIC?
enp2s0 is the NIC you would like to bridge? The device itself must not get any IP address, but the bridge! so dhcp4/6 should be no/false.
The bridge br0 gets the IP assigned per dhcp. So you have to edit the config here and switch it to true (or yes; don’t know the syntax) and remove everything network related (dns, gateway …)

I don’t see anything particularly wrong with your settings (other than stp is not likely being used, so I would turn it off).
Looking at your earlier posting:

I’m trying to figure it out, but a couple of remarks:

  • brctl show - This seems OK. Its showing vnet0 on br0 which should mean your VM is up and running as it usually uses vnet0.
  • ip addr - You show this before and after virt-install. It looks like after virt-install, a new link was added called hassio. I was not expecting this. Instead I was expecting to see vnet0 being added with vnet0 using br0 as master. Today, does your ip addr still show a link named hassio ?

Hi @Aephir so to reassure you I am sysadmin for about 20 years, the knowledge for this i took from this:

and this iptables - Docker breaks libvirt bridge network - Server Fault
So since br_netfilter turns kvm machine into “L3 switch/router” by passing all bridged packets through iptables this is necessary as docker by default puts DROP policy on forward chain
Turning off br_netfilter is like disabling firewall for bridged interfaces including docker ones and the thing i proposed is just turning it off for kvm interface.
AFAIK if you don’t have docker installed you don’t have to do anything of the two as br_netfilter is not loaded

1 Like

So I’ve been trying to get this set up for a couple of days now - I followed @Aephir’s guide (but used the latest release of home assistant, haos_ova-7.4.qcow2.xz) , but have run into some issues.

First, I my netplan had to be modified as such so that I could create the bridge

    version: 2
    renderer: networkd
            dhcp4: no
            dhcp4: yes
                - enp0s31f6

I think the trick is having the dhcp4: no for the ethernets adapter enp0s31f6 in my case. That created the bridge, and everything seemed to work OK so far. I followed @gacopl’s instructions because I was also running some docker containers, and didn’t want to create issues. Things still seemed to be working up to this point.

Then I started the virtual machine with the command in the guide - and received this warning:

WARNING No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results

It did seem to run though, and I could virsh console hassos and get to the console. But nothing ever showed up in my connected devices list on my router. I then found and followed @bsr203’s instructions, and afterwards, the device showed up in the connected devices list, but I am unable to connect to the web interface. I’m not very savvy when it comes to networking, so any help is appreciated, and I do appreciate all of the help from OP, as well as the commenters!


I’ll defer to experience :slight_smile: I’ve updated the guide to include your solution, thanks for the pointer.

@stygarfield I haven’t personally tried @gacopl’s approach, so can’t really offer much help with that. However, the “original” way I did it (disabling netplan) never gave me any issues, and I’m running more than a dozen docker containers. Not saying it’s the best way (since it seems its not). It’s just the only way I have personally tried, and made it work.

Regarding the --os-variant; as far as I can see, hassOS currently builds on Debian 11 (Bullseye), but for me osinfo-query os doesn’t list any version higher than 9 as an option. I wasn’t sure about using a “wrong-but-close” version, so I omitted it.

Does anyone know what would be the best approach here?

1 Like

Maybe Debian 10? As long as it is selectable. Debian 10 is available under arch linux

From my understanding, HassOS uses buildroot as its generic Linux kernel and tailors the environment to provide more of an embedded linux based operating system, that is more like Alpine. --os-variant of generic should work.

1 Like

No joy with --os-variant=generic I didn’t get the warning, but still am unable to connect via web browser.

This may be late for you, but I did a little research on networkd as I am not familar with it. The way my Ubuntu is setup (I don’t think I changed this part), netplan is setup to use Network Manager as its networking backend (instead of networkd), as networkd itself is inactive on my system. So I think you may want to change the renderer from networkd to NetworkManager.

You should confirm that your bridge interface has an address that works for you and that the ethernet interface does not have an address. Type ip addr. See if br0 has an ip address that would work on your network, something like 192.168.blah-blah and that enp0s31f6 has no address . If this looks fine then just make sure you can ping br0 ip address.

When you’re in the hassio console, if you get a ha> prompt, then type login to get to a linux root prompt #. Type ip addr. You may get a long list of interfaces, but see if one of them has an ip address that would work on your network, something like 192.168.blah-blah. If you do have such an address, then at least you are on the right path.

Hey, I had trouble when starting my vms, got the errors Transport endpoint is not connected and stderr=access denied by acl file.
I found to create a file /etc/qemu/bridge.conf with the line allow br0 to be the solution.
Just sharing in case.

1 Like

First off, @Aephir: Thank you for the guide!

Like so many who have come before me, I’m running into a networking issue. I’ve done the whole setup, the bridge is up and I can use it to connect to the Linux host (Ubuntu 20l.04), I can virsh console hassos into the VM and see it’s running. I set HASS to have a static IP (, but what’s interesting is that I can ping that IP from the host, but I can’t ping it from any other hosts on my network. I initially tried DHCP for the guest but it didn’t work, so I’m assuming it can’t talk out to the general network at all. Unfortunately I can’t verify this because I can’t find any way to exit out of the HA CLI… every time it exit I just get sent back to the CLI login.

A few other relevant details:

  • The physical NIC is enp3s0. There’s a wireless NIC in there but I’m not using it and haven’t set it up.
  • I am running Docker containers on this host as well.
  • The host IP is

At any rate, below are the outputs of all the relevant commands I found in this thread. Any help would be appreciated.

# brctl show
bridge name bridge id       STP enabled interfaces
br-e925ad04412b     8000.0242e1764618   no
br0     8000.ee27c0a565fa   yes     enp3s0
docker0     8000.0242eaf3ed2b   no

# ip a | sed 's/..:.. /xx:xx /' | sed 's/:....:....\/64 /:xxxx:xxxx\/64 /'
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:xx:xx brd 00:00:00:00:00:00
    inet scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br0 state UP group default qlen 1000
    link/ether 2c:f0:5d:e0:xx:xx brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
    link/ether fc:44:82:76:xx:xx brd ff:ff:ff:ff:ff:ff
4: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ee:27:c0:a5:xx:xx brd ff:ff:ff:ff:ff:ff
    inet metric 100 brd scope global dynamic br0
       valid_lft 14260sec preferred_lft 14260sec
    inet6 fde0:5b67:ae88:1:ec27:c0ff:xxxx:xxxx/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 2591860sec preferred_lft 604660sec
    inet6 fe80::ec27:c0ff:xxxx:xxxx/64 scope link
       valid_lft forever preferred_lft forever
5: br-e925ad04412b: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:e1:76:xx:xx brd ff:ff:ff:ff:ff:ff
    inet brd scope global br-e925ad04412b
       valid_lft forever preferred_lft forever
6: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
    link/ether 02:42:ea:f3:xx:xx brd ff:ff:ff:ff:ff:ff
    inet brd scope global docker0
       valid_lft forever preferred_lft forever
8: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:3a:xx:xx brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:xxxx:xxxx/64 scope link
       valid_lft forever preferred_lft forever

# ip route
default via dev br0 proto dhcp src metric 100 via dev br0 proto dhcp src metric 100 via dev br0 proto dhcp src metric 100 dev docker0 proto kernel scope link src linkdown dev br-e925ad04412b proto kernel scope link src linkdown dev br0 proto kernel scope link src metric 100 dev br0 proto dhcp scope link src metric 100

# virsh net-list 
 Name   State    Autostart   Persistent
 br0    active   yes         yes

# virt-install --import --name hassos --memory 4096 --vcpus 2 --cpu host --disk haos_ova-8.1.qcow2,format=qcow2,bus=virtio --network bridge=br0,model=virtio --graphics none --noautoconsole --boot uefi --os-variant debian11

I don’t see anything obvious that is incorrect. I usually don’t see /22 subnet mask, and I usually don’t see dhcp handing out routes, but they should still work.

From another host, can you ping your host? If you can, then the only other thing that comes to mind, is perhaps a netfilter may be blocking forwarding of packets beyond the bridge.

In case you want to add periodic backups to your KVM instance:

1 Like

I’ve noticed something kind of annoying. I don’t really know why, or how to fix it, so any ideas would be very welcome!

I’ve attached a ConBee II stick by making a file /var/lib/libvirt/images/hassos-vm/conbeeii.xml with:

<hostdev mode='subsystem' type='usb' managed='yes'>
    <vendor id='0x1cf1'/>
    <product id='0x0030'/>

and attaching it with

virsh attach-device hassos --file /var/lib/libvirt/images/hassos-vm/conbeeii.xml --persistent

I wanted to add this part to the guide, but I have a slight issue I want to figure out first.

Upon a system (Ubuntu) reboot, sometimes my ZigBee won’t work, despite the stick still being attached to the VM. There’s an easy fix, just:

virsh detach-device hassos --file /var/lib/libvirt/images/hassos-vm/conbeeii.xml --persistent
virsh attach-device hassos --file /var/lib/libvirt/images/hassos-vm/conbeeii.xml --persistent

But it’s not always needed, sometimes it just still works. And in any case, is kind of annoying. Any idea how to fix this, so that’s not (sometimes) needed?

1 Like

I get this error, any idea what it could be?

emp83@EMP83-Ubuntu:/var/lib/libvirt/images/hassos-vm$ virt-install --import --name hassos \
> --memory 2048 --vcpus 2 --cpu host \
> --disk haos_ova-8.5.qcow2,format=qcow2,bus=virtio \
> --network bridge=br0,model=virtio \
> --graphics none \
> --noautoconsole \
> --boot uefi
WARNING  No operating system detected, VM performance may suffer. Specify an OS with --os-variant for optimal results.

Starting install...
ERROR    <built-in function virDomainCreateXML> returned a result with an error set
Domain installation does not appear to have been successful.
If it was, you can restart your domain by running:
  virsh --connect qemu:///session start hassos
otherwise, please restart your installation.
1 Like

As far as I can tell, that error means virt-install can’t understand the command. I don’t see any typos, so I’m not really sure what to say.

solved, added my user to docker group.

1 Like