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!