Skip to content

Sluggish or Poor Virtual Machine Performance

There are various issues that can impact the performance of a Virtual Machine (VM) in the Cyber Range, making the user experience slower than normal. Here is a slightly technical description of each, how to detect if it is the cause for your sluggish experience, and if it is the cause, how to address the issue.

Virtual Machine Delayed First Boot

Explanation

When cloud VMs on the range are provisioned and started for the first time, each dedicated VM's underlying Virtual Hard Disk Drive (VHDD) is "instantly" cloned (by reference) from a saved VHDD image. Until the freshly provisioned system is fully "warmed up" (i.e. synchronized between the active VHDD device and the originating, read only, VHDD image), users will not be able to access their VMs. This process can take about 15-20 minutes depending on the environment. This warm-up process only impacts the first startup of a VM; subsequent startups will be much quicker.

Solution

To alleviate a majority of this wait time, the Cyber Range has implemented the Pool Model to provide pre-warmed VMs as often as possible. In cases where a pre-warmed VM may not be ready (i.e. setting the Reserved Enrollments too low for a large course), we recommend booting up all of your students' VMs at least 20 minutes before needed. This can be done by clicking "Start" on each student environment. This process only applies to first time access to a VM and subsequent startups of the VM should only take about 45-60 seconds.

Custom Desktop Settings Causing Sluggishness

Explanation

Instructors are free to customize exercise environments, including the ability to change the operating system's graphic settings (e.g. enable 2D/3D rendering effects, enable Compiz (on Linux), switch from XFCE to Gnome DEs, etc). If you are using a customized desktop environment like this, the additional CPU and memory resources needed for keeping such desktops properly refreshed can detract from the available resources for services and the OS' system scheduler. This can result in an overall slower VM session user experience. This can be seen by looking at the system load. If load levels are consistently high (or over 1-2 as seen from the Linux "uptime" command), or if you need to enable such multimedia rich settings — then please contact support to request a VM environment with additional CPU and/or memory resources. Note, that adding CPU/memory resources to an existing class/exercise architecture after the fact may require the tearing down and recreation of related instructor and student environments.

Solution

This solution is related to desktop loads vs allocated resources. In short, the fix here is to either not run desktop intensive configurations (such as Compiz, 2D/3D effects, Gnome/KDE Desktop Environments, etc), or request higher CPU/memory settings for your classroom environments (which can impose higher Cyber Range costs).

High Network Latency (Based on Location or ISP)

Explanation

This is not a common issue, as the Cyber Range does not need a lot of bandwidth to deliver a crisp, snappy graphical environment to your desktop. In a pinch, some instructors have actually run their class over a smartphone hotspot. However, what can impact perceived performance is high latency (or round trip packet time from client to the cloud and back to the client). High network latency can greatly impact the user experience, especially on graphical (non-console/ssh) sessions. As such, we recommend against high-latency connection technologies such as connecting to the Range over VPN (encrypted Virtual Private Network) connections, satellite ISPs, or congested/shared WiFi (e.g. where clients watching YouTube or Netflix can impose choppy latency issues).

Diagnose

You can test your "ping time" to the front end of the Cyber Range by (on your local PC) opening a terminal or CMD text window and typing "ping console.virginiacyberrange.net". Any ping time of under 50ms should provide a very usable client experience. A ping time from 50-100ms is usable. But a ping time over over 100-200ms will incur noticeable sluggishness or "choppiness" client experience.

Solution

If you are on a high latency network, try reconnecting from an environment with better connectivity (using the ping test as a rough metric).