One of the little known and infrequently used features of vSphere since version 4.1 is the ability to connect a USB device to an ESXi host and then mount that device to a VM, and still allow vMotion to work without any problems. This is usually used for USB dongles required for software licensing, but can be used with a number of other devices. More often these days the USB connectivity is being used from a VMware Horizon View client to connect a USB device to a desktop. But if you’re 9000 miles away from your desktop, and you’ve been asked to connect a console cable to a physical network switch in the same location and run some debug commands, how can you do that? Well I figured it out and it makes for a good story.

I’ve been having a few weird things go on in my network with my home lab and from time to time the engineers I’m working with on this problem have asked me to run debug commands, which can only be run via the console to the switch. Usually this is no drama as I’m sitting right next to the switch and I have my console cable handy. However this week I’m in Boston, MA, and my lab environment is in Auckland, New Zealand (282ms RTT). So connecting up the console cable presenting a bit of a problem from 9000 miles away. Especially when I usually connect the console into my laptop, and in this case I have it with me. At least my VMware Horizon View virtual desktop was usable, almost to the point of not noticing the distance at all, even when using graphics intensive applications.

I figured that if I could get the console cable connected to the switch, I could connect it to a USB port on the back of one of my Nutanix ESXi hosts using a RS232 Serial to USB converter. From there I should be able to connect the virtual serial port to one of my virtual desktops. My first problem was getting all this connected.

Fortunately my 7yr old son Sebastian is pretty clever and often watches me as I pull my systems apart and put them back together. So I decided I would call him on FaceTime and walk him through the process of connecting up the console cable to the switch, and then into the back of one of my ESXi hosts. This was relatively easy, and using the FaceTime call I was able to verify that it had connected properly. As a reward I’ve bought Sebastian a T-Shirt from Cheers in Boston. I’m sure in the future his rates will go up. When I’m not around the house Sebastian takes the role of home tech support.

Next challenge was to find out which host the USB device was connected into, and then to connect it into my VDI desktop. After a quick search I found that using the command lsusb would tell me what devices were connected into my hosts. To save a bit of time I used a for loop to check all my hosts for the devices as follows (only works on Nutanix from one of the CVM’s):

for i in `hostips`; do echo “Host: $i”; ssh root@$i “lsusb”; done

That was easy. Identified which host the USB device is connected to. Now the fun part. Getting it connected to my VDI desktop, while I’m running on the VDI desktop. This is actually very easy. To start with all I had to do was vMotion my VDI desktop (while I’m accessing it) over to the host with the device connected. After that it’s just a matter of installing a USB controller on my desktop (in this case Windows 8.1), which is a simple hot add operation. I had to use the EHCI controller as xHCI didn’t work for this particular device. Within a couple of seconds Windows had detected and installed the correct driver for the USB controller.

Next step, connect the USB device. This turned out to be a little harder. I connected the device and it popped up in Windows, but it couldn’t find the right device driver. After a bit of surfing around I found the right driver and got it installed. Wala, I had a new USB virtual serial port inside my Windows VDI desktop, and could not connect that into Putty to use to access the switch. All of this was done line, using hot add features of vSphere and Windows, and all while I was accessing and vMotioning around the desktop I was connected to. This is how it looked in the virtual machine configuration once I had it completed:

USB Device support is different across the different versions of vSphere and dependant on whether you want to connect a local device directly connected to the ESXi host or via a client, including a View desktop. More information on USB device connections to ESXi and what is supported can be found in VMware KB 1022290.

Final Word

I was successfully able to get onto the console of my switch via Putty using this USB virtual serial port, connected into my Windows 8.1 VDI desktop, via VMware Horizion View from Boston, MA, to Auckland, NZ over a distance of 9000 miles (26 hr flight with layover time included). All without leaving my hotel room. I could collect the data and upload it to the engineers that are working on the problem with me. All while online using the same virtual desktop, including vMotioning it around my hosts, and all without losing connection to the USB device. A big thanks to my 7yr old son Sebastian, as I would not have been able to do this without his help.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com. By Michael Webster +. Copyright © 2012 – 2014 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

Today Nutanix (@nutanix) delivered major hardware updates to it’s radically simple Google like infrastructure platform for the masses. The updates included integration with new GPU and Teradici APEX encoding offload cards for the most graphic intensive desktops, while at the same time providing increased VM density and lower TCO across a new range of hardware options. This announcement came just in time for the VMware Horizon View 5.3 GA release, which was also today. The new Nutanix 7110 platform breaks the final barrier to delivering all applications to all virtual desktop users and powers video and graphics-rich applications with workstation-level performance. This is all achieved while maintaing simplicity customers have come to know and love, and without losing any availability and manageability normally associated with dedicated hardware required for workstation class CAD/CAM and 3D desktops and other high end graphics use cases. The Nutanix 7110 platform and VMware Horizon View 5.3 are a powerful combination for All Virtual Desktops, but wait there’s more.

From the Nutanix Press Release – “The NX-7110 integrates NVIDIA GRID and Teradici PCoIP technologies enabling users to work with the same graphics applications that they use every day, but via a desktop that is delivered virtually. Combining NVIDIA’s GRID and the Teradici PCoIP Hardware Accelerator solutions with the scalability and performance of Nutanix’s virtual computing technology enables enterprises to tackle virtual desktop deployments of unprecedented size and scope.” Full Nutanix Press Release.

When combined with VMware View 5.3 and leveraging the new virtual Shared Graphics Acceleration (vSGA) feature (and vSphere 5.5) high performance graphics intensive workloads are no longer tied to a physical server and can migrate freely while still achieving their requirements for GPU intensive tasks. For workloads that need passthrough (and don’t require vMotion) virtual Dedicated Graphics Acceleration (vDGA) is now fully supported. This greatly improves the manageability, maintainability and availability of your organizations critical desktop infrastructure. Importantly existing Nutanix environments can dynamically deploy NX-7110 appliances into a unified cluster that is centrally managed, while maintaining graphics intensive users in a separate desktop pool. With View 5.3’s full support for the View Composer API for Array Integration (VCAI), which was previously a tech preview, deploying and recomposing desktops gets even faster.

In addition to the features of VMware Horizon View 5.3 mentioned above the release adds support for Windows 2008 R2 to be used as a desktop, which is described in KB 2057605, and Windows 8.1. Windows 2008 R2 is a great option if you are a service provider and want to offer desktop as a service to end users in a multi-tenanted environment, primarily because it gets arounds restrictions in the Microsoft SPLA licensing. Full VMware Horizon View 5.3 Release Notes.

Not only did Nutanix release a great distributed Google like infrastructure platform for graphics intensive workloads they also launched updates to the NX-3000 and NX-6000 series of systems that boosts VM density and enhances performance.  The new platforms now include Intel Ivy-bridge processors, more cores, higher clock speed options, more RAM and more importantly higher VM density in the same amount of space and power footprint. Further information about the launch including links to solutions briefs and white papers can be found here.

Final Word

Virtualized GPU’s are not just the realm of high performance graphics intensive virtual desktops, they are also greatly beneficial and supported for use with Linux Guest VM’s as of vSphere 5.5. This should not be confused with Linux Virtual Desktops, which are not supported, but HPC server workloads. This opens up some incredibly good use cases for high performance computing (HPC) clusters, that can benefit from GPU’s to assist with embarrassingly parallel operations.  So not only is the NX-7110 platform a great virtual desktop platform, because of the unique mix of high performance compute, graphics power and local storage access combined with a distributed architecture, availability and simplicity it could also be a great platform for large scale HPC environments for research facilities, institutions and universities. Just like the one I wrote about in my article Virtual Beats Physical for HPC Monte-Carlo Grid Performance. I bet you hadn’t considered that. As always your feedback and comments are welcome.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

I was upgrading my VMware View environment recently from 5.0 to 5.1 and wrote about some initial problems in my article Trouble Recomposing View 5.x Desktops After Upgrade to vSphere 5.0 U2. After I had resolved those initial problems I needed to load my internal Root CA certificate onto all my company’s iPhone’s and iPad’s. This is because one of the big changes or improvements in View 5.1 is with security and you now need trusted certificates in order to connect to any of the desktops. Fortunately there is no need to purchase expensive public certificates if you have an internal corporate PKI / CA’s already configured, unless you want to. This article will show you how you can easily get your iPhones or iPad’s to trust your corporate CA certificates for use with VMware View.

I’ve included images here to explain the process as I think it’s easier to follow. I used one of my iPhones to keep the images reasonably small. To be honest you’re much more likely to be doing this on an iPad. But iPhones are perfectly usable in my opinion provided  you have the iPhone to VGA adapters and a Bluetooth Keyboard.

Trying to Connect Without Trusting the Certificate

If you try to connect to a VMware View 5.1 environment using the iOS View Client without first trusting the CA certificate you will receive a message as per the image below:

If you click on View Certificate you will see some details about the untrusted certificate:

There is no way to set your device to trust your CA certificate from this screen. In order for you to get your iPhone or iPad to trust the certificate you will need to follow the process below.

Getting Your iPhone or iPad to Trust Your CA Certificate

1. Obtain a copy of the CA Certs (Root CA and Intermediate CA if used) and email them to your device, such as in the following image:

You’ll notice the attachment in the image above shows a certificate type icon.

2. You now need to tap on the attachment. You will be presented with the following screen:

At this point before continuing  to the next step you should click on More Details. You should verify that it is indeed the certificate that you were expecting, it’s form your corporate CA, and that it is valid and should be trusted. Once you are satisfied this is indeed a legitimate certificate that you should trust you continue.

3. Tap Install.  You will see the following warning image displayed on the screen:

Because your corporate CA is not a trusted public CA it is not automatically in the trusted list for your devices. This is the reason this warning is being displayed. Provided you are happy with the checks you’ve done in the previous step, after reading this warning you can continue to the next step.

4. Tap Install. You will see the following image displayed on screen:

At this point you need to enter your passcode so that the certificate can be loaded into your devices trust store and be trusted. Once you have entered your passcode successfully you will automatically be at the next step.

5. You have successfully loaded your corporate CA certificate into your devices trust store. You will see the following image displayed on the screen:

Now when you connect using the VMware View Client your Connection Servers certificates, which were signed by your corporate CA, will be trusted and your connections will be successful. If you have  more than one CA that needs to be trusted you need to complete these steps for each of the certificates. You can now Tap Done and go back to the VMware View Client and test the connections.

6. Now when connecting to your VMware View Connection Servers or Security Servers an image similar to the following will be displayed on screen:

You can see by the tick on the padlock and the text https being displayed in green that the certificate and connection are trusted. If the connections weren’t trusted you wouldn’t have been able to connect. Enter your username and password and then tap done or go.

7. You will receive the list of entitled desktops similar to the image below and you can no proceed to use your desktops as per normal. This process is complete!

Removing a Certificate From Your iPhone or iPad Trust Store 

If for some reason you find out that a certificate has become invalid or has been revoked you will need to remove it from the trust store on your iDevice. To do this is very simple.

1. Tap Settings.

2. Tap General. You will see on the screen something similar to the following:

You can see the profile listed and the name of the CA in this example.

3. Tap Profile. You will see on the screen something similar to the following:

4. Tap  Remove. You will see a warning displayed similar to the following:

5. Tap Remove. You will see the passcode dialog box displayed as per the image below.

6. Enter your passcode. You will be returned to the settings screen and you’ll notice as per the image below that the profile has now gone.

You have now completely removed the certificate from your devices trust store. When the new certificates are issued you can go back and follow the process to install them again.

Final Word

As you would expect Apple has made it fairly painless to get this all working. However when it comes to security and trusting certificates great care needs to be taken. You must verify that the certificates that are being sent to you for use are genuine and can be trusted. If for some reason the certificates expire, are revoked or for some other reason invalidated then you need to follow the process to remove the certificates from the trust store and then install the new ones. I hope this has been helpful and that you get hours of productivity out of your VMware View 5.1 vDesktops from your favourite iDevices.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2013 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

I’ve finally gotten around to upgrading my View environment from 5.0 to 5.1.2. Just before I attempted the upgrade I also applied the latest patches to all my hosts taking them up to vSphere 5.0 U2. This is where some fun started, but fortunately to avoid some of this fun the solution is very easy.

Before I embarked on my upgrade to View 5.1.x I updated my SSL Certificates to use CA Signed Certificates. I found it easy enough updating the certs on View 5.0 prior to the upgrade (made the upgrade smooth). When I went through and updated the SSL Certs on View 5.0 with my CA Certs I followed the instructions in KB 1008705. A couple of tips:

1. The line mentioned in there “keytool -importcert -keystore <keys.jks> -storepass <secret> -keyalg “RSA” -trustcacerts –file <certificate.p7>” should read “keytool -import -keystore <keys.jks> -storepass <secret> -keyalg “RSA” -trustcacerts –file <certificate.p7>”
2. You need to make sure you get the full PKCS7 Cert Chain from your CA if using jks keystores. From a Microsoft CA you would select to download the certificate chain.

When it comes to the computer running View Composer you can use the request new certificate workflow as described by Derek Seamen in his blog article VMware View 5.1 Installation Part 1 – View Connection Server. The process he uses to use SSL Certs is very easy and is also a good option for Connection Servers.

After upgrading to View 5.1.2 when I went to test View Composer and deployed a new desktop pool from one of the Win7 Parent VM’s. I found I was unable to access any of the vDesktops. All of the NIC’s were showing as connected in vCenter, but inside the Guest OS the VMXNET3 driver was showing as not working correctly in device manager. Upon uninstalling the driver through device manager and detecting hardware changes the NIC would start working. This wasn’t going to be a workable solution though manually updating every vDesktop that I deployed.

Fortunately the solution was easy. I simply had to update VMware Tools inside the Parent VM, take a new snapshot and then recompose the desktops in my test pool. This proved not only my new View 5.1.2 environment and View Composer (on a standalone host) was working, but that also the problem was related to View 5.1.2 not wanting to work with the old version of VMware Tools on a newly upgraded vSphere 5.0 U2 host with the previous version of Tools. After upgrading my hosts to vSphere 5.0 U2 I had not updated VMware Tools in all of my View Parent VM’s.

Based on this experience my advice would be to always update VMware Tools in the Parent VM’s prior to a recompose operation after your vSphere Hosts have been updated to a new version. Even though older versions of VMware Tools are supported on newer versions of vSphere sometimes weird things like this happen. Just as well I was testing this in an isolated test pool in my lab prior to recomposing any of my other desktop pools. This shows the importance of testing any changes in your View environments or vSphere environments, even if they seem like a small change.

My only remaining problem is that no matter what I try I can’t get Thin Print installed in the Parent VM. Regardless if I try and install it using VMware Tools or via the View 5.1.2 Agent. The installer always freezes and never continues when it comes to the point where it’s trying to install the Thin Print driver. So I still have some more troubleshooting ahead of me. But at least the critical components are working.

—

This post first appeared on the Long White Virtual Clouds blog at longwhiteclouds.com, by Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.

In order to access my lab environment I have configured a VMware View Infrastructure. I use two connection brokers. One for internal clients, and one for external clients, which goes via a View Security Server originally on 4.6, now 5.0 with PCoIP enabled. This would be completely normal and easy to operate if I had a static IP address. But alas I don’t.

In order to work around this I borrowed a script from a great blog and modified it for my purposes. Below is the script I use to update the external IP address / URL of my View Security Server every time my IP address changes. The great thing about this script is that it works with multiple View connection or security servers in the environment. Enjoy!

I got the original script at Gabes Virtual World – Enabling VMware View 4.6 PCoIP with dynamic IP address and then modified it to work with multiple View connection servers. The key section that I modified below is in red. Before this modification if you called the script and had multiple connection brokers in your environment it would fail. A big thanks to Gabe for originally authoring the script. Without it access to my lab would be very difficult indeed. This may help smaller companies who don’t want to go to the expense of having static ip address space access their remote View environments. The PowerShell script requires the View snap-in’s and should be run from the internal connection broker, not the security server. Make sure you have the correct firewall rules in place for the ports that View 4.6 and above requires. The script works with View 4.6 and above, so includes View 5.0, which I’m now using in my lab.

Add-PSSnapin VMware.VimAutomation.Core
Add-PSSnapin VMware.View.Broker
# Name of the Security Server
$SecurityServer = “VIEWSECSRV”
# For logging creating a timestamp
$TimeStamp = Get-Date -format yyyy-MM-dd-H-mm
# Filling $CheckedIP with the external IP address, using whatismyip.com service
$wc = New-Object net.WebClient
$CheckedIP = $wc.downloadstring(“http://automation.whatismyip.com/n09230945.asp”) # This can be any simple ip display page
# Now check the current ExternalPCoIPURL entry
$CurrentSettings = Get-ConnectionBroker
ForEach ($ConnectionBroker in $CurrentSettings){
if ($ConnectionBroker.broker_id -eq $SecurityServer) {
$CurrentIP = $ConnectionBroker.externalPCoIPURL
}
}
# Check if $CurrentIP starts with the IP address from $CheckedIP
# Used StartsWith because $CurrentIP has port address at the end
$Result = $CurrentIP.StartsWith($CheckedIP)
# Are IP address the same?
If ($Result)
{
# Yes, both IP addresses are the same, do nothing, only write a log entry
$row = $TimeStamp + “,” + $CheckedIP + “,” + $CurrentIP + “,nochange”
}
else
{
# External IP is not equal to IP set in externalPCoIPURL
# Changing the externalPCoIPURL
Update-ConnectionBroker -broker_id “VIEWSECSRV” -externalPCoIPURL $CheckedIP
# Check if it was succesful
$NewSettings = Get-ConnectionBroker
$row = $TimeStamp + “,” + $CheckedIP + “,” + $CurrentIP + “,” + $NewSettings.externalPCoIPURL
}
$row | Out-File -FilePath “C:\scripts\check-ip.log” -Append

The above script first appeared on Gabe’s Virtual World at http://www.gabesvirtualworld.com prior to my modifications to the script. 

This Post By Michael Webster +. Copyright © 2012 – IT Solutions 2000 Ltd and Michael Webster +. All rights reserved. Not to be reproduced for commercial purposes without written permission.