Today sees the release of the vRealize Operations Management Pack for Storage Devices (MPSD) version 6.0.2. This is exciting for me as it means that vROps now has management and monitoring features for Virtual SAN 6.0. The management pack comes with a set of default dashboards for Virtual SAN clusters, as well as the ability to monitor and create proactive alerts/notifications based on VSAN events.
I took the vROps Management Pack for a spin a little while back, and used it on my own lab cluster. Included below are a few of the features that it has.
I’ve been involved in a few conversations recently regarding how VSAN trace files are handled when the ESXi host that is participating in a VSAN cluster boots from a flash device. I already did a post about some of these considerations in the past, but focused mostly on USB/SD. However SATADOM was not included in this discussion, as we did not initially support SATADOM in VSAN 5.5, and only announced SATADOM support for VSAN 6.0. It seems that there are some different behaviors that need to be taken into account between the various flash boot devices, which is why I decided to write this post.
A common question we receive when we meet with customers and talk about Virtual SAN is “whether or not VSAN is going to be able to run my particular workloads?” This is a great question to ask, as most customers are coming from a background of SAN or NAS storage arrays, fibre channel, FC switches, HBAs, CNAs, etc. Since VSAN is still relative new (18 months old at this point), being confident that this new product can successfully run existing virtual machines and applications is paramount. To that end, VMware has developed a number of tools that are simple to use and will provide customers with all relevant details on their current workloads, and whether or not these workloads will run on VSAN.
Note that this new Health Check plugin version 6.0.1 release only requires the vCenter server to be updated. There are no new ESXi host side VIBs required. The patch comes as a new installable RPM for the vCenter appliance and a new MSI for Windows versions of vCenter server.
[Update] For the most part, once the RPM or MSI has updated, there should be no further action needed. However, there have been a few occasions where the health check reports that the VIBs on the ESXi host need to be updated. This can happen when EAM (ESX Agent Manager) does a check on the VIBs during a health service restart (e.g. when the post install script is run). This is simply rectified in a mater of seconds by clicking on the “Retry” button in the VSAN > Manage > Health view.
A very quick “public service announcement” post this morning folks, simply to bring your attention to a new knowledge base article that our support team have published. The issue relates to APD (All Paths Down) which is a condition that can occur when a storage device is removed from an ESXi host in an uncontrolled manner. The issue only affects ESXi 6.0. The bottom line is that even though the paths to the device recover and the device is online, the APD timeout continues to count down and expire, and as a result, the device is placed in APD timeout state. This obviously has an impact on virtual machines, workloads, etc, that are using this device.
Unfortunately there is no resolution at this time, but there are some workarounds detailed in the KB article. For those of you who dealt with APD events in earlier versions of vSphere, you’ll know the drill.
The KB article is 2126021. Note that this doesn’t affect all APD behaviors. Most APD events are handled just fine. However I’d urge you to take a quick read of the KB just to familiarize yourself with the behaviour and workarounds while we work on a permanent solution.
This question has come up on a number of occasions in the past. It usually comes up when there is a question about scalability and the number of disk drives that can be supported on a single host that is participating in Virtual SAN. The configurations maximums for a Virtual SAN node is 5 disk groups, with each disk group containing 1 flash device and up to 7 capacity devices (these capacity devices are magnetic disks in hybrid configurations or flash devices in all-flash configurations). Now the inevitable next question is how is this configuration implemented on a physical server. How can I get to 35/40 devices in a single server. There are a few ways to do it.
In Virtual SAN 6.0, a new snapshot format was introduced called vsanSparse. This improves snapshot functionality by leveraging the new VirstoFS on-disk format used with VSAN 6.0. I had a question recently about what would happen if I migrated a VM with a traditional vmfsSparse/redo log type snapshot. The question was whether or not it would be converted to the new vsanSparse format. Similarly, what if a VM with a vsanSparse snapshot was migrated from VSAN to a traditional VMFS/NFS datastore? Would it also be converted between formats? I decided that the only way was to try it out.