Slow View Event Database

After upgrading my environment from View 5.3.2 to Horizon View 6.0.1, I started having the following issues once production loads returned to normal:

• The Event database performance in VMware View 6.0.x is extremely slow when browsing within View
• High CPU usage on the SQL server, hosting the Event database
• The larger the Event database becomes, the slower the queries run.

This is discussed in VMware KnowledgeBase article – The Event database performance in VMware View 6.0.x is extremely slow (2094580)

To resolve this issue, you have to create an index.  Run the following command on your SQL Event database:

CREATE INDEX IX_eventid ON dbo.VDIevent_data (eventid)

Substitute VDIevent_data for the table name using your Event database prefix.  In my case it was VDI_event_data so I ran:

CREATE INDEX IX_eventid ON dbo.VDI_event_data (eventid)

So now recent Events load in View Administrator in seconds instead of minutes.

VSAN 5.5 - Verifying jumbo frames

I've been working on a Virtual SAN 5.5 POC (for various reasons, the environment is still on vSphere 5.5u2) and came across an issue following the guide provided by VMware:

Tips for a Successful Virtual SAN 5.5 Evaluation

It states on page 9 to use vmkping -S 9000 to test connectivity between hosts using jumbo frames.

There is where I hit a wall....  I kept getting the following error message:

~ # vmkping -S 9000 192.168.100.14
*** vmkernel stack not configured ***

I kept racking my brain, checking my configuration, making sure that MTU 9000 was set on the distributed switch and also on the VSAN VMkernel, and that my network switches were set to support jumbo frames on both the physical ports and on my VSAN VLAN (I use VLAN 1001 since VLAN 1000 is my vMotion network).  Then I came across the following post:

http://rickardnobel.se/troubleshoot-jumbo-frames-with-vmkping/

Even though that is an old post from well before VSAN existed, it is still entirely relevant.  Now armed with the correct formatting of the command:

~ # vmkping -I vmk2 -s 8972 -d 192.168.100.14

PING 192.168.100.14 (192.168.100.14): 8972 data bytes

8980 bytes from 192.168.100.14: icmp_seq=0 ttl=64 time=0.176 ms

8980 bytes from 192.168.100.14: icmp_seq=1 ttl=64 time=0.159 ms

8980 bytes from 192.168.100.14: icmp_seq=2 ttl=64 time=0.157 ms

--- 192.168.100.14 ping statistics ---

3 packets transmitted, 3 packets received, 0% packet loss

round-trip min/avg/max = 0.157/0.164/0.176 ms

Eureka!  (also vmk2 is my VSAN VMkernel interface and adding "-I vmk2" specifies what interface to force the ping to travel over)

VSAN 5.5 - The case of the missing new disks

I'm setting up a VMware VSAN 5.5 POC (can't upgrade to 6.0 yet for various other reasons) and even though each Dell R730 host had 16 drives, only around 10 of them were showing up in the vSphere Webclient to be claimed as a VSAN disk.

The R730's shipped from Dell with the drives setup in a RAID cluster and even though I had deleted the cluster and changed the controller to pass-thru operation, something must've still been present on some of the drives and the existence of any remnants of data on a drive seems to result in the disk not showing up on the VSAN configuration page:

However the drives were present if I would try to make a traditional datastore out of one of them:

So how to solve this?

You can wipe the disks straight from the ESXi console....

1.) First take note of the naa ID of the disks in question, then console into the host.

2.) Then use the "fdisk" command to do the following:

fdisk /dev/disks/naa.XXXXXXXXXXXXX

where XXXXXXXXXXXXX would be the rest of the naa ID.

3.) Ignore the "fdisk command is depreciated" message.

then you'll be prompted for a command

4.) Type o and press enter.  This command states that you want to create a new empty partition table on the drive, but nothing is actually committed to the drive yet.

5.) Type w and press enter.  This writes the change to the drive.

Here is a screenshot showing the above process:

Repeat this for all the drives in question.  Rescan the disk controller and the drives should appear available to add to VSAN in the vSphere Webclient:

A quick review of the LG CBV42-B zero client

As I mentioned in a previous post, all Tera2 equipped zero clients are essentially the same since they are based around the same Teradici chipset, but there are some slight differences in every OEM manufacturer's units, whether it be in the case design, or availability of ports.  The following are some of my thoughts on the LG CBV42-B zero client:

Significant Pros:

• VESA mount is included.
• Has 6 USB ports (2 on the front, 4 on the back) where the norm for zero clients tends to be 4.
• Somewhat cheaper pricing than most equivalent zero clients (usually less than $250/ea street pricing)

Potential Cons:

• The only audio out jack is the headphone jack on the front. Makes for slightly messy cable management if you use a monitor with speakers or external amplified speakers and the zero client is on the desk.  However, this isn't really a factor if when I use these in student computer labs where they have to use headphones for audio anyways.
• The build quality seems to be on the cheaper/lower end.  In the roughly 100 I've purchased, I've had one dud out of the box that wouldn't power up (but replaced quickly by LG under warranty), and I've had to resnap the plastic housing (usually just a corner) on a few where they seem to have not been completely snapped together in production or they might have been jostled too much in shipping.  I haven't had any failures once they were placed into service out in the field though.

Some other thoughts:

• Doesn't include a USB keyboard and mouse, I buy inexpensive Logitech MK120 kits to go with them.
• Has a security cable slot towards one edge near the back of the housing.
• Two DVI ports for monitors, so no need for a DisplayPort adapter if you are hooking up two monitors with DVI connectors.

Not killer features, but still nice touches:

• LED on power switch is red, not really a functional benefit, but does give it a cool HAL 9000 like glow in a dimly lit or dark room.  :)
• The headphone and mic jacks are color coded.

Because of it's inexpensive pricing, the CBV42-B is my current preferred zero client for use in classroom computer labs.  When buying in larger quantities, the $20-$75 saved over other manufacturer's Teradici equipped zeros can quickly add up.

10ZiG first to offer Tera1 zero client upgrade/buyback program

In a follow up to my previous post, thin and zero client manufacturer 10ZiG is now offering Buyback incentives for all Teradici-based Tera1 zero clients (regardless of brand) towards new 10ZiG Tera2 PCoIP Zero Clients.

More info can be found at the following links:

http://www.pages03.net/10zig/terra1/

http://links.mail3.spopessentials3.com/servlet/MailView?ms=MjI2MDMxMjcS1&r=MTEwODA2NzY2MTIyS0&j=NTYwNTQxMDk1S0&mt=1&rt=0

More Horizon 6.1 endpoint bad news... now Tera1 zero clients not supported

I stumbled upon this KB today and noticed that Tera1 zero clients will no longer be supported with any Horizon release after 6.0.1.  As someone with a lot of of Tera1 devices that aren't all that old (it's been what, only 2-3 years since Tera1 zeros were being actively sold by vendors?) and still running great, as expected with something as stable as a zero client, I'm even more disappointed to see this than I was by the end of Windows XP and Vista client support (rant is in my previous post).

I could maybe understand it if they've been off the market for 5+ years (since a lot of traditional corporate PC replacement cycles are around 5 years).  VMware must be making some architectural changes with Horizon 6.1 breaking compatibility or something...not expected for a point release (it's not like this is Horizon 7.0 or anything).  I hope Teradici manages a "best effort" approach to keep the Tera1's going for some time even if they can't be "officially" supported.  

To run Horizon 6.1 (we're currently on 5.3 and now planning on going to 6.0.1 this summer) my organization would have to come up with well over $100,000 in funds, not to mention the manpower to do a forklift upgrade, to replace all the thin clients and Tera1 zeros just to be able run 6.1 in a supported setup.  This kind of unexpected expense might just make me rethink keeping my Horizon licensing and production support contracts current going forward and maybe give me reason to give Citrix a call if I now have to replace a lot of hardware.... are you listening VMware?  I haven't administered XenDesktop since the 4.0 days but I'm sure they haven't been sitting still either, and I do note that Citrix specifies "Support for Windows XP ends April 8, 2014 when Microsoft ends extended support for Windows XP. Support for Windows XP Embedded will continue." for Citrix Reciever on its download site.

New Horizon Client 3.3 ends support for Windows XP

I’m sorry to see that starting with version 3.3, the Horizon Client no longer supports Windows XP and support for the older version 3.2 client has only been promised through the remainder of 2015.  I'm sure that a lot of existing customers have older Windows Embedded 2009 (still based on XP) thin clients that run an OS still supported by Microsoft through January 8, 2019.  One of the major reasons to go to Horizon based VDI is to save on endpoint replacement costs and to extend the replacement lifecycle.  Replacing hundreds (or thousands for larger organizations) of these thin clients with ones running newer versions of Windows Embedded or with Teradici based zero clients can be cost prohibative. If a core thin client OS is still supported by Microsoft, as a customer, I would expect VMware to at least provide a client to support it.

Unless VMware has a change of heart, later this year I'll be investigating solutions like Stratodesk, Wyse PC Extender, and Devon VDI Blaster that can essentially replace Windows Embedded (or XP) with a centrally managable version of Linux that runs the Horizon Client.  However I'll have to do some testing to make sure performance is similar and that options like USB flash drive support and location based printing still functions as it does with a thin client running Windows Embedded.  All of these products have a cost, but they are significantly cheaper than purchasing a new thin or zero client if it extends the usable life of them in a Horizon VDI environment for several more years.

A quick review of the HP t310 zero client

For over two years now, I've exclusively purchased Teradici based zero clients for use in my employer's VMware Horizon View environment because of their ease of management and excellent performance, particularly with full screen video.  I've evaluated a lot of demo units, and usually buy by price (since all Tera 2 chipset zeros essentially perform the same) unless one has a specific feature that I'm looking for in an application.

The following are some of my thoughts on the HP t310 zero client:

Significant Pros: 

- Audio out jack on the back, headphone jack on the front.  Makes for a clean desktop install if you use a monitor with speakers or external amplified speakers.

Potential Cons:

- VESA mount if needed is a pricey extra cost option ($25+).
- Somewhat more expensive than a lot of newer competitors ($359.00 list price....usually around $325 street pricing)

Some other thoughts:

- Could maybe use more rear USB ports.  A lot of competitor's products now have 6 USB ports.
- Includes a USB keyboard and mouse, which take up the rear 2 USB ports.
- Has a security cable slot on back of housing.
- Two DVI ports for monitors, so no need for a DisplayPort adapter if you are hooking up two monitors with DVI connectors.

Not killer features, but still nice touches:

- LED on power switch is green when unit is powered on, amber when it's off but still connected to a power source (might be handy to quickly see if the unit's power cord is unplugged).
- Has a separate LED near the power switch that shows if the zero is currently connected to an active session.
- The headphone and mic jacks are color coded.

In a nutshell, the t310 is my preferred zero client for staff use (when I can get them competitively priced) primarily for the "Pro" I listed above.  Being able to hook up external speakers via the rear audio jack without taking up the headphone jack on the front just makes for a clean desktop install without anyone having to unplug/plug any wires for headphone use and vice versa.  The less my users have to mess with any wires causing potential issues the better in my opinion.  A lot of my staff users also prefer dual monitor setups and I personally prefer using 2 DVI jacks (like the t310 has) over finding a second monitor with a DisplayPort input or using an adapter dongle that adds another potential issue area.

Installing the Horizon View 3.2.0 Client on Ubuntu 14.04 LTS 64 bit

It was quite a process to get the new Horizon View 3.2.0 Client working on my Chromebook running Ubuntu 14.04 LTS 64 bit via Crouton.

Previously I had the View Client 2.2.0 installed using the Synaptic Package Manager which was a relatively easy click on the downloaded file (vmware-view-client_2.2.0-0ubuntu0.14.04_i386.deb) and install.

The Horizon View 3.2.0 Linux client is currently only available from VMware in a generic .bundle format package available at: https://download3.vmware.com/software/view/viewclients/CART14Q4/VMware-Horizon-Client-3.2.0-2331566.x86.bundle

Also, the new Linux client is 32-bit only which makes life harder for those running a 64-bit Linux OS.  With today's amounts of cheap RAM, who installs 32 bit anymore??  But at least VMware has finally posted an up to date generic client for Linux on their website, so that's progress.

I installed the .bundle package by using the following terminal commands in the directory the package was downloaded to:

sudo chmod +x VMware-Horizon-Client-3.2.0-2331566.x86.bundle
sudo ./VMware-Horizon-Client-3.2.0-2331566.x86.bundle

Note: for me it seems that having the 2.2.0 client installed was a necessary step (it must install some prerequisites) because the 3.2.0 installer wouldn't launch on another one of my 64 bit Ubuntu test machines unless the 2.2.0 client was already installed.

I checked the options to install everything in the wizard except for Smart Card, and at the end of the installation you are able to scan for any missing dependencies. Turns out that there is quite a few when you are running 64 bit.  Not only would the new client not launch, it broke my previous 2.2.0 client install as well.

So after a lot of trial and error and Googling, I found that the following finally worked:

Run the following commands using root or sudo:
dpkg --add-architecture i386
apt-get update
apt-get install libudev1:i386
apt-get install libtheora0:i386
apt-get install libssl1.0.0:i386
apt-get install libXss1:i386
apt-get install libpulse0:i386
apt-get install libv4l-0:i386
apt-get install libudev1:i386
apt-get install libxml2:i386
apt-get install libXtst6:i386
apt-get install libpcsclite1:i386
apt-get install libuuid1:i386
apt-get install libspeex1:i386
ln -s /lib/i386-linux-gnu/libudev.so.1 /lib/i386-linux-gnu/libudev.so.0
ln -s /lib/i386-linux-gnu/libssl.so.1.0.0 /lib/i386-linux-gnu/libssl.so.1.0.1
ln -s /lib/i386-linux-gnu/libcrypto.so.1.0.0 /lib/i386-linux-gnu/libcrypto.so.1.0.1

After this, clicking on scan in the installer reported no errors, and I was able to start the Horizon Client by running the command vmware-view from the command line.  After launch, you can then lock the icon to the Launcher for future use.

I did get one error when starting the client, that the ssl lib was old (version 1.0.1f), but according to Ubuntu it is up to date and patched, so I'm not sure why the Horizon Client is looking for version 1.0.0i.  You can dismiss the error message and make it so it's not shown again.

I'm not sure that all features work completely even with all the pre-requisites installed. For instance, I'm guessing that USB redirection doesn't work, because I don't see an option in any of the menus to connect a USB device.

Hopefully this saves someone a lot of head scratching to get the 3.2.0 client installed on Ubuntu, and I wish VMware would have done most of this work for us by making it available in a .deb package like the 2.2.0 release.