This is an issue which has caught a number of customers out during the Virtual SAN beta, so will probably catch some folks out when the product goes live too. One of the requirements for Virtual SAN (VSAN) is to allow multicast traffic on the VSAN network between the ESXi host participating in the VSAN Cluster. However, as per our engineering lead on VSAN, multicast is only used for relatively infrequent metadata operations. For example, object creation, change in object status after a failure and publication of statistics such as a significant change of free disk space (the publication of…
I had a customer reach out to me recently to discuss VMware’s Storage I/O Control behavior and Adaptive Queuing behavior and how it works with QLogic’s Execution Throttle feature. To be honest, I didn’t have a good understanding of the Execution Throttle mechanism from QLogic so I did a little research to see if this feature inter-operates with VMware’s own I/O congestion management features.
This is a topic which has been discussed time and time again. It relates to an advanced storage parameter called Disk.SchedNumReqOutstanding, or DSNRO for short. There are a number of postings out there on the topic, without me getting into the details once again. If you wish to learn more about what this parameter does for you, I recommend reading this post on DSNRO from my good pal Duncan Epping. Suffice to say that this parameter is related to virtual machine I/O fairness. In this post, I’ll talk about changes to DSNRO in vSphere 5.5.
About a year ago I wrote an article stating that Raw Device Mappings (RDM) continued to rely on LUN IDs, and that if you wished to successfully vMotion a virtual machine with an RDM from one host to another host, you had to ensure that the LUN was presented in a consistent manner (including identical LUN IDs) to every host that you wished to vMotion to. I recently learnt that this restriction has been lifted in vSphere 5.5. To verify, I did a quick test, presenting the same LUN with a different LUN ID to two different hosts, using that…
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.