I’m delighted to announce the availability of a new vSphere 6.5 core storage white paper. The paper covers new features such as VMFS-6 enhancements, policy driven Storage I/O Control, policy driven VM Encryption, NFS and iSCSI improvements and of course new limit increases in vSphere 6.5. There are too many VMware folks to thank for putting this paper together, but you’ll find them all listed in the acknowledgements section. I do want to mention one person however; a very special thanks to Cody Hosterman of Pure Storage who spent a lot of time testing many of these new features, and providing the relevant feedback that could be included in the paper. Thanks Cody.
The first email I saw this morning in my inbox was from my good pal, Alan Renouf. Alan is our product line manager for APIs, SDKs, CLIs and Automation Frameworks (congrats on the promotion Alan). Anyway, Alan was announcing the General Availability of VMware vSphere PowerCLI 6.5 Release 1. There are a whole bunch of improvements in this release, and much kudos must go to the PowerCLI team. However from a vSAN perspective, things look really cool. [Update] This version of PowerCLI also works with vSAN 6.2 and 6.0, so there is no need for customers to upgrade to vSAN 6.5 to leverage these new features of PowerCLI.
Hello from VMworld EMEA in Barcelona. Well, we can finally talk about vSphere 6.5 today. In this post, I want to highlight a number of new and enhanced features that you will find in vSphere 6.5 related to core storage. I am not going to discuss Virtual SAN (VSAN), Virtual Volumes (VVols) or I/O Filter enhancements (VAIO) specifically in this post, although you will no doubt see some new features tie directly into the latter. Instead, I want to talk about those features that are specific to core storage.
Earlier this month I had the opportunity to meet with a number of VMware customers in both Singapore and in the UAE. Most of the sessions were enablement and education type sessions, where there was a lot of white-boarding of VSAN (VMware’s hyper-converged infrastructure product) and Virtual Volumes (VVols – Software Defined Storage or SDS for the storage arrays). This wasn’t a sales session; I’m not in sales. The objective of these sessions was simply to educate. I guess when you are immersed in this stuff 24×7, it easy to fall into the trap of believing that everyone is well versed in this technology, and that’s simply not the case.
With both virtualization teams and storage teams in the room at the same time, it was important to show the building blocks with each approach, as well as to compare and contrast the advantages of the different storage solutions over the other. As I repeatedly delivered the same session, I thought it might be useful to share my thoughts with a broader audience, in the guise of this blog post.
By default VSAN.ClomMaxComponentSizeGB is set to 255GB. When Virtual SAN stores virtual machine objects, it creates components whose default size does not exceed 255 GB. If you use physical disks that are smaller than 255GB, then you might see errors similar to the following when you try to deploy a virtual machine:
There is no more space for virtual disk XX. You might be able to continue this session by freeing disk space on the relevant volume and clicking retry.
This is a new feature in vSphere 6.0 that I only recently became aware of. Prior to vSphere 6.0, all the I/Os from a given virtual machine to a particular device would share a single I/O queue. This would result in all the I/Os from the VM (boot VMDK, data VMDK, snapshot delta) queued into a single per-VM, per-device queue. This caused I/Os from different VMDKs interfere with each other and could actually hurt fairness.
For example, if a VMDK was used by a database, and this database issued a lot of I/O, this could compete with I/Os from the boot-disk. This in turn could make it appear that the VM (Guest OS) is running slowly.