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…
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.
In the VSAN 6.0 Design & Sizing Guide, a caveat was placed around the size of a VMDK, and the Number of Failures to Tolerate (FTT) number. It reads like this: “If the VMDK size is greater than 16TB, then the maximum value for NumberOfFailuresToTolerate is 1.” I’m pleased to say that this restriction has been lifted in VSAN 6.2.
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…
In the VSAN Troubleshooting Reference Manual, the following description of VSAN.ClomMaxComponentSizeGB is provided: 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…
I already wrote an article on the NexentaConnect for VSAN product after seeing it in action at VMworld last year. More recently, I had the opportunity to play with it in earnest. Rather than giving you the whole low-down on NexentaConnect, instead I will use this post to show the steps involved in presenting a file share built by NexentaConnect to a VM. In this case, the VM and the file share both reside on Virtual SAN. I will also show you how to simply revert to a point-in-time snapshot of the file share using NexentaConnect. To answer the common…