Cool, will some of the improvements shipped to supervised ? Like snapshot behavior or some kernel configurations ? 
We don’t ship the OS in case of an supervised installation. You are responsible and in control of the OS in the case.
…/Frenck
1 Like
Buy you ship the supervised package and recommended configurations. So that’s why iam asking.
They don’t ship the kernel on supervised, debian does.
1 Like
And I never asked for the kernel. So what?
I think what they’re saying is that the change you’re asking for is something that has to be included with the OS you’re using. It’s not something that’s part of the Supervisor code.
Yes you did. You specifically asked about the preemptible kernel configuration. Right here
Maybe you should learn the difference between configuration (build parameters AND runtime configuration) and the actual kernel. Thanks …
You are still responsible for OS configuration in a supervised install.
2 Likes
I’ve been compiling kernels since pre 1.0, so I do know.
Did I ask you to takeover ? I mean wtf is happening here? I was just asking if the devs can share the settings and confines regarding that changes. If the team will not do it, a simple no would be enough. Instead I get answers for questions never asked? Very very toxic
I’m not sure where this hostile attitude is coming from. I was merely informing you of your responsibility with your chosen installation method as you seemed to be unaware it was your responsibility, not the developers
Here is something else you need to be responsible for, please read it: Code of Conduct - Home Assistant
9 Likes
Everything is on github.
And you, again, not reading nor understanding the question.
Chill out. The only toxic behavior here is yours.
3 Likes
You have full control over the OS. Home Assistant’s just a program you install on it, and it doesn’t care about what kernel it runs on. Supervised may be a nice package you can install, but it doesn’t take over the whole machine like running Home Assistant OS does.
The Snapshot behavior requires the QEMU guest agent. Currently, the Supervised installer/package doesn’t have any specific logic to address virtualized environments (e.g. the QEMU guest agent, package qemu-guest-agent is not managed by the Supervised installation scripts). This is also not planned currently.
But it should be fairly straight forward to install the package and add the scripts yourself. You can find the script which forwards the snapshot (fs-freeze) trigger received by the QEMU guest agent to the Supervisor in this PR. It seems that Debian already ships /etc/qemu/fsfreeze-hook, so I think you can just store that script as a executable shell script in etc/qemu/fsfreeze-hook.d/ should be sufficient.
As for the kernel configuration: The config we use now is CONFIG_PREEMPT. Debian uses CONFIG_PREEMPT_VOLUNTARY, which probably is more sensible for a classic Server installation. In Debian there is a real-time kernel image e.g. linux-image-rt-amd64 (CONFIG_PREEMPT_RT), which is even real-time capable. A more preemptible kernel often comes at the expense of throughput and worse average latency, but delivers better worst-case latency. It’s a tradeoff… That being said: The scheduling latencies are in microseconds typically, often you have much much higher latencies overall, so don’t expect too much from scheduler tuning 
.
6 Likes
Thanks. That’s exactly what I asked for. Guest agent is already running. Now I can add the script to the HA machine and a modified version to my external mariadb server, because the main issue for mariadb snapshots was exactly that (which I addressed by an additional dump before I backup).
If I get it working with the external mariadb, is it ok to present that to the proxmox community including the reference to you guys of course? That’s one of the main issues over there 
Pretty sure open source means you need no permission. Attribution is another matter.