Manual

Virtual machines

A VM combines a boot source, vCPUs, memory, disks and virtual NICs. Create it in the Project that should own it. Before starting, ensure that the Project can use the image's Pool, an appropriate SR and a Network, and that both Project and Silo quotas have room. Use a bootable UEFI image for the current supported path.

Prepare an image

A Template supplies the definition from which hv creates a VM. Project and Silo images appear in the creation sheet. The Project Catalog can import an image or launch a VM; a download/import may run as a Task before the VM appears. Built-in installation Templates do not themselves contain an installed operating system.

The creation sheet starts from an Image. For a first VM, import an installed operating-system image from the Catalog and wait for its Task to finish. An installation Template needs operating-system installation media before it can become a usable guest. Choose the prepared image path below when you want to boot directly into Linux.

Use the creation sheet

Open the Project's VMs and select New VM. The sheet contains these controls:

Choose Create VM, then inspect the VM page and any warning. Creation can succeed while automatic start fails; use the existing VM's page to investigate and start it rather than creating another copy.

Create web-01 from a prepared image

For a first Linux guest, open production and import a UEFI-compatible cloud image through Catalog, Import to project. Wait for the import Task to finish before opening New VM. This separates an image-download failure from a VM-creation failure and lets you confirm that the selected image belongs to the intended Project and Pool.

Name the VM web-01, select that image and an SR with room for its disks. Review the image's existing disks before adding another boot disk. Choose the hardware preset or custom values according to the operating system and application, then select app-net as Network interface. If it is a VPC, it supplies private connectivity without DHCP or internet access; see networking.

Set the hostname and guest-login configuration before creating the VM. A selected SSH key is useful only if the image accepts cloud-init configuration and the guest can be reached over a suitable Network. If the image disables password login, opening the graphical console does not create a password for it. Arrange the guest's intended login method rather than assuming the hv Account also signs in to Linux.

After creation, inspect the power state and any start warning. Open the appropriate console and confirm that the operating system reaches its login. Then check the disks and Network inside the guest. Guest tools and application access are separate checks; a VM can be running while its first-boot package installation failed because the private Network has no repository access.

Configure the operating system

Cloud-init supplies first-boot configuration on a NoCloud config drive. The image must support it. Selected SSH keys require compatible cloud-config user data; arbitrary scripts do not automatically merge the selected keys. On Linux images hv configures, the default login is normally xen. A custom top-level system_info takes precedence and can change that behavior.

Install Xen guest tools adds the agent for recognized Linux images. Check its first-boot result: missing repository access can leave a running VM without tools. The agent provides OS, address and memory information that cannot be inferred from allocated RAM alone.

Windows needs UEFI and an appropriate Windows Template. Images, Build Windows image creates a reusable image from an operator-supplied Windows ISO. Choose the release, ISO, edition, storage, locale, time zone, administrator and size, then follow its Task. hv does not supply Windows or its license. The build installs PV tools and cloudbase-init and captures the generalized image. Its build VM is reserved while the job runs. A restart of hv restarts the build workflow rather than resuming Windows Setup at its previous point.

A VM from a prepared Windows image needs a password or SSH key. Keys require OpenSSH in the image. The Windows password field has Windows-specific limits; do not assume the Linux password rules apply. A virtual TPM is a VM device, not a replacement for Host firmware requirements. Secure Boot needs the Pool's UEFI certificates.

Operate and connect

Open Connect, then Graphical console or Serial console. Console control and viewing have separate permissions. Only one controller may send input on a console channel; use view-only access while another administrator controls it. JavaScript and a working WebSocket path are required.

The CLI equivalents for ordinary lifecycle operations are:

hv vm show VM --pool POOL
hv vm start VM --pool POOL
hv vm shutdown VM --pool POOL
hv vm reboot VM --pool POOL

Use the production configuration or authenticated remote mode described in CLI and API. Check the final power state and application health, not only the command's return. A normal shutdown depends on the VM's operating system responding.

Delete and troubleshoot

Shut down the VM and confirm it is halted before deletion. Review the delete confirmation and disk consequences; keep any required independent backup. The CLI command is hv vm delete VM --pool POOL. Check the resulting VM and disk inventory before reclaiming storage.

If boot fails, check the Template's actual disk content and firmware. BIOS choices are not a working boot path today. If the graphical console is garbled on a newly deployed UEFI Linux image, try its serial console; Catalog cloud-init applies a video configuration fix that takes effect on the next boot. If guest memory is absent, check guest tools rather than resizing the VM. Storage and Network failures are covered in their respective chapters.