Keep Windows Lab Compute Separate From The Current VPS
Context
The current VPS hosts public services and does not expose nested virtualization. The Microsoft Enterprise Lab needs Windows VMs, snapshots and private networking.
Decision
Do not use the current VPS as the Windows VM host. Choose external lab compute, a local lab host, an Azure-first slice or a mixed approach after architecture review.
Alternatives Considered
Install Proxmox or KVM/libvirt on the current VPS
Pros
- Uses the existing server.
- Keeps everything in one place.
Cons
- Nested KVM is unavailable.
- Host resources are too small.
- Existing services would carry lab risk.
Use software-emulated Windows VMs
Pros
- Might avoid new compute.
Cons
- Poor performance.
- Fragile operational behavior.
- Weak evidence for real administration workflows.
Separate compute
Pros
- Isolates experiments from production services.
- Supports private networking, snapshots and rebuilds.
Cons
- Requires a compute decision and extra cost or hardware.
Reasoning
The lab is expected to be broken intentionally during scenarios. That risk belongs on separate lab compute, not on the VPS that serves current products, SSH and public portfolio routes.
The current VPS can host documentation, source control, static portfolio output and lightweight control material. It should not host the Windows VM workload for Lab V1.