Skip to content

Article VIRTUAL LAB

Reading time
5 min
Published

A virtual lab for companies: fewer problems before IT training

A virtual lab sorts out responsibilities between the instructor, the organiser and the IT department. The programme defines the configuration, the company sets the security boundaries, and participants receive separate workstations ready for the duration of the event.

A lab starts with a division of responsibilities

The instructor knows the exercises and the tools they need. The IT department defines the rules for the network, data and accounts. The organiser is responsible for the participant list, the date and communication. The environment provider turns this information into a base image, a topology, an access method and a machine lifecycle.

When no one owns a decision, delays follow. The instructor should not approve the use of company data on their own, and the security team will not choose the library version the material requires. A short specification with named owners works better than a long exchange of e-mails that settles nothing.

The base configuration is a common reference point

The image should contain the specified operating system, runtimes, libraries, clients, repositories and starting materials. The instructor goes through the whole scenario on it from a participant account. Once accepted, the configuration is replicated rather than rebuilt by hand on each VM.

Changes after acceptance require another test. Even a small package update can change a message, a dependency or the result of an exercise. The image version should be visible to the team supporting the event, so that it is easy to establish which configuration a workstation was created from.

The topology must match the way the group works

The simplest option is a separate VM for each person. It works well for programming, administration and tools that run locally. Kubernetes, distributed systems and networking exercises may require several nodes or shared services. In that case, you need to define the boundaries between users and the components that become shared.

A shared cluster or database lowers the number of resources but increases the risk of participants affecting one another. Namespaces, roles or schemas help, but they do not always provide full isolation. The decision should be weighed against what participants will do, especially whether they can change global configuration.

The IT department needs specifics to assess security

The assessment should cover addresses and ports, the authentication method, account validity, outbound traffic rules, the type of data and whether file transfer is possible. A general statement that “the environment is in the cloud” answers none of these questions.

The lab should not contain production secrets. Input data can be synthetic or anonymised. If participants connect from the company network, the test should be run behind the same proxy and filtering. Security exceptions negotiated as the sessions begin usually cost more time than an earlier pilot.

The participant should get a short path in

The welcome message contains the address, how to receive the sign-in details, the supported browser or SSH command, and a contact for help. After signing in, the user sees the first step and the materials. They should not have to choose between several clients and configuration variants if the programme does not require that decision.

A desktop in the browser reduces installations on the laptop, and SSH is a good fit for terminal workshops. Both methods can lead to the same machine. The choice depends on the application, the connection and the device policy, not on which method sounds more technical.

Support should take advantage of identical workstations

The VM number, the exercise stage and the error message are enough to start diagnosing. The instructor can compare the problem with another workstation, check a service's status or, with the user's consent, open the session. If a fault concerns the base image, the information goes to the whole group. If it concerns the solution, the help should lead the participant towards working it out for themselves.

Resetting one machine must not affect the others. A snapshot or recreating the VM restores the state, but the mechanism should also cover data and accounts. Before the event, the team rehearses at least one failure scenario.

Shutting the lab down is part of the operational agreement

The date on which access expires, how results are exported and the rules for deleting data should be known before the training. After the event, accounts are disabled, public ports are closed and the VMs are deleted. The organiser keeps only the agreed materials, not participants' entire home directories.

Scenarios for training and development environments show different topologies and their limitations. A virtual lab is not a single off-the-shelf product. Its value comes from matching the configuration to the programme and from a clear division of responsibilities on both sides.