Moving HA to better hardware

F. Sorry man I’m with everyone else

Sometimes people just don’t - want- to deal with virtualization and most people aren’t it pukes like us. In fact I PREFER running my ha box on iron unless I have a reason for it.

I going to Proxmox myself ina few months but that’s ONLY bewi want to run local ollama on a NUC 14 AI. And that’s going to need it. But it’s also an advanced workload that requires it.

Because of stated reasons simplicity I don’t want to deal with YET another system. Etc etc. But yet I will for the local AI. If I weren’t doing that I wouldn’t even consider it. I’ve got restore to the nuc 10 down to about 30 min fro bare to fully up and restored. (I test DR quarterly) - I simply don’t need anything else. Until ai comes.

HAOS right on the NUC is a perfectly valid install option. Sure you may leave perf. on the table but sometimes sanity is worth it.

I never said it’s not a valid option to install HAOS on bare metal, I pointed out that the claim that it is the «most stable» is incorrect. It is perfectly fine to do bare metal HAOS, but if you want something more advanced, which gives you a lot of benefits (and can give you better uptime and much easier/quicker recovery) it is better to go with a hypervisor based setup.

1 Like

Bare metal will always be more stable just because it has one less layer of software that can contain bugs.
Hypervisors will make administration easier though, because it will make the VM installation hardware indifferent. HAOS is pretty good at being hardware indifferent though…

1 Like

I don’t agree, hypervisors today are just as stable as bare metal, even if you add a minimal layer in between. A minuscule performance drop compared to bare metal, sure, but not stability.

An extra layer will always give extra possibilities for bugs and that is also the case here.
Just look at the number of updates for the Proxmox and that is just the software side of it.
You also have an administrator that have to handle an extra software suite.

It is a scientific proven fact that there is no perfect world.
My statistic teacher always said that you can invent the perfect system, that not even an idiot can destroy and god will invent a better idiot.

I disagree, in a home lab environment you don’t need an extra resource to manage a hypervisor. Sure, you would need to learn something new but I only see that as a positive thing. The benefits you gain are massive, and as I said you will not notice anything stability-wise.

You can disagree all you want and reject reality. :smiley:

And you might see it as a good thing to learn something new, but it is still something extra to remember.

You cannot get 101% stability is my final comment. It’s not “rejecting reality”. If something is 100% stable, you cannot get any better stability.

You can’t even get 100% is my my final comment. :smiley:

I’m at 100% stability on my hypervisors for 15 years. How’s your stability on bare metal (it’s not allowed to say better) :slight_smile:

It is still not 100% for hypervisors.
100% means 100% always, in the past, now and in the future.
You might be lucky and have not experienced instability yet.

Your argument is like saying the earth will never get hit by a meteor that will wipe out humans, because it has not happened during all those years humans have existed.

And the same cannot happen to a community maintained OS, right? There’s nothing magical about having hardware access directly.

Of course the same can happen to HAOS, but it is not like you are not using HAOS, when you use a hypervisor.
The hypervisor is an addition, not a replacement, which is why it will always be less stable.
How much less stable can be discussed.

My point is that it is not a good argument to not do virtulization based on stability. It is just as good as running bare metal stability wise, and with a big amount of added benefits. If you are concerned about stability and uptime virtualization is the better option compared to bare metal, because it has features built in to address this.

Virtualization improves uptime, but not stability.
The improved uptime is on the planned maintenance, due to abilities to move running VMs to other hypervisor hosts, and on ease of setup, due to to setup being abstract from the actual hardware.

Instability is unplanned downtime, cause by bugs and misconfigurations.

Exactly. And my claim is that installing a hypervisor and then running HA on top of that will not bring you any more unplanned downtime than running it bare metal. So in the event of unstability, it will actually get you back online faster.

One could also argue that virtualization brings more uptime if you have unstable systems, like when the latest supervisor was pulled. A snapshot-based restore would have you up and running in seconds, not considering replication.

For a rental house 6 hours away from me, would it be more reliable to have something more like an appliance, something like a HA Green or Yellow? What rig would you want if you could not physically get to get to it and it really needed to run reliably for years to come. What is the most reliable setup if it was headless and co-located?

Thanks,

R

I stand by my assertion that HAOS on bare metal, like the Intel NUC, is remarkably reliable. Install the ZeroTier add-on and you will be on the same local network no matter where the remote is located.

2 Likes

For a rental house 6 hours away I would look into some appliances instead.

I would probably choose Philips Hue for lighting with the Philips Hue hub.
It can be integrated into HA, but will work anyway if HA crash.

I would choose HomeMatic IP for TRV control for heating with door/window sensors combined with Debmatic on a Raspberry Pi. I would not run this on the same hardware as HA.
Homematic IP can be also be controlled through HA, but can also run many automations just with Debmatic and the most basic functions, like communication between TRV, wall thermometer and door/window sensors should even work without Debmatic.

Been using this set up for a few years and still haven’t found anything I think is a better option.