Getting started Libvirt to self host home assistant.

This post documents my learnings from self hosting Home Assistant OS (HA OS) on a VM using libvirt/QEMU/KVM on Debian. A disclaimer that this has been a learning process for me. Do you have any comments or see any mistakes? Please let me know at hello@mail.usrprog.com.

I thoroughly recommend this post, which documents in great detail and very clearly how to setup VM networking with libvirt. I found it a very useful source for this effort.

Design and tech choices

HA - Container vs VM vs bare metal

It was desirable to me to have HA running on top of a vanilla Linux distribution (I am using Debian) so that I can use it for other use cases too such as pi-hole. This ruled out installing HA OS directly on the raspberry pi. HA has a limitation when run as a container that the Home Assistant Add Ons Store is not available, otherwise I would have gone the docker container route. There are some addons that are quite appealing such as being able to bridge to homekit. Therefore I opted for installing HA on a VM.

Hypervisor

For running the VM, I considered Vagrant and VirtualBox, which I have experience with for local development usecases, but not for running on servers. I decided to try KVM as the hypervisor, with qemu on top, with libvert as the interface to interact with QEMU/KVM. This option was appealing due to KVM being free, open source and extensively used by companies in production, not to mention an opportunity to learn something new.

Networking

The Home Assistant VM should ideally get its own IP address and be accessible on the local network,For this we will adopt a bridged network, configured using systemd-networkd. I experimented with using libvirt to configure networking, but I found it hard to use in comparison to configuring networking directly on the host.

Configuration as Code

I want the VM to be able to be easily reprovisioned. Therefore as far as reasnobly possible, everything will be configured in ansible, a configuration management tool I have experience with for similar use cases.

Steps

Networking

1. Install systemd-resolved for systemd-networkd. This network daemon is useful for its very declarative API - network configuration can be expressed entirely as a couple of small configuration files within dir /etc/systemd/network/

sudo apt install systemd-resolved

2. Define a network bridge, br0

[NetDev]
Name=br0
Kind=bridge

This bridge interface will serve as a virtual switch, which both the physical eth0 interface and VMs will connect to directly.

3. Configure eth0 interface to have br0 as a parent

[Match]
Name=eth0

[Link]
RequiredForOnline=routable

[Network]
Bridge=br0
DHCP=yes

The file name is not important, but it must end with a .network extension, and ordering should be considered.

Check the name of your physical interface. On my raspberry pi it is eth0, but yours might be different.

4. Configure br0

[Match]
Name=br0

[Link]
RequiredForOnline=routable

[Network]
DHCP=yes

5. Finally, we can ensure NetworkManager is stopped and disabled, and systemd-networkd is enabled.

sudo systemctl disable NetworkManager
sudo systemctl enable systemd-networkd

6. Reboot, verify everything is working

• Can you SSH into the machine?
• Can you ping the internet?

Configure the VM

1. Download qcow2 image of Home Assistant

… and decompress it (xz)

2. use virt-install to install the VM

virt-install --name haos \
            --os-variant=generic \
            --os-type=linux \
            --ram=1024 \
            --vcpus=1 \
            # the location of the downloaded and decompressed image, 
            --disk /var/lib/libvirt/images/haos.qcow2,bus=scsi \
            --controller type=scsi,model=virtio-scsi \
            --import \
            --graphics none \ 
            # the name of the networking bridge we just setup
            --bridge=br0 \
            --boot uefi \ 
            # disable secure boot - necessary to boot the HA VM
            --boot firmware=efi,firmware.feature0.enabled=no,firmware.feature0.name=secure-boot

Future Improvements

If you are configuring your server over ssh, it is easy to kick yourself out when making changes to systemd-networkd configuration. In future I intend to look at netplan for rolling out network changes. This tool has the concept of being able to try configuration and roll it back if not confirmed.