- Print
- DarkLight
Overview
This article describes key concepts and entities for VM Labs and how they interact with each other.
Global Lab Settings
Global lab settings act as a collection of configurations and preferences that apply across all labs created under them. In these settings, you can establish a predefined list of images, virtual networks, and geographic locations that are available for lab creation.
Additionally, cost optimization settings such as automatic shutdown can be set as defaults for all labs, though these settings can be customized individually at the time of each lab's creation.
Labs
A lab in CloudLabs VM Labs represents a defined environment with specific configurations and settings used to create, manage, and distribute VM Labs. Each learner is provided with a VM Lab instance that mirrors the predefined lab configurations.
When setting up a lab, you can customize the VM size, select a base image from the marketplace, or create a custom image to meet specific requirements.
To manage lab usage and control costs, you can configure settings such as VM uptime, automatic shutdown for inactive VMs, and access management.
Use the activation code or add user’s emails to invite them to the lab.
VM Login Credentials
CloudLabs VM Labs also has a feature to set up both admin and non-admin credentials as per the requirement. When creating the lab, you can choose whether the lab user should be provided with a non-admin account and whether to use the same password for all the virtual machines. You can set this up as per the lab requirement.
If you enable non-admin credentials, the lab user will only receive a non-admin credential, and admin credentials will be only for the lab instructor. If the use of the same password is not enabled, the system will generate different passwords for all the virtual machines. If the non-admin credentials are provided to the lab user, the lab creator should setup the password for the admin user, and the instructor should be using this during template customization.
Image Gallery
The Compute Gallery is a centralized repository within CloudLabs VM Labs for managing custom VM images that are not available in the standard marketplace. It serves as a storage and management space where all custom-created or updated VM images are saved.
Additionally, the Compute Gallery supports the migration of images into the repository using the CloudLabs Image Migration Tool.
Template Gallery
Image customization in CloudLabs VM Labs allows you to tailor VM images specifically for your lab's needs.
The process typically begins with selecting a base image as a starting point. From there, you can install the necessary software and make the required configurations before publishing the image.
Once customized, these images are not only configured for specific labs but are also stored in the Compute Gallery. This enables the images to be reused for other labs.
Lab Instances
Lab instances are the distributable units within CloudLabs VM Labs, created for users based on predefined lab configurations.
Each lab instance is a complete, standalone environment accessible by the lab user that includes its resources, such as a virtual machine (VM), storage, and IP address.
To effectively manage cloud cost, lab instances are only deployed or created either on demand by lab users or using the Hot Instance feature.
Administrators have comprehensive control over these instances. They can connect to any instance via the shadow VM feature, as well as manage instance lifecycle actions such as start, stop, delete, and adjust access permissions.
Hot Instances
To reduce deployment wait time, CloudLabs VM Labs offers "Hot Instances." These are pre-created lab instances that are immediately available to users upon request, eliminating the delay typically associated with on-demand provisioning.
Hot Instances are particularly advantageous for managing peak demand periods efficiently, as they are ready to deploy without the usual setup time.
However, to ensure cost-effectiveness, Hot Instances have specific lifecycle policies. They are automatically deleted if not claimed within 48 hours, and the associated VMs are stopped if inactive for 30 minutes.
This approach balances immediate availability with cost management, making Hot Instances an ideal solution for time-sensitive and high-demand scenarios.
VM Uptime Quota
In CloudLabs VM Labs, you can implement an optional VM uptime quota for each lab instance, which sets a predefined limit on the total active VM usage time. Once a lab user exhausts their uptime quota, they will no longer be able to access their VM. This feature helps in managing resource utilization and controlling costs effectively.
Administrators have the flexibility to adjust the uptime quota either at the lab level or individually per lab instance. This allows for customized allocation of additional hours to specific users or labs as needed, ensuring that resources are allocated according to varying requirements and special circumstances.
Note: Although there is flexibility in setting the user quota, and there is no limit on setting the user quota, it must not extend beyond the lab's expiry date, as labs are automatically deleted upon reaching their expiration. Make sure to set the quota accordingly before the lab expires to ensure proper resource management within the lab's lifecycle."
Lab Expiry Date
Every lab in CloudLabs VM Labs is established with a predefined expiration date, which defines when the lab and all its associated instances will be automatically deleted. This occurs precisely at 00:00 UTC on the day after the expiration date.
Administrators have the capability to update or extend this expiration date as necessary, providing flexibility in managing the duration of lab availability.
This feature ensures that resources are not indefinitely tied up and helps maintain a clean and efficient operational environment.
Advanced Networking
CloudLabs VM Labs offers advanced networking capabilities, allowing you to connect all lab VMs to a virtual network. This feature is crucial when you need to manage network traffic, control ports, and ensure secure access to resources within an internal network, among other network-specific tasks.
By default, all VMs are connected to a standard virtual network (vNet). However, with CloudLab’s advanced networking options, you can either create a new vNet or import an existing one to customize according to your specific lab requirements.
Additionally, you can request access to modify vNet settings and implement network peering, enhancing connectivity and functionality across different virtual environments. This flexibility in network configuration is essential for accommodating complex and varied networking needs within your labs.
Direct Web Connect and Shadow VM
CloudLabs VM Labs features Direct Web Connect, which allows every virtual machine to be accessed directly through a web browser, eliminating the need for any third-party applications. This streamlined access enhances ease of use for users engaging with their VMs.
Additionally, the Shadow VM functionality is integrated into this feature, enabling lab administrators to connect to any user’s virtual machine. This capability allows seamless monitoring and support without disrupting the user's active session. Note that the Shadow VM feature will only work on Windows Server-based VMs.
Persistent & NON-Persistent Virtual Machine
Persistent Virtual Machine: By default, CloudLabs VMs retain its state and data even after it is shut down. This means any configurations, installed software, and files will be available the next time the VM is started. Persistent VMs are useful for scenarios where users need to save their work and return to it later, without losing any data.
NON-Persistent Virtual Machine: Enabling "Non-Persistent VM" while creating a lab implies that the lab instances and their VM resources are temporary and are designed to only exist for the duration of the lab session or until the lab expires. Once the specified duration is completed, or if the VM reaches the set expiry date, it will be deleted along with all its data. This setup is ideal for training labs or test environments where the data does not need to be retained after the session ends, ensuring a clean environment for each new session.
- Lab Duration: The lab instance will be available for a specified duration. Once this duration is completed, the VM will be deleted, and users will need to relaunch the lab instance.
- Total Attempts: The Total number of times user can launch the VM without re-registering.
Virtual Machine Shutdown and Disconnect Settings
CloudLabs VM Labs allows you to set up virtual machine shutdown and disconnect settings. Setting these up will optimize your Azure cost by deallocating the VM after a specific duration of idleness. Following are the different kinds of shutdown and disconnect configurations available in CloudLabs.
Shut down idle virtual machine: If the system is idle for a specific duration, a warning window will pop up asking if the user is active. If the VM is idle and if the user does not respond to this window, the window will timeout in 10 minutes. The VM will deallocate after the warning message is timed out. Note: The minimum duration for this is 15 minutes, and the maximum idle timeout limit is 720 minutes (12 hours).
Shut down the virtual machine when users disconnect: The VM will deallocate after a specific duration if the user has disconnected from the virtual machine.Note: The minimum duration for this is 15 minutes, and the maximum disconnect timeout limit is 720 minutes (12 hours).
Shut down virtual machine when users do not connect: If the VM is running and the user does not connect to it, then the VM will deallocate after a specific duration.Note: The minimum duration for this is 15 minutes, and the maximum no-connect timeout limit is 720 minutes (12 hours).
Supported Virtual Machine Distributions for Automatic Shutdown
For Windows images, automatic shutdown is supported for Windows Server 2016 and above.
Refer to the table below to view the list of Linux distributions that support automatic shutdown:
Distribution | Marketplace image |
CentOS | CentOS-based 7.8 (Gen2) CentOS-based 7.9 CentOS-based 7.9 (Gen2) CentOS-based 8.4 (Gen2) CentOS-based 8.5 (Gen2) |
Ubuntu Minimal | Ubuntu Minimal 20.04 LTS (Gen2) Ubuntu Minimal 22.04 LTS Ubuntu Minimal 22.04 LTS (Gen2) Ubuntu Minimal 22.10 Ubuntu Minimal 22.10 (Gen2) |
Ubuntu Server | Ubuntu Server 20.04 LTS Ubuntu Server 20.04 LTS (Gen2) Ubuntu Server 22.04 Ubuntu Server 22.04 (Gen2) Ubuntu Server 22.10 |
Ubuntu-HPC | Ubuntu-HPC 20.04 (Gen2) |