Can Windows XP be run on an SSD as a VMWare guest OS?

Question

I know similar has been asked before, there is a lot of information around pertaining to Windows XP being installed on a SSD.

I can understand that Windows XP was not made for SSD, OK it was released well before SSDs, so there is no trim function, and XP commits a lot of writes to the disk.

After all this searching and reading, I see why Windows XP should not be installed on a SSD. Though some people claim that SSDs have so many write cycles it doesn't matter, I'm not too convinced of this.

To the point. I've read a blog that claimed, if you're operating system supports trim, which they all just about do these days, you can install Windows XP as a virtual machine guest. And it stops there, they don't eleborate on this. So I'd like to ask, is this true?

Or would it be better to find a 2.5" HDD, attach it into my mainboard, and point the Windows XP guest to the HDD?

In case anyone wants to know why. I'm doing a job that's built in Excel 2010 - VBA intensive (yes, built many years ago), and much of the VBA code calls the Win32 API, built on Windows XP Pro.

Answer 1

if you're operating system supports trim, which they all just about do these days, you can install Windows XP as a virtual machine guest

I'd say that's mostly a false claim (I mean for the fact that TRIM will be triggered by the file deletion done on the VM disk image). Some hypervisor might translate written blocks that are wholy zeroes in to TRIM commands, but file deletion often do not trigger zero filling anyway (rather only a modification in the filesystem metadata). Also, such translation would require the support of the host OS. (I think it is possible with qemu on Linux with the fact that you can trigger partial TRIM on a file with fallocate, but I am not so sure that Windows has similar facilities in its block layer.)

However, I'd say don't worry about TRIM too much. With wear-leveling mechanisms in modern SSD, TRIM is probably not as important/crucial as many might think.

In particular to your case, TRIM being enabled on the host system should make sure that there are always abundant amount of unmapped storage unless it's really full. So as a result, wear-leveling will be in effect even for the writes done by the VM. In other words, even overwriting through a mapped LBA should not cause an inplace write to the same memory behind the scene. (When the LBA is mapped to some other memory, the old memory that was mapped will be garbage collected, since obviously the data on it is not considered "useful" anymore, that's why you don't really need TRIM for all overwrites. What you really need is that there's a pool of unmapped memory that allows wear-leveling to work.)

If you are using a dedicated drive for the VM (regardless of whether it is in a passthrough manner or not), you may want to consider overprovision -- make sure a bunch of LBAs are unmapped and will never be mapped. This can be done by creating a partition that will stay unformatted and TRIM'd. (You can either TRIM the whole drive in advance or just TRIM that partition if it's created by space gained from shrinking an existing one. It can be done with blkdiscard on Linux. Make sure you run it on the right drive/partition though, as it will wipe the data on it.) (I don't know how much exactly would be considered sufficient, but unless it is really tight in space, just give it a few GBs.)

With that said, rumor has it most drive have overprovisioning implemented behind the scene anyway, so it may not be necessary at all to further reserve some unmapped space yourself.

Answer 2

you're operating system supports trim, which they all just about do these days, you can install Windows XP as a virtual machine guest.

This depends on your virtual disk configuration.

If you're using a virtual disk image that's backed by a file in SSD, even if the host operating system supports TRIM, the problem is that the disk image will still be considered dirty. From the point of view of the host system, the disk sectors are still occupied by the guest system. So if the guest doesn't support TRIM, disk images won't shrink if you delete files on the guest OS.

The host system would TRIM overwritten sectors, but the host system wouldn't know to TRIM dirty blocks that the guest didn't TRIM.

If your virtual disk is set up as an IDE/SATA passthrough, then the host OS won't be interfering with that interface in any way. The guest OS would be responsible for any trimming that needs to be done.

Answer 3

SSD's will wear. SSD's will do wear-leveling regardless. TRIM is simply a means to reduce wear and make wear-leveling more efficient. TRIM is only one method, over-provisioning another. If we're required to use a non-trimming OS we could compensate for that to a degree by setting aside more over-provisioned space.

Issue is, SSD's need 'free blocks' to store new data. IOW imagine LBA 1000 keeps part of a file, you update the file, and now the SSD has to find a new spot for LBA 1000. It does so by finding a free spot, write the new data there, and 'map' that spot to LBA 1000. It now knows the spot previously mapped to LBA 1000 can be erased so it becomes part of available free spots for future data.

TRIM

Now assume we delete the file that occupied LBA 1000. This is an OS / file system level operation and the SSD has no way of knowing it can now erase the spot that was mapped to LBA 1000. And this where TRIM comes in. TRIM is a 'command' that allows the OS to tell the SSD "I'm done with LBA 1000", and so the SSD can now proactively prepare the spot that was assigned to LBA 1000 for future data.

No TRIM

Without TRIM the only way of 'knowing' for the SSD that something happened to the data in the spot it mapped to LBA 1000 is once we write to it again. So, in Windows you create a new file and it ends up being written to LBA 1000, which as far as the OS is concerned is free (the cluster mapped to LBA 1000 is free). Since we write new data the SSD maps a new spot to LBA 1000, and the previous spot is now available for the garbage collector that will erase it and make it available for future data.

In itself there isn't a fundamental issue with the no TRIM method. However, lack of TRIM would leave us with a bunch of spots that OS knows to be available while the SSD is not.

The problem

And this can become somewhat of a problem: The SSD can not just erase spots as we've called them until now. It can only erase a bunch of spots that all belong to the same erase block at the same time.

So it can happen the spot at LBA 1000 is discarded because OS delete data in this spot while the spot at LBA 1001 is not. And if both spots happen to be in the same erase block the fact LBA 1001 contains valid data while LBA 1000 does not, prevents LBA 1000 from being erasable. The SSD would first have to move the data from LBA 1001 to a different spot.

IOW the SSD need space 'to breathe', to shuffle data around, to consolidate used spots and thus unused spots so it can erase the latter and prepare them for new data. The less breathing space, the more the SSD has to shuffle to consolidate free erase blocks and in-use erase blocks. The more shuffling, the more wear.

Over-provisioning

TRIM is one means to provide the SSD with space to breath, over-provisioning is another. Over provisioning simply means setting a bunch of spots aside. If we have 1000 LBA spots and we set aside 10% of those, we will always have 10% of breathing space. The cost is that we now only have 900 LBA spots available for the OS to write to, to use.

Note that SSD's have set aside a percentage of available capacity for over-provisioning regardless.

Using SSD's with non trimming OS

Since XP does not 'TRIM' we could create more space to breathe by increasing the amount of space we set aside for the SSD to do it's thing. Some SSD's come with tools to do that (by creating a so called HPA), so that's one option to accomplish this.

In essence you can accomplish the same by simply leaving some space on the SSD unpartitioned. So what I propose would look something like:

• If SSD is not brand new we might first tell it to TRIM entire disk space using something like DiskTrim for Windows - https://github.com/tenox7/disktrim.
• Now during part of setup process or in advance partition the drive, but leave 20% unallocated. It's up to you whether you want to sacrifice more space, you can leave 40% unallocated if you wish.
• Install Windows XP.

Answer 4

Just run it. No virtual machine, it won't help. There isn't a big issue — you're never required to use TRIM for a drive to work. Doing so is beneficial for performance and slightly beneficial for longevity, but even a cluttered-up modern SSD is going to be faster than anything Windows XP ever expected, and even with a busy dev workload I rather doubt you'll hit the drive's TBW limit any time in the next 10 years. You need to be moving around big files, or running a database, for write volume to be a big concern.

But also, lack of TRIM support in your primary OS doesn't mean that you can never TRIM. You could, say, once a month, boot up a Linux live-USB, mount your Windows drive (if it didn't already do that by default), run the fstrim command on it, wait for it to finish, and reboot. Just a minor break for routine maintenance, sort of like running Defrag used to be (and on that note, don't run Defrag, it will make things worse rather than better).