Skip to main content

Exam VDI — SEB + Guacamole on carnaval

Author: Pierre-André Mudry · Date: August 2026 · Status: future work, not started

Scope: browser-based exam environments for BYOD student machines, served from the carnaval playground cluster. Also covers the non-exam variant (generic lab desktops). No new hardware required.

1. The problem​

Exams on student-owned laptops (BYOD) have two failure modes: the machine is uncontrolled (any tool, any file, any network), and the environment is unreproducible (every laptop is different, and nothing survives for later inspection). Buying and maintaining a dedicated exam fleet solves both at a cost the programme does not want to pay.

The alternative is to keep the exam environment on carnaval and let the student's laptop be nothing more than a screen.

2. Architecture​

Three layers, each solving one problem:

LayerComponentSolves
Local kioskSafe Exam Browser (SEB)Locks the student's machine: fullscreen, no Alt-Tab, no other apps, URL-filtered to the gateway only
DeliveryApache Guacamole (HTML5 gateway)Pure-browser RDP — no client to install, nothing executes locally, nothing can be saved locally
EnvironmentExam VMs on carnaval, dedicated VLANIdentical, isolated, disposable per-student environments; disks stay on our side after the exam

Every student connection is outbound HTTPS to one URL. The exam VLAN has no default route: the Proxmox firewall (or the core router) allows only the explicitly whitelisted targets and blocks inter-VM traffic, so students cannot reach the Internet or each other.

Why SEB and Guacamole fit together​

Guacamole renders RDP in a plain browser — and SEB is a browser, just a locked one. The combination closes the gap each leaves alone:

  • VDI alone leaves the local machine free (Alt-Tab to a local browser).
  • SEB alone leaves the environment on the student's machine (uncontrolled, unreproducible).
  • Together, the machine is locked and the environment runs on carnaval.

Config Key enforcement. The reverse proxy in front of Guacamole verifies the X-SafeExamBrowser-ConfigKeyHash header, so only an SEB instance running our exam configuration reaches the gateway. A normal browser is rejected — the URL leaking does not matter.

3. Exam workflow​

  1. Template: one exam VM image (Ubuntu + only the allowed tools + the subject), snapshotted.
  2. Clone: one linked clone per student — a few GB each on fast-vm, scripted qm clone.
  3. Accounts: throwaway per-exam Guacamole accounts, 1 student → 1 VM mapping. (edu-ID OIDC is possible but throwaway accounts are simpler to isolate and purge.)
  4. Exam: students boot SEB with the distributed config file; surveillance in the room continues as usual (see limits below).
  5. After: harvest results, keep the VM disks as long as fraud claims can arise, then destroy the clones. carnaval returns to normal duty.

4. Sizing​

Reference numbers, to verify with a pilot:

ItemFigure
Exam VM2 vCPU / 4 GB — 40 concurrent ≈ 160 GB RAM, comfortable on carnaval
Linked clonesa few GB each vs 20–30 GB full clones — mandatory on the 888/888/464 GB fast-vm pools
guacd (gateway VM)4–8 vCPU for ~40 sessions — guacd transcodes RDP→HTML5 server-side and is the hot spot
NetworkRDP desktop work ≈ 1–5 Mbit/s per session — fine on 1 GbE per node, no fullscreen video

5. Standing rules​

Clipboard must be disabled on both sides

Disable copy/paste in the SEB config and in the Guacamole connection parameters (disable-copy / disable-paste). Either side alone leaves the Guacamole clipboard as an exfiltration channel.

SEB does not replace room surveillance

SEB neutralises the laptop, not the phone or the second device next to it. Physical surveillance in the room stays mandatory; this design removes the technical cheating vectors, not the human ones.

6. Non-exam variant: generic lab desktops​

The same stack minus SEB gives browser-based Linux lab desktops: the exam template with a lightweight desktop (XFCE/MATE + xrdp), Guacamole open to normal browsers, edu-ID OIDC for authentication, no exam VLAN. Same sizing, same linked-clone discipline. GPU-accelerated desktops are out of scope: A2/T4 vGPU requires per-seat NVIDIA licensing, and consumer cards have no vGPU — passthrough (1 GPU = 1 VM) remains the only GPU story on carnaval.

7. Prior art — Nexus VDI (hepia)​

hepia (HES-SO Genève) develops Nexus VDI, a VDI written from scratch in Go under AGPL-3.0, sitting directly on Linux/KVM + QEMU rather than on a commercial hypervisor. What it shares with the design above, and where it differs:

  • Immutable templates plus qcow2 copy-on-write overlays, so a per-student clone costs only its delta — the same reasoning as §4.
  • Capability-based access control (user roles plus per-VM rules) instead of throwaway accounts.
  • Remote access over SPICE, with a random port and password per session, not RDP over HTML5. That needs a SPICE client on the student's machine, which the SEB-locked laptop of §2 does not allow — the browser-only property is what Guacamole buys here.
  • PCIe passthrough and USB redirection are part of the VM configuration, covering the GPU case left out of scope in §6.

Worth evaluating as an alternative to the Guacamole layer for the lab-desktop variant (§6), where the client need not be a locked browser, and as a source of operational experience before any pilot.

8. Open questions​

  • Pilot with one class before any real exam: measure guacd load and per-session bandwidth against the figures in §4.
  • SEB config distribution and versioning (the Config Key changes with every config edit).
  • Retention period for exam VM disks — align with the school's fraud-procedure rules.
  • Whether the exam VLAN firewall lives on the Proxmox side or on the core router (one owner, not both).
  • Talk to hepia about Nexus VDI (§7) before the pilot: their operational feedback, and whether the stack fits the lab-desktop variant.