Interesting Comparisons Between ESXi and Hyper-V

One thing I often do with ESXi setup is use VMRC to connect to a VM (What a shocker I know), but it’s not just that, this tied with the VM having a USB controller allows me to passthrough any and all USB devices on my client machine, to the VM, event though my client machine is completely remote from the host hypervisor. This is a really neat trick and has allowed me to boot live Linux and other things without having to upload ISO’s to datastores.

So can Hyper-V do this? … No….

• USB passthrough
  • VMware ESXi/VMRC: true remote USB passthrough.
  • Hyper‑V: only host‑side USB storage passthrough; other devices need RDP redirection or 3rd‑party USB‑over‑IP tools.
• Passing a USB stick to a VM
  • Plug into host → mark disk Offline in Disk Management → attach as Physical hard disk in VM settings.
  • Works only for storage devices.

Another weird issue I had was when I opened up Hyper-V manager on the hyper-v server itself, and would attempt to add an ISO to a VM by clicking the browse button would give an error “Application failed to open the remote file browser”. If I typed the full ISO path in the UI field it would still work though as a work around.

• Hyper‑V Manager “Browse” buttons error
  • Even locally, Hyper‑V Manager uses RPC/WinRM “remote file browser” calls.
  • Breaks if NIC bindings (Client for Microsoft Networks, File/Printer Sharing, RPC) are stripped down.
  • Typing full path or using PowerShell bypasses it.

I asked it about how the local host connection worked if the hostname showed as the server in Hyper-V manager. I had some other hiccups which was more around auth mixups, but for local host browse issue it gave me the pointer below, but they really didn’t mean much of anything. If I do ever come up with the solution, I’ll update this blog.

• NIC bindings & hostname resolution
  • Hyper‑V Manager always talks to VMMS via RPC/DCOM.
  • Needs a management NIC with default bindings intact.

When I went to create a snapshot of a VM it told me it didn’t save its memory state. I wasn’t sure why on this, then you figure out there two different types of Checkpoints in Hyper-V. It was weird that you have to specify which type for each VM, but I guess it makes sense in certain contexts.

• Checkpoints vs VMware snapshots
  • Standard checkpoint = disk + memory (like VMware snapshot with memory).
  • Production checkpoint = crash‑consistent, no memory state.
  • Set via VM settings or Set-VM -CheckpointType.

Someone reason I can’t explain when running the command to install Hyper-V manager tool alone on a Windows 11 machine, it also installed the Hyper-V platform, allowing me to create VMs on the client machine. Not what I wanted, The below was provided as an answer by AI, but I haven’t personally tested it.. I call bull, I simply lived with it cause I had bigger fix to fry. I just won’t create any VMs.

• Installing Hyper‑V management tools
  • Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Management-Clients -All installs Manager.
  • On Pro/Enterprise, sometimes drags in the full platform too.
  • Use Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All if you want tools only.

Then of course, I was having issues connecting to my Hyper-V server via Hyper-V Manager remotely. The first error complained about WinRM.. Check the service, make sure it’s up and reachable by locally and remotely using:

Test-WSMan hyper-vHostname

Then it said I didn’t have permission, I was trying to connect to the Hyper-V server that was not domain joined via a domain-joined client machine, AI said to try n create a local account with the same creds as my domain account, I didn’t think it would work. but somehow. it did. mind blown…

• Remote management (WinRM/Kerberos/NTLM)
  • Domain client + non‑domain host → Kerberos fails.
  • Fix: enable WinRM on both sides, add host to TrustedHosts,

  • Set-Item WSMan:\localhost\Client\TrustedHosts -Value "hyper-v-host" -Force

  • Create matching local account.
  • Matching local account trick works because NTLM succeeds when creds line up.

• WinRM checks
  • Test-WSMan localhost → confirms service running.
  • Get-ChildItem WSMan:\localhost\Listener → shows listeners.
  • WinRM must run on both client and server.
• WinRM ports
  • Needs inbound TCP 5985 (HTTP) and 5986 (HTTPS) open.
• Enable‑PSRemoting -Force
  • Starts WinRM service.
  • Creates listeners.
  • Adds/activates firewall rules for WinRM.
• Firewall rules group
  • Found under “Windows Remote Management”. Rules may exist but be disabled.
• Fix

  Get-NetFirewallRule -DisplayGroup "Windows Remote Management" | Enable-NetFirewallRule

I noticed I could only have one session on a VM console, unlike VMRC that allows multiple sessions to connect to the same VM.

• VMConnect vs VMRC
  • VMware VMRC: multiple concurrent console viewers.
  • Hyper‑V VMConnect: single session only; others blocked.
  • For multi‑user access, use RDP inside the guest.

As I continue to play with this more in my Lab, I’ll keep following up on this post.