VirtIO SCSI Virtual Disks Showing as "HDD" in Windows Guest Task Manager on Sangfor HCI (SAS SSD Backend)
  

George Fady Lv2Posted 2026-Aug-31 19:34

I'm a Technical Support engineer at Sangfor, and I wanted to share a case I recently worked through, since I think other engineers and customers running HCI may hit the same thing after a cluster migration.
The Problem
A customer migrated several VMs from a POC cluster to their Production HCI cluster (running HCI 6.11.3). After the migration, Windows guest VMs started showing their system disk as "HDD (SCSI)" in Task Manager and Device Manager — even though the backend datastore was confirmed to be 100% SAS SSD. Naturally, this raised concerns that the storage type had somehow changed during migration, and the customer also reported general slowness, so it needed a proper investigation rather than a quick dismissal.
Investigation
A few things stood out early on:

  • Disk latency in Task Manager was already SSD-class (0–2.3ms average response time), which didn't match what you'd expect from an actual HDD.

  • A brand-new VM created directly on the same Production cluster correctly displayed as SSD — its controller showed as "Sangfor Harddisk ATA Device."

  • The migrated VMs, on the other hand, used the "Sangfor FastIO SCSI Controller" (VirtIO SCSI).

That comparison isolated the issue to the controller type, not the storage itself.
We further confirmed this using PowerShell:

Get-PhysicalDisk | Select FriendlyName, MediaType, BusType, Size
This returned MediaType: Unspecified for the affected disks. We also tried running winsat diskformal and Get-PhysicalDisk | Update-StorageProviderCache to see if a fresh benchmark would force Windows to reclassify the media type — it did not. The MediaType field stayed Unspecified even after benchmarking confirmed excellent throughput (6,176 MB/s sequential read, storage score 9.8).
Root Cause
This turned out to be a known characteristic of how VirtIO SCSI controllers work on KVM/aSV-based hypervisors, including Sangfor HCI. Windows determines the SSD/HDD label from a SCSI Inquiry response (VPD Page 0xB1 – Block Device Characteristics / rotation rate), which is a static value reported by the controller at enumeration, not something derived from measured performance. The FastIO SCSI controller doesn't set the non-rotational flag in that response by default, so Windows falls back to displaying "HDD" — regardless of what the actual backend storage is.
Resolution
We confirmed with the customer that this is cosmetic only:

  • No impact on I/O performance — their own benchmarks proved SSD-class throughput and latency.

  • No impact on Space Reclamation (TRIM/UNMAP) — this continues to function normally via the FastIO SCSI driver as long as vmTools is installed and disks are thin-provisioned.

  • We advised against switching the controller back to ATA/IDE just to fix the label — FastIO SCSI gives meaningfully better IOPS, queue depth, and CPU overhead than ATA emulation, and changing controller type on an already-installed system disk risks an INACCESSIBLE_BOOT_DEVICE failure on boot.

Case closed as expected behavior, no corrective action needed on the HCI platform.
TL;DR for anyone who hits this:
If your migrated VMs show "HDD" after moving to a FastIO SCSI-attached datastore but your latency/throughput numbers look fine, it's very likely this same controller-reporting limitation — not a real storage problem. Don't chase it by switching controllers on production system disks.
Curious if anyone else here has run into this, and whether there's an official KB planned for it — happy to compare notes.

Like this topic? Like it or reward the author.

Creating a topic earns you 5 coins. A featured or excellent topic earns you more coins. What is Coin?

Enter your mobile phone number and company name for better service. Go

Arsalan Israr Lv1Posted 2026-Sep-01 01:53
  
Thanks for sharing