In a blog post I put out this week I worked through the process for configuring SSD devices in my ESXi hosts to be used for an all flash (AF) VSAN configuration. After getting the AF VSAN up and running in my lab I started moving over a few of my VMware Horizon View 6.2 infrastructure VM’s (Composer, Connection Servers, etc) just to test the waters. After verifying that all was good with the VSAN Datastore, next step was to create a new desktop pool. That is when things went a bit sideways.
After walking through the new pool creation wizard via the View Administrator console I would switch over to my vSphere client to observe the status of the virtual machine cloning operation. After a few seconds I noticed that the clone operation would error out stating “Insufficient disk space on datastore” . The screenshot below display the message:
While my lab AF VSAN Datastore might not be the size that someone would run in a production environment, I know that the 722GB of free space available should be more then enough space to create a small View desktop pool. I tried the pool creation a few more times, but still no luck and received the same error message.
After doing some baseline troubleshooting and Google-Fu I was somewhat stumped. I had been using a hybrid VSAN configuration for months in the lab without issue when combined with Horizon View linked clones. With it getting late and not really wanting to spend extra time troubleshooting I reached out to Jase McCarty ( blog / twitter ) for some assistance. Jase currently works for VMware in a Technical Marketing role on the VSAN team. It was a good shot he would know the answer or at least where to look.
In chatting with Jase he pretty much new immediately what the issue was, it revolved around the Storage Policy Base Management (SPBM for short) policies that Horizon View creates when VSAN is leveraged for backend storage. Five polices are created by View as displayed in the screenshot below:
Specifically the policy in question and the root of the issue is the Replica Disk policy. When viewing the policy you can see that 10% of space is being reserved for flash read cache. While this setting is appropriate for hybrid VSAN deployment, with an AF VSAN configuration it is no longer needed. Compared to a hybrid configuration were reads and writes are cached/buffered for performance, an AF VSAN configuration with both flash at the cache/buffer tier and capacity tier the performance issues with a “read miss” are less impactful as the reads would be coming from a flash device in the capacity tier.
After modifying the policy and setting the value to a 0% caching reservation I was able to successfully deploy my linked clone desktop pool. I would like to give a hat tip to Jase McCarty for the assistance and also pointing on the VMware KB article that covers this issue as well – Unable to provision linked-clone pools on a Virtual SAN all-flash cluster – 2110786. Something to mention, the KB article lists only VMware Horizon 6.1.x as a product, but based on my lab experience the issue still persists in VMware Horizon 6.2.
Thanks for reading!