Home > Blogs > Virtual Reality > Monthly Archives: March 2010

Monthly Archives: March 2010

VMware ESX to ESXi Upgrade Center – Check it Out!

If you have not had a chance, I would definitely recommend you check out the recently launched “VMware ESX to ESXi Upgrade Center.” We launched this upgrade center to help customers and partners get comfortable with ESXi because we’ve stated on numerous occasions that in the future, ESXi will be the exclusive focus of VMware development efforts.

Why have we made this decision to move towards the ESXi architecture? Simply put, we wanted to improve hypervisor management in regards to security, deployment and configuration, and ongoing administration. You can read more about all the benefits at the Upgrade Center or ESXi product page, but as a quick snapshot, take a look at this graph of how ESXi reduces the number of patches compared to traditional ESX (over the same timeframe).

clip_image002

It just goes to show you what removing the dependency on a general purpose OS in the virtualization layer can do for you. Goodbye patches for general purpose operating system code that wasn’t required for core virtualization functionality. (Although the console OS in traditional ESX serves a vastly different purpose than the Parent Partition in Hyper-V or Domain 0 in Xen, but that’s a whole separate discussion.)

As expected, not everyone agrees with our approach of reducing the role of a general purpose operating system in the virtualization layer. Just take a look at a Microsoft marketing brochure that proudly highlights how their virtualization layer is part of general purpose Windows. But it is very interesting how, once you talk to knowledgeable people outside of the Hyper-V marketing team, you find resoundingly consistent agreement that a smaller code base is the way to go for protecting your mission-critical virtualization layer.

  • From a leading virtualization security analyst’s blog (Feb 2010):
    “The lesson from all of this is that thinner is better from a security perspective and I’d argue that the x86 virtualization platforms that we are installing (ESX, Xen, Hyper-V and so on) are the most important x86 platforms in our data centers. That means patching this layer is paramount. With Hyper-V’s parent partition that means closely keeping an eye on Microsoft’s vulnerability announcements to see if it is affected.” (emphasis added)
  • From an article quoting another leading virtualization analyst (Nov 2009):
    “Problem two is a bigger, architectural problem that he was told about by R2 beta users. As he explains it, in a Hyper-V environment, every physical host has a copy of Windows that is used as the parent OS. It manages the I/O drivers and is home to any management agents that are installed. ‘If I want to use PowerShell, I’m also using the parent OS for that,’ he declares, ‘so what you end up with is one big, fat, single point of failure.’” (emphasis added)
  • Finally, let’s look at what a Director in the Microsoft Azure team said was a key design principle for Azure:
    “[Design Principle #2] Small footprint: any features not applicable to our specific cloud scenarios are removed. This guarantees that we do not have to worry about updating or fixing unnecessary code, meaning less churning or required reboots for the host.” (emphasis added)

Pretty good independent confirmation of our approach with ESXi.

So give ESXi a try if you’ve never done so. If you already own vSphere licenses, you have the option of deploying any of those licenses as either ESXi or as traditional ESX. If you don’t have vSphere, download ESXi for free.

Hyper-V passes Microsoft’s checkmarks exam: isn’t that always the case?

While browsing through the Microsoft Virtualization website, I stumbled across this table included in the Cost Saving section that presents cost and feature checklist comparison between Hyper-V/System Center with few vSphere editions.

image

While Microsoft’s spin on the theoretical cost advantage of Hyper-V/System Center over vSphere isn’t surprising (I am not going to address it here, since we have already shown how it doesn’t hold water), the checklist comparison struck me as having a few factual errors and misrepresentations of actual product capabilities which I think are worth pointing out:

  • vSMP Support – Microsoft’s support for vSMP is actually much more limited than the table shows. Hyper-V R2 supports 4-way vSMP only in VMs running Windows Server 2008 and Windows 7. For Windows Server 2003 VMs, Hyper-V R2 supports up to 2-way vSMP and for Linux (SUSE /RHEL) VMs just single virtual CPU. vSphere, on the other hand, supports up to 4-way vSMP with Standard, Advanced and Enterprise Editions and 8-way vSMP with Enterprise Plus edition on any vSphere supported guest OS (over 50 versions).

  • HA/Clustering – The table incorrectly shows that vSphere Standard does not include HA/Clustering, when in reality it does. Microsoft seems also very generous with Hyper-V by implying it provides equal HA capabilities as vSphere. Unlike vSphere, for example, Hyper-V R2 does not provide VM restart prioritization, which means that there is no easy way for admins to make sure that critical VMs are being restarted first. Incidentally, the lack of VM restart prioritization is one the reasons why Burton Group stated that Hyper-V R2 is not an enterprise production-ready solution. In addition because Hyper-V R2 lacks memory overcommit (a feature that is totally missing from Microsoft’s checklist), it can restart VMs only if the failover server has enough spare memory capacity to accommodate the VMs of the failed host.

  • Hot add – Microsoft gives Hyper-V R2 a check on Hot Add and then below the checkmark specifies “Storage” to indicate Hyper-V supports only Hot Add of a VM’s virtual disk capacity. vSphere gets a checkmark too, but what the table doesn’t tell is that it not only provides Hot Add of a VM’s virtual disk capacity, but also of virtual memory and CPU

  • Storage VMotion – This checkmark is funny to say the least. If you don’t know what the word “quick” means in Microsoft’s marketing jargon (and believe me I have heard illuminating translations of the term from Microsoft’s own employees), you’d think that Microsoft has a fast Storage VMotion (possibly faster than VMware’s). The reality is that even just talking about Storage VMotion in Hyper-V’s case doesn’t make sense, because Microsoft’s Quick Storage Migration, just like Quick Migration for VMs, cannot migrate VM virtual disks without downtime. VMware Storage VMotion, on the other hand, can migrate virtual disks without any application downtime.

  • DRS/PRO – Even now that Hyper-V has live migration, positioning PRO as a DRS-equivalent isn’t accurate. PRO is a fundamentally less usable and more complex solution for resource balancing. Unlike DRS, which can be configured from vCenter in a matter of few clicks, PRO Tips requires both System Center Virtual Machine Manager (SCVMM) and Operations Manager (SCOM). As Microsoft TechNet shows, SCOM is a very complex product that consumes a considerable amount of servers and databases that – opposite to what Microsoft wants people to believe – are neither free nor included in the cost of SMSD licenses. In addition to being hard to set up, PRO is dependent on software packages (PRO Packs) that each hardware vendor creates for its own products Last but not least, PRO lacks a global view of the resources of a group of servers (like DRS does with Resource Pools) and consequently it cannot optimize resource allocation across a cluster, but only react to the local conditions of a certain workload.

  • vNetwork/Host Profiles in my opinion, this line wins the Oscar for best checkmark in a “mis-leading” role. First, Microsoft drops the words “Distributed Switch” from VMware’s vNetwork Distributed Switch (vDS) making it look like a generic virtual networking feature. Then, it gives Hyper-V R2 a check for the vNetwork/Host Profiles combination implying that System Center also provides the same functionality as VMware Host Profiles when in reality the only way it could would be through extensive development of custom scripts and customization of SC Configuration Manager (should we include the extra cost to the System Center price at the top of the table?)

While there is more that could be said about this table from Microsoft, this already shows how easy it is for Hyper-V to pass Microsoft’s checkmark exam. . This isn’t something new, though. Looking through the Virtual Reality archives, I found a 2 year old post (“Can I have the check, please?”) by a former VMware SE now with Microsoft on this same checkmark issue. I guess it is true that old habits die hard.