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:
Instance > VMs > Create VM.
- Select the Template.
Adjust name for VM, Memory, CPU, VCPU and Storage.
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 .
A window like the one below will be displayed showing the original size of the VM, increase space and click on resize.
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.
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.
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 . 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.
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 . 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>
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.
Select Network Section.
Select the Network and Activate the RDP.
Once the VM is instantiated, users will be able to download the RDP configuration file.
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.
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.
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.
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.
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.
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.
|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.|
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.
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.
Live: The VM will be live migrated, the state will not be lost.
Containers do not currently support live migration. This feature is being implemented by a project called CRIU.