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. 😉

A Present from VMware

Recently the number of VMware Certified Design eXperts (VCDXs) passed the 100 mark and to celebrate the wonderful VMware Education team decided to treat all VCDX’s.

Below are some photo’s of what I received late december which included

* A 6 pack of VCDX branded “Special Ale”
* A VCDX branded cooler bag
* Two VCDX Glasses
* A VCDX Sweater custom embroidered with my VCDX Number (#90)
* A VCDX polo shirt
* A HD Camcorder engraved with my VCDX number
* A Leeman Binder with my initials (see picture at bottom of this post)

and my favorite, a Vase with the VCDX logo along with my name and VCDX number on the base.

So just wanted to give a big Thank You to Mark Brunstad (@MarkBrunstad) and the VMware Education team for putting together this package for the VCDXs, I personally greatly appreciate it and you can rest assured the “special ale” did not see out 2012 🙂

How much CPU ready is OK?

I have noticed a lot of search results hitting my blog asking

Question: How much CPU ready is OK?

so I thought I would address this question with a quick post.

Of course the answer is it depends, for example Server workloads have a lower tolerance to CPU ready than desktop workloads but as a rule of thumb, here is my thoughts.

For Production server workloads

<2.5% CPU Ready
Generally No Problem!

2.5%-5% CPU Ready
Minimal contention that should be monitored during peak times

5%-10% CPU Ready
Significant Contention that should be investigated & addressed

>10% CPU Ready
Serious Contention to be investigated & addressed ASAP!

In my experience, the above have been good for a rule of thumb.

However, applications which are latency sensitive may be severely impacted even with low levels of CPU ready, these types of VMs should be on clusters with lower CPU overcommitment, leverage DRS rules to separate the contending workloads or in extreme cases, dedicated clusters.

On the flip side, Some servers are much more tolerant to CPU ready, and 5%-10% CPU ready or higher may not noticeably impact performance.

Keep in mind that setting CPU Reservations does not solve CPU Ready, see my post on the topic for more details.

VMware vCenter Operations is a tool which can help easily identify contention (including CPU) within your vSphere environment.

For Virtual Desktop workloads, what level of CPU ready is acceptable will largely depend on the individual user (ie: Power User verses Task Worker). Keep in mind virtual desktop deployments generally have high CPU consolidation ratios of  around 6:1 all the way to >12:1.

I would suggest the following , again as a rule of thumb

<5% CPU Ready
Generally No Problem!

5%-10% CPU Ready
Minimal contention that should be monitored during peak times

>10% CPU Ready
Contention to be investigated & addressed where the end user experience is being impacted.

Any Higher CPU ready will likely be impacting your users, and should be investigated.

VMware have recently released vCenter Operations for View, which you could use to monitor your VMware View environment.