--- title: "VM lifecycle" description: "After a VM is provisioned: start, stop, restart, resize, console, snapshot, clone, delete — from the dashboard." url: "https://metalhost.net/docs/dashboard/guides/vms-lifecycle" --- # VM lifecycle After a VM is provisioned, you can stop and restart it, resize it, open a console, create and restore backups, clone it, or delete it. Every operation is reversible except `delete`. ## States | State | Meaning | | --- | --- | | PROVISIONING | Boot disk being prepared. Operation still running. | | STARTING | Compute reserved, guest booting. | | RUNNING | Guest is up and reachable. | | STOPPING | Graceful shutdown in progress. | | STOPPED | Off, but boot disk preserved and still billed. | | DELETING | Resources being torn down. | | DELETED | Terminal. VM no longer billed. | ## Start, stop, restart Open the VM detail page (*Compute* → click the VM). The quick-actions row has **start**, **stop**, and **restart**. Stop issues a graceful shutdown; **force stop** is offered only when graceful stop has stalled. Stopping preserves the boot disk and any attached data disks — restart brings the VM back with the same hostname, networks, public IPv4, and firewall rules. Stopping an hourly VM pauses vCPU, RAM, and GPU runtime charges. Its boot disk, attached data disks, and allocated public IPv4 remain provisioned and continue billing. Delete resources you no longer need. ## Resize From the VM detail page, click **Resize** in the quick-actions row. A modal opens — set the new **vCPU** and **RAM** and confirm. The modal shows the price delta and warns that the VM will reboot. Because the CPU and memory of a running guest can't be changed live, resize is a stop → patch → start sequence. Expect 10–60 seconds of downtime depending on how long the guest takes to shut down gracefully. Boot disk, data disks, network, public IPv4, and firewall rules survive. ## Console (serial & VNC) When SSH isn't an option — boot loop, broken sshd, cloud-init wedged — use the console. VM detail page → **Console** tab. The browser embeds a terminal directly (serial) or a graphical session (VNC), no extra tooling needed. Use the **pop out** button to detach the console into its own window. ## Backups A whole-VM backup is a point-in-time copy of a VM's definition and every attached persistent disk. Backups are project-scoped, billed by retained GiB at the backup-storage rate, and remain available even after the source VM is deleted. > **backups stay in the original datacenter** > > Backups live in the same datacenter as the source VM. They protect against guest-level mistakes (bad upgrade, accidental delete) but not against datacenter-level loss. Replicate critical data off-site if you need that guarantee. VM detail → **Backups** tab. Choose a *Whole-VM backup* or *Single-disk backup* and create a copy. To restore a whole VM, use the backup's restore action, or *Compute → Create VM*, switch to **From backup**, pick the snapshot, configure the new VM, create. Every captured boot and data disk is restored to a new volume and attached before the new VM first boots. Restore creates a new VM in the original project, network and datacenter; it does not replace or stop the original. The new VM and disks incur their own charges. Monthly reservations and public IP identities are not copied. Check the displayed disk list before restoring an older backup. ### Automatic policies and retention Use the VM's **Backups** tab for a VM policy, or **Storage → Backups** for disk and whole-project policies. Choose hourly, daily or weekly timing in your browser's local time, and how many successful copies to keep per source. Project policies include every VM and each unattached disk; they do not capture the entire project at one atomic instant. Schedules are stored as fixed UTC times. The dashboard converts them to local time; the displayed local hour can shift when daylight saving time changes. The API and CLI accept UTC times explicitly. Retention only deletes older automatic copies belonging to that policy. Manual backups are retained until you delete them. Pausing stops new captures; deleting a policy keeps its existing backups. Leave snapshot quota headroom for the next capture to succeed before the oldest is pruned. Online VM captures use the QEMU guest agent to quiesce filesystems when available. Writes can briefly stall, but the VM is not intentionally shut down. Check the recorded consistency: **QUIESCED**, **CRASH_CONSISTENT**, or **OFFLINE**. Single-disk backups are crash-consistent. Memory is not captured. See the [KubeVirt snapshot behavior](https://kubevirt.io/user-guide/storage/snapshot_restore_api/) for guest-agent participation and failure handling. ## Clone Clone is snapshot-then-restore in one click. VM detail → **Clone** in the quick-actions row. Set the new VM's display name; optionally override the shape; click *clone VM*. The server snapshots the source and provisions a new VM whose disks start as a copy. Your custom firewall rules **are** copied; the network is **not** — the clone lands on the source VM's network, not a new one. ## Monthly billing controls Only relevant for VMs in a monthly billing mode. Hourly VMs have no term. - **Auto-renew** — when on, the wallet is debited at term-end for another term at the current rate. Set at create time on the dashboard. - **Renew now** — immediately charges the wallet for one more term, regardless of how much of the current term is left. ## Delete VM detail → **Danger** tab → **Delete**. Type the hostname to confirm; the dialog shows the final cost (any partial-hour usage). The boot disk is released by default — snapshot first if you want to keep the data. ## What's next - [SSH keys](https://metalhost.net/docs/dashboard/guides/ssh-keys.md) — register reusable keys per project. - [Public IPv4](https://metalhost.net/docs/dashboard/guides/public-ipv4.md) — pricing, attach, default-deny. - [Firewall rules](https://metalhost.net/docs/dashboard/guides/firewall.md) — control inbound traffic.