Introducing LabConsole for live online IT training: built by instructors, for instructors

Running a live IT class today means working across separate tools, each with its own setup and its own logins. The meeting app carries the voice and the slides. The student machines are somewhere else: a lab vendor's portal, or throwaway boxes the students RDP into, each running a desktop hypervisor. Neither one shows the instructor a student's screen. When a student goes quiet, you ask for a screen share and wait.

LabConsole puts the class in one browser window. Each student works on real virtual machines, and the instructor sees every student's screen on one grid, with audio, video and the slides in the same window. Guru Labs instructors built it for their own classes, still teach on it every week, and are opening it to any IT training team at labconsole.com, with public pricing.

The instructor grid, recorded live: eight student machines on one screen, each showing a live terminal or desktop. As a student speaks, their card turns over to show their camera, then back to their screen.

Where it came from

Guru Labs has taught hands-on Linux classes since 1999. For years our virtual classes, and our partners' classes, ran on a lab service most of those customers knew as rlabs, the Remote Lab Access platform behind Guru Labs courses. Every student got real machines. Instructors got a grid of live screens because they missed seeing the room. We still teach on it every week.

LabConsole is the same platform without the tie to Guru Labs courseware. Your own lab VMs go in, and the class can be anything that runs on x86: a vendor's appliance certification or an internal Kubernetes bootcamp.

Bring your own lab VMs

Upload the OVA you already ship. LabConsole converts it to native KVM automatically, multi-disk and multi-NIC appliances included, and adds it to your organization's private template library. A course blueprint composes templates into one student's lab: your appliance plus a client VM plus a router, say. Schedule a class, set the head count, and LabConsole builds a private copy of that lab for every student before anyone arrives. Teams without an appliance start from standard OS bases instead.

Real machines, private per student

Every student lab is a set of full KVM virtual machines on x86 hardware. Linux, BSD, Windows, firewalls, storage appliances: if it boots on x86, it runs. Each student's lab sits on its own private network, so one student's broken DHCP experiment never reaches another's. Consoles, graphical and text, run in the browser. Students see the BIOS, the bootloader, the installer, and the kernel panic. When a lab goes past the point of no return, restore the machine or the whole lab to the course baseline and keep teaching.

The instructor grid

The grid shows every student's live screen at the same time. In a physical classroom you notice the terminal that stopped moving as you walk the aisle; the grid gives you that same signal from your desk. Click a tile and you have that student's keyboard and mouse on their actual machine. Fixing the typo in their config file takes ten seconds, they watch it happen, and nobody had to find the share button. Our instructors have taught on this grid for years and will not run a virtual class without it.

Teach in the same window

Lecture and lab share the window. Upload a PDF deck and present it: the page you turn to is the page every student sees, with your laser pointer drawn on top of it. Instructor audio and camera video are built in, so there is no second app to join. To walk the class through a lab, share any lab machine's screen to everyone, read-only. A countdown timer marks the lab period, and students can send pace feedback, such as "need more time", which shows up on the grid. Class-wide and private chat are always available.

Nothing for students to install

Students open a browser and type an access code. No learner accounts, no client software, no VPN. LabConsole collects a display name from a student; no student account, email address, or password exists. Live views of lab screens are streamed, never recorded, and presentation audio and video are live only.

Automate the class

Everything the instructor can do in the UI is also a REST API call, and a built-in MCP server exposes the same operations to AI agents. Both are in every tier. Scheduling next month's cohort from a script, or asking an agent to reset a station, uses the same verbs the grid does.

Pricing you can put in a quote

Three monthly plans, no annual commitment:

• Starter, $249/mo: 40 weighted VM-days included, $6.50 per weighted VM-day over, 1 classroom at a time, up to 30 students.
• Growth, $749/mo: 150 weighted VM-days included, $5.50 per weighted VM-day over, 3 concurrent classrooms, up to 75 students, white-label branding +$149/mo.
• Scale, $1,995/mo: 500 weighted VM-days included, $4.50 per weighted VM-day over, 8 concurrent classrooms, up to 200 students, white-label branding included.

The meter: one weighted VM-day is one student lab VM existing on one scheduled class day, where a 2 vCPU / 4 GB machine counts 1.0 and bigger machines weigh in proportion (the larger of vCPU/2 and RAM GB/4). Instructor and admin machines are never metered. Unused allowance rolls forward for 90 days, capped at one month's allowance. Every plan has every feature; plans differ in capacity only. The full rate card and a class calculator are at labconsole.com/pricing.

Where it runs

LabConsole runs on hardware Guru Labs owns in its Salt Lake City, Utah datacenter, not on a third-party cloud. Uploaded images and lab contents are customer content, isolated per organization, and processed only to run that customer's classrooms.

Your first class is on us

Access is gated while we onboard training teams one at a time. Request access at labconsole.com/request-access. A Guru Labs instructor reads every request and replies within one business day. From there: a guided 14-day pilot with your own classroom, your own uploaded template, up to 10 learners, and no credit card. When it fits, your first real class runs free. We migrate your lab VMs, you run that class on LabConsole in parallel with your current setup, and then you compare.