Hi,
been running HA Core on my DietPI server for quiet some time now. now that I am using it more and more i am running into shortcomings that when trying to patch make the system to difficult to maintain: e.g. I want to add matter devices without a matter hub, so i installed a matter-server as docker image (which works), but when trying to build upon that I am really (!) missing the HA addons.
So before ‘crippling’ my dietPI setup with HA Supervised install (network not manageable via DietPI anymore), I’m investigating if running HAOS as a guest on DietPI as a host is something somebody here already has running / tried.
Any thoughts on this from the community would be great: do’s / dont’s etc.
Thanks in advance for sharing your thoughts on this!
regards,
Ruud.
Of you are using HA only on thay device, why not using HAOS directly? Also, while HA supervised is messing with the network, at least it can then also manage it (I suppose).
Since HAOS runs HA within a container already (right?), running it itself in a container would be doubled container layer. Not sure if this is gonna work well. But of course you can test it. systemd-container package => systemd-nspawn command can “boot” rootfs directories without any further needs, in the most sinple case with direct hist network access.
Thanks @MichaIng for chipping in with your thoughts,
DietPI is use to run multiple services on my network, HA being one of them. The HA Core has become just to limited as it lacks the addons.
What I learned is that HAOS runs it functionality in multiple (maintained) docker containers.
My idea was to install Qemu / kvm (or another virtualisation layer) on DietPI so that the DietPI server can act as a host.
HAOS also comes in a maintained qcow2 file (Linux - Home Assistant): When I can run that as a virtual guest on top of DietPI the DietPI would be serving full HAOS functionality without having to ‘sacrifice’ it’s own functionality.
Agree as that would be containers on top of a virtualization layer on top of physical hardware, but my experience is that qemu/kvm is performing perfect (when you have the hardware to support it). I think systemd-nspawn is to limited / will not work for this use case.
If it can be done with a very simple container engine, that would be less overhead. But the question is indeed whether HAOS runs well within it, and one container within another. So possible that virtualization is indeed needed. systemd-nspawn is just the most minimal solution, but it can also be configured to some degree, to create an own network, expose devices etc.
Looks like it is worth to have another look into whether HA supervised can be installed without the installer, setting up the container with minimal surrounding setup that conflicts with DietPi scripts.
As far as I have seen (read in the Internet), the only thing currently ‘conflicting’ is the networkmanager. @Joulinardid a step-by-step here, but that is already from 3 years ago, so maybein the meantime things have changed / evolved?
that is why I’m looking at the virtualization route: that way (although with overhead), there is no conflict, or at least no conflict that I am aware off currently. Also Qemu needs to be installed and not sure if KVM is (natively) supported on DietPI in combination with my Odroid C4 (the Odroid supports it, but need to check if there is kernel support).
Having Qemu / KVM installed would ‘open’ a lot more use cases imo: not in line with the DietPI philosophy (lean and mean), but with regards to possible functionality
I think you can run a kvm virtual machine with home assistant installed without much issues. Just make sure it starts up with your system. And have enough RAM…
Ok some more progress here. Been looking into setting up Qemu / KVM on dietpi, but there are then actually two things that I do not ‘like’:
it installs almost a complete desktop environment, which for me is a ‘nogo’ as in my opinion it should run headless with a remote machine doing the maintenance.
it needs a bridge, which basically (when you get it to work with ifupdown) conflicts in the same way with dietpi-config as using networkmanager would: dietpi-config only support eth0 / wlan and overwrites the config when used removing the setting in interfaces needed for the bridge.
So although my machine in capable of running a VM, I feel the overhead of additionally installed software a nogo and in the end, the result is the same as installing Home Assistant supervised on the diepi server when it comes to managing the network cards.
and just to follow up again:
tried the Home Assistant supervised.
running into a lot of issues while installing (because it toggled the network manager so dietpi was unable to install software etc.)
Finanlly got that ‘working’, HA supervised installed and up and running but effectively it is not usable:
when trying to do a restore or add an addon it produces the error:
The Supervisor needs to have privileged access to the docker runtime on your host to be able to do everything it needs to do.
So it turns out that the docker installed from the dietpi repository cannot be used (outdated?)
so this then also adds to the list of things not working any more from dietpi.
Will try to install docker myself (so not from dietpi repository) and see if that solves the issue: not getting nice warm feeling though regarding doing it this way…
Hi @Joulinar ,
network was not working, so had to go into dietpi config and toggle it back on using the advanced networking entry.
Then I was able to download stuff again, with the downside of HA not working anymore.
as for the docker, it turns out that you need to do a docker restart hassio_superviser.
Turns out it goes down on (multiple) occasions.
So with that up and running again i am able to at least install an addon, which failed again as it stopped halfway and I had to uninstall it, restart the docker instance and then it finished correct when retrying to install.
This is not something I think I would like to maintain in production.
The absolute power with dietpi is that it just works and is very easy to maintain.
Will try the qemu / kvm variant again, issue here is the setup of the virbr0 (virtual bridge), but that is something that can be figured out…
You would have to switch to NetworkManager beforehand. This means no longer using ifupdown and performing a migration to NM. There are some instructions on the Internet on how to do this.
Hi, so one month down the road, thought I’d share some insights:
the KVM / Qemu route was a bust: could not get it to work due to bios issues
so decided to go ahead and install it directly on DietPI
Did it go smoothly… no.
HomeAssistant is a ‘heavy’ application and depends heavilly on Docker. And that is where a lot of the issues i faced are coming from.
The first days I always ‘woke up’ with a borked HomeAssistant instance. It turned out that there was a ‘conflict’ with the dietpi backup I use: as part of the backup process, services are stopped: so is the docker service. This was giving chaos to Home Assistant, in one case I even had to reinstall it to get it working again.
So what I did was exclude the docker service from being handled by the dietpi service manager. So now when a backup starts, all services except the docker service will shutdown.
until I did a dietpi update. Part of the update was a new version of docker and bam… issues all over. At least now I knew how to fix it
So overall the setup with Home Assistant supervised is running ‘smoothly’ but there are some attention points.
Currently thinking of figuring out a way to do a ‘ha core shutdown’ on docker shutdown and a ‘ha core restart / start’ on a docker restart. or something else that avoids HA crashing hard when docker is changing.
Not sure if that is possible, but that would imo at least make the setup a bit better / more stable.
Hope this helps others who are considering moving to Home Assistant Supervised: the added functionality that this version has over the version provisioned by DietPi is worth the effort (at least for me)!
