Remote sites punish a bad update. A retail closet, a plant rack, and a small POP do not have someone standing there with a USB stick. The question is what the host boots when the update fails.
The behaviour
A failed kcore host update boots the previous generation. The update is a transaction. If it does not complete, the machine comes back on the generation that was already running. That is the reason to look at kcore for sites where a failed update is an outage you cannot drive to.
It is a host property. It is not application rollback, and it is not a guest snapshot. Windows and Linux guests come back because the host came back. Their data still depends on the disk and on whatever backup you run.
What you still plan for
- The previous generation has to be one you are willing to run. Do not treat rollback as a test suite.
- Shared Ceph is optional. An edge node on local LVM or ZFS is a normal layout when the VM does not need to move.
- Kubernetes on that node is a later choice. The host update does not require a cluster.
- There is no integrated backup product yet. kctl backup copies the controller database. Guest backups stay with your tool.
Who should care
Teams comparing hypervisor updates for unattended sites. If the failure mode is “the ISO update wedged and the shop is dark,” boot-the-previous-generation is the feature to test on one site before you standardise.
Download the evaluation ISO, update a lab host, and break an update on purpose. The pass condition is the previous generation, not a green dashboard.
Questions: team@tacconiconsulting.com.