Configuring Hassio on Libvert using qcow2 image

I have Hassio running on KVM using the QCOW2 image and thought i’d share the process i went through here for those that are starting off on the same path!

So initially I wanted to run Home Assistant on Docker! which i got running really easily using the below docker create statement:

`docker create \

–name=home-assistant \

–net=host \

–restart=always \

-v /home/$USER/home_assistant:/config \

-v /etc/localtime:/etc/localtime:ro \


docker start home-assistant`

I also got this working in Rancher and Kubernetes, which is awesome! I really enjoy Kubernetes and getting into my bash terminal as often as i can!

I then learn this doesn’t come with Supervisor Doh! have a read here Superviser on generic linux is on hold for the moment:

I then started my journey on getting this working on a Virtual machine using the provided on the Home Assistant website

I didn’t want to invest in a Raspberry PI just yet and wanting to run this on Linux box i picked the QCOW2 image and started using that, i had some initial issues with this due to the configuration that is required to get the image to boot, and at first i forgot to extract the gz file. Here are some commands to get the image form the site and unzip it.


gunzip hassos_ova-4.10.qcow2.gz`

Cool so once that is done assuming you have virt-manger and kvm installed you can run virt-manager to launch the manger.

Follow the details here to create the VM:

For KVM create a new virtual machine in virt-manager, select “Import existing disk image”, provide the path to the QCOW2 image above, choose “Generic Default” for the operating system, assign at least 2 GB memory and 1 vCPU, check the box for “Customize configuration before install” and select your bridge under “Network Selection”, then under customization select “Overview” -> “Firmware” -> “UEFI x86_64: …”.

I am running Ubuntu 20.04 and was able to boot the image using the below firmware:

<loader readonly='yes' type='pflash'>/usr/share/OVMF/OVMF_CODE.fd</loader>

Besure to “Customize configuration before install” and select this firmware, else the image won’t boot, which was one of the issues i had in the beginning. (My own fault)

Next step once you have this booted is to get the networking working so Hassio is running on your lan and not as part a NAT.

To do this i had to create a new bridged network with a slave selected as the physical network adapter on your machine. To find this physical adapter run ip a s and look for the ip ranges that are for your local lan. in my case it was the network CIDR the device this was called eno1. Your device name may be different and so will your CIDR range.

To create the bridge use nmtui, go to Edit a connection > then to add > select bridge.

Give your bridge a profile name, i used brige_home and a device name of nm-bridge1 you will need to select this later when you run virt-manager again to change the network settings

Then add an ethernet slave and give the device name of your physical network card, in my case eno1 it will fill in the MAC address for you so you don’t have to worry about that.

You can leave IPv4 Configuration as since you are most likely running a DHCP server in your network. Set IPv6 to disabled, since most users won’t be using this.

After this your will need to either reboot your host or restart the network service using:

sudo service network-manager restart

Once this is done go back into virt-manager > the VM you created earlier and change the network config to use the nm-bridge1 (the bridge your created earlier), this will place your Hassio on your local network so it can easily connection to all your IOT devices in your home without any natting issues.

Running virsh list will show you all the running VM’s that you have on libvert, it will print out something like the below:

`Id Name State

2 hassio running`

I hope you found this guide helpful in your journey to running Home Assistant with supervisor to take advantage of all its features! If you have any comments or improvements feel free to mention in the comments section.


1 Like

I’ll share my experience briefly just for information purposes (Ubuntu 20.04 on Intel). I did this with virt-manager a couple of weeks ago. I was able to follow the instructions here for the bullet titled: “For KVM…”. I followed the instructions exactly (except they left the unzip the image part out), including the part “under customization select “Overview” -> “Firmware” -> “UEFI x86_64:” which does the same as you mentioned (uses firmware UEFI x86_64: /usr/share/OVMF/OVMF_CODE.fd)…was amazed that it came up the first time, no issues :slight_smile: :slight_smile:


How did you go with getting the VM running on your local network?

I didn’t mention, but I already had a bridge that I created for my VMs. I wanted to have an ability to reach my VMs from the QEMU/KVM host. I created this bridge very similar to what you did.

There is another way that should work to get the VM on your local network w/o NAT. Before I started using this bridge, I would setup my VMs using virt-manager to have the NIC use macvtap with source mode = bridge. This allowed entities on my LAN to be able to reach the VM and vice-versa. The drawback was I was not able to reach the VM from the QEMU/KVM host.

So far following the vague instructions on the home-assistant install page, I was able to install hassos running in a KVM using the provided qcow2 file. I figured out the network bridge part and have that working, but I can not seem to figure out storage. Once my add-ons are install and I enable recorder for history I run out of space within the day. It looks like the image that is installed with the qcow2 file makes a 6Gb volume and I can’t figure out how to make it bigger or put it in a different direction location. I’m hoping somebody here can point me in the right direction. Thanks.

Hi, You can resize the image using qemu-img toolkit, first stop your Hassio Virtual Machine, “virsh shutdown hassio”

To check the current size of your image:

qemu-img info /home/phoenix/hassio/hassos_ova-4.10.qcow2

Mine is also 6GB by default, here is how you can make a backup of the qcow2 image:

cp /home/phoenix/hassio/hassos_ova-4.10.qcow2 /home/phoenix/hassion/hassos_ova-4.10.qcow2.bak

Resize the image and check if the change applied:
qemu-img resize /home/phoenix/hassio/hassos_ova-4.10.qcow2 +10G
qemu-img info /home/phoenix/hassio/hassos_ova-4.10.qcow2 - you should see the image has increased by 10GB

Then fire the machine backup with virsh start hassio.


Example command for running in KVM in case anyone is finding this thread

[01:35:08] root@openhab:~# cat
 virt-install \
  --name home-auto \
  --memory 2048 \
  --vcpus 2 \
  --disk  /home/home/hassos_ova-5.8.qcow2 \
  --import \
  --os-variant generic \
  --network bridge=br0 \
  --boot uefi

[01:35:17] root@openhab:~#

Hi, all.
I follow this steps and resize my qcow2 Image…
…i check the size with qemu-img info… and size is correct…
but Home Assistant keep on say Used Space 72%!?

need suggestion Please
Thank you

I did a little research on this (as I figured I would eventually have to do this), and it seems for some people, resizing a qeum/kvm image not only increases the VM’s disk size, it also increases the partition on the disk, but for others it doesn’t increase the partition. I did a little experiment and my resizing (using qemu-img resize) seemed to also increase the partition as well. If you go into hassos console at the root linux prompt and run lsblk you should see that the disk sda increased in size to about the size of resized image, and the partition sda8 should take up most of the sda disk space.

If you find this is not the case, yet qemu-img info says the virtual size increased, it could be you need to resize the partition. There are different ways to resize the partition, and I found on this forum that another user had used gparted.

I gave gparted a try just to see, and it did showed that the sda8 partition had no free space to grow and thus confirmed that its partition had already been expanded (somehow). If you’re interested in using gparted, I can provide some detailed instructions (using virt-manager), but you basically download the gparted-live iso, and add it as a CDROM to the hassos VM and boot from it instead of hassos. gparted-live runs as a GUI and it is not too difficult to figure out. When done, just remove the CDROM and make sure to boot from hassos.

Thank you for answer.
I have solved the problem using qemu-img resize one more time adding more 4 gb to the image after instatlling HA 5.9 …now HOme Assistant can see the expanded partition and now used space is 2%…correct.

I dont know why after resizing for the secont time with HA 5.9 installed make the new increased partition been seen from HA.
I no have the knowledge to say it,but for me the problem is solved.

May be this can be usefull to other users that accours in the same problem…

Thank you

I hosed my native Debian 10 based supervised Docker installation a couple of weeks back and thought I’d give the KVM route a go. Unfortunately, I’ve not been able to get it going at all. I built a separate box with some considerable power to run multiple virtual machines and hoping that I can get a supervised installation of HassOS on it eventually. Right now the system consistently boots straight to the UEFI shell. I have my network setup correctly, but just don’t seem to be able to get the system to boot.

The new system is running Ubuntu 20.10 Server and tried booting hassos_ova-5.10.qcow2 as well as a 4.x version - same results. It seems like it’s a UEFI boot issue, but I’m out of ideas.

As a test, I configured a new Hyper-V VM and have run the VHDX posted on the HomeAssistant website. This works fine, although I did have to setup a NAT to get the IP addressing working as I wanted. Regardless, I would prefer not to run Windows 10 on my home automation server. I’d like to run it as a VM in KVM running on Ubuntu Server of any flavor that actually works.

Here is another thread to look at which uses QEMU/KVM on Ubuntu Server:

Thanks for sending that link. I had Googled and found that one as well. I have 2 computer systems, both of which do not boot the qcow2 images available on the webpage. System #1 is an Asus board with integrated Celeron 847 dual-core, very low power. System #2 is a Supermicro X8STE mobo with Xeon E5606 quad-core CPU, all server hardware. Neither of these systems will boot the qcow2 image from KVM on Ubuntu Server 20.10 or 20.04. The only image I’ve had any success with is the VHDX running as a Gen 2 VM on Hyper-V on my Windows 10 workstation. Configuring the network bridge on Windows is a nightmare, but I managed to do that and confirmed that the webpage loads and everything.

At this point, I’m thinking of throwing in the towel and setting up the native supervised installation that is not running in a VM. I’m talking about this one. However, taking a snapshot of the disk image once configured correctly takes significantly longer than dealing with VM snapshots and I can’t help but think that this is probably a seldom used approach, although it does appear to be a valid supported installation type.

After much messing around, I gave up on KVM. I shifted my efforts towards configuring VMWare Workstation Player 16, which is free for home use. That didn’t work out very well either. I finally gave up on that as well and moved to VirtualBox. VirtualBox actually works after importing the VDI. So the only working virtual images I’ve been able to get working for HassOS 5.10 are the Hyper-V VHDX image and the VirtualBox VDI.

I had given up on KVM completely and ditched the entire HA project for many months. Things changed and I finally got the old box out of the closet and fired it up, this time running CentOS 7. Again, ran into the aforementioned issues with UEFI boot. The solution is documented here: Can't boot hassos? (x86_64 KVM VM) - #7 by q500dude

The EDK2 firmware is required to boot the qcow2 image provided.