Melbourne VMUG Feb 7th 2013 – Optimizing VMware vSphere , vCloud and VDI Environments with Intelligent Storage

Last month I presented a Community Session at the Melbourne VMUG

“Optimizing VMware vSphere , vCloud and Desktop Environments with Intelligent Storage”

For those who are interested, you can watch the recorded session here.

A special Thanks to Craig Waters (@cswaters1) Melbourne MVUG leader for organizing the Melbourne VMUG and recording/encoding this session for the VMware community.

Example Architectural Decision – Storage Protocol Choice for a VMware View Environment using Linked Clones

Problem Statement

What is the most suitable storage protocol for a Virtual Desktop (VMware View) environment using Linked Clones?

Assumptions

1.  The Storage Array supports NFS native snapshot offload
2. VMware View 5.1 or later

Motivation

1. Minimize recompose (maintenance) window
2. Minimize impact on the storage array and HA/DRS cluster during recompose activities
3. Reduce storage costs where possible
4. Simplify the storage design eg: Number/size of Datastores / Storage Connectivity
5. Reduce the total solution cost eg: Number of Hosts required

Architectural Decision

Use Network File System (NFS)

Justification

1. Using native NFS snapshot (VAAI) offloads the creation of VMs to the array, therefore reducing the compute overhead on the ESXi hosts
2. Native NFS snapshots require much less disk space than traditional linked clones
3. Recomposition times are reduced due to the offloading of the cloning to the array
4. More virtual machines can be supported per NFS datastore compared to VMFS datastores (200+ for NFS compared to max recommended of 140, but it is generally recommended to design for much lower numbers eg: 64 per VMFS)
5. Recompositions/Refresh activities can be performed during business hours, or at Logoff (for Refresh) with minimal impact to the HA/DRS cluster, thus giving more flexibility to maintain the environment
6. Avoid’s potential VMFS locking issues – although this issue is not as important for environments using vSphere 4.1 onward with VAAI compatible arrays
7. When sizing your storage array, less capacity is required. Note: Performance sizing is also critical
8. The cost of a FC Storage Area Network can be avoided
9. Fewer ESXi hosts may be required as the compute overhead of driving cloning has been removed

Implications

1.  In the current release, 5.1, View Storage Accelerator (formally Content Based Read Cache or CBRC) is not supported when using Native NFS snapshots (VAAI)
2. Also in the current release 5.1, “Use native NFS snapshots (VAAI) is in “Tech Preview” – This is rumored to change in View 5.2

Alternatives

1. Use VMFS (block) based datastores and have more VMFS datastores – Note: Recompose activity will be driven by the host which adds an overhead to the cluster.

VMware View 5.1 Local Mode Check Out fails with “Internal Error” at 10%

I had an interesting issue today, where a VMware View virtual desktop failed to check out (ie: Local mode) giving an error “VMware View Client – Internal Error.” (as shown below) at the 10% mark.

View_LocalMode_InitializingCheckOutPaused_InternalError

I went into Monitoring , and Events, and came across the following error while trying to diagnose the issue.

LocalModeEventError

Talk about a useless error message!!

However, as it turns out the solution was actually very simple, all you need to do is the following

Login to VMware View Administrator, under View Configuration, click “Servers”, select the “Transfer Servers” tab, highlight your Transfer server (as shown below) and press the “Enter Maintenance mode” button.

TransferServerEnterMaintenanceMode

Once the “Status” of the transfer server changes to Maintenance mode, perform a controlled shutdown of the VM.

Next edit the settings of the virtual machine and remove any/all Floppy Drives from the VM’s hardware.

Now power back on the VM. While the VMs is powering back on, you can return to the VMware View Administrator, browse back to the Transfer server tab, highlight your transfer server and press the “Exit Maintenance Mode” button. The status of the transfer server will be “Pending” and once the transfer server is back online its status will change to “Ready”.

Now retry your Check Out operation and you should see something similar to the below, where the Check Out process proceeds as it did previously to 10%

View_LocalMode_InitializingCheckOutProcess6%

Where the check out previously failed, it should now proceed similar to the below example.

LocalModeCheckingOutPogress

After the Check out process has completed you should see the message “Log on to Local desktop” (as shown below).

LocalMode_LogOnToLocalDesktop

So what do we learn from this?

It is always a good idea to remove unnecessary devices from your VMs. 😉