Dual-boot inside Native Boot disk

I have a Hyper-V setup for testing software and development ISOs. For now this works fine, but I find myself needing to run tests on bare metal. I know I can setup my Windows 11 system in a multi-boot setup, but I really want to experiment with Native Boot.

Here's the setup I want to build:
1) Create a dual-boot system in Hyper-V (obviously Windows will be one of the OS's installed)
2) Use that vhdx disk to run with Native Boot

Is this setup even possible? If so, I'd love to here your experiences.

Here is a good tutorial on the topic of native booting. Note that you don't need Hyper-V (or any hypervisor) for this.

As you had noted, this is great way of testing when you want access to the actual system hardware. It's also easy to remove that second OS. You can literally do so in mere seconds.

Hi folks
Theres loads of topics on the forum on this -- you don't even have to use vhdx files for the windows installs either

For your main bootable disk (I'll assume it's Windows with the HYPER-V function enabled) the Disk Geometry should basically look like this:

Host machine EFI partition,MSR,HYPER-V HOST OS- recovery-datapartition for your VM's

The data partition for the VM's i.e the GUEST bootable disk should be ONE efi partition then data 1, data2, data3 etc for the vm's. If using vhdx files for the VM's then one data partition only is needed.

Now simply install your Windows to data1, data2, data3 etc via standard install file (the.exe from the install media) or if using vhdx files use boot the installmedia WITHIN THE GUEST, choose repair windows -->command prompt. Now go into disk part, attach the vhdx file as a disk create a std ntfs partition on it and assign it a letter and then install windows to it using dism /Apply-Image.

If you want to install LINUX as a guest then you will just have to have a non vhdx data area. (Note this is the data area INSIDE the guest as Hyper-V from the HOST will create a "big" vhdx file for the VM's.)

There might be other ways such as Macrium VIboot but I think you have to create the VM's first in any case.

Note also that the above suggestion means that you will get a choice of Windows systems to boot WITHIN the VM which means you can't run them concurrently. If you want to have multiple concurrent VM's then create each one individually and you'll have to choose from the Hyper-V menu what to boot.

It depends on what you want to do with the VM's whether you want to run them concurrently or singly. There's no problem in multiple Windows installs whether you use vhdx files or not.


Incidentally to get round updates on unsupported hardware not working - you can always attach a Real Windows disk as a physical disk to a VM -- change the offending /lacking hardware e.g use TPM emulation if you don't have one, or change the CPU's topography to one supported by W11,boot the disk and and do your updates.

I prefer that method than fiddling around with dll's etc - but in all these things YMMV. This method certainly works using KVM/QEMU as a host --I'm not sure if it's possible to mess around with the Virtual CPU parameters in HYPER-V but there must be some setting somewhere since HYPER-V makes more use of paravirtualisation than KVM/QEMU in typical cases.

Cheers
jimbo

Wow - that's a lot of information to process. But thanks a bunch for going to all this effort. I guess I really need to decide what the pros/cons are of Active Boot vs. traditional multi-boot before proceeding.

I've got a ton of reading to do.

Native boot vhdx files enable you to manage spare space more easily without having to change partition sizes.
Removing is easy - delete vhdx file, delete boot entry using msconfig.

With a vhdx, you can run it on host or in a virtual machine if configured correctly (vhdx normally needs separate boot files to boot on a vm).

There is a slight performanced penalty using native vhdx booting but the pros outweigh the cons.

Many here use native boot vhdx files for Insider versions.

Backing up vhdx files is simple - just copy it using File Explorer - no need for image backups (unless if space is at a premium).