This is a conversation that comes up time and time again. It’s really got to do with the following considerations when booting an ESXi host that is participating in VSAN from an SD/USB device:: What should I do for persisting the vmkernel logs? What should I do about persisting the VSAN trace files? What should I do for capturing core dumps (PSOD)?
Another hyper-converged storage company has just emerged out of stealth. Last week I had the opportunity to catch up with the team from SpringPath (formerly StorVisor), based in Silicon Valley. The company has a bunch of ex-VMware folks on-board, such as Mallik Mahalingam and Krishna Yadappanavar. Mallik and Krishna were both involved in a number of I/O related initiatives during their time at VMware. Let’s take a closer look at their new hyper-converged storage product.
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.