Skip to content

Article WORKSHOP LOGISTICS

Reading time
5 min
Published

Virtual machines for the duration of an IT workshop

A workshop needs infrastructure for a specific period: before the sessions for testing, while the group is working and for a short while afterwards to export results. Temporary VMs let you match the lifecycle of the workstations to the event calendar.

The reservation period should cover more than the class hours

Machines started exactly when the training begins leave no time to sign off the configuration. The instructor should sign in beforehand as a participant, run through the main scenario, check the materials and confirm that reset works. With a more complex topology, a connection test from the organiser's network is also needed.

After the workshop it is worth leaving a short window for exporting code, reports or configuration. Its length depends on the type of data and on what has been agreed with participants. The expiry date must be known before the start, so that nobody treats a temporary VM as permanent storage.

The specification links the syllabus to the configuration

The number of workstations and the hardware specification are needed, but they are not enough. The environment provider should receive the operating system, tool versions, repositories, test data, the permission model, ports, the sign-in method and a list of services that should be running after start-up. For a group, the key element is the base configuration from which identical copies will be made.

It is worth tying requirements to the exercises. If participants build container images, you need to plan for disk space and access to a registry. Data analysis may need more memory, and compilation spare CPU. Specifications that follow from the task are easier to verify than a general wish for a “powerful machine”.

The acceptance test should have an unambiguous result

Before the event, the instructor runs a short set of checks: signing in, starting the tool, accessing the materials, running a sample command and saving a result. In a multi-machine lab they also check communication between nodes. Every test should end with an observable result, not a statement that the configuration “looks fine”.

Sign-off from an administrator account does not replace a user's trial. Permissions, the home directory and access to services may differ from what the person preparing the image sees. A useful addition is a test on one device and on one network similar to the group's conditions.

Access must be handed over securely and in advance

Each person should receive their own account and a workstation identifier. Passwords or one-time links should not end up in a shared document. Participants can run a short technical test the day before, without opening the full training material.

With a desktop in the browser, you need to confirm access over HTTPS and how the session behaves. With SSH, the port, the key or password and the ability to connect from the company network all matter. The instructions should give one primary method and a simple way to report a problem.

Spare capacity protects the group's pace

The machine profile should be sized for the peak stage of the exercises, not for the state just after start-up. If all participants compile a project, import data or build images at the same time, the load will arrive at the same moment. A test of one VM will not show the effect of the whole group working in parallel.

That does not mean every workstation has to be oversized. You can run a trial on a few copies beforehand, watch CPU, memory, disk and network, and adjust the configuration. A shared component, such as a registry or a database, needs a separate assessment, because it becomes the point where traffic converges.

The support plan should distinguish between types of problems

On the day of the class you need one person responsible for access and the state of the infrastructure, and an instructor responsible for the material. Participants do not need to know about this division. They report their workstation number and the symptom in a single channel, and the team works out whether the problem concerns the network, the base image or the exercise.

A snapshot or recreating the affected VM lets you return to the starting point, but a reset should not be the first reaction to every error. If the problem comes from the task and has teaching value, it is better to analyse it. When the prepared environment fails, quick restoration protects the group's time.

Shutting the environment down needs a short checklist

Before access ends, participants export the agreed results. The organiser confirms which data should be kept, revokes temporary credentials and closes publicly accessible ports. The machines can then be deleted on the agreed date.

The model for preparing and closing down an environment lets you pay for the agreed reservation period instead of maintaining a lab between events. It is particularly useful for workshops whose configuration matters for only a few days and can be recreated from a documented base configuration.