VCritical » vSphere

Hyper-Vacating Your Datacenter with vSphere 4.1

Eric Gray — Mon, 30 Aug 2010 12:20:13 +0000

Has a rogue Hyper-V host popped up in the server room? Did someone develop a now-critical application atop Hyper-V on a PC under his desk? Has your company acquired another that hadn’t standardized on VMware vSphere? Do you need to get a Hyper-V VM onto vSphere quickly?

Then Hyper-Vacate your datatacenter — stat!

Thanks to a new feature in VMware vSphere 4.1 to convert and import virtual machines — also known as V2V — from a Hyper-V host, Hyper-Vacating is now easier than ever. From the What’s New in vSphere 4.1 document:

vCenter Converter Hyper-V Import. vCenter Converter allows users to point to a Hyper-V machine. Converter displays the virtual machines running on the Hyper-V system, and users can select a powered-off virtual machine to import to a VMware destination. See the vCenter Converter Installation and Administration Guide.

It has always been possible to import a Hyper-V VM — even before vSphere 4.1 — by simply treating it as a powered-on physical machine; this is still a valid approach for those that prefer to do a hot conversion. The new enhancement in 4.1 allows a cold conversion, which is worth considering to ensure a completely consistent V2V copy.

Downtime?

A cold conversion will require some downtime for the Hyper-V virtual machine. As a vSphere administrator, you may not be familiar with the nuances of Hyper-V, but the good news is that users serviced by a Hyper-V infrastructure are not unfamiliar with downtime. That’s because tasks like removing a snapshot require VMs to be powered off. Therefore, do not be too concerned with this brief outage.

Visual Walk-Through

If you have installed vCenter Server with vCenter Converter and plug-in, a wizard will guide you through the entire process. Take a look at some of the key steps:

Select Hyper-V as the source type:

Allow a Converter agent to be installed on the Hyper-V host:

Select a powered-off virtual machine from the listed inventory:

Customize the destination vSphere VM as needed. You can convert to vSphere thin provisioning and make a number of other modifications, such as disabling the Hyper-V components inside the guest.

After the process begins, a summary can be found by right-clicking the task in the vSphere Client:

Hyper-Vacated!

Hopefully, you have already standardized on the best virtualization platform available, but if you find yourself needing to move Hyper-V VMs to vSphere, this new vCenter Converter capability could save the day.

Book Review: Maximum vSphere

Eric Gray — Thu, 26 Aug 2010 12:05:44 +0000

Maximum vSphere is a new book by Eric Siebert, writer and purveyor of VMware information at vSphere-land. Not only that, Simon Seagrave of TechHead fame contributed two chapters and VMware’s John Troyer provided his individual style to the Foreward — be sure not to miss it.

For those in a hurry, here is the executive summary: buy the book, it is an excellent practical guide and reference.

The cover promises Tips, How-Tos, and Best Practices for Working with VMware vSphere 4 — and the Maximum vSphere delivers on all counts.

vSphere accommodates a wide range of business requirements and therefore often provides various ways to meet those different needs. Siebert uses a consistent approach throughout to clearly organize and present options faced when making decisions; storage technologies, networking hardware, monitoring tools, and many other areas are examined — clearly articulating advantages and disadvantages of one choice over another so readers can better understand broader implications.

One of the first things that I noticed, and liked, was the robust table of contents in addition to a useful index. When using a reference like this, it is always better to be able to quickly locate applicable sections.

The overall flow of the book is great — but I suspect that most readers will skip around and focus on specific areas of interest. Interestingly, Siebert did not start out with a long, drawn-out tutorial on installation in chapter one. Instead, he chose to describe what is new in vSphere 4 — very useful for VI3 administrators looking to get up to speed quickly. Don’t fret, installation and upgrade do receive ample coverage later in the book.

It was interesting to see a large section at the end devoted to building your own vSphere lab — very useful for experimenting and learning the features. Siebert even discusses one of the very popular topics here at VCritical, running ESX on ESX.

Siebert covers the whole range of VMware vSphere, from ESX and ESXi to vCenter Server to vShield Zones and beyond. My impression is that even the most virtualized vSphere administrator would learn a few things from Maximum vSphere.

Unfortunately, there is a serious error on page 31: it’s Elastic Sky, not Electric Sky. How that passed technical review, we may never know.

At well under 400 pages, Maximum vSphere is not huge by technology-book standards — but it is chock full of content, especially considering the conservative use of product screen shots. Check it out.

Disclaimer: The publisher provided a review copy of the book, but did not influence the content of this article.

VMware vSphere 4.1 – the best virtualization platform yet

Eric Gray — Wed, 11 Aug 2010 19:10:02 +0000

This week Network World is hosting an online debate, posing the question Who has the better virtualization platform – VMware or Microsoft? There is also an opportunity for readers to vote for their choice, and the results as of today are not surprising — VMware winning by a landslide.

No matter how you slice it, VMware vSphere is simply the best virtualization platform available. Let’s take a look at a few points to back up this claim.

Favorable Reviews

VMware vSphere 4.1 launched last month and has been very favorably reviewed by mainstream technical media:

InfoWorld: VMware vSphere 4.1 keeps the virtualization crown
eWeek: VMware vSphere 4.1 Features Large Capacity Cluster, VM Density

Gartner Magic Quadrant

Recently, Gartner, Inc. published the Magic Quadrant for x86 Server Virtualization Infrastructure and placed VMware in the Leaders Quadrant. Please see the full report for details.

In-Depth Virtualization Platform Comparisons

If you find yourself in a situation where you need to clearly articulate your requirements for the advanced capabilities of VMware vSphere, have no fear — VMware provides very helpful material to guide users through concise platform comparisons. From a Windows admin considering Hyper-V to upper management helpfully suggesting the “free” XenServer hypervisor, you should have no trouble explaining why the exclusive features found in vSphere are the only choice for building your private cloud.

All of this great material has been updated for vSphere 4.1:

vSphere 4.1 Features and Benefits Comparison – Excellent matrix covering vSphere, Hyper-V, XenServer, and RHEV
vSphere 4.1 Competitive Reviewer’s Guide – Comprehensive coverage of capabilities
The VMware Advantages website – Perfect overview of the key advantages; links are easy to email around
Why Choose VMware Whitepaper – Based on the material from the above website; easy to read and share

Another great technical resource to bookmark is the vSphere 4.1 link collection from Eric Siebert, purveyor of quality VMware information.

The Best is the Best

There is only one best and only one virtualization platform that offers all of the advanced capabilities of VMware vSphere.

Multiple hypervisors? What about multiple SANs?

Eric Gray — Tue, 15 Jun 2010 18:40:30 +0000

Some of the cool kids are talking about a multi-hypervisor strategy these days. Mostly journalists and such who could never truly feel the pain of dealing with two vastly different virtualization management platforms.

As you may recall, Red Hat is attempting to bring their new RHEV product to market by playing the old “don’t get stuck with a single vendor” trick. Red Hat’s CEO claims:

“…customers don’t want one platform. They want two.”

Let’s save the multi-hypervisor discussion for another day, but shift to the topic of storage diversity.

While there may be a few environments that can standardize on a single storage area network technology, it typically makes sense to mix and match iSCSI, NFS, or Fibre Channel SANs to optimize for cost and performance.

During my recent foray into the chaotic world of Red Hat Enterprise Virtualization, I encountered an unbelievable storage limitation with their new KVM hypervisor.

“Virtualization diversity… when and where we say”

VMware vSphere customers are free to mix and match supported storage technologies within datacenters, clusters, and even hosts.

I would have thought that a company like Red Hat that is pushing heterogeneous solutions and multiple vendors might feel the same way when it comes to storage. But that’s not quite how things go in the land of Red Hat Enterprise Virtualization.

With RHEV, a “Data Center” is configured to use a single type of storage; all clusters and hosts in that Data Center are restricted to that, so choose wisely:

Storage Freedom

VMware vSphere allows administrators to move virtual disks for running VMs from one array to another — even between different types of arrays — with zero downtime. Storage vMotion is a very powerful feature and it is simply not available from Red Hat – only VMware.

The Best Choice: VMware vSphere

Virtual machines have differing storage requirements — certainly not a one-size-fits-all component of an efficient virtual infrastructure. The best platform for building your own private cloud is also the one with the broadest support for today’s storage technologies: VMware vSphere.

Oh, by the way, did you know that VMware is positioned in the Leaders Quadrant of Gartner’s newly-released x86 Server Virtualization Magic Quadrant. Take a look at the full article — I’ll give a free subscription to the VCritical RSS feed to the first 10 people that spot Red Hat’s position.

Red Hat Enterprise Linux is not Enterprise Virtualization

Eric Gray — Fri, 09 Apr 2010 13:15:05 +0000

With Red Hat Enterprise Virtualization, the RHEV Manager can manage two different types of KVM hypervisor hosts:

RHEV Hypervisor (RHEV-H) — slimmed-down to run just the KVM Linux kernel modules and supporting services
Red Hat Enterprise Linux 5.4 (RHEL) — full installation with any applications, GUIs, or tools desired

By paying $749/socket for RHEV, users are entitled to use RHEV-H for no additional cost. However, those that opt to use the full installation of RHEL 5.4 must purchase an appropriate RHEL subscription separately, which typically runs $1299-$2499 per host.

Wow, the cost of all this open source virtualization technology can really add up!

Red Hat Enterprise Confusion

A full installation of RHEL 5.4 provides necessary KVM Linux kernel modules and some basic management tools to create and run virtual machines — without a trace of RHEV:

However, don’t jump to the conclusion that such a RHEL 5.4 host can also be managed by the RHEV Manager — the KVM packages required by RHEV are different and incompatible with those provided in a standard RHEL 5.4 installation. In fact, for some odd reason, even the command-line tools are unavailable or incompatible with RHEV — the only way to manage virtual machines is with the RHEV Manager.

Don’t just take my word for it, the Installation Guide says it best:

And don’t forget, the RHEV Manager runs exclusively on Windows and the only interface is Internet Explorer. So much for open source virtualization management technologies.

VMware vSphere Consistency

One of the great strengths of VMware ESXi is the consistent management experience across a range of deployment options. This is because the same exact bits are used for every edition of VMware ESXi — features are simply added by applying appropriate licensing. In fact, the same exact vSphere Client connects to every edition of ESXi — from free to Enterprise Plus — as well as to VMware vCenter Server for centralized management. This design offers a consistent virtualization management experience in every environment.

Red Hat Enterprise Virtualization offers no free edition and expects customers to contend with multiple incompatible variations of the same core hypervisor — each with a different management interface. Somehow, I doubt that is what “customers are asking for.”

Treat your Red Hat Enterprise Linux workloads to the best — run them on VMware vSphere.

What is Red Hat Enterprise Virtualization?

Eric Gray — Thu, 08 Apr 2010 14:30:27 +0000

Virtualization experts know that Red Hat has abandoned Xen in favor of the younger, hipper Kernel Virtual Machine (KVM) hypervisor. Red Hat Enterprise Linux 5.4 (RHEL) — which was released last September — marks the official beginning of their new virtualization era.

Red Hat Enterprise Virtualization 2.1 (RHEV), released in November 2009, is a new product from Red Hat — essentially an update to the management tools acquired along with Qumranet in 2008. RHEV consists of two main elements: RHEV Manager and RHEV Hypervisor. RHEV Hypervisor is a slimmed-down version of RHEL 5.4 designed to function solely as a KVM hypervisor.

RHEV Manager, on the other hand, has nothing to do with Red Hat Enterprise Linux. Unbelievably, the product runs exclusively on Windows Server 2003, is based on .NET, and is only accessible with Internet Explorer. I know this sounds like Bizarro World, but it’s true!

One Hypervisor is not Enough?

Red Hat CEO, Jim Whitehurst — evidently borrowing some pages from the Microsoft Virtualization playbook — claims that customers want an alternative to VMware vSphere so they do not need to be completely dependent on one hypervisor. Since it is practically impossible to get a single one of the thousands of satisfied VMware customers to replace their beloved vSphere with another platform, the only sensible approach is to promote a dual-vendor strategy. No surprises there.

References?

If customers were actually asking for this, then you’d expect some of those alleged customers to be readily available as references. So far there appears to be just one, a Swedish Internet video company named Voddler. I’ve never heard of them either — but a reference customer is a reference customer, and name recognition isn’t everything! I tried to find another reference, but after almost half a year since the RHEV 2.1 GA release there aren’t any.

Same or Better than vSphere?

Red Hat claims that RHEV is “…60-80 percent lower cost with the same or better features compared to other solutions.”

Same or better features than vSphere? According to whom?

I’ve taken a close look at RHEV and will publish some of my findings soon — subscribe to the RSS feed if you want to follow along.

Taking snapshots of VMware ESX 4 running in a VM

Eric Gray — Fri, 26 Feb 2010 19:08:38 +0000

Clearly, the capability introduced with VMware vSphere 4 that allows VMware ESX 4 to virtualize itself is a real crowd-pleaser.

However, one limitation that some have discovered while using this lab-testing technique is the lack of ability to use snapshots with virtual ESX systems. In fact, after taking a snapshot of a virtual ESX VM, you will see the system boot into the recovery shell like so:

Ouch.

Can we fix it?

I asked some super-smart engineers inside VMware about the issue, and of course they know all about it and how to make it work.

The solution is to enable an undocumented advanced configuration option on the physical ESX host like so:

In other words:

Log into the console of the physical VMware ESX 4 host
Run the following command: esxcfg-advcfg -s 1 /COW/PermitVmfsOnRedoHierarchy
Verify the setting with the “get” flag: esxcfg-advcfg -g /COW/PermitVmfsOnRedoHierarchy

Do I even need to say that this stuff is not supported by VMware Global Support Services (GSS)? Well, I just did.

Yes we can!

After executing that one command on your physical machine, take a snapshot and boot up your virtual ESX:

Everything works just like you need it to now — you can even create a snapshot hierarchy:

Now what?

Were you constrained by the lack of virtual ESX snapshots? What interesting things will you use this for?

Linux apps run directly on Windows with virtualization!

Eric Gray — Wed, 17 Feb 2010 12:09:52 +0000

Microsoft has done remarkable things with virtualization — unbelievable, some say.

One outstanding achievement is the way the Hyper-V architects managed to completely collapse the guest operating system layer directly into the hypervisor. Take a look at this diagram from a Microsoft Virtualization competitive brochure:

[Yes, it's that same brochure again.]

There are several key differences between Microsoft and VMware hypervisor architectures. While the hardware and applications layers are pretty straightforward, applications don’t run directly on hardware. As you are about to see, these two platforms take very different approaches when it comes to virtualizing workloads.

The VMware vSphere solution is to use a thin, high-performance virtualization layer that enables a single physical system to simultaneously host multiple virtual machines. Each of these virtual machines executes isolated instances of traditional guest operating systems — Windows, Linux, Solaris, Netware, etc.

Due to apparent technological advancements in Hyper-V, it is now possible to run applications of all kinds directly on that integrated Windows OS/hypervisor layer without the need for a guest operating system at all. This allows Microsoft to omit an entire layer from their virtualization architecture.

I’m sure you have seen various announcements about the exceptional support that Hyper-V has for Linux workloads. Without a guest operating system layer, one must logically conclude that Linux applications are actually running on the Windows/Hyper-V hypervisor integration directly. Spectacular!

I thought I’d test this technological breakthrough in the lab myself by running Postfix, a very popular Linux SMTP mail server, on Windows Server 2008 R2 with Hyper-V. According to the diagram above, Postfix is classified as an application — the third layer.

Now, in order to install Postfix, I have to interact with the second layer in the stack, which is the “Microsoft Operating System w/Virtualization.” Since I’m an RHCE, I decided to use a Red Hat Enterprise Linux package of Postfix, but we can all agree that SUSE Linux Enterprise Server 11 would work equally well. However, I would not recommend using Ubuntu packages since that distribution is not supported by Hyper-V. Another side benefit to this technique is the fact that Windows has great mouse support.

Just as one would do on a legacy Linux system, I opened a trusty command shell and installed the package like so:

This is the first step to getting Postfix installed and running. I do have to admit that it took a few additional troubleshooting steps in my case — most certainly unique to my environment, so I will spare the details.

In order to complete the Postfix implementation, you’ll need to edit several configuration files. Do not use Notepad for this, as it does not understand the peculiar format of these text files:

One would think that the virtualization layer could also dynamically accommodate for UNIX line formatting, but that evidently was not part of the design. Fortunately, this is a very minor issue since WordPad can be used without problem:

Once you have the basic configuration in place, restart the service and validate — telnet to port 25 and send a test email.

There you have it, amazing Hyper-V virtualization — same capabilities as VMware vSphere with 25 percent fewer layers!

Leave a Comment • Subscribe to RSS • Subscribe via Email • Follow Eric Gray on Twitter
More articles on: ESX, Hyper-V, Linux, satire, vSphere • Browse All Virtualization Content
Linux apps run directly on Windows with virtualization! by Eric Gray © 2010 • VCritical

The Truth About Hyper-V Memory Overcommit

Eric Gray — Wed, 13 Jan 2010 13:20:05 +0000

The ability to assign more memory to virtual machines than physically available on a host is called memory overcommit and is a major factor that contributes to higher VM density — running more virtual machines per host increases efficiency and reduces cost. VMware ESX has provided this feature for multiple generations, giving it an advantage over competing hypervisors.

The Cost Per Application Calculator makes it clear that investing in VMware vSphere 4 significantly reduces your datacenter hardware footprint and associated costs. Scott Drummonds, the VMware performance expert, recently explained how memory overcommit is the only way to effectively use all of the physical RAM in a hypervisor.

Each time this topic comes up, Microsoft revs up their marketing machine and responds like this:

Hyper-V is free, use your money to buy RAM upgrades instead of VMware vSphere licenses
Memory overcommit is risky, VMware tells customers to turn it off anyway

The truth is that Hyper-V will have memory overcommit the moment Microsoft figures it out. If that day ever does come, watch the messaging quickly change to the familiar, “our customers asked us to implement this…” line.

Why is it fair to make such a bold claim? Two words:

Dynamic Memory

It’s a little known fact that some of the early releases of Hyper-V R2 actually had a feature that allowed administrators to assign more RAM to virtual machines than was physically present on the host — “Dynamic Memory” a.k.a. memory overcommit.

We can look back and see what bloggers like Mark Wilson had to say:

Microsoft also spoke to me about a dynamic memory capability (just like the balloon model that competitors offer). I asked why the company had been so vocal in downplaying competitive implementations of this technology yet was now implementing something similar and Ward Ralston explained to me that this is not the right solution for everyone but may help to handle memory usage spikes in a VDI environment. Since then, I’ve been advised that dynamic memory will not be in the beta release of Windows Server 2008 R2 and Microsoft is evaluating options for inclusion (or otherwise) at release candidate stage.

And this blog provided more detail on the implementation:

In Hyper-V 1.0, physical memory was hard allocated to the VMs, but in 2.0 the pool of memory is dynamically allocated and removed based VM usage with no service interruption. Dynamically allocating memory to VMs can drastically improve host consolidation rates.

Hyper-V 2.0 VMs are configured with an initial RAM setting (how much the machine boots with) as well as minimum and maximum RAM values. Hyper-V then adds RAM using the Hot-Add function, and removes it using a balloon driver (for supported OSes).

For the visual learners in the crowd, take a look at this VM configuration dialog:

Note that this is nothing like Transparent Page Sharing in VMware ESX — Hyper-V VMs would actually be reconfigured using hot-add memory, so the guest operating systems must cooperate.

In an interview with Steven Bink, even Bob Muglia acknowledged the need for overcommit:

We talked about Vmware ESX and its features like shared memory between VMs, “we definitely need to put that in our product” later [Muglia] said it will be in the next release. Like hot add memory, disk and nic’s will be and Live migration of course, which didn’t make it in this release.

By the way, hot-add memory didn’t make it into Hyper-V R2, either — VMware ESX 4 has it today.

Quick Memory Overcommit?

Evidently, dynamic memory was not even up to the rigorous “Quick” standard and was dropped from the release train. Perhaps in some future edition of Hyper-V, Quick Memory Overcommit will be offered — with just a few seconds of VM downtime as RAM allocation is dynamically adjusted. But that’s just speculation.

Sour Grapes

Instead of finding a way to implement memory overcommit in Hyper-V R2, Microsoft has taken the alternate approach of attacking VMware and declaring the feature unnecessary, unsafe, or too expensive.

The fact is that memory overcommit is an extremely valuable capability and VMware ESX has had it all along. Some of the Linux-based hypervisors are starting to figure it out. Until Hyper-V finally adds the feature we’ll continue to hear how easy it is to simply buy more RAM.

How long can you afford to wait?

Leave a Comment • Subscribe to RSS • Subscribe via Email • Follow Eric Gray on Twitter
More articles on: ESX, Hyper-V, memory overcommit, vSphere • Browse All Virtualization Content
The Truth About Hyper-V Memory Overcommit by Eric Gray © 2010 • VCritical

vSphere issues? Ask VMware.

Eric Gray — Wed, 06 Jan 2010 23:26:21 +0000

A new feature in VMware vSphere 4 provides additional information for certain warnings and errors. When more help is available, “Ask VMware…” is displayed in the vSphere Client and clicking the link takes you to a specific VMware KB article.

From What’s New in VMware vSphere 4.0:

Enhanced ESX Error Reporting — vSphere 4.0 gives you the ability to report per-host network, storage and VMFS issues to the vSphere Client in the Events tab. Each error event also provides a link to a specific Knowledge Base article that explains the event and provides detailed remediation steps to resolve the error. vSphere 4.0 also has the ability to set specific alarms for such events, with the help of the Events and Alarms feature. See vSphere Basic System Administration.

I experienced the feature firsthand recently while reconfiguring some physical switches in my lab, causing the following event:

Clicking the link took me to KB 1009542 with much more specific detail about the warning.

Very nice enhancement.