In a post on the vSphere blog, I spoke about how to use maintenance mode. As a follow on request, a number of people asked me how they should safely shutdown a VSAN cluster. In this post, I will address that question and share my observations. On my three-node VSAN cluster, I had a number of virtual machines as well as a vApp running vCenter Operations Manager VMs. My first step was to shut down all virtual machines in my cluster.
Thanks to our friends at EMC, I was recently given the chance to attend a session on EMC’s new storage acquisition, ScaleIO. This acquisition generated a lot of interest (and perhaps some confusion) as VMware Virtual SAN product seemed to play in that same storage area. My good friend Chad Sakac over at EMC wrote about this some 6 months ago in his evocatively titled blog post VSAN vs. ScaleIO fight! Chad explains where, in his opinion, each product can be positioned and how EMC/VMware customers have a choice of storage options. His article is definitely worth a read. I…
This is something which comes up a lot. In the past, many people used a by-product of the Storage vMotion operation to rename all of the files associated with a virtual machine. In this vSphere 5.1U1 post, I mentioned that we brought back this functionality but you had to set an advanced parameter to make it work. Well, in vSphere 5.5, it works without the advanced option. The following blog post shows you this rename of virtual machine files using Storage vMotion in vSphere 5.5 to rename all of the files associated with a virtual machine.
A number of new enhancements around Microsoft Clustering Services (MSCS) have been introduced in vSphere 5.5. I wanted to cover those in this post as I know many of you continue to use MSCS for service availability in your vSphere environments.
There have been some notable discussions about VMFS heap size and heap consumption over the past year or so. An issue with previous versions of VMFS heap meant that there were concerns when accessing above 30TB of open files from a single ESXi host. VMware released a number of patches to temporarily work around the issue. ESXi 5.0p5 & 5.1U1 introduced a larger heap size to deal with this. However, I’m glad to say that a permanent solution has been included in vSphere 5.5 in the form of dedicated slab for VMFS pointers and a new eviction process. I will…
I am presenting at a number of upcoming VMware User Group (VMUG) conferences over the next month or so. I’ll be basically doing my pitch on Virtual SAN (VSAN) along with some demos on install and configuring. On November 21st, I’ll be presenting at the UK National VMUG (for the 3rd year in a row) at the National Motorcycle Museum in Solihull. More information about the UK National VMUG here, including registration. On December 3rd, I’ll be at the Nordic VMUG in Copenhagen, Denmark. This is being held at the Bella center, where VMworld was held before Barcelona. More information…
In my recent post about the new large 64TB VMDKs available in vSphere 5.5, I mentioned that one could not hot-extend a VMDK (i.e. grow the VMDK while the VM is powered on) to the new larger size due to some Guest OS partition formats not being able to handle this change on-the-fly. The question was whether hot-extend was possible if the VMDK was already 2TB or more in size. I didn’t know the answer, so I decided to try a few tests on my environment.