Server 2025,vEthernet SET,Hyper V Cluster - VeeamBackup

Hi Muhamed Panchili,

Updating the VM configuration versions is a crucial first step to ensuring stability on the 2025 cluster. You can segregate traffic on an active SET switch without any downtime or impact on your production VMs. Because SET is software-defined, you do not need to unplug physical cables or rebuild the switch. Instead, we create "Host vNICs" (Virtual Network Adapters specifically for the Hyper-V host) that attach to your existing SET switch.

Here is the safest way to implement this architecture:

Step 1: Create Dedicated Host vNICs You will need to run PowerShell as an Administrator on each Hyper-V host to add logical adapters for specific traffic types (like Live Migration and Backup). Because this only adds logical adapters to the host OS, it does not drop the connection for your running VMs.

• Run: Add-VMNetworkAdapter -ManagementOS -Name "LiveMigration" -SwitchName "YourSETSwitchName"
• Run: Add-VMNetworkAdapter -ManagementOS -Name "Backup_CSV" -SwitchName "YourSETSwitchName"

Step 2: Assign VLANs (If applicable) If your physical network switches use VLANs to separate traffic, you must tag these new host vNICs so they can communicate on those isolated networks.

Run: Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "LiveMigration" -Access -VlanId <YourVlanID>

Step 3: Assign Unique IP Subnets For the Windows Failover Cluster to recognize these as completely separate networks, each vNIC must have an IP address in a completely different subnet.

Open Control Panel > Network and Internet > Network Connections.

You will see your new "vEthernet (LiveMigration)" and "vEthernet (Backup_CSV)" adapters.

Assign them static IPs in their respective subnets. Do not assign a Default Gateway to these storage/migration adapters to prevent routing confusion.

Step 4: Configure Failover Cluster Manager Once the IP addresses are applied, the Failover Cluster will automatically detect the new subnets.

• Open Failover Cluster Manager and navigate to Networks.
• Rename the newly discovered subnets to identify them clearly (e.g., "Live Migration Network").
• Right-click the Networks node and select Live Migration Settings.
• Uncheck your production/management networks and strictly check only your new Live Migration network.

By forcing Live Migration and Cluster communications onto these new, logically separated pathways, your Backup traffic (which usually traverses the Management or CSV network) will no longer collide with the cluster's internal operations, which should immediately improve your Veeam backup speeds.

Tracy Le.

Hi Muhamed Panchili,

I just wanted to follow up and see if you had a chance to try the recommendations provided above. Did updating the VM configuration versions or adjusting the traffic segregation on your SET switch help resolve the slow Veeam backup speeds on your Server 2025 cluster? Please let me know if the issue persists, or if you need any further assistance verifying your vNIC bandwidth allocations!

Tracy.

Hi Muhamed Panchili,

Since your 2019 cluster is performing perfectly, the slow Veeam backups on your new Windows Server 2025 cluster highly suggest network contention within your SET (Switch Embedded Teaming) configuration or an issue with outdated VM integration components. Here are the three most effective areas to check to resolve this issue:

1. Update VM Configuration Versions

If these VMs were migrated from the 2019 cluster, they might still be running on an older configuration version. This can cause VSS (Volume Shadow Copy) integration issues during Veeam snapshots. Run Update-VMVersion -Name "YourVMName" in an elevated PowerShell to ensure they are optimized for Server 2025.

2. Prevent Traffic Contention on SET

With SET, all traffic shares the same underlying physical NICs. If your Live Migration, CSV storage, and Backup traffic are not properly segregated, Veeam will frequently time out on larger VMs.

Open Failover Cluster Manager and ensure Live Migration is strictly limited to its own dedicated network.

Verify that your SET switch has QoS (Quality of Service) or dedicated vNICs configured so backup data isn't choked by heavy cluster communication.

3. Avoid VSS Overload on CSVs

Ensure your Veeam backup jobs are scheduled so they do not hit the same Cluster Shared Volume (CSV) simultaneously. Overlapping hardware snapshots on Server 2025 can cause severe I/O delays and access denied errors, leading to incomplete jobs.

I hope this response provided some helpful insight. If it clarified the issue for you, please consider marking it as Accept Answer so others with the same issue can find the solution.

Tracy.

The behavior points to a networking or storage path issue on the Windows Server 2025 Hyper‑V cluster rather than Veeam itself, especially since the same backups run well from a 2019 cluster. Focus on host networking for CSV/SMB storage and live‑migration/backup traffic on the 2025 cluster.

Use these targeted checks and adjustments:

1. Validate storage path health and access

• On each 2025 node, verify Cluster Shared Volumes (or other shared storage) are healthy and reachable:
  • Run Get-ClusterSharedVolume on each node and confirm the paths and states are correct.
  • For CIFS/SMB shares, ensure the cluster and any management/backup accounts have the necessary access.
• If disks or paths are intermittently locked, restart the node or detach/reattach the disk as needed.

2. Check for disk permission or “Access Denied” issues Even if backups start, permission problems can cause retries and severe slowdown.

• Confirm NTFS permissions on VHDX files and VM folders are correct. If needed, grant the VM’s virtual machine account full control, for example:
  • icacls <Path\To\Disk.vhdx> /grant "NT VIRTUAL MACHINE<VM_GUID>:(F)"
• If using SMB/CIFS storage, ensure the cluster name object and any SCVMM/backup service accounts are explicitly granted share and NTFS permissions.

3. Review Hyper‑V cluster and configuration health Misconfigurations after moving to 2025 can cause slow or stuck I/O and backup operations.

• Use Failover Cluster Manager for VM operations and check for warnings or errors on roles.
• If the cluster was upgraded or VMs were migrated from 2019, verify:
  • VM configuration versions are current; if not, upgrade using Update-VMVersion.
  • VM storage and network paths are correct and not pointing to stale locations.
• If there are persistent warnings, perform a live migration of the VMs between nodes to resynchronize cluster metadata.

4. Check for storage performance issues on the 2025 cluster

• Compare storage latency and throughput on 2025 vs 2019 using the same CSVs/SMB shares if possible.
• Use Get-StoragePool, Get-VirtualDisk, and Get-ClusterResource to verify storage pool and virtual disk health.
• If performance is degraded only on 2025 nodes, look for driver/firmware mismatches or misconfigured storage pools.

5. Validate Hyper‑V networking design for backup traffic On the 2025 cluster with vEthernet SET:

• Ensure backup traffic (Veeam data movers, SMB, etc.) is not contending with live migration or storage traffic on the same oversubscribed NICs.
• For clustered Hyper‑V, follow the guidance to separate traffic types:
  • Use dedicated networks or VLANs for live migration traffic so it does not saturate links used by backup/storage.
  • Ensure all Hyper‑V hosts have proper connectivity to the networks used for storage and backup.
• If using SMB 3.0 for storage:
  • Confirm SMB Multichannel is active with at least two NICs of the same type and speed.
  • Prefer RDMA-capable adapters for SMB Direct to reduce CPU overhead and improve throughput.

6. Compare 2019 vs 2025 configuration Since the 2019 cluster performs well, directly compare:

• NIC speeds, teaming/SET configuration, VLANs, and QoS policies.
• Which networks are used for CSV/SMB storage and which for backup traffic.
• Any changes in firewall rules or security policies that might throttle SMB/HTTP traffic on 2025.

7. General Hyper‑V and backup best practices

• Avoid overlapping backup jobs that hit the same CSVs or VMs simultaneously, as this can cause VSS contention and slowdowns.
• Ensure cluster nodes are not being rebooted or maintained without draining roles, which can leave resources in unstable states and impact I/O.
• If VMs are stuck in Saved or similar states after failed backups, clean up .vmrs and .vmgs files in the VM folders after ensuring proper backups.

If, after these checks, backups from 2025 are still significantly slower than from 2019 using the same storage and network, collect detailed logs (cluster logs, storage performance counters, and Veeam logs) and engage both Microsoft Support and Veeam support to pinpoint whether the bottleneck is in the Windows Server 2025 networking/storage stack or in the backup configuration.

References:

• Troubleshoot Hyper-V virtual machine backup, checkpoint, and storage failures
• Troubleshoot storage issues in Hyper-V and Windows Server failover clusters
• Network recommendations for Hyper-V in a failover cluster