The new calculator’s results, highlighted by Microsoft in a gloating blog post, show vSphere 5.1 Enterprise Plus as 19% more expensive than Hyper-V 3.0 with System Center 2012 when running 100 virtual machines (VMs) with an iSCSI SAN. Other configurations, such as running 150 VMs on NAS, also show VMware to be more expensive (by 6% in that particular case).

While embarrassing for VMware, this development is just one tiny part of bickering that has been going on for quite a while. And even these favorable calculator results are not good enough for Microsoft. In last week’s blog post, VMware’s rival insisted the findings are still off, particularly when the full vCloud Suite is taken into account.

Has anything really changed?

This summer’s SearchServerVirtualization.com special report on VMware and Hyper-V pricing and licensing found that the actual overall cost for the two platforms depends heavily on the size of the IT shop and the type of workload being virtualized.

It also found that the story doesn’t end there. For one thing, public-facing cost calculators are based on list prices, which enterprises rarely pay, thanks to Microsoft and VMware’s deep discounts.

Some shops may find the cost savings enticing enough to swap out one hypervisor for another, but VMware also remains the incumbent vendor in most enterprise shops, and the costs of switching have many users saying Microsoft’s savings aren’t worth it.

It’s also important to remember that VMware and Hyper-V don’t match feature for feature, especially with several of Windows Server 2012’s Hyper-V advanced features still waiting on System Center Virtual Machine Manager 2012 Service Pack 1 to be put to the test.

VMware has not responded to multiple requests for comment about its online calculator.

Update: VMware published a blog post yesterday called “Flawed Logic Behind Microsoft’s Virtualization and Private Cloud Cost Comparisons” which says that in the more common configuration of 128 GB memory server hardware, VMware vSphere remains on par with or cheaper than Hyper-V, and concludes that the Microsoft blog post pointing out the calculator’s findings “is yet another attempt to artificially inflate VMware’s prices and distract customers from the shortcomings of their own products.”

– As expected, VMware made a grand show of ending the much-reviled vRAM pricing program this week at VMworld 2012 in favor of per-CPU licensing and bundled up its products into a vCloud Suite.

Now, some IT shops wonder what they’re supposed to do with the additional licenses they bought to accommodate vRAM requirements for vSphere 5 last year.

VMware stated that vSphere licenses purchased for vRAM capacity can be used to license processors and expand existing vSphere environments.

Unfortunately, customers may also have scaled out servers, which racks up costs in network ports and other software licenses, rather than scale up and consolidate more VMs onto beefier hosts thanks to vRAM.

Though VMware maintains that it doesn’t try to compete with Microsoft on price, competition from Hyper-V was a factor.

“Competition forces you to listen to your customer base,” said Rick Jackson, a VMware spokesperson, during a press conference at VMworld 2012 here this week.

“You don’t compete with Microsoft on price…you compete with Microsoft on value,” he added.

There were also pricing details surrounding vCloud which might have gotten lost in the vRAM ruckus.

First, there are actually three editions of the vCloud Suite that are bundled into packages available as single SKUs:

• Standard, which includes vSphere Enterprise Plus, vCloud Director, vCloud Connector, and vCloud Networking and Security Standard,  is priced at $4,995 per CPU, plus support and subscription;
• Advanced, which includes vSphere Enterprise Plus, vCloud Director, vCloud Connector, vCloud Networking and Security Advanced, vCenter Operations Management Suite Advanced costs $7,495 per CPU, plus support and subscription; and
• Enterprise, which includes  vSphere Enterprise Plus, vCloud Director, vCloud Connector, vCloud Networking and Security Advanced, vCenter Operations Management Suite Enterprise, vFabric Application Director, and vCenter Site Recovery Manager Enterprise. Itis priced at $11,495 per CPU plus SnS.

VMware vSphere remains available, in all its editions, as a standalone product as well.

The vSphere Storage Appliance is now bundled in with Essentials Plus licenses, and vSphere Replication has been added to all vSphere editions, rather than being packaged solely with VMware’s Site Recovery Manager.

But beyond the immediate, what is VMware’s long-term plan for pricing its wares? Is per-CPU licensing really the way of the future?

It depends. Site Recovery Manager, for example, remains priced per VM when bought standalone, though it is priced per CPU when purchased as part of the Enterprise vCloud Suite.

“When you’re just using SRM as a point solution, per-VM makes more sense,” said Neela Jacques, a VMware vCloud product spokesperson. “But when you’re using multiple products, it makes more sense to buy the suite.”

Intel-based servers virtualized: 25% to 60%

VMware Certified Professionals: 25,000 to 125,000

VMworld attendees: 13,000 to more than 20,000

Once new VMware CEO Pat Gelsinger took the stage, he said more than 90% of servers will be virtualized within the next three years. Maritz received a nice standing ovation from the crowd when he left the stage.

After seeing some Twitter users grumbling about hotel rates around the Moscone Convention Center, I decided to investigate (i.e., go to Hotels.com).  I restricted my search to hotels that are less than a quarter mile away from the VMworld epicenter. After all, who wants a long trek back to bed after “networking” until last call?

On the high end, there is The St. Regis at $774 a night. The most affordable is The Westin at $381 a night. (Hurry! Only 4 rooms remain!) And there is a smattering of choices in between those prices.

That said, you could stay at The Mosser for $139 a night, but it’s a hostel and you have to share a bathroom. Just be sure to check in early, so you can claim the bottom bunk.

Luckily, many companies use travel agency for better rates. But you should still anticipate a pretty hefty lodging bill, regardless. Where’s Jimmy McMillan when you need him?

Then, the hacker claiming responsibility for the leak reportedly told Kaspersky Labs’ Threatpost blog that among those files, a terabyte in all, there were 300 megabytes (MB) more VMware source code.

Thus, it was widely anticipated by the VMware community (including this blog) that 300 MB of VMware source code would be released on Saturday.

On May 3, VMware rushed out a bunch of critical patches for ESX, ESXi, Workstation and Player, heightening the anticipation.

The big day has now come and gone, however, and there was nary a whisper of VMware’s name on various Twitter accounts associated with the initial leak. If 300 MB more source code did hit the Internet this weekend, it was done with far less public fanfare than the “sneak preview” received.

Users say the lack of leak doesn’t change much about their outlook on the situation.

“These types of hackers are criminals, and criminals aren’t known for keeping their word,” said Bob Plankers, a virtualization architect at a large Midwestern university. “There are a number of security updates now available for nearly every version of vSphere and its predecessors, so at the least it looks like VMware took the issue seriously on all fronts.”

Trying to guess at what happened means trying to figure out the agenda of a hacker, which is nearly impossible to do, said Edward Haletky, CEO of The Virtualization Practice LLC. It might have been that the wide-ranging publicity the initial leak received was all he was looking for.

“It could’ve been truly just about awareness, saying, ‘hey, you know, this code really isn’t private anymore’,” Haletky said. “There could be a million and one reasons.”

The fact that there was no obvious code release on May 5 shouldn’t make much difference to VMware pros, Haletky said. They should still apply VMware’s new patches and keep up with security best practices. “The answer still is to prepare for such things…do the defense in depth, do the research…if it happened once, it could happen again.”

Affected products include ESX and ESXi versions 3.5, 4.0, 4.1 and 5.0, Workstation and Player. A further description of problems associated with the patches and linked from the security update blog describes remote procedure call (RPC), SCSI driver and network file system (NFS) vulnerabilities which could potentially allow an unauthorized user execute code on a virtualized host.

With the post’s repeated use of the word “critical,” and widespread Tweeting of a link to it by VMware officials, it’s clear the patches are important. In fact, such a security update hasn’t been posted on the VMware Security and Compliance Blog since the announcement of a critical update to ESX 3.5 in 2008.

Though the post referred directly to the leak incident, what’s less clear is the exact relation of these newly announced vulnerabilities and the leaked source code file.

VMware framed the security advisory as the accelerated release of patches the company was working on anyway. “In light of the current circumstances, we have accelerated our most recent security patches and applied them to all affected currently supported products,” the post said.

“I think it is an abundance of caution, but in addition, some pro-active concern,” said security expert Edward Haletky, CEO of The Virtualization Practice LLC. While there is historical evidence that it is possible to crash a VM using paravirtualized drivers and backdoor elements in the past, he added, “the execution of code on the host is intrinsically difficult regardless of how an escape is performed.”

These aren’t the first VMware product patches which raise the spectre of rogue code executed on a host – even in the last few weeks. A security advisory was also issued without nearly as much fanfare April 12, in which three critical patches were released for VMware’s vShield Endpoint security product.

VMware’s Knowledge Base article paired with today’s security advisory also specifically credits an individual, Derek Soeder of Ridgeway Internet Security LLC, with identifying some of the vulnerabilities, rather than specifically linking their discovery back to the leaked file. Soeder, meanwhile, was publicly raising security issues with VMware’s software in a blog posted March 30, before the 2004 source code file was leaked.

Regardless of whether the hacker who threatens to leak megabytes more source code on May 5 acts on that threat, or whether these patches are specifically related to the high-profile leak, VMware customers shouldn’t take any chances, experts say.

“For now, all we can do is what we should always do, keep current on our patching levels,” said Christian Mohn, senior infrastructure consultant at EVRY Consulting in Norway.

Meanwhile, “May 5th might just turn into something more interesting than I had thought a week ago,” he said.

The code, which dates to 2003 or 2004, was apparently stolen from “a variety of compromised Chinese firms,” according to a Threatpost report. The code was confirmed as genuine by the director of VMware’s Security Response Center in a blog post yesterday. Although only a single file has been released publicly, the hacker claims to have another 300 MB of source code and that the rest will be published May 5.

If the rest of the code is of the same vintage, it may not be much of a threat. In fact, providing a more secure hypervisor was a primary goal of the conversion over the last year from ESX to ESXi, a set of code with a much smaller attack surface. So far, no data has been published which indicates the ESXi hypervisor is involved.

But if the remaining code published May 5 is more current, and contains information that could allow hackers to access hosts from guests, it could potentially pose a security threat to enterprises as well as cloud service providers with infrastructures based on vSphere.

The worst-case scenario is that such a “VM escape” is found, but not published, according to Bob Plankers, virtualization architect with a large Midwestern university.

“There’s a lot of money to be made by hacking enterprises,” he said. “So VMware and their customers would be best served by an attitude akin to a race: who can find all the security holes first?”

The risk is probably not very high right now based on what’s been released, according to security expert Edward Haletky, CEO of The Virtualization Practice LLC. But “believe me, on May 5, I’ll be paying attention to what is released,” he said.

So far, escape-the-VM attacks have proven relatively toothless – none has been able to really do much to cross VM boundaries even when they have penetrated the hypervisor in experimental settings, Haletky said. If areas of the code having to do with the virtual machine manager leak out, it could help such an attack do more damage.

For now, it’s much easier to attack virtual machines through the management layers, and therefore much more common, Haletky said. Enterprises can protect themselves by following security best practices such as separating management networks from storage networks, fault tolerance and vMotion networks; limiting the footprint of VMs; effective network monitoring; and using early warning systems. But it’s something he says most enterprises don’t do.

“I think this may push more people to follow best practices because of the increased awareness,” he said.

IT pros shouldn’t expect this to be an isolated incident, according to Haletky. VMware and its competitors have become high-profile enough that their software is a juicy target for potential attackers.

“Years ago…we said we can’t say there won’t be a major incident involving one of the hypervisor vendors, whether it be VMware, Microsoft or even Citrix or Red Hat, and it’s going to be disastrous,” he said. “Does this raise the risk for VMware? Yes. As a company, absolutely.”

The vSphere 5 edition of VMware’s Security Hardening Guide is still in the works, but one blogger brought up a potential conflict between the API, called VIX, and a recommendation against enabling it in the Hardening Guide issued with vSphere 4.1.

“SRM now requires that the VIX API be enabled on all protected virtual machines that will have their IP changed during recovery,” according to the blog post by Michael Webster, a VMware Certified Design Expert and director of IT Solutions 2000 Ltd., a VMware consultancy based in Auckland, New Zealand.

Previously, users had the option of changing IP addresses without using the API, which is slower but considered more secure. “This has already caused me design problems in a number of customer environments,” Webster wrote.

However, enterprises that don’t require the highest security measures may not run into an issue, experts say.

Shannon Snowden, a consulting partner at New Age Technologies in Louisville, Ky., said he has yet to run across the problem despite having done several large-scale SRM deployments over the past few months.

“If it is of concern, we could most likely use a couple of scripts to enable it temporarily during the actual SRM event then disable it as a post-recovery step,” Snowden said. “Obviously, I would prefer to have the old way as an option along with the new faster way, instead of having to put together and coordinate scripts.”

While most companies probably won’t be impacted, the use of the VIX API to change the IP address of virtual machines (VMs) may be a problem for customers in government, research and finance industries, said Bill Hill, infrastructure IT lead for a Portland, Ore.-based logistics company. He doesn’t anticipate it will be a problem in his shop, but he can see where it might be for some.

“Ultimately, VIX allows for significantly more access to a virtual machine outside of just changing the IP address,” Hill said.

Other operations enabled by VIX include the ability to copy files from hosts to guests and guests to hosts, for example.

As an alternative to the API, IT pros may be able to use Dynamic Host Configuration Protocol (DHCP) to assign IP addresses to VMs according to MAC address, suggested VMware principal architect Duncan Epping in Webster’s blog’s comments.

But the environments that are concerned with VIX API may also disallow DHCP, according to Webster. “I think in a lot of environments block this at the switch and insist on static IP addresses.” he wrote.

Some applications for data conversion, PDF generation, and multi-factor authentication in Hill’s environment require static IP definition and therefore wouldn’t be able to use the DHCP workaround, he said.

One financial shop running SRM, South Africa’s Investec Bank, will avoid the VIX issue because its layer 2 domain is stretched, so IP addresses don’t have to be reassigned at all.

“If we do a test we actually isolate the environment completely and our VMs have the same IPs as they would have in production,” wrote Etienne Neethling, who administers SRM for the bank, in an email. “And if we had a real DR [situation], they would [also] stay the same.”

However, this approach comes with its own set of challenges, especially over distance.

In the post, Wright noted that Hyper-V can make headway in the SMB market, because there are some features on VMware hypervisors that admins at smaller shops won’t or don’t need to consider. Wright goes on to note a Gartner prediction that 85% of companies with fewer than 1,000 employees will be Hyper-V shops.

Chanda Dani, senior product marketing manager at VMware, took issue with that and other claims. Dani said the “85%” prediction is incorrect; that of all Hyper-V installations, 75% will be in SMB with fewer than 1,000 employees.  Dani said the “statement has been erroneously interpreted in the blog. The author should back up Gartner’s statements with citations.”

Then, earlier this week, Wright took to the SolarWinds blog again, responding to Dani’s critiques. He took to task the idea that VMware products could cater to the small-to-medium business set when VMware’s Essentials kits might not support the needs of a medium-sized company. Wright said it’s hard to deny the advancements Microsoft has made in the SMB market with Hyper-V.

With 60% of our purchasing intentions survey respondents planning to expand server virtualization, Microsoft has a chance to cut into VMware’s substantial market share. It’s no wonder why it’s a contentious topic.

What do you think about VMware and SolarWinds’ slings? Let us know in the comments.

Users may be more wary of bugs today. But, in the case of vSphere 5, the delay may have as much to do with the lack of a major feature or driving need to make the switch, said Tim Antonowicz, a senior sales engineer with Mosaic Technology, an IT infrastructure consulting company based in Salem, N.H.

“In most cases that I’ve come across, people didn’t see a compelling reason to upgrade. If they had a vSphere 4.0 or 4.1 infrastructure, they could keep it patched and updated without doing a major upgrade. In their minds, why introduce something new into what is a stable environment right now, when there’s no confirmed need?” Antonowicz said.

In fact, it wasn’t the new features included in vSphere 5 that garnered most of the attention after the July 2011 launch, it was the change in the licensing model. While there have been some reported bugs with vSphere 5, more recently Antonowicz has seen customers deciding that it is safe enough to make the move. Instead of one keystone feature that might have pushed faster adoption, it has been a variety of smaller improvements driving this new wave of upgrades.

• With vSphere 5, you can have bigger file systems that allow you to put more of your data together in a consistent format. Admins can also now thin provision the data they don’t need, allowing for the proper interaction between the software and the array.

• “VMware finally got around to building a totally new high-availability system from the ground up. So High Availability, is much more robust and better supported in vSphere 5,” Antonowicz said.

• Storage optimization is now more efficient. The Storage Distributed Resource Scheduler helps automate storage management. Administrators can set the storage policy of their virtual machines (VMs) and automatically manage the balancing and placing of the VMs across storage resources.

“Taken individually, none of those changes are a compelling reason to upgrade,” Antonowicz said.

But taken together, along with the calming of fears over bugs, and we should start to see more organizations take the vSphere 5 plunge in the next few months.