SSD recognition issue in Windows 11 guest? (possible bug with SSD premature wear potential)

[svenmerget]

This is my 3rd post/question in a row, but my last one for now!

I notice that my Windows 11 guest, running on Windows 11 host, in Workstation Pro 7, is having one small problem recognizing the SSD storage correctly. The host storage is a 1TB NVMe SSD on a laptop. It's exposed to the guest via an NVMe virtual controller (maybe that was my mistake, and I should've stuck with SATA?). Chose NVMe because my understanding is that the CPU and instruction overhead is smaller than with SATA, but maybe in the virtualized environment this is irrelevant.

In any case, the guest, newly installed in this configuration, sees the boot drive (a fixed-allocated VMDK on the aforementioned host SSD) as an SSD when looking for example at Task Manager / Performance. If I run Get-PhysicalDisk in PowerShell on the guest, I get a FriendlyName of "VMware Virtual NVMe Disk" and a MediaType of SSD. All good. However, if I start the old-school "Defragment and Optimize Drives" tool, a dinosaur from the XP days I think, but which is still the official way Windows runs (by default) weekly drive optimization, it sees the same disk as a "Hard disk drive." If I run Optimize on it, it actually does an old-school spinning-drive defragment! When this tool This is a task that runs silently in the background once a week, unless the schedule is turned off by the user!

Running defragmentation on an SSD increases cell wear and is not a good idea. Luckily, I stumbled across this and turned off the scheduled optimization schedule.

On the host, the same tool reports the physical drive as a "Solid state drive," and when Optimize is run with it, it performs only an SSD retrim via TRIM commands, as it should.

So, my question is, how can the guest see the virtual drive as an SSD (which makes sense, as it the VMDK is located on an SSD), but the Optimize Drives tool does not? What's the secret sauce in the OS that is misidentifying this, and can this be fixed?

Btw before someone dredges this up after a web search: I've already tried running "winsat formal" in an administrative command prompt, which on a physical machine does indeed re-recognize the drive types as part of a WinSAT assessment, and can be used to shake some sense into Windows after e.g. cloning a drive HDD->SSD or vice versa, and mounting it to the same OS installation (or cloning a Windows OS boot drive). Also ran "winsat diskformal" which runs just the disk assessment. This had no effect, even after a restart. Also tried using PowerShell's Set-PhysicalDisk but a) the Get-PhysicalDisk reported drive type is already correct, and b) using Set-PhysicalDisk to change MediaType flag is only possible on a drive that's part of a storage pool, otherwise the change has no effect and reverts after a restart.

[svenmerget]

Here's some additional information that may be useful: I had the exact same problem in VirtualBox. In VBox, a virtual drive can be flagged as "SSD" in the VM Settings, and I had it flagged that way. The guest's Task Manager Performance tab would say the disk is SSD, but the Optimize Disk tool would say it was a Hard Disk Drive (and want to defragment it improperly). Exactly the same as in VMWare Workstation. Someone over in the VBox forums had me try something, and the verdict so far is that it has fixed the problem. In the .vbox file that contains the VM configuration settings, I was asked to try changing the line that describes the drive attached to the SATA controller as follows:

<AttachedDevice nonrotational="true" discard="true" type="HardDisk" hotpluggable="false" port="0" device="0">

I've bolded the part I was asked to add. The UI "SSD" checkbox sets the nonrotational="true" property, but not the discard="true" property. I was told this would have the VM/controller signal that the drive supports TRIM commands. Indeed, upon starting the VM, the Optimize Disk app showed the drive as a "Solid State Disk," and running Optimize with the tool had it perform retrim (not defragment).

Given the parallels, I believe that the Workstation VM is failing to signal the exact same flag that the VirtualBox VM was missing. I wonder if an edit of the .vmx file would allow for a similar "fix" in VMWare-land?

If I'm right about this missing flag, it seems to me that Workstation's default behavior of not signaling it for virtual disks residing on host SSD's is a bug, especially given that any VMWare Workstation VM running with an SSD-based disk will by default silently perform weekly optimization passes on the disk, consisting of an old-school SSD-life-reducing defragmentation.