By VMworld, vSphere

Note: Special thanks to my esteemed colleague Cormac Hogan for answering some of my questions when I was writing this post. To learn more about VAAI unmap check out Cormac’s rather excellent blogpost: VAAI Thin Provisioning Block Reclaim/UNMAP In Action

There’s lots of news stuff storage wise in vSphere5.5. I could use this space to talk about VSAN (apparently the v is capitalized?!?!) and vFRC (stands for vSphere Flash Read Cache apparently the V is not capitalized and vFlash was regards as too snappy and easy to remember :-p ) – but I want to keep those separate for now, and focus on the core platform.

16GB Fibre-Channel Support

vSphere 5.5 now completely support 16GB FC end-to-end. Previously, 16GB was supported natively at the vSphere host, but once you got to the ports connecting to the storage array this was teamed to multiple 8GB. This looked like this:

vsphere-16gb-compromised

Now with vSphere 5.5 the 16GB support is native to array, and looks like this:

vsphere-16gb-end-to-end

I imagine that this was largely a Q&A effort with VMware working with its storage partners to get gear required qualified for the HCL.

Microsoft Clustering Services (MSCS)

Yeah, I know its mad. Folks still run MSCS in guest. I can’t believe it myself that this junk is still used, never mind that Microsoft persists in retro-fitting it to offer availability to VMs on Hyper-V. Talk about if all you have is a hammer, every problem looks like a nail. In fairness though a lot of people do still use MSCS to help with patching critical systems. You can’t help thinking if Windows was more robust as OS that the up times of single instance would be good enough for most people. Anyway, the news is that Windows 2012 clustering is supported. It took sometime, and the process was complicated by funkiness involved in the Microsoft EULA – the less said about that the better. The support has been extended not just to include FC backed storage, but iSCSI as well. iSCSI always worked for me in my lab, but it wasn’t QA’d and not officially supported. There’s also now support for iSCSI inside the guest OS as well as the iSCSI initiator in vSphere. I don’t see much advantage to using the Microsoft iSCSI initiator as it gives you more admin work to do…The other good news is 5-node MCSC cluster are to be supported on FC, iSCSI and FCoE. Sadly, MSCS will not be supported on ToE (Token Ring over Ethernet) 😉

Permanent Device Loss/All Paths Down (PDL & APD)

In rare case you can experience PDL/APD where access to storage is lost completely. That can be due to hardware failures or major power loss to the rack. APD and PDL are terms used in SCSI sense codes to indicate that storage has come unavailable. This starts life as indication of APD, and then moves to PDL status after a period of time. The difference is with PDL is that the host stops trying to reach storage it cannot reach. The logic behind the APD/PDL process has been improved, and should mean that dead devices do not lurk around in the storage device list. Remember that a vSphere host see’s 256 LUNs (0-255) maximum so cleaning up the list can be important. Of course, if the device comes back online, all that’s need is a rescan for it to be discovered, and the VMFS mounted.

VAAI Unmap

As you may (or may not) know VAAI Unmap concerns the process by which thinly provisioned data/vmdk disk space is recouped to the overall system. As you might know when you delete stuff in the world of computers, it doesn’t actually get deleted – just marked for deletion. That can cause problems in the thin world because disk space isn’t restored back to the overall storage system. It’s a particular pain in environments where large amounts of temp data is created and then destroyed again. VAAI introduced the SCSI unmap primitive to fix this issue. Initially, it was enabled by default in vSphere5.0 but then it was made a manual process with subsequent updates – that’s because of the law of unintended consequences – the unmap process could negatively affect performance on some storage arrays.

There have been some improvements made here. It’s still a manual process using the vmkfstools -y command (currently this is executed in the path of the datastore where you want to free up space and uses a % value to indicate how much free space to reclaim – it creates a temp file to handle the process, and care must be taken in specifying to high a percentage value, and accidentally filling the volume) with vSphere5.5 this % value has been changed to use a block size instead. The vmkfstools -y it’s joined by a new addition to the esxcli command – called esxcli storage vmfs unmap. The esxcli method does the unmap exactly the same as the vmkfstools -y. I think its addition is to make sure esxcli remains a complete toolset rather than having different commands for different functions. It’s taken quite a feat of engineering to maintain the unmap functionality, whilst accommodating the new 62TB disk size.

VMFS Heap Size

VMFS has a “heap size” value of 30TB limit on open files, that’s despite the fact that vSphere5.5 supported 64TB disks. Very rarely it is possible to run out of heap size, this was caused by the file system not clearing out indirect file system pointers correctly. Essentially, the issue was VMFS not evicting stale files system points in a timely enough fashion. Previous updates have fixed the issue by merely increasing the heap size value. In vSphere5.5 this issue has been properly addressed by improving the reclamation of heap space. It now means the heap size allocation has returned to a more acceptable level. So the 256MB heap size now allows access to all the 62TB available to a VM.