Yellow Bricks

by Duncan Epping

view

VSAN Healthcheck: Read Cache Reservations test failed

· ·

** Please note: this has been solved in vSAN/vSphere 6.5GA and 6.0 p04 **

I’ve seen this popping up a bunch of times now, and it seems that the problem and solution is not easy to find for people so I thought I would give it a try as well. When running VSAN all-flash and Horizon View it can happen that you see a failed test for Read Cache Reservations in the VSAN Healthcheck. The reason for this failed test is simple: you are using read cache reservations but All-Flash has no read cache. So this is why the read cache reservations test failed. You can see the error below.

The solution is even easier, you change the policy that you are using on those objects. Change the policy to state 0% read cache and apply this policy to all objects! When applied you click “retest” on the Healthcheck and the error should go away. If you want to know more about Horizon View and policies make sure to read Cormac’s post here. There is also a KB on this topic, which can be found here.

VC Ops included in the VMware Horizon Suite 5.3

· ·

I was reading up on the announcements published today during VMworld. When talking about VDI/EUC with customers, and I am not an EUC guy so try to avoid this when I can, a couple of things always stood… First one was storage problems and the second one was monitoring. I think the announcements done today are a game-changer in that space, and I am sure that you will appreciate this:

New VMware Virtual SAN for Horizon View beta will deliver significantly lower upfront capital expense (CAPEX) and total cost of ownership (TCO) for virtual desktop infrastructure (VDI). The bundling of VMware vCenter Operations Manager for View in Horizon Suite, available at no additional cost, offers advanced VDI performance and operations management for large-scale virtual desktop production monitoring, advanced problem warning, faster time to resolution and complete infrastructure coverage.

How about that? I definitely think this a great step forward, and am happy to see that especially VC Ops is being included with the Horizon Suite. I can definitely recommend implementing it to those who own the Horizon Suite, and those who do not own the Suite yet, it might be time to invest. Please note that VSAN is still in Beta and is not been included from a licensing perspective but has been tested with the Horizon Suite. Use it in your test environments – play with it etc… but do not run your production workloads on it yet.  (Read Andre’s article for more details on the Horizon Suite.)

** EDIT, there was a lot of confusion yesterday about VSAN being bundled or not. Apparently the press release was only supposed to say that you can use VSAN with the Horizon Suite. There is no support, no bundling, no technology preview. **

VMware View Infrastructure Resiliency whitepaper published

· ·

One of the white papers I worked on in 2012 when I was part of Technical Marketing was just published. This white paper is about VMware View infrastructure resiliency. It is a common question from customers, and now with this white paper you can explore the different options and understand the impact of these options. Below is a link to the paper and the description is has on the VMware website.

VMware View Infrastructure Resiliency: VMware View 5 and VMware vCenter Site Recovery Manager
“This case study provides insight and information on how to increase availability and recoverability of a VMware View infrastructure using VMware vCenter Site Recovery Manager (SRM), common disaster recovery (DR) tools and methodologies, and vSphere High Availability.”

I want to thank Simon Richardson, Kris Boyd, Matt Coppinger and John Dodge for working with me on this paper. Glad it is finally available!

VMFS File Sharing Limits increased to 32

· ·

I was reading this white paper about VMware View 5.1 and VMFS File Locking today. It mentions the 8 host cluster limitation for VMware View with regards to linked clones and points to VMFS file sharing limits as the cause for this. While this is true in a way, VMware View 5.1 is limited to 8 host clusters for linked clones on VMFS Datastores, the explanation doesn’t cover all details or reflect the current state of vSphere / VMFS. (Although there is a fair bit of details in there about VMFS prior to vSphere 5.1.)

What the paper doesn’t mention is that in vSphere 5.1 this “file sharing limit” has been increased from 8 to 32 for VMFS Datastores. Cormac Hogan wrote about this a while ago. So to be clear, VMFS is fully capable today of sharing a file with 32 hosts in a cluster. VMware View doesn’t support that yet unfortunately, but for instance VMware vCloud Director 5.1 does support it today.

I still suggest reading the white paper, as it does help getting a better understanding of VMFS and View internals!

DR of View persistent linked clone desktops…

· ·

I know some of you have been waiting for this so I wanted to share some early results. I was in the UK last week and we managed to get an environment configured using persistent linked clone virtual desktops with View. We also managed to fail-over and fail-back desktops between two datacenters. The concepts is really similar to the vCloud Director DR concept.

In this scenario Site Recover Manager will be leveraged to fail-over all View management components. In each of the sites it is required to have a management vCenter Server and an SRM Server which aligns with standard SRM design concepts. Since it is difficult to use SRM for View persistent desktops there is no requirement to have an SRM environment connecting to the View desktop cluster’s vCenter Server. In order to facilitate a fail-over of the View desktops a simple mount of the volume is done. This could be using ‘esxcfg-volume -m’ for VMFS or using a DNS c-name mounting the NFS share after point the alias to the secondary NAS server.

What would the architecture look like? This is an oversimplified architecture, of course … but I just want to get the message across:

What would the steps be?

  1. Fail-over View management environment using SRM
  2. Validate all View management virtual machines are powered on
  3. Using your storage management utility break replication for the datastores connected to the View Desktop Cluster and make the datastores read/write (if required by storage platform)
  4. Mask the datastores to the recovery site (if required by storage platform)
  5. Using ESXi command line tools mount the volumes of the View Desktop Cluster cluster on each host of the cluster
    • esxcfg-volume –m <;volume ID>;
      or
    • point the DNS CNAME to the secondary NAS server and mount the NAS datastores
  6. Validate all volumes are available and visible in vCenter, if not rescan/refresh the storage
  7. Take the hosts out of maintenance mode for the View Desktop Cluster (or add the hosts to your cluster, depending on the chosen strategy)
  8. In our tests the virtual desktops were automatically powered on by vSphere HA. vSphere HA is aware of the situation before the fail-over and will power-on the virtual machines according to the last known state

These steps have been validated this week and we managed to successfully fail-over our desktops and fail them back. Keep in mind that we only did these tests two or three times, so don’t consider this article to be support statement. We used persistent linked clones as that was the request we had at that point, but we are certain this will work for the various different scenarios. We will extend our testings to include various other scenarios.

Cool right!?