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.
I was involved in an interesting case recently. It was interesting because the customer was running an 8 node cluster, 4 disk groups per host and 5 x ~900GB hard disks per disk group which should have provided somewhere in the region of 150TB of storage capacity (with a little overhead for metadata). But after some maintenance tasks, the customer was seeing only 100TB approximately on the VSAN datastore. This was a little strange since the VSAN status in the vSphere web client was showing all 160 disks claimed by VSAN, yet the capacity of the VSAN datastore did not…
I’m sure many of you will be attending Partner Exchange next month in the Moscone Center in downtown San Francisco. I did not expect to be attending this year, but I got a request to co-present a Virtual SAN Proof Of Concept/Evaluation session. I’ve delivered a similar session at a number of EMEA VMUGs recently. This presentation seems to have been well received to date, and I’m hoping it will got down well at Partner Exchange also. The session details are as follows: STO4289 – Conducting a Successful Proof of Concept for Virtual SAN [update] I checked the schedule builder…