Moved from VMware to new Host Windows Server 2025 Standard Core Hyper-V VM guest specially SQL Server CPU raise above 12% on ideal server

Question

Hi Support Team,

We recently upgraded our Physical server R730 (Previously old VMware Host) with new R760 (Wndows Server 2025 Standard Core License fully complaint to run all 8 VMs in Hyper-V host) same old configuration and setup.

Converted VMware servers to VHDX and imported to Hyper-V bare metal host OS.

Steps did:

• IDRAC9 first updated all the latest firmware available and clean reboot.
• RAID 10 SSD and RAID 10 HDD drives. (As recommended by Dell)
• SSD (Installed Host OS first)
• Host OS > Created D: drive from SSD RAID 10
• Host OS > Create E: Drive from HDD RAID 10
• Hyper-V enabled clean reboot.
• Imported VHDX fixed and RAM (not dynamic) and SCSI (Same setup as previously configured in VMware Host).
• VM SQL server 2019 imported in Hyper-V path D: drive from SSD RAID 10 Storage
• Other VMs in imported in Hyper-V path E: Drive from HDD RAID 10 Storage
• Remove VMware tools as recommended.
• Windows is not managing storage — the PERC is:
  [FriendlyName : Primordial OperationalStatus : OK HealthStatus : Healthy IsPrimordial : True IsReadOnly : False Size : 8.29 TB AllocatedSize : 0 B]

No change in sever configuration which is running windows sever 2019.

All servers seems fine but one of the VM Guest Server which has SQL database CPU goes above 12% every time you can observer it going up with in seconds. In old VMware, it never reach even 1% in ideal condition but in Hyper-V does. I can see task manager showing system kernel as 12% CPU and above. Which is causing the issue like file explorer in E: ( which is a VHDX attached to the SQL Server) keeps on showing no responding on couple of seconds like 20 to 50 seconds depending. This is also effecting when SQL database in operation on business hours spiking CPU to 100% which causes time outs how to fix this.
I also changed to new version in place upgrade form 2019 to 2025 licence which was success without issue and updated all the windows to latest available. But even after upgrading SQL server guest VM it is having same issue.

SQL server VM Guest:

• CPU given Processor 8 CPU in Hyper-V
• RAM = 160GB more than previous VMware.
• C: 200GB
• There is no D: drive
• Only E: drive which is 2TB (Where Database Sits)
• E: has some folders at 2 clients access for updates.

So, where is the problem?

I could not figure out which kernel to stop and is it safe or not.

as I can see
System ~12%

Service Host: Diagnostic Policy Service

1. **Service Host: Microsoft Software Shadow Copy Provider (VSS)

Its been months I was not able to fix this issue. This is give us big hard time in our production warehouse daily operation causing Delays.

Thank you**

Answer 1

Hi Sushan Lama,

At this point, the behavior we are seeing indicates kernel‑level or storage‑level contention after the migration from VMware to Hyper‑V. Since the CPU usage is coming from the System process rather than SQL Server itself, configuration changes alone are no longer sufficient.

To proceed safely and identify the root cause, I need to collect diagnostic data while the issue is occurring. This will allow me to confirm whether the CPU spikes are caused by storage latency, VSS activity, or Hyper‑V integration components.

Could you please provide:

1. Task Manager screenshots (Processes, Details, and Performance tabs) captured while the issue is happening. These screenshots help confirm how CPU usage correlates with disk activity.
2. PerfMon Collect the PerfMon log regarding the high CPU issue on the affected server:
   1. Open an administrator Command Prompt.
   2. Run this command to set up the log collection:

      Logman.exe create counter PerfLog-Long -o "c:\perflogs\PerfLog-Long.blg" -f csv -v mmddhhmm -max 500 -c "\Cache\*" "\LogicalDisk(*)\*" "\Memory\*" "\Network Interface(*)\*" "\Paging File(*)\*" "\PhysicalDisk(*)\*" "\Processor(*)\*" "\Processor Information(*)\*" "\Process(*)\*" "\Redirector\*" "\Server\*" "\Server Work Queues\*" "\System\*"  -si 00:01:00
   

   3. Run this command when the issue start:

      Logman.exe start PerfLog-Long
   

   4. Run this command after 5 minutes from the start command in step 3:

      Logman.exe stop PerfLog-Long
   

   After you finish the above command, there will be a file name PerfLog-Long.blg created in C:\perflogs folder. This allows me to verify whether CPU spikes are caused by disk latency or kernel waits.
3. TSS logs
   1. Please open the below link https://aka.ms/getTSS
   2. Download the zip file and move file on all the nodes, so that we can collect logs offline.
   3. Open Admin PowerShell on the server.
   4. Browse to the location where file name as TSS.ps1 is present (present in TSS folder)
   5. And run .\TSS.ps1 -SDP:Perf [Run this command in PowerShell window as Administrator]
   If you encounter an error that running scripts is disabled, run: Set-ExecutionPolicy -ExecutionPolicy Bypass -force -Scope Process and verify with 'Get-ExecutionPolicy -List' that no ExecutionPolicy with higher precedence is blocking execution of this script. Then run ".\TSS.ps1 -SDP:Perf" again.
   6. Upload resulting compressed data (TSS *.zip file).
   These logs are critical to analyze storage stack behavior, VSS activity, and Hyper‑V integration at the kernel level, which cannot be determined from configuration checks alone.

Please note: I do not recommend stopping any system or kernel services, as this can cause instability or data issues. Log collection is the safest and most effective next step.

In addition, I have some quick questions to correlate the spike:

1. Does it happen at a specific time in the day (e.g., backups/maintenance/AV scan window)?
2. Does it happen when starting a certain application or job (e.g., SQL Agent job, ETL, backup task, scheduled task)?

After collecting these logs, kindly upload it to OneDrive and share the link. Once you share the screenshots and logs, I’ll analyze them and advise on the next steps as quickly as possible to minimize further impact on your production operations.

Thank you for your cooperation.

Ivy Bui

Answer 2

It seems you are experiencing high CPU usage on your SQL Server VM after migrating from VMware to Hyper-V. Here are some potential areas to investigate and troubleshoot:

1. Resource Allocation: Ensure that the CPU and memory allocation for the SQL Server VM is appropriate. You mentioned allocating 8 CPUs and 160GB of RAM, which should be sufficient, but monitor the resource usage to ensure that the VM is not being starved of resources due to other VMs or processes on the host.
2. Hyper-V Configuration: Review the Hyper-V settings for the SQL Server VM. Ensure that the VM is configured to use the correct virtual hardware settings, including the SCSI controller and network settings. Sometimes, performance issues can arise from misconfigured virtual hardware.
3. Storage Performance: Since you are using RAID 10 SSD for the SQL Server VM, check the performance of the storage subsystem. Ensure that the SSDs are functioning correctly and that there are no bottlenecks in disk I/O. You can use performance monitoring tools to analyze disk latency and throughput.
4. Antivirus and Security Software: Check if any antivirus or security software is interfering with the SQL Server operations. Sometimes, these programs can cause high CPU usage by scanning files excessively or interfering with SQL Server processes.
5. Windows Updates and Drivers: Ensure that all Windows updates and drivers, especially for the storage controller and network adapter, are up to date. Outdated drivers can lead to performance issues.
6. Event Logs and Error Messages: Monitor the Windows Event Logs for any warnings or errors that may provide insight into what is causing the high CPU usage. Look for specific events related to SQL Server or Hyper-V.
7. SQL Server Configuration: Review the SQL Server settings. Sometimes, certain configurations or settings can lead to increased CPU usage. Consider optimizing your SQL queries and indexes as well.
8. Kernel Processes: The high CPU usage from kernel processes like "System" and "Service Host" may indicate that there are underlying issues with drivers or services. Use tools like Process Explorer to get more detailed information about what is consuming CPU resources.
9. Performance Monitoring: Use performance monitoring tools to track CPU, memory, and disk usage over time to identify patterns or spikes that correlate with the high CPU usage.

If these steps do not resolve the issue, consider reaching out to Microsoft support for more specialized assistance regarding Hyper-V and SQL Server performance issues.

---

References:

• Troubleshoot Hyper-V virtual machine performance