I’ll defer to experience 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?
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.
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.
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 (192.168.4.224), 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 192.168.4.119.
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
vnet0
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 127.0.0.1/8 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 192.168.4.119/22 metric 100 brd 192.168.7.255 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 172.18.0.1/16 brd 172.18.255.255 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 172.17.0.1/16 brd 172.17.255.255 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 192.168.4.1 dev br0 proto dhcp src 192.168.4.119 metric 100
8.8.4.4 via 192.168.4.1 dev br0 proto dhcp src 192.168.4.119 metric 100
8.8.8.8 via 192.168.4.1 dev br0 proto dhcp src 192.168.4.119 metric 100
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-e925ad04412b proto kernel scope link src 172.18.0.1 linkdown
192.168.4.0/22 dev br0 proto kernel scope link src 192.168.4.119 metric 100
192.168.4.1 dev br0 proto dhcp scope link src 192.168.4.119 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 192.168.4.119 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.
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?
Hello,
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.
First off, thank you for this wonderful guide. I successfully used it to guide me through setting up a dedicated VM on Debian, only had the ignore the netplan bits.
Just wanted to offer up one alternative solution for section 2.1 regarding Docker breaking the libvirt bridge. The solution provided absolutely does work, but I also found to have success with simply telling Docker that the bridge exists rather than force my own iptables rule in to the service override.
You can do this by creating /etc/docker/daemon.json and simply adding the name of the bridge to the file.
{
"bridge": "br0"
}
Then a quick systemctl restart docker and Docker will itself acknowledge the bridge and permit the traffic.
Thanks for this write up, got everything configured from this yesterday and now working on getting my zigbee configured also. Any luck on find out a method for the attachment issue?
Also something else you might want to mention is the command for making the image to start on boot (ie. virsh autostart hassos)
What exactly is the attachment issue you refer to? That it sometimes doesn’t work after a system reoboot? For that, I haven’t found a great solution.
My workaround is that I use JuiceSSH (there might be something similar for iOS?), and have just made a profile that automatically logs in, and runs the detach/attach commands (I’ve put them in the guide under 4. After install). So still something done manually, but (literally) a click of a (virtual) button.
I guess because of that, I haven’t put much time into finding a proper solution, but please let em know if you do!
@Both, sorry, I can’t give thanks in the original post, since it will only allow mentioning 10 users in one post.
I was replying to your post from June 28th where on reboot it sometimes isn’t attached. I just got mine up and running this morning so I’ll be monitoring to see if I have the same issue or not.
I was able to get through the guide but I’m not able to connect to the web interface. When I go to the hassos console and type ip addr I see a hassio item but it’s a 172. ip and not a 192.168. ip. Not sure how where to look next. Any ideas?
The Homeassistant Web-Interface is reachable from outside the HASS-OS.
First try :8123 e.g. http://192.168.xxx.yyy:8123. If this also fails, then look for the address of the bridge
I’ve updated the guide to include your solution, thanks for the pointer.