After a succesful installation of VSAN and a storage migration of a virtual machines to the aggregated VSAN datastore, I was wondering how to monitor VM/VMDK placement on the ESXi hosts/disks. I also want to find out how virtual machines use available VSAN capacity. This article gives an answer on these two questions based on some testing in the lab. I will start answering the second question.
How VSAN capacity is used
As you might know VSAN includes RAIN (Redundant Array of Independent Nodes) and will save VMDKs on more than one ESXi node. In case of a VSAN/ESXi node failure, data available on a second node is used and guarantees continued virtual machine operation. You can configure this “number of [VSAN node] failures to tolerate” (min 1, max 3) on a per VM basis leveraging vSphere’s storage profiles feature.

Figure 1
In my VSAN lab I am running a three node VSAN cluster, each ESXi host contains one 120 GB SSD disk and one 250 GB SATA HDD. In VSAN SSD disks are only used for caching, and do not count towards available capacity. In this case I am ending up with about 700 GB of available capacity in the VSAN datastore. This capacity is just RAW capacity and doesn’t take into account capacity required for redundancy.
Virtual machines will consume disk space depending on the configured storage profile and configured features in the profile (check Cormac’s article for more details on this). If the number of failures to tolerate is 1 for example (so we need 1+1 copies of the data), data is saved twice on different VSAN nodes. This will double required capacity for such a virtual machine.
An example

Figure 2
Currently there’s only one virtual machine placed on my vsan datastore; this virtual machine includes a local disk of 3 GB (let’s start small 🙂 and requires 600 MB of memory/vswp file (it’s VMware’s vMA). I choose to set the “Object space reservation (%)” to 0%, this means the VM is entirely thin provisioned; actual occupancy is about 1.732 MB of the 3 GB disk.
Because N+1 is configured for this VSAN setup, required capacity is doubled for this virtual machine: 2 x (1.732 MB (vmdk usage) + 600 MB (vswp)) = 4.664 MB = 4.6 GB. This is exactly the difference between the total capacity and the free capacity as displayed in Figure 1.
VSAN VMDK placement
To monitor VMDK placement on the available ESXi VSAN nodes, we have to use the vSphere WebClient. Select the VSAN cluster, monitor and Virtual SAN. This option gives you insight on which physical disks are used to host VMDK and VM files.
Let’s take a look at this and select a HDD disk in use by VSAN:
The VM (or VMs) that uses this disk is displayed in the lower pane. A closer look unveils some interesting information on the Capacity, Used Capacity and Reserved Capacity for the available disks:
As you can see 2 VSAN nodes have a reservation of about 600 MB configured, which can be linked to the 600 MB VSWP file required for the virtual machine. Node esx02 and esx03 include the data disk of the virtual machine (do the math), notice that an empty VSAN datastore still contains a little less than 800 MB per node. Also notice that available SSD storage is not used as “Used Capacity”, SSD is only used for read/write caching.
After choosing VSAN cluster, monitor and Virtual SAN and virtual disks, you can select a specific virtual machine and get some information of the placement of the virtual (VMDK) disk and VM files. Notice that the placement differs for the available objects that compose a virtual machine:
And:
This interface offers information on the exact placement of the data and the witness.
This concludes this article about VSAN, if you would like to follow my blog just follow me on twitter or leave your e-mail address in the “Subscribe to this blog!” field. Enjoy!
5 Comments
Pingback: Welcome to vSphere-land! » VSAN Links
Pingback: Consolidated list of all Virtual SAN (VSAN) deep dive resources. |
Pingback: VMware Link Collection | Life
Golak
Very informative, thanks for explaining in exact figure.
Brett
Great article. Here is a challenge, how do you tell where a vmdk has been hosted historically?