Updates
hv updates come from a trusted Release repository. A Pool follows a channel, normally stable, with candidate and dev also supported. Unless an Administrator sets a channel in the Pool's update policy, the Pool follows the channel the Host was installed with (the channel of /etc/hv/repository.json, chosen when the ISO was built or in the installer's [updates]); there is no channel setting in prod.toml. Before updating, review release notes, verified backups, capacity for evacuation and a working Host console. A root rollback does not undo shared management databases or VM disks.
Use the documentation for the installed release
The administrator manual is installed with each hv release. The console's Docs section shows it in the Account's language, English or Spanish. Updating hv updates the manual as well, so it matches the installed version. The public website shows the manual for the latest release. Use the installed copy when administering a system that has not yet been updated.
Before starting a rollout, record the current and target releases and read the target's release notes. During a rolling update, Hosts can temporarily run different versions. Check the individual Host's version before using local recovery commands, and keep the notes for the release you are applying available until the rollout is complete.
Inspect available releases
Open System, Updates and choose Check now. Inspect the repository, channel, version, verification status and Release notes. The Hosts tab shows running and staged versions, root state and progress; History records rolling updates. Updating requires host.patch, normally held by Fleet administrators.
A signed channel index and verified package manifest establish the release. A release is not trusted merely because an HTTPS URL responds. Older or replayed repository information can be refused. Do not bypass a verification failure by copying arbitrary signing keys into the Host.
Choose live or platform behavior
hv determines the update kind per Host from the release's platform identity. Matching platform identities allow a live update of hv's own packages. Different or unknown identities require a platform update.
| Kind | What happens |
|---|---|
| Live | hv packages are replaced and affected services restart. No Host reboot or evacuation occurs; VMs keep running. Management connections can reconnect after service restarts. |
| Platform | The inactive A/B root is staged, the Host enters maintenance and evacuates VMs, reboots into a trial root, is verified and leaves maintenance. |
Platform Hosts are processed first, with the coordinator first among them. Live Hosts follow, with the coordinator last. This lets the management service restart at the end of a live rollout. Download and stage applies to platform updates; live Hosts have nothing to stage and need Apply.
Select Apply, review the kind and choose Now, At a time or In the maintenance window. The window uses UTC. The update progresses one Host at a time and stops at a failure. A single-Host Pool needs its VMs shut down before a platform update because evacuation has no destination.
For example, a Pool with hv-01 and hv-02 may need a platform update while web-01 runs on hv-01. Verify that hv-02 can receive that VM and its storage and Network dependencies before applying the release. If it cannot, resolve the missing resource or plan a guest shutdown with the application owner. Scheduling the update does not create evacuation capacity.
Follow the Host sequence in Hosts and the rollout in History. If a Host fails at evacuation, investigate its remaining VMs before considering any reboot. If it fails after reboot, use the Host console and its slot status to determine which root is running. Resume only after correcting the reported cause, then repeat the application checks at the end. See the CLI reference for Host-local status and rollback commands.
Configure policy
Open the Pool's Policy sheet. Manual: check and notify is the default. Download and stage automatically prepares platform updates. Apply automatically in the maintenance window also applies them when the window permits. Without a window, ordinary automatic application does not proceed.
Live updates normally follow the window too. Any time permits an all-live automatic rollout outside it. Live updates from and Platform updates from can select distinct repository/channel sources. If a newer live release requires a platform identity a Host does not yet have, it waits for the platform update first.
Add or change a repository
Use Repositories, Add repository to change release sources. Before saving, obtain the publisher's root-key fingerprint through an independent trusted channel.
- Enter the HTTPS URL and choose Test.
- Review the repository name, document serial and channel results.
- If trust does not follow from an already trusted repository, compare the reported fingerprint with the publisher's independent value. Enter the verified value in Root key fingerprint.
- Select Make it the default repository only when the Pools using the default should change source.
- Choose Save repository and inspect Hosts holding its trust.
A fingerprint copied only from the same untrusted test response is not independent confirmation. hv distributes the signed document and release keys to Hosts. A default switch requires affected Hosts to accept the new trust; failure can leave the repository saved but not default. Read the reported Host state and retry after resolving connectivity. Old keys are retired after the first successful rolling update from the replacement source. Use a public HTTPS repository; this workflow does not support repository access credentials.
Verify and recover
Watch the final rolling-update verdict and each Host's version, service health, Pool membership, SRs and Networks. Test a VM after a platform update. Resume retries from the failed step after its cause is fixed. Cancel rolling update prevents further Hosts starting; it does not undo the active step or remove maintenance from a Host already there.
A failed platform trial can return to the committed root. A hung Host may need a console-assisted power cycle; there is no automatic hang-recovery guarantee. Roll back in the UI reboots the Host immediately without first migrating VMs. Plan their handling before selecting it.
For Host-local recovery, hv-upgrade status reports slots and hv-upgrade rollback --dry-run previews a rollback. The local hv-upgrade rollback command changes the next boot selection but does not itself reboot. Live-update failures attempt restoration of cached previous packages; inspect whether the reported result is rolled back or failed. Do not remove update locks or repeatedly force a failed release. Staging another platform release can overwrite the previous rollback slot.