When you create a new virtual machine in Hyper-V, the wizard stops you on the second screen and asks a question that trips up a lot of people: Generation 1 or Generation 2? There’s a short blurb, an OK button, and no obvious “recommended” choice.
It matters more than it looks, for one reason above all others. You pick the generation once, and you’re stuck with it. Hyper-V has no built-in button to convert a VM from one generation to the other after you create it. Choose wrong and your only real fix is to build a new VM and move the workload over.
So it’s worth understanding what actually changes between the two before you click. The difference comes down to the firmware the VM boots with — old-style BIOS versus UEFI — and everything that follows from that.
The core difference: BIOS vs UEFI
A Generation 1 VM emulates a traditional PC from the BIOS era. It boots with legacy BIOS firmware, uses an MBR partitioned boot disk, and presents a set of emulated hardware that’s been around since the early 2000s — an IDE controller, a legacy network card, a COM port, the works. It’s the same virtual hardware Hyper-V has offered since the beginning, and it runs basically any x86 operating system you throw at it.
A Generation 2 VM boots with UEFI firmware instead. That single change pulls in a chain of modern features: a GPT boot disk, Secure Boot, SCSI-based booting, and the removal of the old emulated legacy devices. It’s a cleaner, more modern virtual machine — but it only runs 64-bit operating systems that understand UEFI.
Generation 1 vs Generation 2 at a glance
| Firmware | Gen 1: Legacy BIOS — Gen 2: UEFI |
|---|---|
| Boot disk partition style | Gen 1: MBR — Gen 2: GPT |
| Boot disk controller | Gen 1: IDE — Gen 2: SCSI |
| Secure Boot | Gen 1: Not available — Gen 2: Supported (on by default for Windows) |
| Guest architecture | Gen 1: 32-bit and 64-bit — Gen 2: 64-bit only |
| Boot disk size limit | Gen 1: ~2 TB (MBR) — Gen 2: larger, GPT boot |
| Legacy/emulated devices | Gen 1: Present (IDE, legacy NIC, COM) — Gen 2: Removed |
| PXE network boot | Gen 1: Legacy NIC — Gen 2: Standard (synthetic) NIC |
Secure Boot, and why Generation 2 has it
Secure Boot is the headline feature for Generation 2. It checks the digital signature of the bootloader and kernel before they run, which blocks a class of boot-level rootkits from loading on a compromised VM. Generation 1 has no equivalent — its BIOS firmware will boot whatever’s on the disk.
For Windows guests, Secure Boot is enabled automatically and you can leave it alone. The gotcha shows up with Linux. Many distributions boot fine only if you switch the Secure Boot template, and some need it off entirely.
You can change the Secure Boot template per VM in PowerShell, which is handy when you’re scripting Linux builds:
# Allow a Linux guest to boot under Secure Boot
Set-VMFirmware -VMName "Ubuntu-Web01" -SecureBootTemplate "MicrosoftUEFICertificateAuthority"
# Or turn Secure Boot off for that VM
Set-VMFirmware -VMName "Legacy-Linux" -EnableSecureBoot OffThe boot disk controller: IDE vs SCSI
This is the difference that bites people who don’t read the fine print. On a Generation 1 VM, the operating system disk must hang off the emulated IDE controller — you can attach SCSI disks too, but Windows won’t boot from them, because the IDE controller is what the BIOS knows how to start from. SCSI on Gen 1 is for data disks only.
Generation 2 drops IDE entirely. Every disk, including the boot disk, lives on the SCSI controller. That brings a couple of practical wins: you can add and remove virtual disks while the VM is running (hot-add), and you’re not capped by the old IDE limits on disk count and size.
Which guest operating systems support Generation 2
Generation 2 is 64-bit only, and the OS has to understand UEFI boot. That rules out a fair number of older systems. Here’s the practical breakdown.
Supported on Generation 2:
- Windows Server 2012 and 2012 R2, 2016, 2019, 2022, and 2025 (64-bit)
- Windows 8/8.1 and Windows 10/11 (64-bit editions)
- Recent 64-bit Linux distributions with UEFI support — current Ubuntu, RHEL/CentOS, Debian, SUSE, and similar
Generation 1 only:
- Any 32-bit operating system, Windows or Linux
- Windows Server 2008 / 2008 R2 and older
- Windows 7 and earlier
- Older or specialized OSes with no UEFI boot support
You must use Generation 1 if any of these are true
- The guest OS is 32-bit
- You're running Windows Server 2008 R2 or older
- The OS or boot media has no UEFI support
- You depend on the legacy emulated network adapter (e.g. a specific PXE setup)
- You need a virtual floppy or COM-port device the VM relies on
When you genuinely need Generation 1
Generation 2 is the better default, but Generation 1 isn’t dead weight. Reach for it when:
- You’re running a 32-bit OS. This is the big one. Gen 2 simply won’t boot a 32-bit guest.
- The OS predates UEFI. Server 2008 R2, Windows 7, old appliances — they expect BIOS, and Gen 2 doesn’t provide it.
- You’re importing or migrating an existing BIOS/MBR VM. A physical or virtual machine built on MBR boots cleanly as Gen 1. Forcing it onto Gen 2 means converting the disk to GPT and rebuilding the boot config — more work than just running it as Gen 1.
- You need legacy hardware the guest expects — a virtual floppy drive, a COM port, or the old emulated network adapter for a particular PXE workflow.
If none of those apply, there’s no real reason to pick Generation 1 on a new build.
You can’t change generation after creation
Worth repeating because it catches people out: Hyper-V locks the generation at creation time.
There is no Settings page, checkbox, or right-click menu that flips a Gen 1 VM to Gen 2 or
back. The Hyper-V Manager wizard and New-VM both take the generation as a one-time choice.
# Generation is set here and only here
New-VM -Name "Web01" -Generation 2 -MemoryStartupBytes 4GB -NewVHDPath "D:\VMs\Web01.vhdx" -NewVHDSizeBytes 80GBIf you later decide you want the other generation, your options are:
- Build a fresh VM of the right generation and reinstall or migrate the workload onto it.
- Use a community conversion script (the well-known one is
Convert-VMGeneration) that rebuilds the disk as GPT and recreates the boot configuration. These work, but they’re third-party, so test on a copy first and have a backup.
Neither is as simple as a setting, which is exactly why the choice matters at creation. If you’re still mapping out your virtual network alongside the VM, it helps to have your external virtual switch set up first so the new VM gets connectivity from the start — and if a freshly built VM can’t reach the network, the Hyper-V VM no internet fix covers the usual causes.
The recommendation
For almost every new VM, choose Generation 2. If the guest is a 64-bit Windows Server 2012 R2 or later, a 64-bit Windows 10/11, or a current 64-bit Linux distribution, Gen 2 gives you Secure Boot, UEFI, GPT boot disks, SCSI hot-add, and faster startup with no real downside.
Drop to Generation 1 only when you have a concrete reason: a 32-bit guest, a pre-UEFI operating system, an existing BIOS/MBR machine you’re migrating as-is, or a dependency on legacy emulated hardware. Outside those cases, Gen 1 just leaves modern features on the table.
And because the generation is permanent, decide before you click Create. It’s a thirty-second question that saves you a rebuild later. If you’re standing up new VMs regularly, it’s worth browsing the rest of the virtualization guides so the next round of choices — networking, storage, performance — go smoother too.
