I wouldn’t normally call out new patch releases in my blog, but this one has an important fix for Virtual SAN users. As per KB article 2102046, this patch addresses a known issue with clomd. The symptoms are as follows: Virtual machine operations on the Virtual SAN datastore might fail with an error message similar to the following: create directory <server-detail>-<vm-name> (Cannot Create File) The clomd service might also stop responding. Virtual SAN cluster might report that the Virtual SAN datastore is running out of space even though space is available in the datastore. An error message similar to the…
We made a number of enhancements to Storage DRS in vSphere 6.0. This article will discuss the changes and enhancements that we have made. There is a white paper which discusses many of the previous limitations of Storage DRS interoperability and I’d recommend reviewing it. Although a number of years old, it highlights many of the Storage DRS interoperability concerns. As you will see, a great any of these have now been addressed, along with some pretty interesting feature enhancements.
The embargo on what’s new in vSphere 6.0 has now been lifted, so we can now start to discuss publicly about new features and functionality. For the last number of months, I’ve been heavily involved in preparing for the Virtual SAN launch. What follows is a brief description of what I find to be the most interesting and exciting of the upcoming features in Virtual SAN 6.0. Later on, I will be following up with more in-depth blog posts on the new features and functionality.
One policy setting that I have yet to discuss in any great detail in my blog posts about VSAN. The ForceProvisioning policy setting, when placed in the VM Storage Policy, allows Virtual SAN to violate the NumberOfFailuresToTolerate (FTT), NumberOfDiskStripesPerObject (SW) and FlashReadCacheReservation (FRCR) policy settings during the initial deployment of a virtual machine. This can be useful for many reasons. One reason is that it enables the boot-strapping of a vCenter server on a VSAN deployment as highlighted by William Lam in this excellent blog post on the subject. Another reason is that it allows the provisioning of virtual machines…
I was having some discussions recently on the community forums about Virtual SAN behaviour when a VM storage policy is changed on-the-fly. This is a really nice feature of Virtual SAN whereby requirements related to availability and performance can be changed dynamically without impacting the running virtual machine. I wrote about it in the blog post here. However there are some important considerations to take into account when changing a policy on the fly like this.
Yesterday I posted an article which discussed some common misconceptions with Virtual SAN that come up time and again. Once I published that article, I immediately had an additional question about basic VSAN behaviour and functionality related to stripe width. More specifically, the question is how many disks do you need to satisfy a stripe width requirement. Let’s run through it here.
I’m currently neck-deep preparing for the next version of Virtual SAN to launch. As I prepare for all the new features that are coming (that I hope to be able to start sharing with you shortly), I’m still surprised by the misconceptions that still exist with regards to basic Virtual SAN functionality. The purpose of this post is to clear up a few of those.