As you might’ve seen, Cormac Hogan just posted about an UNMAP fix that was just released. This is a fix I have been eagerly awaiting for some time, so I am very happy to see it released. And thankfully it does not disappoint.
First off, some official information:
Manual patch download:
Or you can run esxcli if you ESXi host has internet access to download and install automatically:
esxcli software profile update -p ESXi-6.5.0-20170304001-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
Continue reading “In-Guest UNMAP Fix in ESXi 6.5 Part I: Windows”
So vSphere 6.5 introduced VMFS-6 which came with the highly-desired automatic UNMAP. Yay! But some users still might need to run manual UNMAP on it for some reason. Immediate reasons that come to mind are:
- They disabled automatic UNMAP on the VMFS for some reason
- They need to get space back quickly and don’t have time to wait
When you run manual UNMAP one of the options you can specify is the block count. The UNMAP process since 5.5 iterates through the VMFS, by issuing reclaim to a small part of the VMFS, one at a time, until UNMAP has been issued to all of the free space. The block count dictates how big that segment is. By default ESXi will use 200 blocks (which is 200 MB). Continue reading “Issue with Manual VMFS-6 UNMAP and Block Count”
A question recently came up on the Pure Storage Community Forum about VMFS capacity alerts that said, to paraphrase:
“I am constantly getting capacity threshold (75%) alerts on my VMFS volumes but when I look at my FlashArray volume used capacity it is nowhere near that in used space. What can I do to make the VMware number closer to the FlashArray one so I don’t get these alerts?”
This comment really boils down to what is the difference between these numbers and how do I handle it? So, let’s dig into this. Continue reading “VMFS Capacity Monitoring in a Data Reducing World”
I posted shortly after ESXi 6.0 came out a while back explaining how to do in-guest UNMAP with Windows. See the original post here:
Direct Guest OS UNMAP in vSphere 6.0
The high-level workflow if you don’t want to read the post is:
- You delete a file in Windows
- Run Disk Optimizer to reclaim the space
- Windows issues UNMAP to the filesystem
- ESXi shrinks the virtual disk
- If EnableBlockDelete is enabled on the ESXi hosts, ESXi will issue UNMAP to reclaim the space on the array
This had a few requirements:
- ESXi 6.0+
- VM hardware version 11+
- Thin virtual disk
- CBT cannot be enabled (though this restriction is removed in ESXi 6.5 see this post)
Continue reading “Allocation Unit Size and Automatic Windows In-Guest UNMAP on VMware”
This is the fourth in my series of what’s new in ESXi 6.5 storage. Here are the previous posts:
What’s new in ESXi 6.5 Storage Part I: UNMAP
What’s new in ESXi 6.5 Storage Part II: Resignaturing
What’s new in ESXi 6.5 Storage Part III: Thin hot extend
Here is another post for vSphere 6.5 UNMAP! So many improvements and this is a big one for many users. Certainly makes me happy. Previously, in vSphere 6.0.x, when in-guest space reclamation was introduced, the enabling of change block tracking for a given virtual disk blocked the guest OS from being able to issue UNMAP to that disk and therefore prevented it from leveraging the goodness it provides. Rumor has it that this undesirable behavior continued in vSphere 6.5…
Continue reading “What’s new in ESXi 6.5 Storage Part IV: In-Guest UNMAP CBT Support”
So as you might be aware, vSphere 6.5 just went GA.
There is quite a bit of new stuff in this release and there have certainly been quite a few blogs concerning the flagship features. I want to take some time to dive into some new core storage features that might be somewhat less heralded. Let’s start with my favorite topic. UNMAP. Continue reading “What’s new in ESXi 6.5 Storage Part I: UNMAP”
A recent question I got about my UNMAP PowerCLI script was it says it was using a certain block count but when I looked at the log it was using 200. Why?
Well I blogged before about why a given UNMAP process might revert to the default block count of 200 here. Essentially, if you indicate a block count larger than 1% of the free space of the VMFS ESXi will revert it to 200. Or if the VMFS is more than 75% full it will always override the block count back down to 200. Continue reading “VMFS UNMAP switches block count”
Let me start out with saying I’m embarrassed I have only been using vRO for 8 months or so. It is AWESOME.
The FlashArray Workflow Package for vRealize Orchestrator has been updated to include two new objects:
- Auto-expand datastore policy template
- Workflow to run UNMAP on a datastore
The creation of the first part is explained in this post. But if you are using the FlashArray it is all built into the package, so you have to do very little work. I’ll explain in a bit.
The UNMAP workflow is generic–it can be used with any VMFS datastore that supports UNMAP. So it is included in the workflow package and it is also standalone for those of you who don’t have a FlashArray. You can get the standalone here:
Continue reading “Running UNMAP with vRealize Orchestrator”
I’ve noticed I am beginning to have some blog post sprawl as I update my UNMAP script over and over so I will be using this post from now on to record future updates. Please use this post as the final word on what is new with my UNMAP Script.
Continue reading “Pure Storage FlashArray UNMAP PowerCLI Script for VMware ESXi”
Having a best practices conversation the other day with a customer and the usual topic came up about any recommendations when it comes to virtual disk type. We had the usual conversation thin or thick, the ins and outs of those two. In the end it doesn’t matter too much, especially with some recent improvements in ESXi 6.0. The further question came up, well what about between zeroedthick and eagerzeroedthick? My initial reaction was that it doesn’t matter for the most part. But we had just had a conversation about Space Reclamation (UNMAP) and I realized, actually, I did have a big preference and it was EZT. Let me explain why.
Continue reading “ZeroedThick or EagerZeroedThick? That is the question.”