VMware 2:

Taking back time...

and adding something free into the bargain

(Page 2 of 2)

Digging even deeper

However, now employing a JCB to do our digging, we discovered whilst running simulations within our development network that VMware Server had some rather major issues with timing. This problem is seemingly common to all hypervisors: an OS measures time by measuring how many cycles a processor clock has processed in a second—so for example a 1MHz CPU will make a million ‘cycles’ per second. So if a 1MHz CPU has undertaken a million one-cycle operations, the OS knows categorically that a second has passed.

Now we move on to the difficulties imposed by virtualisation on this relatively easy time-keeping task. With multiple host OSes on one server, an individual host OS is assigned a number of clock cycles for it to complete its set of tasks, before the baton is then passed to the next virtual host for it to have its turn.

If you haven’t grasped the idea already, this quickly gets out of hand. To start, a virtual host has 1,000,000 clock cycles assigned to it, and then the CPU is given over to another VM for it to process 1,000,000 cycles of its own operations, and it’s then passed back to the first VM who processes another 1,000,000 cycles. So at this stage the first virtual host thinks that 2,000,000 clock cycles have occurred, and therefore two seconds have passed (continuing on with the 1MHz example so as to not make the numbers even more confusing)—where in fact three seconds have actually passed in reality.

This completely throws off the OS when the moment comes to carry out a time-sync (which it does via VMware Tools with the host server)—leading to a complete server standstill as it busies itself with scratching its head and correcting various internal counts. In an Active Directory environment this adverse effect is amplified, whereby the entire network can grind to a halt whilst the DC puts its accounts in order.

Surely there’s a better way…

Well, you’d like to think so. But for a long time, unless the client was willing to pay for the ‘enterprise-level’ hypervisor where this problem was dealt with comprehensively, VMware Server couldn’t hack it.

Yes, in small networks of less than 10 PCs and where only two virtual hosts idling along existed on a server, the adverse effects were rarely noticeable. But make that three or more hosts, all busy and needing processing power, and throw into that another 10 or more users/PCs—the effect became more than noticeable, it became a reason not to virtualize.

So for a long time we were in a conundrum of sorts—to virtualize or not to virtualize. We knew ourselves it made perfect sense to do so, but when costs were brought into the equation and a cheaper (read: free) solution had to be provided for our smaller clients—we were left to deliberate over the risk involved. Planning and prior simulation of the client’s network on our development network aided these decisions greatly; however we couldn’t adequately plan for client’s future growth and other unforeseeable future requirements.

And then, out of the ether of the internet mist came word of the mother of all updates: VMware Server 2—still free, and this time on time.

Meet ESX’s little brother

That’s right, the family tree has grown—as of today VMware Server 2 is finally under general release. We have been using it since RC2 on our own development network, and has already proven its worth its weight in gold (its weight being a rather hefty 502MB, a 400MB increase on Server 1—more on that later).

And yes, as the (relatively sparse) rumours hinted, the timing issue now seems to be nothing but a memory to be hurriedly forgotten. On two of our test servers, after rolling out VMware Server 2, upgrading the ‘Virtual Hardware’ version and deploying the new installs of VMware tools—every server has kept it’s time perfectly and the standstills are a thing of a past.

This improvement (and many others) is largely down to the fact that the VMware Server 2 hypervisor seems to be closely based on ESX/ESXi—and therefore has some of the good genes bred in. This is most evident in the command sets available for both, with them being practically identical—but I’ll save details of that for another blog entry.

Whilst they certainly are of the same heritage, VMware Server 2 and ESX do differ in a lot of ways too. The most glaring example being the overheads involved—ESX’s hypervisor has a footprint of typically less than 40MB, where VMware Server 2’s footprint can easily run in to the 100s of megabytes.

I mentioned earlier that the download size between the two versions of Server has increased by around 400MB—a large portion of this chunk of data is given over to Server 2’s front-end, the controversial (and seemingly much hated) Web Management Interface—which is Java based and uses the rather bloated TomCat to process web requests.

In early tests, we’ve found that a handsome proportion of Server 2’s cumbersome footprint is owed to the related web processes responsible for providing the new console. However, we’re willing to forgive this rather minor shortcoming—we can plan and cater for a large footprint, but we couldn’t provide for a ‘bug’ with no fix.

So now we’ve thoroughly tested VMware Server 2 on our own environment, and its gone through our meticulous testing and probing, we’re now in a position to provide a workable and reliable solution on to our clients; and best of all, for free.

I’ll be writing a lot more with regards to VMware Server 2, including the new features I haven’t had chance to touch upon within this entry, along with other virtualisation products in the very near future. In the meantime, head over to VMware to register and download your now final release version of VMware Server 2. Enjoy!

Oh, and I almost forgot to say: Server 2 now supports two processors or cores and 8GB of RAM per each virtual host—plenty of room to play, sorry, work. Well, for now at least.