Hyper-V PowerShell Generator

Tick a few boxes, get a Hyper-V PowerShell script you can paste and run. Create VMs, wire up virtual switches, handle checkpoints.

This Hyper-V PowerShell generator turns a few checkboxes into a script you can paste straight into a console and run. Pick a VM mode and it stitches the whole chain together, New-VM for the shell, Set-VM for CPU and Dynamic Memory, Set-VMFirmware for Secure Boot and boot order, Add-VMDvdDrive for an install ISO, and Start-VM to light it up. Switch to virtual switches mode for External, Internal and Private one-liners, or checkpoints mode to snapshot and roll back. Every line carries a note on what it does, and presets cover a Kali lab, a Windows target, a nested host and a Linux server. It all runs in your browser, so nothing you type leaves the page.

100% in your browser. Nothing you type ever leaves this page.

Hyper-V PowerShell generator

Nobody memorizes every flag on New-VM. I gave up pretending I do. So this thing exists. Tick a few boxes and you get a Hyper-V script you can paste straight in, spin up a VM, wire up virtual switches, fiddle with checkpoints, and every line carries a little note on what it's for. Honestly, I reach for it most when I'm throwing together a CTF lab and can't be bothered to type it all. It runs in your browser. Nothing you type leaves the page.

What this Hyper-V PowerShell generator does

Clicking through Hyper-V Manager is fine for one machine you'll never touch again. Fine, sure. But the moment I want a lab I can tear down and rebuild on a whim, I'm back in PowerShell. And here's the part nobody mentions: a real VM build is never one command. You've got New-VM for the shell. Then Set-VM and Set-VMProcessor for CPU and memory, Set-VMFirmware for Secure Boot and boot order, maybe Add-VMDvdDrive if there's an ISO, and finally Start-VM to light it up. This tool stitches that whole mess together from whatever you tick, hands you a script that runs end to end, and tells you what every line is doing.

The other two things I end up scripting on repeat are here as well. The switch types (External, Internal, Private) that decide how boxed-in each VM is. And checkpoints, so there's always a clean spot to roll back to when an experiment goes sideways.

Why script Hyper-V instead of clicking

  • Reproducibility. I nuke VMs constantly. The script rebuilds the same one in seconds, and I never sit there wondering what I picked last time.
  • Speed. Five VMs? That's a loop. The same thing in the wizard is twenty minutes I'm not getting back.
  • Documentation. The script is the record of how that VM got built. Drop it in git beside the rest of your infra and future-you will be grateful.
  • Consistency. Same Secure Boot and memory and switch on every box, every time. Kills the "but it works on that one VM" headache before it even starts.

The cmdlets behind a VM build

CmdletRole
New-VMThe starting point: sets the generation and startup memory, points at a fresh or existing VHDX, and hooks up a switch.
Set-VMOnce the VM exists, this is where I set the vCPU count and the Dynamic Memory floor and ceiling.
Set-VMFirmwareGen 2 only. Flips Secure Boot on or off and decides what the VM boots from first.
Set-VMProcessorExposes the virtualization extensions so you can run a hypervisor inside the VM (nested).
Add-VMDvdDriveBolts an install ISO onto the VM so it has something to boot the installer from.
Start-VM / Checkpoint-VMOne powers the box on; the other snaps a named checkpoint you can jump back to later.

Virtual switches and isolation

The switch type decides how far a VM can reach. That's the whole game. An External switch bridges a physical NIC, so your VMs get a real network and a path out to the Internet. An Internal switch lets the host and the VMs chat among themselves and nothing past your box. A Private switch is stricter still: VMs talk only to each other, no host, no Internet, nowhere to phone home. That last one is where I dump anything I don't trust. Malware samples, a target I'm poking at, that sort of thing. The switch mode here writes all three and you delete the lines you don't want.

Privacy and how this tool runs

The script-building runs in JavaScript, right in your browser. Your VM names and paths and settings? None of it gets sent anywhere or logged. Once the page is loaded you can yank your network cable and it keeps working.

Sources and further reading

Frequently asked questions

How do I create a Hyper-V VM in PowerShell?

Start with New-VM -Name "lab" -Generation 2 -MemoryStartupBytes 4GB -NewVHDPath "D:\VMs\lab.vhdx" -NewVHDSizeBytes 60GB -SwitchName "Internal". That is the shell. Then hand it cores with Set-VM -Name "lab" -ProcessorCount 2, sort the firmware out with Set-VMFirmware, and Start-VM to boot. Do not fancy typing all that? The generator above writes the full chain.

How do I disable Secure Boot for a Linux VM?

Most Linux ISOs choke on Secure Boot. So on a Gen 2 VM I just kill it: Set-VMFirmware -VMName "lab" -EnableSecureBoot Off. Want to keep it on? Point it at the Linux template with -SecureBootTemplate MicrosoftUEFICertificateAuthority and most modern distros stop complaining. Gen 1 VMs have no Secure Boot in the first place, so nothing to toggle there.

How do I enable nested virtualization?

Shut the VM down first. This will not take on a running machine, learned that the annoying way. Then run Set-VMProcessor -VMName "lab" -ExposeVirtualizationExtensions $true and switch off Dynamic Memory for it. Now you can run Hyper-V, WSL2 or Docker inside the VM. It is how I spin up a throwaway hypervisor and never touch the host.

What is the difference between a standard and a production checkpoint?

Not the same thing, and the gap bites people. A production checkpoint leans on the guest VSS for an application-consistent snapshot, basically a proper backup, so databases and the like stay clean. A standard checkpoint grabs the whole machine state, memory included, so you land back exactly where you were. Great for a lab, not what you want for live data. Pick one with Set-VM -CheckpointType.