miriswisdom / dietpi.hyper-v

VHDX images for DietPi, fully compatible with Microsoft Hyper-V.

Howdy, I'm Emilian Roman / Miris Wisdom

Software Engineer & Architect and System/Infrastructure Operator

... with a generalist, holistic and pragmatic approach to everything!

• 🔭 I’m currently working on platforms that empower Academic Staff & Medical Students

• 🌱 I’m currently learning orchestration/IaC/SoA; utilising & integrating AI/LLM; art/illustration for the sanity and soul

• 👯 I’m looking to collaborate on project utilising AI and Kubernetes

• 🤝 I’m looking for help with nifty ideas that I could build

• 👨‍💻 All of my projects are available at github.com/miriswisdom

• 📝 I once in a blue moon write articles on blog.miris.design

• 💬 Ask me about I'm a jack of all trades, so anything and everything!

• 📫 How to reach me [email protected]

• ⚡ Fun fact I use infamously boring tools to make reasonably exciting solutions.

Connect with me:

Languages and Tools:

 

dietpi.hyper-v's Issues

Question: is disabling HyperV boot customizations possible?

Hi! After using your image for about a year I decided to migrate from HyperV to Proxmox.

So after setting up the VM in Proxmox and connected the existing disk to it, I can see Grub loading but then failing on loading two 'hv_.ko' files. Is this something that can be solved? Ie. Can I disable the loading of the .ko files?

Thanks for any help on this.

VHDX Capacity

This issue aims to discuss and decide on the maximum size of future VHDX images.

What capacity do you think the VHDX images should have and why? 80GB seems like a nice balance between stability, flexibility and nimbleness. However, it wouldn't be enough for a small media server. However, would people even store media in a VM? This is the kind of dilemma that inspired this post.

At the moment, the maximum capacity of the released images are 8GB, though posts such as MichaIng/DietPi#3559 hint at the capacity needing to be increased,.

---

When suggesting a capacity, please consider any technical caveats. Some (speculative) examples include:

• can DietPi handle a, say, 64TB VHDX?
• will there be any performance losses with increased disk capacity?
• will there be a hassle with administrating, backing up, cloning, etc.?

Ultimately, the decided capacity will need to be a balance between practicality and technicality.

The VHDX images are dynamic, which means that the capacity change won't affect their initial physical size. This means that the images can be set to have a maximum of size of entire terabytes without any impact on distribution and base system requirements. The releases will continue to remain nimble!

Upgrading existing installation

Thoughts or comments on how to update an existing install?

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

Issue Loading Kernel

I am testing this image out on Hyper-v but the image fails to boot. The error is below. Any ideas or is this image just not compatible on hyper v? I'm using the DietPi_Hyper-V-x86_64-Stretch - v6.25.3.vhdx by the way.

"Loading Linux 4.9.0-8-AMD64
error: Invalid magic number
Loading initial ramdisk
error: you need to load the kernel first. "

Update - Tested the Virtualbox image and it works great. So I can use that if the hyper v won't work. Would be preferable however.

Default region on new install is GB?

Heya. Thanks so much for maintaining these, DietPi works great on my Win10 system.

Is there anyway to setup the region/keyboard settings based on IP when first booting into DietPi fresh? I recently found out it defaults to GB (I live in US) and had issues thinking my KB was malfunctioning because some keys were writing different things. ;)

Update to Buster-based image

@yumiris
If you find time, would you mind to create a new image based on new stable Debian Buster?
Includes many benefits, native PHP7.3, a much newer Linux (even 5.2 possible via backports) and of course generally better long term support.

But probably its best to wait for v6.26 stable release 😉.