VMware released VSAN 6.2 on March 15, 2016. However, if your VSAN is running on a Dell server with H730 or FD332-PERC controller, do not upgrade to VSAN 6.2.
See KB2144614 for more information.
VMware released VSAN 6.2 on March 15, 2016. However, if your VSAN is running on a Dell server with H730 or FD332-PERC controller, do not upgrade to VSAN 6.2.
See KB2144614 for more information.
I look for an IOPS calculator for the EMC VNX2 5400 storage that I am working on. There are many available on the Internet. But none of them gives me exactly what I want. More frustrated, different calculators produce different results. So I decide to build one myself. Here is what I get.
My IOPS calculator concept:
My IOPS Calculator Download (save the spreadsheet and open in Excel)
An ESXi 6.x host shows an warning message “Deprecated VMFS volume(s) found on the host. Please consider upgrading volume(s) to the latest version.”
After verifying all the datastores mounted on the host are VMFS5, I restarted the management agent on the host. That cleared the warning.
This is a known issue on vSphere 6 (KB2109735).
VSAN is a hot topic nowadays. Once it is set up, it’s easy to management and use. No more creating LUN and zoning.
We recently experienced some catches about its free available storage - at least we didn’t think about or were told before; or maybe our expectation to VSAN was too positive.
Our VSAN hardware disk configuration:
Calculation of each node storage capacity (RAW):
931.51 x 14 = 13,041.14 GB = 12.73549 TB
Total storage capacity (RAW)
931.51 x 14 x 3 = 39,123.42 GB = 38.20646 TB
This calculation matches the storage capacity shown in the VSAN Cluster’s Summary.
We are adding more VMs to the VSAN. Once the free storage drops below about 12 TB (about one node’s RAW capacity), the VSAN health check starts showing critical alert “Limits Health - After 1 additional host failure” (KB2108743).
And the component resyncing starts more frequently.
My take away:
A lesson to remember if you do not have the time to read this entire post: do not migrate the cluster VMs without fully understanding the impact.
Here is our story.
We had a Microsoft SQL 2008 Cluster VMs in the CIB (see my previous post about various Microsoft Cluster VMs configuration). The shared disks of the cluster VMs were on an EMC SAN. When the free space of EMC SAN was running low, an engineer migrated the cluster VMs (the VMs were powered off during the migration) to the VSAN v.6.1 hosts and storage. The migration completed successfully, but the VMs would not power on with the error message “Cannot use non-thick disks with clustering enabled (sharedBus='physical'). The disk for scsi1:0 is of the type thin.”
Because VSAN does not support Microsoft Cluster with the shared disk (non shared disk cluster, e.g. SQL AlwaysOn Availability Group is supported), this is no option but migrating the VMs back to the original hosts and SAN storage.
PS: In this case, the new target storage is VSAN. I think if the new target storage were the traditional SAN, the cluster would break too. Because the cluster VMs were not shared anymore after the migration (see below). But you probably could recover the cluster by reconfiguring the VMs to share the shared disks without migrating the VMs back to the original storage.
When we reviewed the disks of the migrated VMs on the VSAN storage, each VM had its own copy of the shared disks. So the cluster VMs were not shared the shared disks any more. We could not simply migrate the VMs back to the original hosts and SAN storage.
When we reviewed the original EMC SAN storage, the VMDK files of the shared disks were still left there, only the non shared disk (e.g. the OS’s C drive) was completely migrated to the VSAN storage.
Recovery Procedure:
A SAN datastore is shown inaccessible on one of the ESXi hosts in the cluster. Other ESXi hosts can access that datastore without problem.
Solution: restart the ESXi management agents on the ESXi host
There are a few ways to restart the management agents (KB1003490).
This post is to summarize the various backup consistency types:
Source: VSS Crash-Consistent vs Application-Consistent VSS Backups
This is a quick update on my previous post “ Use WinSCP to Transfer Files in vCSA 6.5 ”. When I try the same SFTP server setting in vCSA 6.7...