I am on latest windows 11 pro and created an Ubuntu 26.04 VM with Hyper-V dedicated to completely sandbox Claude Code. I have several issues with the VM though :

1) the only way I can get close to a full screen experience with the VM is manually redimensionning its windows to the maximal size of my screen (and to be achieve that I had to delve with PowerShell commands first). Would I double click on the VM top bar the windows maximizes but the effective --visible -- size of the window is then quite small like 3/5 of the scree (I tried to get biggest resolutions in the VM with PowerShell commands and inside VM commands etc, nothing worked).

2) I could swear having had sound at the beginning (but I could mistaken) but yesterday I remarked that I don't have sound at all. This is pretty cruel as I use Claude Code to ... fine-tune a sound analysis library ...

3) There no way apparently to copy paste something in or out the VM (which revealed itself particularly complicated for long command line Claude's assertions etc).

This is my first Hyper-V VM, all VM I had before were Virtual box, never had such issues as everything was working right after the box usually.

I'm running win 11 26h2

I have a hyper-v machine that wouldn't boot - it was in a saved state from a reboot. I couldn't get it to boot as it said it had the wrong processor settings even though I haven't changed it in over a year. The settings were grayed out so I couldn't change anything.

I created a new VM and used the old hard drive - works great.

What I can't figure out is in Hyper-v manager, how to delete the ghost machine. that won't ever start. Right click only gives me Help as an option.

Please disregard - figured it out - I shut down the hyper-v server and ran from powershell.

MOFCOMP %SYSTEMROOT%\System32\WindowsVirtualization.V2.mof

Restarted the service and I could delete it.

I'm doing paravirtualization Hyper-V GPU passthrough.
It works. I can see my GPU in Task Manager in the VM and I can use software that use the GPU. All good.

BUT, the only thing not using GPU is Firefox.
I go to about:support and see: "WebRender (software)", that's a sign it's not using the GPU. Not to mention any webpages with some effects are very laggy.

I tried:

• Open Firefox Settings -> General -> Performance.
• Uncheck Use recommended performance settings.
• Check Use hardware acceleration when available.

Doesn't work.

Here are the steps I used to set up the VM to have paravirtualization Hyper-V GPU passthrough, from https://www.youtube.com/watch?v=XLLcc29EZ_8

if (Get-VMGpuPartitionAdapter -VMName $vm -ErrorAction SilentlyContinue) {
    Remove-VMGpuPartitionAdapter -VMName $vm
}
Set-VM -GuestControlledCacheTypes $true -VMName $vm
Set-VM -LowMemoryMappedIoSpace 1Gb -VMName $vm
Set-VM -HighMemoryMappedIoSpace 32Gb -VMName $vm
Add-VMGpuPartitionAdapter -VMName $vm



Remove-VMGpuPartitionAdapter -VMName $vm
Add-VMGpuPartitionAdapter -VMName $vm -InstancePath "\\?\PCI#VEN_10DE&DEV_...}\GPUPARAV"

How to make Firefox use GPU inside the VM?

Just checking here if anyone had any issues with a failover cluster and October's CU patch, some concerns in sysadmin sub, but not seeing any official news of an issue.
Thanks

We run Hyper-V in our environment on Windows 2019 DC and Stnd (guest servers).

I would like to know if a host had 128GB of RAM, how much would need to be set aside for Windows Server DC and the Hyper-V host to run its own operations; and if there anything additional like there needs to be an extra x number of MB or GB of memory fer x number of guest servers running that needs to be added?

We have two R650 128GB of RAM, management has been running the sh*t out of them, so one HVH uses 115GB free out of 128GB, the other uses 92GB out of 128GB. And the old R540 server single CPU (sad) uses 89GB out of 94.6GB. The first system mentioned has 10 HVG's, the next has 10 HVG's, and the R540 has 5 HVG's one of which is SQL which is consuming 60GB of RAM.

Thanks,

Server 2022 VM's, UEFI, from vSphere, using Veeam instant recovery. Most of the VM's will not boot with Secure Boot enabled under Security, but some do. I cannot tell a rhyme or reason. I'd obviously like to be able to turn on Secure Boot for all of them.

Has anyone experienced this before?

We are moving off Broadcom/vsphere to Hyper-V. Our hardware is:
Pure Flasharray x50 FC connected and Cisco x210c-M7 blades managed by IMM with SAN boot.

We have built a cluster and it seems to be working well, but am looking for anyone else out there that has this (or similar) setup. Before we move prod vms over, I would really like a professional to go through our settings (especially the networking policy details) and verify we haven't done anything too stupid. I have reached out to my VAR, but I think we might have more knowledge than they do with this and am not getting too far with them. Any advice would be appreciated.

TIA

*Updated with config:

PS C:\WINDOWS\system32> Get-Cluster | Format-List *

AddEvictDelay : 60

AdministrativeAccessPoint : ActiveDirectoryAndDns

AutoAssignNodeSite : 1

AutoBalancerMode : 2

AutoBalancerLevel : 2

BackupInProgress : 0

BlockCacheSize : 0

DetectedCloudPlatform : None

DetectManagedEvents : 1

DetectManagedEventsThreshold : 60

ClusSvcHangTimeout : 135

ClusSvcRegroupStageTimeout : 10

ClusSvcRegroupTickInMilliseconds : 300

ClusterEnforcedAntiAffinity : 0

ClusterFunctionalLevel : 12

ClusterUpgradeVersion : 6

ClusterGroupWaitDelay : 120

ClusterLogLevel : 3

ClusterLogSize : 1536

CrossSiteDelay : 1000

CrossSiteThreshold : 20

CrossSubnetDelay : 1000

CrossSubnetThreshold : 20

CsvBalancer : 1

CsvTimeToWait : 600000

DatabaseReadWriteMode : 0

DefaultNetworkRole : 3

Description :

Domain : (removed for reddit)

DrainOnShutdown : 1

DumpPolicy : 1375801625

DynamicQuorum : 1

EnableSharedVolumes : Enabled

FixQuorum : 0

GroupDependencyTimeout : 600

HangRecoveryAction : 6

Id : 2446e344-00a1-499a-9b98-0269a923b1a4

IgnorePersistentStateOnStartup : 0

LogResourceControls : 0

LowerQuorumPriorityNodeId : 0

MaximumParallelMigrations : 1

MessageBufferLength : 50

MinimumNeverPreemptPriority : 3000

MinimumPreemptorPriority : 1

Name : D800-HV

NetftIPSecEnabled : 1

PlacementOptions : 0

PlumbAllCrossSubnetRoutes : 0

PreferredSite :

PreventQuorum : 0

QuarantineDuration : 7200

QuarantineThreshold : 3

QuorumArbitrationTimeMax : 20

RecentEventsResetTime : 10/15/2026 2:51:06 AM

RequestReplyTimeout : 15

ResiliencyDefaultPeriod : 240

ResiliencyLevel : AlwaysIsolate

RouteHistoryLength : 40

S2DBusTypes : 0

S2DCacheBehavior : Default

S2DCacheDesiredState : Enabled

S2DCacheMetadataReserveBytes : 34359738368

S2DCachePageSizeKBytes : 16

S2DEnabled : 0

S2DIOLatencyThreshold : 10000

S2DOptimizations : 0

WprSessionCount : 2

WprSessionCoolOffTime : 600

RolloutAudience : 6

DpcWatchdogProfileSingleDpcThreshold : 5000

DpcWatchdogProfileCumulativeDpcThreshold : 5000

GlobalWprSessionConfig : {}

SameSubnetDelay : 1000

SameSubnetThreshold : 10

SecurityLevel : 1

SecurityLevelForStorage : 0

SetSMBBandwidthLimit : 1

SMBBandwidthLimitFactor : 2500

SharedVolumeCompatibleFilters : {}

SharedVolumeIncompatibleFilters : {}

SharedVolumeSecurityDescriptor : {1, 0, 4, 128...}

SharedVolumesRoot : C:\ClusterStorage

SharedVolumeVssWriterOperationTimeout : 1800

ShutdownTimeoutInMinutes : 1199

UseClientAccessNetworksForSharedVolumes : 2

WitnessDatabaseWriteTimeout : 300

WitnessDynamicWeight : 0

WitnessRestartInterval : 15

EnabledEventLogs : {Microsoft-Windows-Hyper-V-VmSwitch-Diagnostic,4,0xFFFFFFFD,

Microsoft-Windows-SMBServer/Analytic,

Microsoft-Windows-Kernel-LiveDump/Analytic}

UseRdmaForStorage : 1

RdmaConnectionsPerInterfaceForStorage : 4

AcceleratedNetworkingNodeReserve : 0

AcceleratedNetworkingEnabled : 0

QuarantineOnGumSlownessEnabled : 0

GumExecutionTimeSmoothingFactorPercentage : 60

Hello!

Recent VMware to HyperV here!

We're experiencing quite a havoc of our VMs whenever we lose network connection. It doesn't happen often, but we have tried it twice recently and some VMs are almost unrecoverable.

All of us are quite new to HyperV so it must be some kind of misconfiguration of our cluster.

We currently have 3 nodes connected to a powerstore through a switch.

Hey everyone,

I’ve been running into a persistent, deeply frustrating Hyper-V bug across multiple systems and OS versions, and I'm hoping someone here might know of a workaround or fix.

### The Issue

The moment I create a new **External Virtual Switch** for bridging connections, my machine's **upload speed drops by exactly 4 Mbps**, even for purely local LAN traffic.

### What I've Tested & Observed

Instant Trigger: The speed drop happens the *exact second* the virtual switch is created and applied.

Persists Regardless of VMs: Even with Hyper-V turned off entirely and zero virtual machines running, the issue remains.

The Only Fix: The moment I delete the Virtual Switch and apply changes, my upload speed immediately returns to normal.

### Scope & Reproducibility

I first encountered this exact same issue a few years ago on Windows 10 Pro. Fast forward to today, I've tested it on **Windows 11 Home, Windows 11 Education, and even on Snapdragon ARM CPUs**—and the bug is still fully present.

I had no issues while briding the NIC for WSL2 before.

Has anyone else run into this or found a way to stop Hyper-V’s bridging from throttling upload speeds? Any registry tweaks, driver workarounds, or hidden settings would be hugely appreciated. I'm still leaning towards a bad driver design however. Issue is gone after removing the Switch, but still I think it's worth for discussion if anyone has experienced similar.

Thanks!

Question about deleting VMs in SCVMM, I know with Failover clustering and HyperV Manager when you delete a VM from the GUI it only removes the VM and it doesnt clean up any disks and such.

Does SCVMM delete all data when you delete from the GUI (like VMWare's "Delete from Inventory") or is cleanup still needed afterwards?

Doing the cleanup via powershell isnt a bid deal for me i have the commands and have been rumming some test the last day my concern is co-workers having the GUI option would be nice for them so they do not try to generate AI code and remove the wrong VMs due a wildcard or something.

Anyone with some insight on this would be great, thanks.

I'm importing my VMs over to a new server 2025 host. I've got 20 VMs and it went smoothly for 16 of them. I simply search the VM Storage directory on the iSCSI share, the VM names popped up, I choose one to import, rinse and repeat. However, there are four that for some reason I can't select for importing. When I view the iSCSI share in File Explorer, I can see the files on the old host, but not the new one. This leads me to believe it's a permissions issue, but I can't figure out what the difference is.

If I export the VM from the 1st host and copy the files over to the new host locally, I can then import it and save them to the iSCSI storage. The new host can see the files on the iSCSI share at that point, but then the old host can't see them.

The end goal is go get both hosts in to a clustered setup. However, I need to get Windows updated on the first host and my plan was to migrate VMs to the new host, shut them on old host, power up on new host so that my downtime is minimal for my users. I'll then proceed with getting the first host updated so that the clustering setup doesnt' complain about the hosts having different levels of windows updates.

I've done some Googling and Reddit searching but haven't been able to find anybody discussing this exact issue.

A VM can start from its new location while parts of its state still refer to the old volume. Checkpoints, differencing disks, Smart Paging files, configuration data, replica settings, cluster resources, backup jobs, and ISO paths can be less obvious than the primary VHDX. Deleting the source as soon as the guest boots can turn a hidden reference into a later failure.

A useful post-migration check seems to need an inventory from Hyper-V and Failover Clustering rather than a folder comparison alone: every attached disk and parent path, VM configuration and runtime paths, checkpoint chains, cluster ownership, replication health, and backup discovery. I would also run a guest-level read/write test, a controlled restart or live migration, and a fresh backup before leaving the source read-only through a rollback window.

Is there a dependable PowerShell inventory that proves nothing for a VM still references the old CSV or volume? Which checks differ for standalone hosts, clustered VMs, shared VHDX/VHD Sets, and Hyper-V Replica?

hyper-v manager an error occurred while attempting to connect to server 35791. I also don't have any backup is there any way to make it work as it is more serios

I've been able to get the vm to boot but once I get to the setup window the buttons are completely unresponsive.

Hi,

I am troubleshooting a two-node Hyper-V failover cluster. During a maintenance operation, transferring CSV ownership from Node B to Node A caused a CSV operation to hang on Node A. The Cluster Service subsequently terminated and Node A was reported as isolated. Recovery involved an iDRAC power cycle.

Environment:

• Two Dell PowerEdge servers.
• Windows Server 2022 Datacenter, build 20348.5622 on the affected nodes.
• Dell PowerVault ME5024 shared iSCSI storage with two controllers.
• Two Netgear M4350-12X12F switches in a stack.
• Two dedicated 10 GbE iSCSI NICs per host, using separate subnets/VLANs, without NIC teaming.
• Microsoft DSM / MPIO, Round Robin with Subset.
• Eight connected iSCSI sessions per host. Previous path checks showed four Active/Optimized and four Active/Unoptimized paths per LUN.
• Two CSV LUNs and a separate disk witness.
• Host management, cluster communication and Live Migration share a 2 × 1 GbE LACP team.
• Cluster communication is disabled on the dedicated iSCSI networks.
• VM networking uses a separate 2 × 10 GbE SET switch, SwitchIndependent / HyperVPort.

Incident sequence, local time:

• 21:59:19 — CSV Volume2 ownership moves from Node B to Node A during node drain.
• 21:59:21 — Node A starts a dcm/map operation for Volume2, which does not complete.
• 22:06:44 — A VM resource on Volume2 exceeds its health-check timeout. The cluster restarts the corresponding RHS process.
• 22:07:06 — The Cluster Service on Node B stops gracefully for its restart. The problem on Node A is already present before this.
• 22:13:53 — Another timeout occurs for the same VM resource.
• 22:17:21 — After approximately 18 minutes, Node A logs the following error and its Cluster Service terminates:

FatalError: Volume 'Volume2:<redacted>' is stuck transitioning to CsvFsVolumeStateSetDownlevel (status = 121)

• 22:17:22 — Node B reports Node A as isolated.

Additional findings:

• Node A's System log confirms Cluster Service termination with error 121.
• CSV event 5120, STATUS_NO_SUCH_DEVICE, and disk reservation release errors appear around the time the Cluster Service terminates. Their timing does not establish that they initiated the incident.
• No preceding iSCSI or Broadcom NIC errors were found in the reviewed System log interval.
• VMMS also recorded errors referencing AVHDX files of another VM on Volume1 a few seconds before the Volume2 mapping operation became stuck. Their relevance is unclear.
• No backup job was running during the incident.
• After recovery, both nodes were Up, both CSVs showed Direct access on both nodes, and all eight iSCSI sessions were connected on each host.

The versions match between nodes. We have not established that either filter caused the hang.

Cluster.log records an unsuccessful attempt to capture a live dump, with status 0xd0000022. No relevant dump was found in the checked Cluster\Reports or LiveKernelReports directories.

Has anyone encountered this particular dcm/map / CsvFsVolumeStateSetDownlevel hang during CSV ownership transfer on Windows Server 2022?

Are there known issues involving CSV state transitions, these filter drivers, or this storage configuration? What tracing or dump collection would you prepare before a controlled reproduction to identify the blocked operation?

This past weekend my two-node Windows Server 2025 Hyper-V cluster did a cluster-aware Windows update. After the update, one node wouldn't boot back up. I ended up removing the node from the cluster and rebuilding the server. Now the server is up and configured as it was before, but for some reason I can not join the node to the cluster. It gets stuck on (Waiting for notification that node is fully functional member of the cluster). When I look at the error reports, it shows there is a network issue, but I checked the firewall, and all the ports are open. I can use PowerShell to test the ports, and they all come back as true. Did anybody run into this issue and can point me in the right direction I would really appreciate it. So far I rebuilt both servers, went through all firewall ports and configurations a 100 times, looked at all the events in Event Viewer, and nothing works.

Both of the servers are Dell PowerEdge R660 with two processors and 512 GB RAM. Identical hardware in both servers.

Recently installed Windows 2022 Hyper-V to an older server that I am having issues with the VM's crashing, when the VM is under load. The host is a Dell PowerEdge R6525 with 2 AMD EPYC 7452 and 512GB of RAM. The host shows correctable and uncorrectable memory errors. The VM's memory dump shows a 0x124_0_AuthenticAMD_PROCESSOR_CACHE_IMAGE_AuthenticAMD.sys.

I have run the Dell diagnostics, windows memory test, and Memtest86. Non of them find any issues. The idrac does not have any uncorrectable memory errors in the logs. The issue stated after I installed Hyper-V and tried to run some test machines. I have adjusted the processors to NUMA Nodes per socket of 4 and L3 cache as NUMA domain as enabled. This seems to have helped as they crash less often but they still crash. All drivers are up to date and all windows updates have been applied. Is there anything else I can look at to fix this?

Update: I have reinstalled Windows 2022 with no updates or drivers installed. Added Hyper-V and connected my test boxes. Ran Memory tests on the VM's to have load. The Host shows correctable memory errors only, IDRAC just shows that there were diagnostic events on the RAM due to the test. I have installed an older Rome chipset driver to the server and same events. No crashes/uncorrectable errors. Currently working on windows updates. After tests I will run more driver installs.

Update 2: I think I found the problem. Dell recommends a Milan based chipset driver for Windows 2022, but the processors I have are Rome based. I know they are supposed to be compatible. I reinstalled Windows 2022 with the Rome chipset, no crashes. I upgraded to the Milan chipset driver and the crashes returned. Looks like I have to run the old chipset driver to be stable.