VMware View 3.1.1 Released

Just a quick bug-fix release, View 3.1.1 fixes the following issues. From the Release Notes:

View Administrator

• When using View Web Portal to launch a virtual desktop with a user, the User field in the View Administrator Console does not display the name of the desktop user although the desktop is assigned to the user persistently.
  This issue is resolved in this release.
• The list of desktop pools in the left-hand pane of the Web Administrator window’s Inventory tab is sometimes not populated. This issue prevents the administrators from managing the desktops.
  This issue is resolved in this release.

View Client

View Clients might unexpectedly disconnect from the desktops when tunneled (KB 1012388)

Miscellaneous

When you perform some functions on a virtual desktop that is running View agent and certain third-party GINAs that do not completely support WLX version 1.4, the guest operating system fails and displays a blue screen. This issue is resolved in this release.

You can download it here. Note that there is no new View Composer version.

Using the HP t5545 Thin Client with VMware View

This is my first in a series of articles outlining how to setup various Thin Clients with VMware View.

One of my favorite thin clients as of late is the HP t5545. It’s a very inexpensive thin client with a lot of great features – local web browser, full VMware View support, Multimedia redirection, USB redirection, and more. Up until recently, however, getting all that to work was a bit of a challenge.

Using HP RGS with VMware View 3.1

So as I’m sure many people are aware, VMware will be shipping a protocol in the near future (with View 4, most likely) called PC-over-IP. In the meantime, however, VMware View 3.1 has included support for HP Remote Graphics Software, which provides a similar experience today (albeit not for free). VMware hasn’t come out with tiering or pricing for View 4 yet, and since customers today may require this kind of functionality, I think it’s wise for people to test out how well it works.

First, a disclaimer. In the release notes for View 3.1, VMware states the following policy:

View Client can now use HP Remote Graphics Software (RGS) as the display protocol when connecting to HP Blade PCs, HP Workstations, and HP Blade Workstations. The connection is brokered by View Manager. HP RGS is a display protocol from HP that allows a user to access the desktop of a remote computer over a standard network. VMware View 3.1 supports HP RGS Version 5.2.5. VMware does not bundle or license HP RGS with View 3.1. Please contact HP to license a copy of HP RGS software version 5.2.5 to use with View 3.1. This release does not support HP RGS connections to virtual machines.

So be aware that VMware does not support running RGS Senders in Virtual Machines. That said, HP does support it, and the plan was prior to View 3.1’s launch to have this fully supported by both parties. From what I heard, issues at the last minute caused them to push this off. As a result, if you try to create a pool using VirtualCenter VMs (i.e. an Individual Desktop with VirtualCenter VM selected, any kind of Automated Desktop Pool, or a Manual Desktop Pool with VirtualCenter VM selected) RGS does not show as an available default protocol.

A Plea to VMware: Please add a timezone setting to ESXi

So as ESXi 4.0 is becoming the new standard in our lab, we’re running into little annoyances here and there. The first of which is something that’s been a problem since ESXi was still called “ESX 3i” – ESXi has no ability to set a timezone. On the face of it, this doesn’t seem too critical, but this has a big impact on some environments.

First, we need to cover some background. Back in 1979 when MS-DOS was first shipped, no one could envision it being involved in a giant network of computers across different time zones, so it stored the hardware clock as local time. When Windows was released, it piggybacked off DOS for timekeeping. When Windows NT came out, they decided since people would be dual-booting between 16-bit Windows and NT, they needed to keep the same convention (having the hardware clock set to local time). When 2000 came out, because people might dual-boot….. ad-naseum. Windows 7 is coming out and still stores the hardware clock as local time. Almost all modern Unix-like operating systems store the hardware clock in universal time (UTC). This includes ESX server (and, by extension, ESXi).

Now, in ESX Server Classic, one of the options during the setup process is to assign the server a timezone. This is important because the UTC of the server + the TimeZone offset will be presented as the hardware clock to Guest Operating Systems which expect a hardware UTC clock (like Windows).

ESXi has no ability to assign it a timezone. This means that when you start up Windows systems, their clock is wrong (it’s UTC). You also can no longer rely on VMware Tools to perform timesync with the host OS, you must use NTP or some other method of time keeping. Obviously, in lab, test, and development environments this can be less than desirable.

Is there any way around this? Can Windows be forced to use UTC? Yes and no. There is a registry setting called “RealTimeIsUniversal” that supposedly helps, but it is buggy and doesn’t work properly in several instances in all current shipping versions of Windows. Supposedly, this will be fixed in Windows 7/Server 2008 R2, however this promise has been made before, and it doesn’t appear very high on Microsoft’s to-do list.

This is not an unusual problem for people. VMware – why can’t we set a TimeZone in ESXi, and then present this modified clock to “legacy” operating systems?

VMware comes out and says it: ESXi is the future

Most of us have known that VMware has been planning to move toward an all-thin hypervisor portfolio in the future, but they had been reluctant to come out and say it publicly. I had heard way back in the ESX3.5 days that ESX4 would be the last major version to ship with a “Classic” version that had a Service Console. But it was tough to get any kind of real confirmation of that out in the open.

Last week, the ESXi team blog seemed to make it pretty definitive:

In the future, ESXi’s superior architecture will be the exclusive focus of VMware’s development efforts. (emphasis mine)

This is all the more reason to move towards ESXi if you can during your vSphere upgrades. If you’re an HP customer, by the way, there is now an updated ESXi version with the HP CIM providers preinstalled. Or you can install them on an existing ESXi system using this.

Why you may want to leave FT alone for now…

Today, FT has a LOT of caveats. Aside from the obvious one everyone’s talking about (the limitation to 1 CPU VMs), there’s some other ones that I think are much worse (especially if you have newer CPUs) because they don’t just affect one VM, but the whole host. Here’s a few examples:

• Power Management must be turned off in the BIOS on the ESX Host. This is a big bummer, considering ESX4 just started supporting low-power state CPU features like SpeedStep.
• Hyper-Threading must be turned off on the host. If you’ve got a new Xeon 5500 processor, this is a bummer as well.
• Turning on FT disabled EPT/RVI for the ENTIRE host. This means one of the biggest performance enhancements (vMMU support) is gone for your whole host when you turn on FT for a single VM! UPDATE: This only disables FT for the single VM, not all VMs.

And as for VM-specific limitations (meaning these at least only affect the FT VM):

• No Virtual SMP
• No Snapshots (meaning no Storage VMotion, no VCB)
• No Hot-Add hardware
• No NPIV
• No DRS
• No Thin Provisioning

I think FT is a really cool piece of engineering, but today it’s pretty obvious that’s a version 1.0 (or worse, version 0.9) product. It works, but there are more gotchas than in any other VMware feature I’ve ever seen.

Lies, damn lies, and ROI models

Anyone who is looking at comparing different Hypervisor platforms is certainly trying to figure out which one will give the better Return On Investment. The challenge is, everybody’s ROI model is different, and will generally favor their own product. But when a company starts using their ROI model to compare their product vs. someone else’s, it’s not hard to guess whose product will win. But in some cases, it can be a truly egregious effort. Example: Microsoft’s latest ROI calculator for Hyper-V vs. VMware. I suggest everyone check out Steve Kaplan’s excellent analysis in his latest blog post.

Really, MS? $4100 per ESX host for “Backup Software” vs. $0 for Hyper-V? What, is Hyper-V so reliable that you don’t need backups or something? You know what’s a cool backup software? VMware Data Recovery, which I’m sure you know is included in ESX Advanced, Enterprise, and Enterprise Plus. And why does ESX server require CALs, but Hyper-V doesn’t?

Remmeber: there are lies, damn lies, and ROI models.

Project Virtual Reality Check updated – RVI!

As I noted way back when version 1.0 of Project VRC was posted, MMU virtualization technologies like AMD’s RVI and Intel’s EPT can have significant performance improvements in Terminal Sever (and VDI) workloads. It appears that in the original Project VRC tests, RVI was not used. Thankfully, the Project VRC team has updated their ESX White Paper with new results where RVI is enabled. Like I suspected, performance improved dramatically for Terminal Services VMs, so much so that even in Login Consultant’s independant testing, ESX Server 3.5 is now within 10% of the results from XenServer 5 (with XenApp optimizations turned on). I would suspect that when using ESX4.0’s performance improvements, the competition will get even tighter.

Hopefully this spurs innovation at all major vendors to improve performance!

vSphere Tidbits Number 2

I’m chronicling some of the cool things I discover as I go along playing around with vSphere. This time, some stuff about Fault Tolerance!

First off, if your CPUs are not FT-compatible (check here) then it won’t even turn on. So unfortunately, it’s not one of those “it works but is unsupported” deals, unless there’s some way to turn off the CPU checking that still needs to be discovered. This has already bitten us in the lab…

Next, if they are compatible, then you need to turn HA on. So far it seems like HA is much more tempermental about DNS in 4.0 than it was in VI3.5 (even pre-Update 2). For example, do NOT add your hosts to vCenter by IP address if you want to get HA to work…

Also, FT is actually really flexible once you get it turned on. You can migrate not only the primary node but also the secondary. This can be important if you want to make sure your two FT nodes are in separate blade chassis, or even different datacenters if you’re doing stretched ESX clusters.

Finally, You can actually Open a Console to each VM (the secondary gives you a warning that it’s read only) and watch what you do on the primary VM get replayed in near-realtime on the secondary node.

I think FT is a really neat feature, and despite all the caveats (no vSMP, no thin provisioning, no snapshots, etc) I still think it’ll be a really great feature that can only get better!

vSphere Tidbits Number 1

As I play around more and more with vSphere, I wanted to post some little tidbits here and there of stuff that I find which it doesn’t seem like anyone has talked about yet.

The first cool tidbit is that the VI Client (now the vSphere Client) gives you a lot more information about what it’s doing on those long, multi-part tasks. However, if you upgraded your VI2.5 client to the vSphere Client, this area isn’t visible!

After upgrading to the vSphere Client, make sure you right click on the columns title area of the Recent Tasks pane, and check the “Details” column to make it visible. After an upgrade, this is hidden by default. Now, instead of wondering “What the heck is actually happening when VMotion is at 90%?” you can see it! For example, when enabling Fault Tolerance, you see the following subtasks:

• Configuring the primary VM for Fault Tolerance
• Creating secondary VM
• Registering secondary VM
• Preparing the VM for live migration
• Migrating the active state of the VM

Pretty cool! Now when doing tasks like Enabling HA, you can see at which point the tasks fails.