VM storage and SSDs

[destrekor]

The recent SSD Defrag thread reminded me that I have been very curious about a similar subject:

Storing a VM data store on an SSD used to be strongly advised against. Is this still bad practice to store on an SSD?

I've got a VM I use for work stuff (Win10 vm) and the performance difference is noticeable, but it seems to be strictly disk-limited performance, otherwise it feels like it really keeps up for what I need. I'm just wondering if throwing the datastore on an SSD would be a bad idea.

I know it used to be all about the fact that the whole data store would be viewed as a single file to the file system and thus the SSD wouldn't be able to properly utilize TRIM and wear-leveling on those blocks and would create uneven wear.

On a similar note, I am considering the same thing for an ESXi box I plan to build this summer. For that, I would put a few different VM data stores on an SSD.

 

[sdifox]

Dont worry and just put the vm on the ssd. Just backup the vms regularly.
Boot off a usb 3.0 stick for the esxi so your disk is dedicated to storage.

 

[destrekor]

Dont worry and just put the vm on the ssd. Just backup the vms regularly.
Boot off a usb 3.0 stick for the esxi so your disk is dedicated to storage.

Yeah for ESXi that was the plan.

Has the SSD firmwares and smarter OS handling helped limit the impact on endurance?

 

[Elixer]

Has the SSD firmwares and smarter OS handling helped limit the impact on endurance?

Somewhat, however, it still takes a ton of writes to have a impact, and unless you are writing 50+ of GB of data a day, I wouldn't worry about it that much.

Of course, I think MLC is better than TLC, so, +- a some GB depending on which SSD you have, and how much reserve you also set.

 

[dave_the_nerd]

The recent SSD Defrag thread reminded me that I have been very curious about a similar subject:

Storing a VM data store on an SSD used to be strongly advised against. Is this still bad practice to store on an SSD?

It never was, unless 1) you believe that business about SSDs being less reliable than HDDs, or 2) if cost prevents you from deploying SSDs in redundant RAID configurations where you'd have HDDs in RAID-1 or better.

(For a server that's "production" - uptime > all - then the choice between a $200 SSD vs. $200 worth of HDDs in a redundant array is a no-brainer in favor of the HDDs.)

I've got a VM I use for work stuff (Win10 vm) and the performance difference is noticeable, but it seems to be strictly disk-limited performance, otherwise it feels like it really keeps up for what I need. I'm just wondering if throwing the datastore on an SSD would be a bad idea.

I know it used to be all about the fact that the whole data store would be viewed as a single file to the file system and thus the SSD wouldn't be able to properly utilize TRIM and wear-leveling on those blocks and would create uneven wear.

Not exactly true.

With thick provisioning, it can be sort of an issue. But with thin provisioning, as long as the guest OS supports it and the VMFS datastore is configured right, TRIM commands get passed along fine, your thin provisioned VMDK shrinks when it's supposed to, and the device releases its pages/blocks back to whatever pool they're supposed to go in.

 

[destrekor]

It never was, unless 1) you believe that business about SSDs being less reliable than HDDs, or 2) if cost prevents you from deploying SSDs in redundant RAID configurations where you'd have HDDs in RAID-1 or better.

(For a server that's "production" - uptime > all - then the choice between a $200 SSD vs. $200 worth of HDDs in a redundant array is a no-brainer in favor of the HDDs.)

Not exactly true.

With thick provisioning, it can be sort of an issue. But with thin provisioning, as long as the guest OS supports it and the VMFS datastore is configured right, TRIM commands get passed along fine, your thin provisioned VMDK shrinks when it's supposed to, and the device releases its pages/blocks back to whatever pool they're supposed to go in.

Ah, hmm.

Well how does Windows 10 as a host handle that? (this particular instance for the immediate future is just a VM on my desktop... I'll deal with the ESXi server when it gets built)

 

[frowertr]

Flash for datastores is extremely common nowadays. The reliability factor for Enterprise Level SSDs has "closed the gap" quite a bit with mechanicals. If using 2.5" drives, Im using SSDs unless they dont fit in the budget.

 

[dave_the_nerd]

Ah, hmm.

Well how does Windows 10 as a host handle that? (this particular instance for the immediate future is just a VM on my desktop... I'll deal with the ESXi server when it gets built)

What hypervisor are you using?

 

[destrekor]

What hypervisor are you using?

VMware Workstation 12 Viewer

 

[dave_the_nerd]

VMware Workstation 12 Viewer

Well, windows supports TRIM, so you're halfway there.

Simple test:

1) Create a thin-partitioned VMDK.
2) See how big VMDK is.
3) Write a big file of random noise (say, a video file)
4) See how big vmdk is. (It should be what it was before, plus the size of that file.)
5) Delete the file.
6) See how big vmdk is. (It should be smaller again.)

If it's not, the guest OS isn't doing TRIM on delete, although it might still be possible to issue a manual trim command. (fstrim on linux.)

 

[frowertr]

I thought a thin provisioned data store could only be shrunk by punching zeros.

 

[dave_the_nerd]

I thought a thin provisioned data store could only be shrunk by punching zeros.

Depends on the software versions involved and how smart they are. And the SAN controller firmware, etc.

But yes, I've had to do the "balloon file" thing too. (If that's what you mean by "punching zeroes" - haven't heard that one before.)

 

[frowertr]

Yeah using sdelete is what i meant. Ive never been able to get a thin provisioned VMDK to shrink without it except through vMotion.