Skip to main content

Virtual Machines

Realms

A realm is a hypervisor which is a specific type of computer software that is used to create and run virtual machines. These realms can only be managed in the configuration files. Users can view the Realms that exist in the system through the "Realms" tab in management. Associated to each Realm is a Driver. The purpose of this driver is so the backend of the system knows HOW to communicate to the infrastructure. Realms do NOT connect to other realms. Users of tiCrypt cannot create their own realms. The realms section of the management tab is just to see which realms and drivers exist in the system.

The actions that can be done in this tab are as follow.

ActionNotes
Fix VMs A user sync up all of the current VMs.
Fix drives A user can sync up all of current drives.

About every hour, the backend of the system syncs up what is in the database and what is known to libvirt to actually be running. If a user would not like to wait and would like to do it manually they can do so by selecting fix on either the VMs and or drives.

Libvirt Hosts

Hosts are the servers that host the virtual machines, or where the virtual machines live. These servers are physical and actually exist somewhere. These hosts are the "home" of the realms, which is the software that creates and run the VMs. Each of these realms consist of servers and other components.

A Host can be added by selecting the plus icon located at the top right side. A modal will appear that prompts the user to select a Realm, a name, a URI, the hardware Profile, and the state.

A Host has the following actions.

ActionNotes
Delete A user can delete a host.
Edit A user can edit the basic information about a host such as the name.
Change State A user can change between three states of the host.
Check utilization A user can check the resources that have been used up in the host.

There are three different states that a host can be. They go as follows.

Enabled: tiCrypt can interact with the host and schedule VMs on it.

No scheduler: tiCrypt can interact with the host however, it cannot schedule VMs on it.

Disabled: tiCrypt cannot interact with the host nor can it schedule VMs on it

The reason for changing states is to allow a flexible architecture of the Libvirt hosts over Virtual Machines.

Check utilization serves various resource management purposes and has the following quotas:

  • Name of the host
  • Realm ID
  • Current number of active VMs out of the total VMs
  • Current number of cores out of the total cores
  • Current memory out of the total available memory
  • Current number of devices out of the total available devices

Hardware Profiles

Hardware profiles define the specific VM hosts on the system. These are necessary to transfer the information to the scheduler about what resources are still available on the host. Hardware profiles tell the system how many resources on a specific host are allowed to be used for scheduling and running virtual machines.

Hardware profiles can be created in this tab.

Libvirt Storage Pools

There are different tiers of storage that a user may want to use for their drives such as flash or slower spindle. Libvirt Storage pools is the interface that allows fast or slow types of drives to be created.

Libvirt Volumes

Libvirt Volumes are essentially the "disk" where the operating system lives. Users cannot populate the volume tab through tiCrypt. Rather, the system backend communicates with the host and requests all of the volumes that have been integrated into the system.

Libvirt volumes listing

VM Images

A Virtual Machine Image is a fully configured virtual machine as a file that is used during deployment. A virtual machine defines the Realm, the volume, and the operating system. When defining the OS upon creating an image, the OS MUST match the OS that is associated with the Volume.

note

For each Volume, there can only be one VM Image.

VM images can be edited, deleted, or cloned in this tab.

VM Hardware Setups

Hardware setups are configuration setup templates for virtual machines. Specifically, they specify:

  • the realm the VM will use
  • the virtual machine image
  • the number of cores
  • the amount of memory (RAM)
  • the list of devices such as GPUs/FPGAs
  • debug options such as pty and console.

Hardware setups can be created in this tab. The actions that can be done on a hardware setup are as follows:

ActionNotes
Edit A user can edit the components of the hardware setup.
Clone A user can clone an existing hardware setup.
Simulate allocation A user can simulate how the scheduler would land on the host. This is commonly used for debugging.
Delete A user can delete a host.

VM Configurations

This tab shows all of the VM configurations in the system of both running and shutdown VMs. Virtual machines can be started, edited, and deleted in this tab

Running VMs

This shows all running VMs in the entire system. When a VM is selected, there are a variety of actions that can be done.

ActionNotes
View logs A user can view the logs pertaining to selected virtual machine.
Set Project A user can assign a new project to the virtual machine if and only if the tag of the new project is a subproject of the parent one.
Shutdown A user can shut down a virtual machine from the management tab.
Open VNC A user can open a VNC terminal which is used for running virtual machines in debug mode. This enables admins to login to debug an issue.

All of these actions can be accessed as seen in the video below.

Past VMs

This tab will show the hundred most recent VMs that have been shut down or that have become inactive. It is very important to view logs if something unexpectedly weent down. The only action that can be done here is view logs.

Service VMs

This tab displays all of the service VMs that exist in the system. Recall that service VMs are VMs that are used for a more harmonious workflow in updating and maintaining virtual machines. Service virtual machines are virtual machines that have minimal restrictions, have access to the internet but DO NOT have access to the encrypted drives or the vault. These machines cannot be used for research and they are only available for maintenance by administrators.

Service machines are exclusively created and used in this tab. They do not exist anywhere else in the system.

The actions that can be done here are as follows:

ActionNotes
Restart Controller A user can edit the basic information about a host.
Shutdown A user can shutdown a virtual machine.
Delete A user can delete a virtual machine.
Edit A user can edit information about the VM such as cores, memory, etc.
Open VNC A user can open a VNC terminal .
Power up A user can turn on the VM.

Drives

This tab displays all drives that exist in the system.

The actions that can be done here are as follows:

ActionNotes
Transfer ownership A user can edit the basic information about a host.
Unshare with everyone A user can shutdown a virtual machine.
Delete A user can delete a virtual machine.
Edit A user can edit information about the VM such as cores, memory, etc.
Open project A user can open a VNC terminal .
Share A user can delete a host.

Licensing Servers

Licensing servers allow users to add IP addresses that all of the virtual machines can connect to. These servers allow you to create entries that get placed in an allowed list that all VMs can access when running. This may be used to contact licensing servers for software.

ActionNotes
Create A user can edit the basic information about a host.
Re-sync A user can shutdown a virtual machine.
EXport CSV A user can edit information about the VM such as cores, memory, etc.
Delete A user can delete a virtual machine.

The drives tab allows users to view all of the drives that have been created in the Virtual Machines tab.

For each drive, the name, owner, team, size, and format are displayed.

A Drive has the following actions.

ActionNotes
Info A user can view basic information about a drive.
TransferOwnership A user can transfer the ownership of the drive to another user.
Delete A user can delete a drive.

A user may want to transfer the ownership of a drive. This can be thought of, essentially, as someone sharing a USB drive with another person. A VM must not be running. The owner of the drive can "transfer ownership" or give the "USB" to another user so that the user can use that drive in one of their VM's. A user can only transfer ownership of a drive to an individual who already have access to that drive.

The way that the drives work is as follows:

When a user creates a drive, it is encrypted using their public key, and another key that the system generates is called a symmetric key. This information is sent and lives on the server. If a user would like to share access of the drive with another user, their private key is used to decrypt the symmetric key. Using the receiver's public key, a version of the symmetric key is created, and another "chunk" of information is sent to the server.

The cryptography used for the drives prevents any type of admin in the system from simply granting themselves access to a drive and taking them over. ONLY users who were added to or created a drive can access them.

System Services: allow for a super admin to restart a specific service in frontend or to look at logs of a specific service to better debug.

Audit log: interface that shows lines of the audit log being written; confirms that the auditing is working.

Running VMs: do the VM actions of any VM that is currently running throughout the entire system.