Virtualization vs. Container for Home Assistant

alienjon · Veteran Joined: 09 Feb 2005 Posts: 1732

I'm looking to run Home Assistant on my Gentoo-based home server. I actually had it installed via the layman repository, but the python dependency conflicts became nightmarish on a few occasions and I'm looking to simplify. The recommended method is a stand-alone server (probably via Raspberry Pi). I may do this in the future, but for now I want to keep running off of my current hardware. I was starting to setup the OS via virt-install, but then wondered if the container method (I'd likely use Docker) has any significant drawbacks. I'm not running state of the art hardware here (See below) but do have a file server and Plex Media Server running off the device already (so I'm looking to run more than just Home Assistant). Any thoughts on whether I'd see any major benefit (performance or otherwise) in choosing one over the other?

My system stats are:

pa4wdh · l33t Joined: 16 Dec 2005 Posts: 916

I have experimented with Home Assistant in a container and in itself it works fine. (I ended up removing it for reasons i don't remember, not related to virtual vs. container).

One limit i'm aware of is that containers don't support bluetooth, so if you wish to use bluetooth from home assistant containers won't be the way to go. With a VM you could probably assign a USB bluetooth device to the VM and get it working.
Most z-ware/zigbee devices i'm aware of present themselves as serial ports to the OS so they will be usable in both containers and a VM.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

alienjon · Veteran Joined: 09 Feb 2005 Posts: 1732

Not looking for bluetooth, I don't think, but I did install the VM and having networking issues. Home Assistant instructions basically say that once installed it should just work, but I found that the bridging wasn't setup properly and I couldn't connect from outside the host. I fixed that with xinetd, but now it's still considered on a separate (host) network and doesn't see the rest of my LAN (ie: it doesn't detect any of my LAN devices). Any sense on whether a container would be easier to configure in CLI or run faster/slower than a VM?

pa4wdh · l33t Joined: 16 Dec 2005 Posts: 916

I don't think containers are more or less difficult than virtualization, especially network-wise. You'll still need to configure networking inside the VM/container and you still need some kind of bridging to connect it to the rest of your network.

In terms of speed a container will win, specially on slower hardware the difference will be noticeable. A VM has ~20% overhead (ie: software inside the VM will run 20% slower than software outside the VM), for containers this is even below 1%. As an example: I'm running 10 full gentoo containers on an Intel Atom CPU and CPU load is ~1.0 so there is room for more. With VM's it would even be a challenge to make it fit.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

alienjon · Veteran Joined: 09 Feb 2005 Posts: 1732

Thanks. That's helpful. I've only had the VM running for a day or two (And then my house lost power and it was off for a day or two) so I'll have to keep an eye on the load.

Meanwhile, any suggested readings for setting up the bridging to fix the networking issue? Networking has never been my strong suit.

pa4wdh · l33t Joined: 16 Dec 2005 Posts: 916

Regarding bridging:
You'll need net-misc/bridge-utils
Set up your networking to include a bridge, the netifrc docs provide nice examples, be sure to include your actual network interface with the bridge

(Pitfall: If you add your physical interface to the bridge the IP address configured on the physical interface does not work anymore, you need to move your IP configuration to your bridge interface)
Instruct your VM/container to be attached to the bridge, how that is done is up to the software you use.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

grknight · Retired Dev Joined: 20 Feb 2015 Posts: 2114

pa4wdh · l33t Joined: 16 Dec 2005 Posts: 916

Thanks for letting me/us know.
I'm kind of old-skool when it comes to networking tools so i use brctl myself and i was not aware that netifrc does not need it :-)

_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

alienjon · Veteran Joined: 09 Feb 2005 Posts: 1732

I'll look into iproute2 then. Any suggested readings beyond man pages? (ideally examples, though some man pages are better with those than others)

pa4wdh · l33t Joined: 16 Dec 2005 Posts: 916

I think /usr/share/doc/netifrc-<version>/net.example.bz2 is a good read, especially the section called "Bridging (802.1d)".
Also make sure you understand the network concepts related to bridging in general and virtual interfaces provided by your hypervisor/container platform.
_________________
The gentoo way of bringing peace to the world:
USE="-war" emerge --newuse @world

My shared code repository: https://code.pa4wdh.nl.eu.org
Music, Free as in Freedom: https://www.jamendo.com

alienjon · Veteran Joined: 09 Feb 2005 Posts: 1732

So update on this. I did elect to go the container (docker) route as my hardware doesn't support virtualization and it sounds like the overhead would be ridiculous. I installed docker per the wiki instructions and got the expected output in the test at the bottom of the instructions. For reference:

alienjon · Veteran Joined: 09 Feb 2005 Posts: 1732

Sorry, one more quick update. The Home Assistant log shows this:

alienjon · Veteran Joined: 09 Feb 2005 Posts: 1732

Ok. I may have figured it out.

Turns out:

Hu · Administrator Joined: 06 Mar 2007 Posts: 23336

alienjon · Veteran Joined: 09 Feb 2005 Posts: 1732

Firstly, so far and still good. Stopping xinetd seems to have fixed the problem.

Hu · Administrator Joined: 06 Mar 2007 Posts: 23336

Emulated would definitely be slower than hardware-assisted virtualization. Assuming docker is not being stupid, even hardware-assisted virtualization would perform at best equally, and quite possibly worse than, docker.

As I read ARK: Core i5 2500K, your CPU ought to support virtualization. However, since you do not want to use it here, we do not need to pursue why it seems not to be available to you. I recall that some systems shipped with a firmware that would disable virtualization support at boot time. Some, but not all, of those had a user-configurable setting in the pre-boot environment to choose whether to lock out virtualization. Once locked this way, it could only be unlocked by rebooting and avoiding having it locked again on the next boot.

alienjon · Veteran Joined: 09 Feb 2005 Posts: 1732

Thanks for the insight. Curious that it isn't enabled. I may check the bios if I get the chance but, honestly, I'm looking to upgrade my desktop soon and could use my desktop hardware to upgrade the server (Which should open up virtualization options as my desktop CPU is newer).