Win11 guest recognizing SSD as HDD

[SvenM]

Hello! First post!

I've been trying to virtualize my AAD-joined, corporate-managed work machine setup on my personal laptop (to keep my host OS free of group policy and other restrictions), and have been playing with Hyper-V, VMWare, and VirtualBox for the last few days. So far, VirtualBox has been providing the best compromise of performance and functionality, including webcam (USB capture) and sound support for my constant Teams usage in meetings. However, I've been having one problem that so far seems insurmountable. Hopefully someone can point me in a new direction.

The laptop has a 1TB SSD. The guest is set up on an expanding VDI, which has the SSD flag set in the VM's settings. The guest OS is installed via an IT-provided/approved bootable ISO. The installation is basically a normal Windows 11 install, except IT has some scripting in place to also install M365 apps, apply group policy, force immediate BitLocker encryption, etc. etc.

The problem is that I can't get the guest OS to recognize the virtual drive (its own boot drive) as an SSD, despite the SSD flag being set in the virtual drive's options in VBox. In Task Manager and other places where hard drive type is shown, it's listed as an HDD, including in the drive optimization tool. When the guest OS thinks it's on an HDD, its normal scheduled drive optimizations perform full defragmentation passes that are detrimental to the underlying physical SSD's life, and possibly there are other more subtle effects on how disk writes are handled by the OS, which is why I'd really like to get this fixed. Here are the actions I've taken so far, based on lots of web searches, with some results coming from this very forum:

• During the first install, forgot to set the SSD flag, so it was understandable that the guest OS thought it was on an HDD. I tried the corrective actions listed below, but none of them fixed the issue, and in one forum about cloning an OS from a physical HDD to a physical SSD there was a comment that sadly once Windows decides a drive is one type, it won't change its mind no matter what, and only a fresh install can fix it. So, reluctantly I started over. New VDI, SSD flag set from the beginning, and another ISO boot to get the guest OS installed from scratch. Nope. Still recognized as HDD.
• The often-cited fix is to re-run WinSAT assessment. Open an administrative command prompt (on the guest) and run "winsat formal" (full assessment) or "winsat diskformal" (just the disk assessment). Supposedly the disk type is re-assessed/re-recognized, and the Windows flag for it is reset. Didn't work despite repeated attempts, both on the original install and on the second install where the VBox SSD flag was set from the start.
• One other promising approach was to run PowerShell as administrator (in the guest) and use Get-PhysicalDisk and Set-PhysicalDisk to verify and if necessary reset the detected drive type. When I ran Get-PhysicalDisk, I found that the drive's media type was "Unspecified". After running Set-PhysicalDisk to change the media type to SSD, another Get-PhysicalDisk indeed reported it as SSD. Hurray! But no, all the UI indicators in the OS still report it as HDD, and the drive optimization tool still performs an HDD-style defragment when it runs. Re-running WinSAT yet again had no effect.

For now I've turned off scheduled optimization/defragment on the guest OS, and maybe I'll have to live with it this way, as otherwise the setup is performing well, but am hoping for some new ideas. Maybe some VBoxManage magical command, or some obscure registry change on the guest OS, or another PowerShell command?

[fth0]

Please provide a (zipped) VBox.log file from a complete VM run (from Powered Off state to Powered Off state).

[SvenM]

Of course. Here you go.

[SvenM]

New information: Must've played with the VM hardware configuration too much, because after a guest restart it started saying Windows wasn't activated, and then it couldn't contact the AAD servers to reactivate and...well, after an hour of frustration I started over yet again.

Created a brand-new VM configuration with a new VDI, this time keeping the default configuration where the VDI is attached to an AHCI SATA controller (whereas previously I'd been trying SAS, and a flirtation with an NVMe controller was a total disaster. Made sure the SSD checkbox was checked before starting the guest OS installation.

Well, now the Task Manager Performance tab says the guest boot drive is an SSD, as does Get-PhysicalDisk command, but the disk optimization tool still calls it a Hard Disk Drive and wants to do a normal defragment. Again, I've disabled scheduled optimization to stop it from attempting daily defragmentation. Tried the WinSAT re-assessment again (and restart), and it didn't change anything.

So, now the guest OS sort of knows its boot drive is an SSD, and yet in some way or partially it doesn't know it.

[scottgus1]

I have a test you could try. This install media you're using sounds like it's been custom rolled by IT. Please try the Microsoft Media Creation tool to get a fresh un-IT'd ISO of the flavor of Windows your existing ISO is, then try a fresh new VM with the Media Creation Tool ISO. See if that OS recognizes the SSD correctly.

It could be the IT ISO was prepared (sysprep'd?) on a PC or VM with a spinning platter drive.

Note that you have to be logged in on an Admin account on the PC you run the Tool on, running it as Admin on the regular account won't work (been there tried that). A Home PC where you have an Admin account to use will work fine, if your work PC doesn't let you log on as the Admin account.

[fth0]

VDI is attached to an AHCI SATA controller (whereas previously I'd been trying SAS

A quick look into the VirtualBox source code revealed that the non-rotational property (Solid-state Drive checkbox) is only provided by the virtual SATA/AHCI, IDE/ATA and VirtIO-SCSI controller devices to the guest OS. For the other virtual storage controller devices this hasn't been implemented.

Regarding the disk optimization tool: Is it still automatically started or does it only not differentiate between SSDs and HDDs?

[SvenM]

Please try the Microsoft Media Creation tool to get a fresh un-IT'd ISO of the flavor of Windows your existing ISO is, then try a fresh new VM with the Media Creation Tool ISO. See if that OS recognizes the SSD correctly.

Thanks, I'll give this a try. Had thought about it before, but hesitated because although indeed the IT-rolled image could be part of the issue here, Media Creation Tool image is the consumer client image, i.e. Home or Professional (Home by default, with Professional available if an appropriate key code is entered in the Activation tool), but I'm running Enterprise, and I have no key code to use as normally my Enterprise installs get validated by my AAD membership. If I go to a normal client image, I'll have to acquire at least a Professional key to make the machine able to join AAD. I should do the test, just to see if indeed the SSD is properly recognized, as a step toward finding the answer(s), but it could end up being a throwaway install that can't actually be used. When a chance comes up, and after freeing some space on the host drive, will give this a try.

A quick look into the VirtualBox source code revealed that the non-rotational property (Solid-state Drive checkbox) is only provided by the virtual SATA/AHCI, IDE/ATA and VirtIO-SCSI controller devices to the guest OS. For the other virtual storage controller devices this hasn't been implemented.

Regarding the disk optimization tool: Is it still automatically started or does it only not differentiate between SSDs and HDDs?

Thanks, this answers a lot, and explains why things are different with the SATA-only setup I finally tried. Good to know. Doesn't explain why the disk is now seen as SSD by some UI components of the UI, but still as an HDD by the optimize tool. To answer the second question, after install the scheduled optimization was automatically set to occur once a day (this is standard in any new Windows install), and when manually triggering optimize in the tool, it indeed attempts a full hard-drive style defragment. When an SSD is correctly detected (like on my host system), the Optimize tool still runs every day by default, but only does TRIM stuff and doesn't try to move clusters around to make contiguous chains. I have manually disabled the optimize schedule to prevent daily attempts to defragment, and maybe ultimately that's all that matters, as long as there isn't some other "hidden" SSD-damaging activity going on in the misinformed guest OS.

[fth0]

TRIM stuff

That gives me another idea:

Reboot the host to ensure that no VirtualBox component is running. Then open the Work VM.vbox file in a text editor and replace the last occurrence of nonrotational="true" with nonrotational="true" discard="true" (note the space). This will signal the availability of the TRIM command to the guest.

Before running the VM, enable the Host I/O Cache on the virtual SATA controller (when I started using TRIM for VirtualBox VMs in the past, the VM could hang indefinitely without using the Host I/O Cache).

PS: No backup, no mercy!

[SvenM]

Reboot the host to ensure that no VirtualBox component is running. Then open the Work VM.vbox file in a text editor and replace the last occurrence of nonrotational="true" with nonrotational="true" discard="true" (note the space). This will signal the availability of the TRIM command to the guest.

Before running the VM, enable the Host I/O Cache on the virtual SATA controller (when I started using TRIM for VirtualBox VMs in the past, the VM could hang indefinitely without using the Host I/O Cache).

Tried that, thanks. Adding the discard="true" property to the disk seems to have fixed it, although something strange happened that I haven't reproduced yet. The Host I/O Cache setting was already enabled on the controller btw. Booted the VM, confirmed that Task Manager still categorized the disk as an "SSD," launched the Optimize Disk tool, and hurray, it reported the partitions on the disk as "Solid state drive." Good, so I hit the Optimize button and it ran a retrim pass. About the time it finished, everything seemed to come to a screeching halt. Frozen app window, frozen Explorer, or so it seemed until a few seconds later I was able to start Task Manager, then things froze again. And so on, everything slowed to a crawl. The Performance tab of Task Manager showed that disk active time was at 100%, explaining the slowness. Slowly I made my way to the Start menu and had the VM restart. After restart was unable to reproduce. Ran Optimize again, opened some apps, edited some files, it seemed to work OK. I'm suspicious, but overall the change did seem to provide the necessary flag for Windows Optimize Disk tool to decide this should be treated as an SSD.

Since this value doesn't get set via Settings UI, should this be considered a bug?

[SvenM]

Btw I've been playing with VMWare Workstation Pro also, and it has the exact same problem. There's no "SSD" flag when setting up a VM there, but it does seem to recognize when a vmdk is on an physical SSD, and it passes the SSD flag through into the VM. However, it's exactly the same: Task Manager Performance tab sees it as SSD but Optimize Disk tool doesn't. I'm guessing VMWare is failing to set this exact same "discard" flag that was apparently missing here. This means that in both VBox and VMWare (at least the desktop hypervisors, not sure about their enterprise ones), any virtual disk that is reporting as SSD to a Windows guest may show up correctly in e.g. Task Manager but will have an automatic default weekly drive optimization scheduled that will perform an old-school and SSD-life-reducing defragmentation pass. Unless one looks at Optimize Disk tool, recognizes the problem, and disables the automatic schedule, this happens silently and repeatedly. Seems like a bug worth thinking about fixing.

[fth0]

Since this value doesn't get set via Settings UI, should this be considered a bug?

AFAIK, VirtualBox doesn't advertise the TRIM capability on purpose, because of the potential hang-type issues with and without the Host I/O Cache. For a few years now, I've heard that the VirtualBox devs want to rework the corresponding parts of the disk I/O code, but unfortunately, that just hasn't got enough priority yet.

SSD-life-reducing defragmentation pass

FWIW, in many cases, that is not as bad as it sounds, because life spans of SSDs have increased much over time. For a heavily used SSD, the defragmentation passes might be only a fraction of the total use. And for a less used SSD, the life span might never be reached at all, for example, when the life span was reduced from 15 years to 10 years. These are made up numbers, but too often I've read repeated statements without real numbers to back them up, and I once made a real calculation for a related topic that opened my eyes.

[mpack]

SSD-life-reducing defragmentation pass.

Bear in mind that VirtualBox is just an app, it's drives are just host files. We'd be in a very sorry state of affair if it was so easy for an app to damage actual hardware by normal write activity to files.

Defragging a VM filesystem is often pointless, but I'd be surprised if it noticeably shortens the life of a host SSD.

[s1L3nCe]

Reboot the host to ensure that no VirtualBox component is running. Then open the Work VM.vbox file in a text editor and replace the last occurrence of nonrotational="true" with nonrotational="true" discard="true" (note the space). This will signal the availability of the TRIM command to the guest.

Before running the VM, enable the Host I/O Cache on the virtual SATA controller (when I started using TRIM for VirtualBox VMs in the past, the VM could hang indefinitely without using the Host I/O Cache).

This worked for me too! Thanks

[javispedro]

I wouldn't really recommend setting the discard flag, as there are quite some reports of data loss (including this very thread). The point of the discard flag is to be able to shrink the VDI filesize "dynamically", and if anything it may even have a detrimental impact on performance.

If you are doing this just to get the builtin defragmenter to stop, that's quite a wasteful way. Just disable the builtin defragmenter. The HDD/SDD thing is almost entirely cosmetic.