3 Days, 18 Hours: What I Learned at NDG's Proxmox Workshop

When Broadcom wrecked VMware’s educational licensing, a lot of schools suddenly had the same question: now what?

NDG’s Proxmox VE 8 workshop was one of the first places I saw a clean answer.

This was an 18-hour, three-day workshop focused on deploying Proxmox for NETLAB+ environments. Not generic virtualization theory. Not vendor fluff. Real decisions about storage, networking, clustering, backups, pod deployment, and the little gotchas that can waste a week if you learn them the hard way.

I signed up because I knew we were heading toward Proxmox anyway. By the time it ended, I had a much clearer picture of what a sane academic deployment should look like.

What the Workshop Covered

The workshop walked through the full lifecycle of a NETLAB+ Proxmox deployment.

Day one was infrastructure planning:

• hardware requirements
• storage design
• RAID vs HBA decisions
• ZFS caveats
• network topology
• management server vs user server roles

Day two moved into platform operations:

• clustering and quorum
• HA configuration
• Proxmox Backup Server integration
• VM deployment strategy
• SPICE remote access
• Windows 11 and VirtIO requirements

Day three focused on the NETLAB+ side:

• NDG post-install scripts
• fresh install vs migration paths
• VM distribution and catalog workflow
• linked clones
• golden image handling
• Python SDK automation

That structure worked. It started with the physical and architectural reality first, then moved upward into the application layer where NETLAB+ actually lives.

The Big Stuff I Took Away

A few workshop points stuck because they were immediately useful.

Storage design matters more than people think

NDG’s guidance was blunt. If you’re building user servers for student pods, plan around large NVMe capacity. Their recommendation was 15 TB NVMe on user servers because linked clones cannot span storage pools in Proxmox. Masters and clones need to live together.

That sounds like a small implementation detail until you realize it drives the whole storage budget.

They were also pretty clear about RAID controllers becoming bottlenecks and why HBA mode makes more sense for this kind of deployment. ZFS was discussed too, but not as a magic answer. NDG does not officially support it for these environments because they have seen too many institutions get buried under complexity they did not actually need.

That was refreshing. Sometimes the right answer is not the coolest answer.

Network separation is not optional

The workshop reinforced something I already suspected but needed to hear from people who deploy this at scale: separate management, cluster, and storage traffic whenever possible.

The cluster network handles migration and replication. That is not where you want bandwidth fights. NDG recommended 10G for the cluster side, which lined up perfectly with what I later built.

This was one of the most useful parts of the training because it tied the logical design directly to performance and stability instead of treating networking like a footnote.

Windows 11 on Proxmox has sharp edges

One of the easiest ways to waste time is to assume Windows 11 will just behave.

NDG called out two specifics:

• CPU type needs to be set to Host
• VirtIO drivers need to be preinstalled or injected through WinRE before first boot

Miss either one and you are fixing it the annoying way.

That kind of detail is exactly why workshops like this matter. It saves you from learning the same dumb lesson alone at 2am.

SPICE actually matters in a lab environment

SPICE sounds like a small checkbox until you remember students need copy and paste, decent remote display behavior, and something better than a miserable console experience.

NDG wanted SPICE across the board for VM access. Better clipboard support, better multi-monitor handling, better experience than VNC. In a classroom or remote lab setting, that is not cosmetic. It changes how usable the platform feels.

Backups need their own plan

The workshop also covered PBS in practical terms instead of just saying “do backups.” The advice was straightforward:

• run Proxmox Backup Server on separate hardware
• stop VMs before backup when consistency matters
• use vzdump for snapshot backups where appropriate

There was also a strong operational theme around keeping infrastructure boring. Out-of-band management, BIOS auto power-on after failure, and UPS-aware shutdown tooling are not glamorous, but they are the difference between a recoverable problem and a stupid outage.

The Three Deployment Paths NDG Laid Out

One part I liked was how clearly they framed migration choices.

1. Fresh install

Blow away the old VMware environment, install Proxmox clean, and pull everything fresh from NDG’s distribution system.

This is the cleanest path if you can tolerate the downtime and if your current environment is not worth preserving.

2. VMware migration

Keep the physical pod side intact. PDUs, routers, switches, existing layout. Migrate the NETLAB+ database and settings while swapping the hypervisor layer underneath.

This is more complex, but it preserves more of the work already invested in the environment.

3. Hybrid

Run VMware and Proxmox side by side during the transition.

NDG did not love this option, and I get why. Hybrid buys flexibility at the cost of complexity, and complexity is usually where infrastructure starts lying to you.

The Small Tips That Were Weirdly Valuable

Some of the best advice was the least glamorous.

Install tmux first

Seriously. Before the long-running work starts.

If your SSH session dies during a cluster operation or an install script, tmux keeps the session alive and saves you from starting over or guessing what half-finished successfully.

That one tip paid for itself.

Use NETLAB’s cloning workflow, not Proxmox’s default cloning

NDG was explicit here. Do not use Proxmox’s normal cloning path for NETLAB pods. Use NETLAB’s own pod management and linked clone system so VM IDs, pod relationships, and platform expectations stay intact.

This is exactly the kind of thing that seems harmless until you break something subtle and spend hours untangling it.

Naming and consistency matter

They recommended consistent storage naming like NETLAB1, NETLAB2, and so on, with preallocation disabled on NETLAB storage. That is simple, but it keeps a cluster readable when more than one person has to work on it.

They also pushed proper DNS and FQDN planning up front, especially if you want Let’s Encrypt certificates. Another boring decision that becomes painful if you get cute with it.

Why This Workshop Actually Mattered

Plenty of training gives you trivia. This one gave me patterns I used almost immediately.

Within weeks, I was applying the workshop directly while deploying a 6-node Proxmox cluster at a Florida state college:

• dedicated 10G cluster networking
• NETLAB storage naming conventions
• disabled preallocation on NETLAB storage
• LACP on gigabit interfaces
• PBS on separate hardware

That was the real value.

The workshop did not only explain Proxmox features. It gave me a practical model for how institutions are actually building these environments after VMware stopped making sense for education.

Final Take

The certificate was nice. The real value was confidence.

Not fake confidence. Not “I watched the demo and now I’m an architect” confidence. The useful kind. The kind you get when someone who has seen hundreds of deployments tells you what breaks, what scales, and what decisions are worth making early.

If you’re responsible for academic lab infrastructure and trying to figure out how to move from VMware to Proxmox without making a mess, this workshop was worth the time.

It gave me a cleaner mental model, better defaults, and a shorter list of mistakes I had to make myself.

View full workshop details and certificate →