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.
In case you want to add periodic backups to your KVM instance: https://thegabo.dev/backup-script-for-kvm-virtual-machines/
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'>
<source>
<vendor id='0x1cf1'/>
<product id='0x0030'/>
</source>
</hostdev>
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?
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.
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.
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)
@brady, thanks for the suggestion, I have added a note with a link to your post in the guide.
@Buster, same as above.
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.
Well, now I just upgraded to Ubuntu server LTS 22.04, and now I can’t get the ConBeeII to work anymore, and the “detach/attach” doesn’t work.
If anyone knows of a fix/trick I’d be happy to know 
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
Did you get the MAC? Assuming you called it hassos, then from the host (Ubuntu) CLI:
virsh dumpxml hassos | grep "mac address" | awk -F\' '{ print $2}'
Then look in your router for this MAC (and give it a DHCP reservation, if you haven’t already).
@Aephir I was able to find the mac and assign an IP but still not able to connect. Also, FWIW it’s showing as “unnamed device” in my router.
Tried both bridge and assigned DHCP ip assigned to the hassos kvm mac addr
Stopping the docker.service and containerd.service and reboot did work so must be something with the firewall?
Not really sure what to say, unfortunately. Maybe someone with more networking experience has a suggestion?
I’m trying to replace my old docker based Hassio with this but having a bit of trouble getting the network bridge for the VM working. Running Ubuntu 18.04.06 but will update to 20.04.5 before my next attempt at setting up. Normally I’d be happy to do more trial and error to figure this out but I’ve a few docker containers running on the same computer that need to stay available. Here’s the netplan config file I’m going to try. I want the docker images on 192.168.178.26 and VM/HAOS on 192.168.178.94
version: 2
renderer: NetworkManager
ethernets:
en7s0:
macaddress: aa:bb:cc:ff:ff:ff
dhcp4: no
addresses:
- 192.168.178.26/24
gateway4: 192.168.178.1
bridges:
br0:
dhcp4: no
addresses:
- 192.168.178.94/24
gateway4: 192.168.178.1
interfaces:
- en7s0
parameters:
stp: true
MAC address to be updated with real one.
Does that look right?
I needed to deploy this onto a ubuntu 18.04 install with a pre-existing docker configuration and didn’t want to disturb the bridge between my containers and the primary interface mapped to my DMZ VLAN.
I wanted home assistant to sit on my internal VLAN, but trunking the VLANs into the NIC and creating virtual interfaces mapped to independent bridges seemed overkill.
After adding a second NIC to connect natively to my internal VLAN, I attempted to follow these instructions again. That led to a competing default route added to the routing table on the host, breaking SSH and my docker services. No bueno.
I contemplated setting up a VRF to isolate the interface/subnets routing, but ultimately decided on skipping L3 configuration on the new interface/bridge in netplan altogether. This has a couple benefits:
This worked out super well, as the hassos runs its own TCP stack anyway. I just let that do its thing instead of trying to arbitrate it.
For anyone attempting to replicate this here’s the netplan:
# This is the network config written by 'subiquity'
network:
ethernets:
enp0s31f6:
dhcp4: true
enp1s0f0:
dhcp4: false
version: 2
bridges:
br1:
interfaces: [enp1s0f0]
dhcp4: no
The second NIC is enabled, but doesn’t participate in any L3 services, it just acts as a hook for a bridge, which also doesn’t run any L3 services.
Point the virt-install to the new bridge et voilà , you’ve got yourself a KVM-based hassos install running along side existing services without messing with their networking at all.