VM Management

Overview

HyperCX allows users to create new VMs using prebuilt templates and they are defined in a way that multiple VMs can be deployed using the same template and context. Creating new VMs can be as easy as a click of a button everything is predefined by us and users just need to initialize the template. Having control over a running VM is quite important and this section defines some important aspects.

Create Virtual Machine

Simply create the VM with steps below: 1. Click Instance > VMs > Create VM. Users

  1. Select the Template.

Users

  1. Adjust name for VM, Memory, CPU, VCPU and Storage.

  2. Then Create.

Note

For templates downloaded from a market, the name of the VM will be used as hostname inside the VM. This behavior can be changed.

Resizing Virtual Machine Capacity

You may resize the capacity assigned to a Virtual Machine in terms of the virtual CPUs, memory and CPU allocated. VM resizing can be done in any of the following states: POWEROFF, UNDEPLOYED.

If you have created a Virtual Machine and you need more resources, the following procedure is recommended:

  • Perform any operation needed to prepare your Virtual Machine for shutting down, e.g. you may want to manually stop some services

  • POWEROFF the Virtual Machine

  • Resize the VM

  • Resume the Virtual Machine using the new capacity

Resizing Virtual Machine Disks

To adjust the size of a disk in the VM can be done live or with the VM turned off. Go to the VM menu and in the Storage section click on Users.

A window like the one below will be displayed showing the original size of the VM, increase space and click on resize.

Users.

For Linux based VMs and containers nothing else needs to be done. New capacity will be reflected automatically inside the VM/container. For Windows Server after resizing the disk through portal, user will need to expand the partition manually inside the Windows VM by following below steps:

  • Search Disk Management.

  • Check if there is an unallocated space in disk, if not click Action > Refresh.

  • Select the disk that you want to resize.

  • Right Click and Choose Extend Volume.

  • Adjust Size for Disk.

  • Finish.

Users.

Important

When the VM has a snapshot created on the disks, it is not possible to resize. To do this it is necessary to remove the snapshot.

Warning

Live disk resize is not supported for LXD containers

Attach a disk

To attach a disk to a VM go to the VM menu, in Storage click on Users. In the next menu select an existing image or a new empty disk (volatile disk) to be attached to the VM, this process can be done live. Users

Note

When you selecting a volatile disk (or a new datablock) on HyperCX, it contains no format. Because of this, attaching volatile disks or empty datablocks to containers is not supported at this moment.

Modifying CPU Topology

To modify the CPU Topology of a VM go to the VM menu, in Conf click on Users. In the next menu select Tags and add the following lines within Data box.

<cpu mode='host-model'>
   <topology sockets='2' cores='2' threads='1'/>
</cpu>

Note

The VM must be powered off for the changes to take effect.

Accessing the VM

SSH access for Linux based VMs

HyperCX offers password-less authentication by default so all a User needs to do is provide their public SSH key(RSA SSH-2 preferably) on the HyperCX portal, then initialize the VM and once it’s initialized user can access the VM using their private key and user as root. More information can be found here.

RDP access for Windows based VMs

Windows VMs can be accessed using RDP. By using this feature, HyperCX will provide a RDP session configuration file.

How to Activate it:

  • Go to Windows Template.

  • Click Update.

  • Select Network Section.

  • Select the Network and Activate the RDP.

Users.

Once the VM is instantiated, users will be able to download the RDP configuration file.

Users.

Important

The RDP can be activated on a single NIC only. If this option is enabled in several NICs, the RDP configuration file will only contain the IP of the first NIC where it was enabled.

Note

If the VM template has a password and username set in the contextualization section, this will be reflected in the RDP file.

VNC access for any platform

HyperCX implements a VNC client to connect out-of-band to the VM. Any VM can be accessed using VNC by clicking on this icon.

The VNC endpoint varies depending on the hypervisor:

  • For KVM, the endpoint is the VNC server integrated into QEMU. This will show the video output from the VM.

  • For LXD, the endpoint is an interactive session using the output from “lxc exec $container login”.

Terminating VM Instances

You can terminate an instance with the onevm terminate command, from any state. It will shutdown (if needed) and delete the VM. This operation will free and destroy the resources (images, networks, etc) used by the VM. This operation can not be rolled back.

If the instance is running, there is a --hard option that has the following meaning:

  • terminate: Gracefully shuts down and deletes a running VM, sending the ACPI signal. Once the VM is shutdown the host is cleaned, and persistent and deferred-snapshot disk will be moved to the associated datastore. If after a given time the VM is still running (e.g. guest ignoring ACPI signals), HyperCX will returned the VM to the RUNNING state.

  • terminate --hard: Same as above but the VM is immediately destroyed. Use this action instead of terminate when the VM doesn’t have ACPI support.

Pausing VM Instances

There are two different ways to temporarily stop the execution of a VM: short and long term pauses. A short term pause keeps all the VM resources allocated to the hosts so its resume its operation in the same hosts quickly:

  • suspend: the VM state is saved in the running Host. When a suspended VM is resumed, it is immediately deployed in the same Host by restoring its saved state.

  • poweroff: Gracefully powers off a running VM by sending the ACPI signal. It is similar to suspend but without saving the VM state. When the VM is resumed it will boot immediately in the same Host.

  • poweroff --hard: Same as above but the VM is immediately powered off. Use this action when the VM doesn’t have ACPI support.

You can also plan a long term pause. The Host resources used by the VM are freed and the Host is cleaned. Any needed disk is saved in the system datastore. The following actions are useful if you want to preserve network and storage allocations (e.g. IPs, persistent disk images):

  • undeploy: Gracefully shuts down a running VM, sending the ACPI signal. The Virtual Machine disks are transferred back to the system datastore. When an undeployed VM is resumed, it is then moved to the pending state, and the scheduler will choose where to re-deploy it.

  • undeploy --hard: Same as above but the running VM is immediately destroyed.

  • stop: Same as undeploy but also the VM state is saved to later resume it.

When the VM is successfully paused you can resume its execution with:

  • resume: Resumes the execution of VMs in the stopped, suspended, undeployed and poweroff states.

Rebooting VM Instances

Use the following options to reboot a VM:

  • reboot: Gracefully reboots a running VM, sending the ACPI signal.

  • reboot --hard: Performs a ‘hard’ reboot.

Note

VMs on reboot always recontextualizes the data from the VM template therefore changes made to the environment(initially contextualized) will be restored to the ones defined in the context variables of the VM template.

Delaying VM Instances

The deployment of a PENDING VM (e.g. after creating or resuming it) can be delayed with:

  • hold: Sets the VM to hold state. The scheduler will not deploy VMs in the hold state. Please note that VMs can be created directly on hold, using ‘onetemplate instantiate –hold’ or ‘onevm create –hold’.

Then you can resume it with: - release: Releases a VM from hold state, setting it to pending. Note that you can automatically release a VM by scheduling the operation as explained below

Attaching/Detaching an NIC

New NICs can be hot-plugged directly and user can continue their work without even worrying about restarting the VM. To attach a new navigate to the desired VM select Network tab and click on while for removing a network select the cross button to remove the desired NIC. Keep in mind that cases as Centos may change the default gateway. To know how to avoid this, go to Virtual Networks.

Example

Disk Save As

Virtual Machine's virtual disks can be saved as a new image. This new image can be used to create a new template or be attached to an existing VM.

To export the VM's virtual disk as an image go to Storage tab inside the VM's view and click the Save As icon. This action can be done live, or with the VM powered down. It will create a new image out of the saved virtual disk and can be located in Storage > Images.

Attach disk

New disks can be attached to running or powered off VMs. To attach a new virtual disk to the VM go to Storage tab inside the VM's view and click the Attach disk button.

Note

LXD containers can not have volatile disks or empty datablocks attached.

Save a VM Instance

Any VM can be saved as a new template before it is destroyed. To do so, the user has to poweroff the VM first and then use the save operation.

This action clones the VM source Template, replacing the disks with snapshots of the current disks (see the disk-snapshot action). If the VM instance was resized, the current capacity is also used. NIC interfaces are also overwritten with the ones from the VM instance, to preserve any attach/detach action.

This feature is compatible with both KVM and LXD hypervisors.

Understanding Virtual Machine Lifecycle

During any modification/initialization or any other task a VM displays its status and to have complete information and control over User’s running VMs it is important to understand these states. Admin can view the status on Instances -> VMs. While a user can view state by heading over to the VMs tab on the portal and hovering over the status icon.

Following is a descriptive table that defines status of a VM.

Short state State Meaning
pend Pending By default a VM starts in the pending state, waiting for a resource to run on. It will stay in this state until the scheduler decides to deploy it, or the user deploys it using the onevm deploy command.
hold Hold The owner has held the VM and it will not be scheduled until it is released. It can be, however, deployed manually.
clon Cloning The VM is waiting for one or more disk images to finish the initial copy to the repository (image state still in lock).
prol Prolog The system is transferring the VM files (disk images and the recovery file) to the host in which the virtual machine will be running.
boot Boot HyperCX is waiting for the hypervisor to create the VM.
runn Running The VM is running (note that this stage includes the internal virtualized machine booting and shutting down phases). In this state, the virtualization driver will periodically monitor it.
migr Migrate The VM is migrating from one resource to another. This can be a life migration or cold migration (the VM is saved, powered-off or powered-off hard and VM files are transferred to the new resource).
hotp Hotplug A disk attach/detach, nic attach/detach operation is in process.
snap Snapshot A system snapshot is being taken.
save Save The system is saving the VM files after a migration, stop or suspend operation.
epil Epilog In this phase the system cleans up the Host used to virtualize the VM, and additionally disk images to be saved are copied back to the system datastore.
shut Shutdown HyperCX has sent the VM the shutdown ACPI signal, and is waiting for it to complete the shutdown process. If after a timeout period the VM does not disappear, HyperCX will assume that the guest OS ignored the ACPI signal and the VM state will be changed to running, instead of done.
stop Stopped The VM is stopped. VM state has been saved and it has been transferred back along with the disk images to the system datastore.
susp Suspended Same as stopped, but the files are left in the host to later resume the VM there (i.e. there is no need to re-schedule the VM).
poff PowerOff Same as suspended, but no checkpoint file is generated. Note that the files are left in the host to later boot the VM there. When the VM guest is shutdown, HyperCX will put the VM in this state.
unde Undeployed The VM is shut down. The VM disks are transfered to the system datastore. The VM can be resumed later.
fail Failed The VM failed.
unkn Unknown The VM couldn’t be reached, it is in an unknown state.
clea Cleanup-resubmit The VM is waiting for the drivers to clean the host after a recover --recreate action
done Done The VM is done. VMs in this state won’t be shown with onevm list but are kept in the database for accounting purposes. You can still get their information with the onevm show command.

VM Snapshots

You can create, delete and restore snapshots for running VMs. A snapshot will contain the current disks and memory state.

At the moment this feature is only available for KVM, it will soon be available for LXD. Please take into consideration the following limitations:

  • The snapshots are lost if any life-cycle operation is performed, e.g. a suspend, migrate, delete request.

  • Snapshots are only available if all the VM disks use the qcow2 driver.

Users

Migrating VMs

It is possible to migrate VMs from one node to another "live" within the same cluster, that is, without shutting down the VM.

There are 2 supported methods:

  • Migrate: The VM will be gracefully powered down.
  • Migration Live: The VM will be live migrated, the state will not be lost.

Warning

Containers do not currently support live migration. This feature is being implemented by a project called CRIU.

Users