Hyper-V is quite fast, in the tests I did, it was way faster than using Proxmox e.g.. A windows machine running Hyper-V will also consume less power, compared to a Proxmox based Linux setup.
I have a dozen little Futro S720 and S920 machines here, which run at 3-4W with Windows Server 2022 Datacenter Edition (as host) and another Windows Server as VM (guest) and an open RDP-Connection in idle mode, this is fantastic! o)
Disk IO is basically at native performance in a Hyper-V guest, CPU is 5-10% less, network not tested yet, but I guess it's fine, no issues so far.
On Proxmox or bare metal Linux, Disk IO is 50% at best for a guest (even the host might be slower already compared to Windows), and CPU is 20-25% less than native and network only reaches 50% of full network speed of the bare metal Windows performance (and uses 100% CPU load at the same time), while a Windows machine saturates the network easily at 100% with 30% CPU usage only.
I can even add AES encryption to the local drive and copy things with full network speed over to the little Futro computers when using Windows, on Linux it was overloaded already without the encryption going on.
Wrapping up, the Windows technology performes the best for me (on the hardware I tested).
It's worth testing it out! o) If you have dedicated hardware, there also is this free to use Windows 2019 Hyper-V Server from Microsoft, if you don't have access to other Windows (Server) versions.
Hyper-V on my Win10 also runs fine, even though I only run 16GB of memory and that RAM was already fully used before tinkering around with virtual machines. I have a 32GB swap file now, I constantly standby and resume and the host OS including all guests go to sleep and wake up just fine. It works awesome!
Drawback with Hyper-V is making use of audio and video of the guest or making use of specific hardware attached to the host (USB device e.g.). This is much easier in VMWare / Virtualbox, if possible at all for a VM hosted on Hyper-V (possible, but needs fighting with powershell commands, no option in the GUI to pass through any devices apart from disk / network).
The native guest console / video output has bad performance on Hyper-V and no audio, it's not meant to be used outside of setting up a VM / guest. You will have no shared clipboard in this console either, if you don't make use of that "enhanced connection experience" thing, which uses RDP under the hood to provide better performance and usability, but this is not available if you install plain Debian for yourself (and you actually don't need it if you are using a regular RDP connection later on, which ends up being the same experience).
If you are connecting via RDP to a guest Windows, you are fine for office / adminstration work and light gaming. You will have audio, clipboard and video being streamed with good performance.
If you connect via RDP to a Linux guest, audio is there in specific distributions only (most distros lack PulseAudio modules for xRDP, you can compile these for Debian on your own though, if you want to go through that hell.. o). Only very latest Fedora and Ubuntu have audio enabled RDP support. Video / streaming the RDP connection from the Linux guest is not performing well in general, it is totally usable and I do coding on a Linux VM via RDP and things, but the efficiency is not there, the video streams take 20 mb/s bandwith on your LAN for full screen video playback and around 2-5 mb/s if you are doing regular things on the desktop. This is nothing for connecting to over the internet in most cases (unless you reduce resolution and color depth), since the Linux xRDP does not do any video or audio encoding, it just streams raw video and audio, kind of.
The actual RDP implementation when used with Windows host and guests is very more effective, using host side rendering and only using 2-5% the bandwidth compared to connecting to a Linux machine via RDP, but at least it is working with Linux, very compatible with all RDP-Clients I tested, including audio, clipboard and local drive sharing and it's working very good in general (despite the bandwidth issue and audio crackling here and there, but I do not stream music over RDP that much.. o).
Hyper-V is a nice hypervisor, it only fits specific use cases though and you won't run older machines and operating systems in there I guess, that's not what it was invented for, that's where VMWare and VirtualBox, QEMU etc. come in. VMWare supports GPU hardware acceleration to some extend, VMWare allows 2GB GPU memory, VirtualBox is somewhere around 128MB and not accelerated iirc, but connecting devices or building a Pentium based DOS machine is way easier.
If you need to run / emulate old PC hardware, there is PCEmu as well, it is meant to emulate old PC hardware and will emulate soundblaster and all the things we had back then.
Wrapping up again:
It's important to know what you want to do with the VM and pick the right hypervisor for it. Looking up benchmarks and performance comparison between Hyper-V, ESXi, VMWare, VirtualBox, Proxmox etc. gives very mixed results. It always depends and the right configuration is crucial to keep performance up (which means installing guest side driver packages e.g., or picking the right network translation layer, file system for your guest disks, disk driver etc..). It's a quite complex topic, but Hyper-V in general is not a bad choice for modern OS and running anything headless. If you run Linux guests in Hyper-V, make sure the distribution makes use of the various Hyper-V aware system daemons (providing heartbeat, memory balooning, etc..). Some distributions come with these by default, at least the kernel or something detects the environment and runs the Hyper-V modules automatically). If they are not present, you can add them by using the "backports" repo on Debian e.g.. Detailed information on that is to be found on the internet.
The Microsoft / Hyper-V preferred *.vhdx disk image format is also quite capable, providing dynamic sizing and mounting options and even on Linux I am able to dynamically mount a *.vhdx file from a Windows network share and have a virtual disk for generic use directly in Linux, which is not passed through to the actual guest VM by the Hyper-V host (I'm using "qemu-utils" and "nbd-client" for this.)
