Official DietPi Hyper-V images

As part of switching to a new build process and having this done fully automated, I also had another look into Hyper-V and was able to create an image for it. But I faced quite some hurdles, so as you have more experience with Hyper-V, some questions:

How did you convert the VMDK to VHDX? First I tried VBoxManage, but for some reason it fails to convert either a raw image or a VMDK into VHD (I wanted to use the MS conversion tool for the second step to VHDX), with some "invalid argument" error, not sure whether this is a bug in VBoxManage, as docs and help print shows it being supported just as VMDK and VDI (which both work). There is this MS VM converter tool, but it is designed to convert remote VMs, not really to convert local image files, at least I wasn't able to achieve that without being forced to enter remote hostnames/IPs, having remote share instead of a local directory as target etc. Finally V2V Image Converter worked well. I guess on a Linux system qemu-img is the way to go to convert a raw img into VMDK, VDI and VHDX all together.
Do I get it right that Hyper-V Generation 2 VMs strictly require booting from an EFI partition (even with Secure Boot and other UEFI features disabled), so that an MBR single partition image can only be used with a Generation 1 VM? What I am puzzled with is that it shows the drives as IDE then, still internally loads SCSI drivers, while only Gen 2 VMs show an actual SCSI controller, but do not boot any of our images (on my tests). Since I don't even see GRUB being loaded, it must be looking for an GPT/EFI partition. Would be just nice if it was possible to use Gen 2 but still boot from MBR.
Do you think there is a point in packing a whole Hyper-V VM export available as download, instead of only the VHDX? At least it assures that users do not try to boot it with a Gen 2 VM. But I'm not sure how well this is compatible with older Windows versions, when I create the export on a current Hyper-V. Sadly the exported VM configuration is binary, so no chance to review and in case adjust things like local network adapter info or so.

Here the image to review/test: https://dietpi.com/downloads/images/DietPi_Hyper-V-x86_64-Bullseye.7z

How did you convert the VMDK to VHDX?

StarWind V2V in the early days; however, the caveat was manually having to update the bootloader to recognise the new partition UUID. You mentioned it worked fine for you, so perhaps that's no longer an issue. This was for the very early versions; every VHDX afterwards was created from scratch.

Regarding Generation 1 and Generation 2, my experience was similar, and have come to conclude that G1 is purely for Legacy BIOS/MBR, and G2 is purely for UEFI/GPT.

G2 doesn't seem to have MBR compatibility, like you've said. It's why I created the VHDX with G1 usage in mind. Plus, in the context of using DietPi on a Hyper-V VM, I can't imagine any practical benefits from using UEFI. Seems a little overkill, though it could just be me being a wee bit overcautious.

I released plain VHDX purely for simplicity. When a new VHDX gets released, users can replace the old one without having to play around with their VM settings. It also takes care of the potential issues you've mentioned, including compatibility, ambiguity and even complexity.

There is indeed a risk of users creating a Generation 2 VM, though the problem becomes apparent immediately and the solution is straightforward. Ideally, they'd only be dealing with this once. If they recreate the VM configuration each time they use a new VHDX, then I can only hope that using Generation 1 will become muscle memory for 'em.

Though I understand the benefits of automated upstream releases, I'm more than happy to continue releasing images each time a major DietPi version comes out. It gets me in the groove for playing around with Debian and Hyper-V as well.

StarWind V2V in the early days

Okay, good to know that I didn't ended up using some crap 😄. Creating the image from scratch is of course always the safest and cleanest solution, but for sake of reducing overhead, I go now that way:

Create a single VM raw image via: https://github.com/MichaIng/DietPi/blob/dev/.meta/dietpi-build
- Downside, since everything runs in a container, tiny-initramfs cannot detect or know the kernel modules required to mount the root filesystem at boot. So I needed to test which virtualizer uses which controller and hence which kernel module and have now this set: ahci,sd_mod,vmw_pvscsi,hv_storvsc,ext4
- It's 100 - 200 KiB larger initramfs when supporting VirtualBox, VMware and Hyper-V all together, but compared to 30 MiB generic initramfs-tools, it's still "tiny" 😉.
Converting this raw image into VDI (for VirtualBox), VMDK (for VMware) and VHDX (for Hyper-V) via VBoxManager for the first two and StartWind V2V for the last. Testing it with qemu-img is the next step, to be able to integrate it into the above script. For VirtualBox its also easy to create the complete appliance within the script, for VMware I haven't tested it yet and for Hyper-V... this is the reason why I was asking 😄.

G1 is purely for Legacy BIOS/MBR, and G2 is purely for UEFI/GPT

Thanks for verifying. Generally I also think that UEFI is overkill on a VM. But at least Debian ships GRUB with Secure Boot support now, so it would be definitely possible. Mid-term we might ship VM images for MBR and for UEFI and on the Hyper-V download/docs name them Generation 1 and Generation 2 images. For now it should be sufficient to add a fat message to the downloads page, stating that a Generation 1 VM needs to be created for it to work.

Hyper-V has this quick start VM creation tool, but I couldn't find a way to create a Generation 1 VM with this, despite unchecking the checkbox that it's a Windows system with Secure Boot on the image. So the Hyper-V-Manager needs to be used. And I just recognise that our docs's install instructions have all these information already, awesome guys 👍: https://dietpi.com/docs/install/

When a new VHDX gets released, users can replace the old one

But then they would start with a fresh DietPi, which shouldn't be required thanks to dietpi-update? However, yes generally this is then possible to reset the system. And unless the Hyper-V export formats and settings are better understood (which is difficult due to non-standard and binary config format), it is better to keep it simple and compatible, and our docs cover the VM creation nicely.

Though I understand the benefits of automated upstream releases, I'm more than happy to continue releasing images each time a major DietPi version comes out. It gets me in the groove for playing around with Debian and Hyper-V as well.

And I'm very thankful for having you doing this until now ❤️ 👍 ! When we're able to update images via CI/CD pipeline it's however indeed much beneficial to offload that effort to the bots, assuring consistency and transparency in the same turn, and use our precious time for other things. E.g. I'd be very happy if you find time to give those new Hyper-V images a quick try by times, whether they boot and setup fine, and whether dmesg -l emerg,alert,crit,err is silent => no kernel errors, and also in case keep our docs updated if something changes in Hyper-V (I use VirtualBox regularly but may miss Hyper-V or VMware changes). Not sure whether we can run a Hyper-V on the GitHub action's VMs, including writing some flags to a host <> guest shared directory to automate even such boot and setup tests, but it's definitely not achievable short term 😄.

EDIT: I just added you to the team list on our README, to keep the credits despite we're switching to auto-generated Hyper-V images. Without your ongoing work since 2018, Hyper-V still wouldn't be a topic and we hence would have excluded quite a number of users.

The initramfs thingy is delightfully clever. As far as scripting it goes, I couldn't figure out a sensible way to automate Hyper-V without risking something going wrong. What I did is reduce steps by reusing stuff, i.e. I have a "generic" Debian VHDX which I copy and install DietPi to whenever a major version is released. The manual part is loading up the VM and installing DietPi on top of it.

But then they would start with a fresh DietPi, which shouldn't be required thanks to dietpi-update?

Yup, that's why I encourage people to use dietpi-update. Replacing the VHDX should be done for resets; however, the same would happen if we distribute Hyper-V configurations.

I'd be very happy if you find time to give those new Hyper-V images a quick try by times

Will give them a shot! I've moved back to Linux a while ago, but I still have Windows 10 w/ Hyper-V installed, so I'll boot into it once in a while to test out the images.

I just added you to the team list on our README [...] Hyper-V still wouldn't be a topic and we hence would have excluded quite a number of users.

Cheers! Always been a pleasure contributing to DietPi, both in readme/update patches, and of course, the VHDX images.

I've always assumed Hyper-V is pretty niche, but it seems like the latest VHDX has 1,000+ downloads already, which was quite a pleasant surprise.

Replacing the VHDX should be done for resets; however, the same would happen if we distribute Hyper-V configurations.

The configuration would only make the initial setup easier as you import the basic setup already, including Generation 1 and some reasonable defaults. It shouldn't ever be required to download the image again or hassle with this, aside of when you explicitly want to reset the whole server or migrate to a new underlying Debian version, Bookworm then. And when you do, again, the configuration saves you some steps, in theory. The only question is whether a configuration on a certain Windows and Hyper-V version does indeed work well and as expected on a sufficient variety of OS and Hyper-V versions, or if there are incompatibilities. If so, then the config may after all cause more trouble than that it helps, so that its purpose is broken and the effort for us producing it nonsense. So unless there is sufficient evidence that those configs work well in 99% if cases, we better skip it.

I've always assumed Hyper-V is pretty niche, but it seems like the latest VHDX has 1,000+ downloads already, which was quite a pleasant surprise.

It's the 3rd most used outlink to GitHub from our website:

CLICKED OUTLINK	UNIQUE CLICKS	CLICKS
`github.com`	32.6% 3,303	32.7% 3,606
`/MichaIng/DietPi/issues/4641`	4.1% 415	4.7% 515
`/MichaIng/DietPi`	2.4% 246	2.3% 255
`/yumiris/DietPi.Hyper-V/blob/master/README.md`	1.4% 143	1.4% 157

This is the last 30 days, by visitors who do not block our Matomo tracker: First line overall outlinks/click to GitHub, including all the cross references of issues and troubleshooting between forum and GitHub issues. Second the v7.5 beta release notes, which was on the first banner on the website for 7 days and an announcement in the forum. Third line is our GitHub repo front page, which is linked throughout the while website, on all docs pages, on all blog pages etc. You links is/was only shown when someone actively clicks on Hyper-V in the download section, just to put this into context 😉.

Unique vs non-unique is btw when the same visitor uses the link multiple times.

MirisWisdom / DietPi.Hyper-V

Official DietPi Hyper-V images #8