Operating a host

This page is for a host that is set up and enrolled. The host’s commands take its UUID, which ghost provider hosts lists; on the website every host has its page under Provider (/provider/hosts/HOST_ID).

Controlling rental admission

ghost provider hosts
ghost provider host resume <HOST_UUID>
ghost provider host pause <HOST_UUID>

To find the host’s UUID, run ghost provider hosts.
You finish the pricing and network configuration and inspect the host: its inventory, pricing, storage, and networking. At this point you can also make the checks of Checking a new host that need no rental.
When the host is ready, you resume new rentals explicitly, with ghost provider host resume or on the host’s Settings tab.
Last, you make the checks of the same section with a small test VM.

Every newly enrolled host starts paused, which gives you time to verify it before customers can rent it. It stays paused even after inventory and healthy heartbeats are visible.

A cloud host first needs its public path verified; see The host’s public path.
Home hosts need no such check: each rental’s public address is its Gigahost-run gateway.

Pausing admission before planned maintenance is the safe way to work on a host. Pausing affects only new rentals: existing VMs and work already queued for the agent continue normally.

`ghost provider hosts`

ghost provider hosts lists your hosts as the website’s hosts table does:

each host’s state (accepting, paused, unverified, offline, and so on);
when its agent was last seen;
its type, location, rentals, CPU, RAM and disk;
its SLA and prices.

Retired hosts are left out unless you add --retired. ghost provider host <HOST_UUID> shows one host in full, and --json gives every field of every host.

Private hosts

A host can be kept for your own instances and for the accounts you choose: a private host takes new instances of your own account and of the accounts on your list alone. The website’s Private hosts page says so: a private host only allows your own account, or accounts on the allow list, to create instances on it; you can make a host private on its Settings tab; and private hosts are not visible to the public. No public page or read shows it: the catalog, an offering looked up by its ID, the counts of hosts and instances, the listed locations, the offerings on your public profile, its network tests and the status page all leave it out, and to anyone else its offerings are unknown.

ghost provider host private <HOST_UUID>
ghost provider host public <HOST_UUID>
ghost provider private-renters list
ghost provider private-renters add <ALIAS>
ghost provider private-renters remove <ALIAS>

On the website a host is made private or public on its Settings tab, and the list is the Private hosts tab under Provider.
The list is one for all your private hosts, up to 100 accounts, each added by its alias (the gh- name its owner sees in ghost account show). Your own account is always allowed and is not listed.
Your own account and the accounts on your list see the private host’s offerings in the catalog, marked private: on the website while logged in (Capacity and the offering’s page show a Private tag) and in ghost catalog signed with their account key. An account removed from the list stops seeing them at once.
An allowed account rents a private host as any renter rents a public one, at the listed price. Your own account is charged too, and your share comes back to your earnings, as when you rent one of your public hosts.
A private host’s offerings have IDs of their own: they never share an offering with a public host of the same hardware, whose IDs stay as they were.
Your public reliability record counts the rentals of your public hosts alone: a private host’s rentals, its outages and its abandoned instances are left out of what is counted while it is private. Days counted before you made it private stay as they were.
Making a host private, or removing an account from the list, leaves what is there as it is: instances and local backups of accounts you no longer allow keep running, reinstall, upgrade in place and are billed as before; only their new instances, and restoring a local backup into a new instance there, are refused. Before you confirm, the website and ghost say how many there are; ghost asks for --yes when there are any.
Allowing an account lets it start instances on your private hosts, at their listed prices.
Making a host public lists it in the catalog again at once.
Each change of a host’s privacy and of the list is recorded in the platform’s audit.

Watching a host

ghost provider host <HOST_UUID>
ghost provider host metrics <HOST_UUID> --resolution current
ghost provider host metrics <HOST_UUID> --resolution daily
ghost provider host instance-usage <HOST_UUID> <INSTANCE_UUID> --resolution 15m

These show everything the platform knows about a host, and what it and its rentals are using.

The detail shows the last heartbeat and the health the agent derived from its own measurements, the agent version and uptime, hardware with the host’s CPU score (how it is measured), the inventory revision, the revisions of the host’s capacity with their reasons (capacity_revisions, the newest first), and per NUMA node and storage pool how much of the saleable capacity rentals hold.
It also shows the image cache (image_cache) of a host that downloads the catalog’s images ahead of demand, a home host by default: each image with its state and why, and what the cache takes of its limit and filesystem (the image cache).
Metrics carry CPU busy and steal time, load, memory and hugepages, disk I/O and SMART health per pool and device, traffic per uplink, and temperatures, at the current, 15-minute, daily, and monthly resolutions (what the agent reports).
Each metrics row also sums the rentals’ usage for the same period, so the platform’s overhead is visible. A current row counts only running rentals sampled since their last power change, reinstall, or restore.
A single rental’s usage is available at the resolutions the renter sees, which helps you find a noisy neighbour.

On the website

The host’s Overview tab (/provider/hosts/HOST_ID) shows the current readings.
Its Usage tab shows the history each UTC month (the default), each UTC day, or every 15 minutes.
Its Mesh tab lists its peer links, their kind, state and linked-since time, followed by daily WAN/LAN traffic and LAN earnings for the last 30 days. Your own hosts link to their Mesh pages; another provider’s host is identified only by its public address when available.
Rentals shows each rental’s usage (/provider/hosts/HOST_ID/rentals/INSTANCE_ID/usage), also each month by default.

The host’s Overview tab

The Overview opens with the host’s Health: the agent, the conditions and the host’s open incidents. Its Capacity follows, what the host offers for rent under the capacity revision in force:

its vCPUs (cpu_core_limit_per_numa_node times its NUMA nodes);
the RAM and the disk that come with them (memory_bytes_per_cpu_core and root_storage_bytes_per_cpu_core times those vCPUs);
what its rentals hold of each, running or stopped, and its VMs;
the RAM and disk per vCPU, and its prices on one line.

Then come:

Status: the readings, then a table each for the NUMA nodes, storage pools, uplinks, temperatures and disks;
Capacity details: what each NUMA node offers and its rentals hold, every size of the host with its RAM and disk and whether it is offered (the Sizes table’s VM and Container columns say Yes or No for each, and it lists Shared 8x, for containers only), and what is reserved of each storage pool.

A cloud host’s IP addresses follow its Hardware and Network tests: whether an address has answered through it, and the addresses of the IP pools that serve it (the first 50 of each pool, the rest on the pool’s page) with their gateway and state.

The agent judges its readings itself and reports what is worth your attention as a condition of the host, which you get as an incident for as long as it lasts. A warning leaves the host as it is. A critical condition degrades the host: it takes no new rentals until the condition is over, and its instances keep running. Every condition is listed under Host conditions.

The daily CPU benchmark

Once a day, at a random time of its own, the agent runs a CPU benchmark on one core of the host for about a minute and reports the result. The agent carries the benchmark itself, built the same way for every host, so the figure reflects your processor and not the operating system you chose. The best score of the host’s last 7 runs is its CPU score, which renters see on the host’s offerings and on their instances; the figure and how it is worked out are on How the CPU score is measured.

The run does not start while the agent waits for the backend to accept it or while the host’s network tests run, and it waits for the next day’s turn after a failed run. It needs about 400 MiB of free memory and skips the one workload that needs it when the host has less, in which case the host shows no score until a complete run succeeds.

Reviewing incidents

ghost provider incidents
ghost provider incidents --state open --severity error
ghost provider incident get <INCIDENT_UUID>
ghost provider incident acknowledge <INCIDENT_UUID>
ghost provider incident resolve <INCIDENT_UUID>

You review the inbox as part of normal operations; doing so regularly keeps you ahead of problems.
You acknowledge an item while you are working on it.
You resolve it after the underlying condition is fixed.

Gigahost records actionable host warnings without waiting for a renter to open a support request. If it observes the same condition again, the stable incident is reopened instead of creating an unrelated warning. Acknowledging or resolving an incident does not itself change the host or VM.

On the website, Provider › Incidents (/provider/incidents) lists them with their State (Open, Acknowledged or Resolved) and Severity (Critical, Error, Warning or Info) in columns of their own, filtered by either, and a host’s Overview lists its open ones the same way.

What an incident reports

The inbox deduplicates host outages or degraded health, failed work, root-storage pressure, telemetry gaps, invalid telemetry excluded from billing, and a bandwidth reading well below the host’s previous reading against the same test server. It links each item to the affected host or job where applicable.

Incidents show the first and latest occurrence, count, affected resource IDs, and a recommended action.
Their context is limited to operational data and does not contain renter SSH keys, startup commands, or guest initialization secrets.
A failed address check opens no incident; the pool listing shows it.

Which failed work is yours

A failed job is an incident only when it failed on the host’s side, one for each kind of job, step, and error. A failed job is not yours:

when it failed at a step the platform runs itself, such as setting up a home VM’s gateway;
when the renter caused it, such as a restore the renter did not authorize in time;
when a guest starts no operating system again after its renter’s reboot, reset, upgrade or restore, because that system is the renter’s.

A guest that does not boot a catalog image when it is created or reinstalled is still an incident for you to look into.

Uptime and outages

Every time a host stops answering, Gigahost records an outage of it: when it began, when it ended, and why. Provider › Uptime (/provider/uptime) lists them, and each host’s Overview links its own.

ghost provider uptime
ghost provider outages
ghost provider outages --host <HOST_UUID> --from 2026-09-01 --to 2026-09-30
ghost provider outage <OUTAGE_UUID>

The top of the page has a Total section (Outages, Length, Counted, Excused and SLA cost), and shows each host’s uptime over the last 30 and 365 days beside the SLA you chose for it, and says Below target where the host is under it. A period counts from the host’s enrollment when that is later, and to its retirement when it was retired. Next to the uptime it shows the downtime that counts (Counted), the part excused as the platform’s, and the SLA credits (Credits) of the outages that began in the period. Percentages are shown without trailing zeros. The hosts come by label, 100 at a time: with more than that, Next hosts and First hosts under the table turn the page, and the outages below keep their place. The same list is ghost provider uptime: it prints "more": true while hosts follow, and --after with the last host’s ID reads the next.

Retired hosts are hidden from that list, so a machine you re-enrolled shows once, under its current host. Show retired hosts under the table (or ghost provider uptime --retired) lists them too, each marked with the day it was retired and the end of its ID. Their outages stay in the list below either way, because the credits are tied to them.

Below it, every outage is listed, newest first, with:

when it began (Started) and ended (Ended, after it; an outage that lasts says Ongoing) and how long it was, and why: No heartbeat, Operator or Maintenance;
the time that counts against the host, and the part excused when Gigahost itself was at fault (for example when its backend could not be reached), so that time is on neither the host’s uptime nor a customer’s credit;
the rentals it touched, the ones billed on the host while it was down;
what it cost in SLA credits, which reads Settling until it is final. Credits are written a few minutes after an outage ends, one for each rental, so a long outage can show a partial amount until the last is written.

The filters narrow the list to one host and to the UTC days the outages began on (the last 365 days by default); the totals under the list are those of every outage the filters match, not only the page shown. Opening an outage lists its rentals, each with the multiple of its base price it was credited at and the credit, and links the incident the outage raised while that incident still records it.

The page counts downtime as the credits count it, excusing the part that is the platform’s fault. The hosts list shows the same 365-day figure for each host. See SLA tiers for the credits and When earnings can be paid out for how an unsettled outage holds payouts.

Updating the agent

curl -fsSL https://api.gigahost.cloud/install/hypervisor.sh | sudo sh

To update, run the install command again. It installs a newer release, restarts a running agent (the agent resumes its work from its journal), and reports when the installed release is already current.

Updates are best scheduled like reboots: pausing new rentals first keeps work from queueing during the restart.
The agent does not update itself.
gigahost-hypervisor --version prints the installed release, which the agent also reports to Gigahost; a binary not installed by the script reports dev.

Updating within the support window

Gigahost serves every release of the agent for at least 90 days after it was built (a release’s name starts with its build time, such as 20261010T120000Z-…). Your host’s page and the Agent column of your host list show the release each host runs and until when it is served; from 14 days before the end they say “Support ends …: update it”. To stay within the window, you can update before then by running the install command above.

When a release is no longer served

Once Gigahost stops serving a release, it still accepts the agent’s heartbeats and metrics and what the work the host was already doing needs to finish (its progress, its results, a backup’s transfers). It does not accept the agent’s other requests, and it names the release to install.

The agent logs that once as an error, keeps its VMs running and its heartbeats and metrics going, and finishes the work under way.
sudo gigahost-hypervisor check shows it, and you get a critical incident naming the host and the command, which resolves once the host runs a release that is served.
Until then the host stays up and degraded: no outage opens, but it takes no new rentals and starts no new work, so your renters’ requests for its VMs (starting, stopping, backing up, deleting) wait until the agent is updated.
An updated agent is served again as soon as its first heartbeat arrives.
An agent of a release that is no longer served cannot enroll a new host either, so the current release comes first.

When Gigahost no longer speaks the agent’s control protocol, it treats the agent the same way; see The control protocol.

Applying system updates

With unattended-upgrades disabled, as set up, you apply updates yourself in a maintenance window, while you watch the host:

Pausing new rentals, as for any reboot, keeps work from queueing during the restart. To pause them, run ghost provider host pause <HOST_UUID>.
To upgrade, run apt-get update && apt-get upgrade.
An upgrade that leaves a new kernel waiting for a reboot is best followed by a reboot of the host.
To resume new rentals, run ghost provider host resume <HOST_UUID>.

Scheduling reboots and hypervisor upgrades lets you handle active guests deliberately.

The capacity check at every start

Before it serves anything, every start of the agent checks that the machine still has the capacity Gigahost accepted for the host:

as many logical CPUs on every allowed NUMA node as the CPU limit;
in each node’s MemTotal, the guests’ RAM and 0.5 % of it;
room in the root pool for every guest disk beside the router’s volume and the backup scratch, the disks of existing guests counting as room.

Free or available RAM plays no part. The margin of 512 MiB that enrollment asked for is not needed any more, so a BIOS, firmware or kernel change that takes a little of a node’s RAM is fine.

A machine that has less

A machine with cores or SMT turned off, RAM removed or a smaller root pool still starts, and the agent logs the shortfall with its numbers.

The host is then degraded (the Accepted capacity condition): it takes no new rentals, its instances keep running, and its inventory is not updated until the machine has the capacity again.
The agent never lowers an accepted limit to fit, so restoring what is missing is the way back.
It checks the whole machine again with every inventory, every 15 minutes or sooner, and the host is healthy again once the machine passes.
sudo gigahost-hypervisor check makes the same check without starting the agent and fails on such a machine, naming the shortfall.

A configuration that is not the host’s, with another mode, location or capacity than Gigahost accepted, is another matter. The agent does not start with it and says what to restore.

A root pool enrolled before VMs were counted by their CPU shares may lack the room for the metadata of that many disks, a file pool 4.5 MiB for each and a thin pool its volumes’ share of its metadata. The agent logs it and the host keeps selling its disk as far as it goes. Extending the pool, or a thin pool’s metadata with lvextend --poolmetadatasize, comes before raising the host’s capacity.

Adding a backup pool to an enrolled host

You prepare the storage as for enrollment: a thin pool with zeroing enabled, or a dedicated filesystem, mounted, with the pool’s directory on it.
You add the pool to hypervisor.toml as a [[lvm_storage_pools]] or [[file_storage_pools]] entry with kind = "backup", as Preparing storage shows.
To check what the host would offer, run:
```
sudo gigahost-hypervisor check
```
To restart the agent, run sudo systemctl restart gigahost-hypervisor. The inventory it sends when it starts lists the new pool, and from then on Gigahost places local backups in it and the catalog’s backup_limits count it.

You can add a backup pool to a host that is enrolled and rents out instances. Its mode and location stay as they were enrolled, and its capacity as Gigahost accepted it (see Raise a host’s capacity). Only the storage pools change.

What `check` shows

Without contacting Gigahost, sudo gigahost-hypervisor check reads the configuration as the agent does when it starts, then lists every pool the host would offer with its kind, its storage backend, its capacity, and what of it the host keeps for itself. A backup pool it cannot find is shown as a warning with what it found. It ends with status 1, and says why, where:

the agent would not start;
the machine lacks the capacity Gigahost accepted (the agent would start, and the host be degraded);
it could not read the pools.

Removing a backup pool

A pool that holds local backups stays in the configuration until they are deleted. The agent does not start while a local backup’s artifact is in a pool the configuration no longer names, with backup pool holding N local backups is not configured any more (first: PATH); put the pool back in the configuration, or delete the backups first. You can remove an empty backup pool.

A missing backup pool

You mount the drive or activate the volume group.
The agent finds the pool again within a minute and sends a new inventory. If it does not, restart it.

A backup pool holds nothing a running instance needs, so the agent starts without one it cannot find, as long as the root pool is there:

a file pool whose directory does not exist, or is on the host’s root filesystem or on another pool’s filesystem (a drive that is not mounted leaves its mount point there, an empty directory that is not to receive backups);
a thin-LVM pool whose volume group or thin pool cannot be read.

The agent leaves the pool out of its inventory and reports the condition backup pool missing with the pool’s ID and what it found, which you get as an incident. It is a warning, and the host stays up and its instances run on. A missing root pool still stops the agent, because the instances’ disks are in it.

While the pool is missing

Gigahost places no local backup in it.
Gigahost does not accept a restore of a backup in it, or a new instance from one, and answers with backup_pool_unavailable.
It charges the backups’ owners nothing for keeping them, which earns you nothing for them either. Their owners see those backups as unavailable, and why.

When the pool is back

Before restores and storage charges resume, Gigahost has the agent check every backup’s artifact in the pool:

a backup whose artifact is there with its recorded size is available again;
one whose artifact is gone is marked lost. Its owner is told, it is charged for nothing after the pool went missing, and it stays listed until its owner deletes it.

A backup deleted while its pool was missing leaves its artifact behind in the pool, since the agent could not reach it then. When the pool is back, and also whenever the agent starts and once a day, the agent asks Gigahost which of the backups it finds on the host Gigahost no longer has, and removes those leftovers. It never removes a backup Gigahost still has.

Hardware RAID

Where the controller allows it, handing its drives to Linux (HBA or JBOD mode) and building the redundancy with Linux software RAID is the better setup. The platform then sees every drive: its model in the catalog, its SMART health, wear, media errors and temperature, and the array’s level.

A hardware RAID controller shows Linux one logical disk for each of its arrays and hides the drives. The agent knows such a disk by its driver (megaraid_sas, mpt3sas, hpsa, smartpqi, aacraid, arcmsr, 3w-sas) and works with it as follows:

The catalog shows the array under the controller’s name as a hardware RAID array, with its level where that can be read: from the driver (hpsa, mpt3sas), or from the controller’s tool when every array it lists has the same level. Otherwise the level is shown as unknown.
The drives behind the controller are read through smartctl (-d megaraid,N, -d cciss,N and the like, as smartctl --scan-open names them) and judged like any disk. They are listed under the host’s details as drives behind a hardware RAID controller. The array itself is shown with its health unknown, never as healthy.
The state of the arrays comes from the kernel (mpt3sas) or from the controller’s own tool, which you install. A degraded or failed array degrades the host; one that is being rebuilt is a warning.
Without the tool the agent cannot tell a drive that left its array, and you get the warning that the controller cannot be watched for as long as that lasts.

Controller	Its tool
MegaRAID, PERC	`storcli` or `perccli`
Smart Array	`ssacli`
Adaptec	`arcconf`

Enrollment and gigahost-install-hypervisor-deps --check tell what the agent reads of a controller. The state of the controller’s battery and of its write cache is not read.

Raise a host’s capacity

To stop the agent, run:
```
sudo systemctl stop gigahost-hypervisor
```
To change the settings, run:
```
sudoedit /etc/gigahost/hypervisor.toml
```

To raise the capacity, run:

sudo gigahost-hypervisor update-capacity --reason "Sell all 64 threads"

To start the agent again, run:

sudo systemctl start gigahost-hypervisor

The command exits with status 0 when the host keeps the new capacity, with 1 when nothing changed, and with 3 when it is to be run again.

A host can sell more of its machine without a new enrollment, keeping its identity, its rentals and their history. Two settings of hypervisor.toml can grow:

cpu_core_limit_per_numa_node, up to the logical CPUs of the smallest of the allowed NUMA nodes; 0 takes them all.
allowed_numa_nodes, with another NUMA node that has at least as many logical CPUs as the accepted CPU limit. With a limit of 0, a node with fewer would take the limit below the accepted one. The command names the node, which has to stay out.

The RAM and root storage per logical CPU stay as enrolled, so every size keeps its shape and the host’s saleable RAM and disk grow with its CPUs. The machine needs to have them. Gigahost does not accept a lower limit, a node dropped or another value of any other capacity setting, and names the change. These need a new enrollment (below), as does another mode or location.

What `update-capacity` checks

update-capacity does not run while the agent does, since the agent rewrites the state the command updates. It shows the capacity Gigahost accepted and the one the configuration gives, and does not accept a configuration that raises nothing or changes anything else. It then checks the machine as enrollment does:

every allowed node needs as many logical CPUs as the new limit, and in its MemTotal the guests’ RAM, 0.5 % of it and the margin of 512 MiB;
the root pool needs room for every guest disk of the new capacity with the metadata of the most VMs it allows, beside the router’s volume and the backup scratch, the disks of existing guests counting as room.

It boots no VM: enrollment’s smoke tests proved the machine already. The reason, 1 to 500 bytes on one line, is kept with the change.

Gigahost’s answer

The command then sends the new capacity to Gigahost, signed. Gigahost checks it the same way against the latest inventory the agent sent, records it as the next revision of the host’s capacity with its time and reason, and the command keeps it as the host’s own.

When Gigahost does not accept the capacity, it gives its reason and changes nothing. With explicit limits, the agent then does not start with the larger configuration until the command succeeds or you restore the accepted values.
When the reason is a lack of CPUs, RAM or disk, the message names the inventory Gigahost judged by and its age. If the machine changed since, Gigahost does not know it yet. Starting the agent sends a fresh inventory at once; you then stop it again and run the command again.
A host Gigahost no longer knows (retired, or enrolled again under a new identity) has nothing to raise.

If the command ends without Gigahost’s answer, from a lost connection, an answer it cannot verify or a failure on Gigahost’s side, Gigahost may have accepted the new capacity.

Running the same command again before you start the agent settles it: a second run of a capacity Gigahost accepted answers the same revision, and the command keeps it. An agent started in between keeps the old capacity (with explicit limits it does not start), and Gigahost does not accept its inventories until the command has run.

After the change

When the agent starts, it sends its inventory at once, and the catalog offers the larger sizes from its next refresh, under new offering IDs.

Prices are kept per vCPU, so every size the host offered keeps its price for existing and new rentals, and the whole-host total on the Pricing tab grows with the vCPUs. The command changes no price. You set prices on the Pricing tab or with ghost provider set-pricing as before.
Existing rentals keep their reservations, NUMA node, prices and SLA.
The host’s Overview tab names the revision in force and when it was accepted, and lists every revision with its reason under Capacity details, as ghost provider host get (capacity_revisions) does.

Retiring a host with notice

ghost provider host retire <HOST_UUID> --notice-days 7 --yes

To permanently retire a host that still has rentals, you give customers at least seven full days of notice. The agent needs to stay online through cleanup.

Gigahost calculates and returns the exact deadline using its own clock.
Every affected customer sees the deadline on their instance.
At the deadline, instance usage, gateway base charges, and the refundable balance hold stop, and the platform queues the VMs’ deletion.
Storage capacity, public addresses, and gateways remain reserved until their deletion is confirmed.
Local-backup records and billing close at the deadline, and those backups leave the platform-managed lifecycle, although their physical files may remain; hosted backups remain available.
Failed cleanup is reported as action_required, which needs operator attention, instead of being retried forever.

Retiring one rental

To retire one rental without draining the host, you keep the host online and give the same minimum notice:

ghost provider retire-instance <INSTANCE_UUID> \
  --notice-days 7 \
  --reason 'retiring this workload class' \
  --yes

A host that is lost for good

A host whose system drive failed is not lost when its state is on its root pool’s drive and that drive is intact: it comes back with Recovering from a lost system drive.

ghost provider host emergency <HOST_UUID> \
  --reason 'unrecoverable hardware loss' \
  --yes

If the physical host is permanently lost and cannot serve the notice, you can declare an emergency instead. The declaration stops affected billing at once, revokes the host’s enrollment, records every affected VM as abandoned in provider reliability history, and notifies the renters. Gigahost completes external gateway deletion asynchronously.

Retiring or re-enrolling an empty host

An empty host needs no notice period.

A host’s mode and location, and any change of its capacity other than a higher CPU limit or more NUMA nodes (see Raise a host’s capacity), need a new enrollment.

The host needs to have no live rentals, unreleased instance resources, gateways, local backups that renters still keep, or active jobs.

To stop the service and run the local reset, run:

sudo systemctl stop gigahost-hypervisor
sudo gigahost-hypervisor reset-enrollment --yes

To enroll again, you create a fresh single-use enrollment token, replace the consumed token file, adjust the configuration, and run enroll, as under Enrolling once.

The retired record remains visible, and its label can be reused. The historical host and tenant records are not erased.

What the reset does

The command first asks Gigahost to retire the identity. Gigahost does not accept the retirement while any of the resources of step 1 remains.
It independently stops if a managed libvirt domain still exists.
It then archives the state file, durable job journal, telemetry spool, and SQLite sidecars with a .retired-<HOST_UUID> suffix.
Local backup artifacts are untouched. After retirement they are outside the platform-managed lifecycle, and you can keep or remove them according to your policy. Their platform records and storage billing close at retirement, while hosted backups remain available.

You can also retire an empty host remotely. The local reset is still needed before enrollment can be repeated:

ghost provider host delete <HOST_UUID> --yes

A cloud host keeps its public addresses across this: hand the retired identity’s pool to the new one, as under Handing a pool to a new host identity.

Checking a new host

A paused host takes no new rental, a test VM of your own included. The checks that need no rental come first, while the host is still paused. Then you resume new rentals and make the checks with a small test VM. If one of them fails, ghost provider host pause <HOST_UUID> pauses new rentals again until it passes.

Home host

After the host is online and you have resumed new rentals, you can check it with a small test VM. Create one through Gigahost, then:

confirm that it obtains public connectivity without any router changes;
test inbound SSH and outbound Internet access from the guest;
reboot the host and confirm that the hypervisor service and the test VM recover.

If the home connection changes address, the agent reconnects automatically. Deleting the hypervisor state file, or re-enrolling the same machine as a new host, is not a fix for a temporary connectivity problem and is best avoided.

Cloud host

While the host is still paused, you can confirm that:

sudo virsh list shows the gigahost-router domain running;
ghost provider ip-pools shows your addresses verified, and ghost provider hosts shows the host’s public path verified;
the host management address and route are byte-for-byte unchanged.

After you have resumed new rentals, you can check the host with a small test VM. Create one, then:

confirm that it receives an address from the intended pool;
test inbound SSH and outbound Internet access;
reboot the guest and the host and confirm that the address remains reachable;
check that guest traffic follows the expected upstream billing policy.

If the upstream provider changes its routing requirements, ghost provider host pause <HOST_UUID> pauses new rentals until you have updated and tested the address-pool configuration. Verified addresses stay verified. To have an address checked again, add it again with its new gateway, prefix, or MAC, or remove it and add it again.

Reviews of your service

Customers review providers after paid usage. How reviews are given and weighted is under Reviews.