We were virtually there

Last issue, I covered the news about the Microsoft Viridian release, and some bumpy times I’d had at the MMS conference. I’d hoped the matter had been put to bed, but some nagging doubts remained, simply because the whole story didn’t quite add up. I’d heard, but not mentioned either here or to anyone, some rumblings in the jungle from within Redmond over the progress of the Viridian development project, but the forcefulness of the statement by Microsoft saying all was well didn’t sit comfortably. Still, I took the company at its word and published the timescale for beta delivery (around now) with final product delivery around next summer. And the list of capabilities that were being promised were truly high end, offering some things that were beyond its competitors today, and possibly even still by launch day.

Then on 10 May, it went horribly wrong. Microsoft, through the blog of Mike Neil, general manager of virtualisation strategy, announced that everything was just fine, but that a few high-end features were going to be cancelled for the first release of Viridian.

The list isn’t big: no live migration, no hot-add resources (storage, networking, memory, processor), and a supported limit of 16 cores (for example, a two-processor, quad-core system is eight core; a four-processor, quad-core system is 16 cores).

It doesn’t seem particularly onerous at first glance, but the problem runs deeper than this. As Neil said in his blog: “But with all this progress comes the occasional trade-off. Earlier this week, we had to come to terms with some universal truths about product development: shipping is a feature too. The quality bar, the time you have and the feature set are directly correlated. The mythical man-month – resources are not infinite and, even if you could add more, it does not help get more done faster.”

The reality is that the features are the truly high-end ones where Microsoft was pushing the boundaries, and attempting to get to expected equivalence to its competitors. In at least one of these items, live migration of a running VM between two physical machines, Microsoft is already behind – offers this today.

The removal of hot-add resources is again a big issue. If I have a virtual machine, which is running out of RAM due to unexpectedly high demand from users, what do I do? With hot-add memory, I can take an unused gigabyte of RAM from the system (or downsize a lightly used virtual machine that has an excess of memory) and drop it into the struggling VM. And do this on-the-fly, with no downtime. Again, if I need to reconfigure network interfaces, I can do that too. Or add more processor crunching at key parts of the working day. Or at month end, when lots of numerical calculations might be running for the financial program.

Similarly, the limit to 16 cores is a big issue. I’d been pondering the hardware issue for Viridian and concluded that maybe, just maybe, Microsoft was being held hostage by Intel. If you think about it, running a virtual machine that takes 16 cores is all well and good, but you need more than that number of cores on the physical hardware if you’re going to run several large VMs at once. Given that the existing Virtual Server product does a reasonably good mid-range job on the existing hardware, what’s the role for Viridian? Given that the existing hardware doesn’t scale well beyond 16 cores, maybe there’s some new super-wizzo ultra server architecture coming down the line from Intel, which does scale better and provides the huge levels of memory bandwidth and device I/O required of a server with more than 16 cores? If so, it might not be ready until the summer of 2008, and Microsoft will be handcuffed to non-disclosure agreements over the hardware until Intel is ready to announce.