#Working in a Module

Once you are inside the console, you are driving a real virtual machine. Most of what works on a normal computer works here. A few things are specific to the platform, and a few things will get you in trouble if you break them.

#How the VM is set up

Modules run on KVM under KubeVirt. Most VMs are configured the same way:

• Firmware: UEFI (OVMF). Secure Boot is off by default and on for some Windows modules. Boot menus, EFI shells, and efibootmgr work the way you would expect on bare metal.
• Disk bus: virtio by default; some modules use SCSI or SATA. Linux ships virtio drivers built in. Windows modules ship with the viostor driver pre-installed.
• Network adapter: virtio by default. The Windows driver is netkvm and is pre-installed. Some modules use an emulated card (e1000, rtl8139) when the lesson requires it.
• A second serial port (ttyS0 on Linux, EMS on Windows). This is how the autograder talks to your VM. See Don't break the autograder below.
• A helper binary called ruddergrade. On Linux it is at /bin/ruddergrade; on Windows it is at C:\Windows\System32\ruddergrade.exe. The autograder invokes it during submission.

Modules are otherwise standard installations. There is no sidecar agent watching what you type, and no Rudder Virt branding inside the guest.

#What persists, what does not

Your VM is cloned from the module's template once, before the first time you start the module. From then on it is yours for the duration: files you create, software you install, and configuration you change all stick around across sessions and across submissions. Closing the tab, signing out, and coming back tomorrow leaves the VM exactly where you left it.

The only way to get a fresh clone is a reprovision, which only a teacher or administrator can perform. A reprovision destroys the current VM and hands you a brand-new clone from the template; anything you had on the old VM is gone. Submitting for grading does not reset the VM — your work stays put after the autograder runs.

Things that are not on the VM disk also have their own lifetimes:

• Scores for every submission you make are recorded in the gradebook.
• Scratchpad notes live alongside the module and persist across reloads. See VM controls in the console for the exact lifetime.

There is no shared filesystem between you and other students. Your server VM is a different machine from another student's server, even when both have the same name and IP.

#Treat the VM like a system you're supporting

The fastest rule is one that applies in any real job: change what the work order asks you to change, and leave the rest alone. The same habit will keep you out of trouble with the autograder and is what most modules are quietly grading you on, even when the rubric does not say so directly.

• Change only what the briefing tells you to change. If a module is about installing a web server, the firewall, the existing users, the SSH config, and the rest of the system are not yours to rewrite. Many rubrics check that you did not break unrelated things.
• Do not change passwords you were not asked to change. This includes root, the user the rubric logs in as (see below), and any other accounts on the VM.
• Do not delete files that are not yours to delete. A user's home directory, application data, and unfamiliar files in /etc or /var are usually load-bearing. Move, do not delete, if you need them out of the way.
• Do not disable the firewall as a shortcut. A rubric that tests "port 80 is reachable" passes whether or not the firewall is on, but a rubric that tests "only HTTP is permitted" will fail after you have run iptables -F or ufw disable. If the briefing does not tell you to turn the firewall off, do not.
• Do not stop services you do not recognize. Time sync, logging, networking, and the serial getty (see below) are common ones to leave running. If a service is unfamiliar, treat that as a signal to check what depends on it before stopping it.
• Do not reboot to "fix" things blindly. Most issues are quicker to diagnose than a cold boot, and a reboot can interrupt grading if you submit immediately after.

If a module's lesson genuinely is about hardening, locking down SSH, or rotating credentials, the rubric is written to account for that. The rule of thumb stays the same: do what the briefing asks, and only that.

#Don't break the autograder

The autograder talks to your VM over the serial console, not over SSH. If you accidentally disable the serial port or remove the helper, the autograder cannot reach the VM and your submission will fail with a grading error rather than a low score. A few specifics in addition to the rules above:

• Do not stop or disable serial-getty@ttyS0 (Linux) or the Special Administration Console (SAC) / EMS service (Windows). If a module has you hardening services, leave the serial getty alone.
• Do not delete, move, or rename ruddergrade. This is the binary the autograder invokes. If a Linux module has you cleaning up /bin/, stop short of ruddergrade.
• Do not change the password of the user the rubric logs in as. The rubric's user and password are how the autograder authenticates. If you change them, the grader cannot run any commands.
• Do not disable the user account, lock the shell, or set nologin on the user the rubric uses. Same problem.

#Performance expectations

VMs are sized for the lesson, not for benchmarking. The numbers below are typical defaults; some modules override them.

If a module feels unusually slow, check for runaway processes inside the guest before assuming the platform is at fault. The console renders the VM's actual screen over a network connection, so a few hundred milliseconds of input lag is normal.

#When something is broken

Walk through these before submitting a help request:

1. Re-read the briefing first. Some modules intentionally block ping or SSH, ship with the network unconfigured, or leave a service down on purpose. If "broken" matches what the briefing describes, fixing it is the assignment.
2. Is the VM running? Power state shows in the menu bar; VM Controls > Power On if it is off.
3. Did the autograder previously work on this module for someone else? If so, the issue is almost certainly inside your VM, not in the platform. See Troubleshooting grading.
4. Did you change something the rubric depends on (firewall, user, serial)? Re-read the briefing and revert if so.
5. If you cannot recover, file a helpdesk ticket from the console or contact your instructor. Note that submitting a broken VM will record a low or failed grade, so do not submit until you understand what is wrong.