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

Community Guides
16

Hey wmaker!

You are probably right. I also see no need to assign eno1 an IP address, since all traffic in + out the host should be routed through the bridge. But that’s also my 2 cent.

And most definitely, you have to create the xml file for kvm and make your bridge known! I missed this (I would say fundamental step) is missing in the above guide! This is crucial.

As for netfilter all I can tell you is my virtual machines (and I tried to setup a couple) would not get any IP traffic at all until I did this. Maybe it’s the other way round and you need netfilter to do be loaded. But then again, this is where Ubuntu does it’s magic and I really don’t have the time to go that deep. I’d prefer I had to proactively do my configuration, than “magic” happen under the hood.

I hope we can help with our comments :smiley:

17

Hey @oldrobot & @wmaker, thanks for the inputs.

I noticed that indeed virsh net-list --all doesn’t show the br0. It shows up with brctl show though, and the VM has internet when using the virt-install command in the guide. My physical interface has no IP, but the bridge does. Regardless, all my VMs having internet by using the br0. Is it still advisable to create a host-bridge.xml file and add the br0? What will this mean (what will the actual difference in behavior be)?

Good point, I’ll clarify in the guide. Thanks! (though the qcow2 image came as a .gz file back when I made this guide, so if that changes every now and then, perhaps I’ll just note that it should be unzipped).

Is this what you see by ufw status verbose? If so, mine shows Status: inactive, which is probably why I didn’t need to do this step (and thus why I didn’t include in the guide). Could this be a change in Ubuntu 20.10 v 20.04?

18

Hi @Aephir

I’m looking at your brctl show and it shows that vnet0 is associated with br0 and as well, en01 is also associated with br0. To me this explains how the traffic flows successfully.

My observation has been that when qemu/kvm starts up a VM it creates an interface vnetX (X being 0, 1,2, etc, one for each VM being started). qemu/kvm virtualization has to know which bridge to assign vnetX to and my presumption is it knows this using --network bridge=br0. But since br0 is not in the netlist, it apparently takes --network bridge=br0 at face value. So… I’m not really sure know how to answer your question, but I would suggest as a best practice, that the xml file should at least be mentioned, maybe a pointer to another web page that shows how to do it.
EDIT: Having thought some more, I’m speculating that the net-list is only needed by virt-manager as its GUI is used show the user what bridges are available to use and for the user to select one. So with that, I now think it is not necessary to include the creation of the xml file.

I don’t think ufw status is an adequate indicator. Instead, run the comand $lsmod. There will be lots of output, but if you see the lines something like:

br_netfilter           24576  0
bridge                155648  1 br_netfilter

Then the netfilter is running on the bridge. If it is not, then disabling the filter would have no affect.

19

NOTE: Disregard update for now. The Hass I could access in this way was the instance I have running in Docker. I’m working on finding the update to give network to the VM with the updated approach. I’ve reverted the guide, since it is taking longer than I thought.

@wmaker, @seventh: I have updated the “network setup” part based on your (and other) input, thanks for the suggestions. Hopefully it’s better this way.

Now we create a vlan on the eth interface, a bridge on the vlan, and set up the VM on that.

@seventh: If you do end up trying this approach, please let me know if you try without setting DHCP reservation before first HassOS boot, I’d like to know if that step is necessary :slight_smile:

20

This is great! I need to map my usb z-wave stick into the VM. It’s mounted as:

/dev/serial/by-id/usb-Silicon_Labs....

if someone could point me to the correct incantation to get that inside my VM somehow… I would be grateful

21

@ha_steve: I was going to update the guide to include this part as soon as I’ve done it in practice. But I’ll throw in the notes I have for now (so no guarantees, I haven’t done this myself yet).

Guide taken mostly from here.

(Of course, adjust the ID’s and paths as needed for your system.)

Find the idVendor and idProduct of the USB device you want to attach.

lsusb -v

A few examples from my system, an Aeotec Z-wave:

  idVendor           0x0658 Sigma Designs, Inc.
  idProduct          0x0200 Aeotec Z-Stick Gen5 (ZW090) - UZB

And a ConBeeII stick:

  idVendor           0x1cf1 Dresden Elektronik
  idProduct          0x0030

[NOTE] Can also be attached using device address on host, though that might change if they are unplugged or host is rebooted.

EDIT I think you need one file per USB device. Below I have used the ConBeeII stick as an example.

With the above, create an xml file:

sudo nano /var/lib/libvirt/images/hassos-vm/conbeeii.xml

And insert

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

[NOTE] - the “managed=‘yes’” makes it behave as if “nodedev-detach” and “nodedev-reattach” had been called at correct times, so you shouldn’t need to do anything else.

Then you can attach USB devices using virsh

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

[Note] use “virsh detach-device [DOMAIN] [FILE]” to detach, where it will reattach again upon next boot. Add “–persistent” to this, to make the detach persistent.

4 Likes
22

@Aephir - thanks for this! I have it working now!

One additional question. Do you have a way of connecting to the console?

23

Good to hear, and thanks for being guinea pig before I had to test on my own! That gives me a little peace of mind before pulling the plug, and moving my old (unsupervised) Docker setup to a shiny new VM :slightly_smiling_face:

I use the “SSH and Web Terminal” add-on for what I need in HassOS, would that work for your needs?

24

I have followed all this tutorial step by step, and at the end I get an error:

Error: --boot uefi: Don't know how to setup UEFI for arch 'i686'

What can I do now? Im using an Asus Laptop (1201ha) and even if it has BIOS vt support, it’s a 32 bits machine… any workaround?

Update: I’m trying with: --archx86_64 but now i get:

Error validating install location: Distro 'rhel8.1' does not exist in our dictionary

I see with osinfo-query os many of them, rhel from 12.1 to 17.5, and doesn’t matter what i use, I got the same error over and over again :frowning:

By the way I’m using minimal ubuntu 18.4 for 32 bits, since my laptop is kinda old.

25

First off, I have no idea if it works on 32 bit, I guess I should specify that. But I’d be interested to see if it does!

Secondly, I might have made a typo in the guide (copied the wrong command after testing a few different ones). Try installing without specifying the os-type, so use the below instead of step 3 in guide:

cd /var/lib/libvirt/images/hassos-vm
virt-install --import --name hassos \
--memory 2048 --vcpus 4 --cpu host \
--disk hassos.qcow2,format=qcow2,bus=virtio \
--network bridge=br0,model=virtio \
--graphics none \
--noautoconsole \
--boot uefi

Note that I also decreased the amount of RAM. If you run 32 bit version, you have a maximum of 4GB, and the base OS (Ubuntu) says minimum requirements is 2GB (well, I think that was for the desktop variant, so likely lower minimum requirements for CLI only. But not zero.). So I’ve only allowed 2 GB to the HassOS VM in the above.

Also remember you might need to change the vcpus if needed (depending on your CPU).

And @mabusdogma, please let me know if this works so I can fix the guide :slight_smile:

26

Sadly it does not work, I’ve changed everything as you said on your last comment and now I get this:

this kernel requires an x86-64 CPU, but only detects an i686 CPU, unable to boot

:frowning:

Maybe a workaround is to virtualize a RbPi 3 or something 32bits… I’ll try, I hope it works

27

I found this guide that says

… choose either Other Linux 32-bit or 64-bit depending of your system…

This one uses the VDI image. I’m not sure KVM supports this (?), but you might try one of the other images? Or maybe ask in the Discord channel, there might be a workaround (and old image that can then be updated once installed, or something like that?)

28

Thanks for this guide!

When I applied the netplan my ip address changed and I thought I had botched the config. So as hint to others: either specify an IP or double check the host ip before you re-install the OS :smiley:

Home Assistant is now running but I’m not sure what the best way to access the VM is. Using virsh console hassos doesn’t seem to work. Am I missing something obvious or do I have to install the ssh addon to get proper access?

The only solution I’ve found to enable the virsh console requires that you have access to the vm already so I don’t see a way around the ssh addon. Is that the way to do it?

29

Glad it helped.

I use the “SSH and Web Terminal" add on. It’s a "community add-on, that allows a bit more access than the default “Terminal & SSH”. I haven’t found (or indeed looked for) an alternative way to access. And to be honest, I haven’t been using supervised all that much. Is there a native way to access? I mean, if you flash HassOS on a RPi and plug in a monitor and keyboard, do you have shell access directly? If not, there might not be a way to do this in KVM.

And yes, I guess I should specify/recommend that a DHCP reservation is made for both the host machine and VM, to avoid any scares :slight_smile:

30

If the VM supports it you can run virsh console hassos to open a console into the image without having to configure SSH. It seems that hassos doesn’t have this activated and you need access to configure it. https://serverfault.com/questions/364895/virsh-vm-console-does-not-show-any-output

Either way, I guess I’ll use the addon.

edit:
Lessons learned for me:

  1. Executing netplan apply can cause you to lose your connection if you are doing it remotely. You may get a new ip address. I didn’t notice and thought I had botched the config.
  2. The hassio vm ip apparently can’t be configured via netplan. It should come from the vm itself (I think home assistant has it in settings menu) or from your dhcp server.
  3. The hassio image does not have a console you can use with virsh. If you want to enter the vm your best option is probably the home assistant ssh addon. From there you can potentially configure the kvm/quemu/virsh console.
32

What is the correct --os-variant ? is it really rhel8.1?

33

Oops, good catch. I think that was from an older copy-paste when testing, I can see I didn’t specify os-variant. Corrected in first post, thanks!

34

i think it makes sense to define the variant. the only thing you would need to know is which distribution the VM is based on.

35

Shouldn’t it be dhcp4: true instead of dhcp4: yes?

36

@broken.pipe As I understood, HassOS is not based on a single recognizable OS, but is made in some different (mashup?) way. If you know the OS version that would make sense, please let me know, and I’ll add it.

@revolter Either is fine, you can use true/false, y/n, yes/no, on/off interchangeably. Either all lower case, or with an initial capital or with all caps. It’s pretty forgiving (in that regard, at least) :slight_smile: