VMware vSphere 5 License Reporting

The new vSphere 5 licensing model is accompanied by a new licensing report that allows customers to query vRAM utilization.  Although this report is accessed through the standard vSphere Client, it is based on the next-generation Flex framework and served up via the vSphere Web Client — a server normally used by end-user web browsers.  The report looks like this:

VCVA License Reporting Bug

Conveniently, the VCVA comes with the Web Client already installed.  Unfortunately, a small workaround is needed before the license reporting feature can be used on the VCVA, which shows the following error by default:

While the actual bug is in the vSphere Client, the workaround is to re-register the Web Client from the command line on the VCVA.  Keep in mind the default username/password for the VCVA are root/vmware, shown below — please change yours.  To fix the reporting issue, log in via SSH and run the following commands, which will prompt interactively for confirmation:

# /usr/lib/vmware-vsphere-client/scripts/admin-cmd.sh unregister https://`hostname`:9443/vsphere-client localhost root vmware
# /usr/lib/vmware-vsphere-client/scripts/admin-cmd.sh register https://`hostname`:9443/vsphere-client localhost root vmware

Here is the process in action:

After re-registering the vSphere Web Client, the license report will work as expected.

Related posts:

1. VMware vCenter CapacityIQ 1.0.1 for vSphere
2. Wanna see a million ESX licenses?
3. vSphere issues? Ask VMware.
4. Installing vCenter on Linux Technical Preview

What to do in a heterogeneous environment?  This can be a challenge for PXE because it requires DHCP — it is difficult to have more than one PXE server on a network. While it is possible to configure a WDS server to install non-Windows operating systems, NFS support can be an issue.  Besides that, do you really want to install Linux via IIS?

Deploying a Linux system configured with DHCP, TFTP, HTTP, and NFS on a separate VLAN is certainly one approach.  But wouldn’t it be convenient if the WDS and Linux PXE servers could coexist peacefully on the same network?

There is a way…

As it turns out, thanks to the lesser-known pxechain utility, it is possible to seamlessly jump from one PXE host to another.  With a few tweaks to your WDS server, you can continue to use it for Windows OS installs and bounce over to a Linux host for Linux, ESXi, or rescue-CD purposes.

Windows Deployment Server Modifications

To make this possible, alter WDS to serve up a PXELinux menu with options to either proceed with WDS or jump over to a Linux PXE server:

• Download Syslinux 3.86 and extract to a temporary location
• Copy the following three files directly to your WDS x64 boot directory, e.g., D:\RemoteInstall\Boot\x64\
  • core\pxelinux.0
  • modules\pxechain.com
  • com32\menu\menu.c32
• Make duplicate copies of these existing WDS files (should already be present in directory above); they need to have “zero” as the extension
  • pxeboot.n12 -> pxeboot.0
  • abortpxe.com -> abortpxe.0
• Create a directory in x64 named “pxelinux.cfg”
• Create a new text file: x64\pxelinux.cfg\default with the following as a guide:

DEFAULT menu.c32
MENU TITLE WDS PXE Server

LABEL wds
MENU DEFAULT
MENU LABEL Windows Deployment Services
KERNEL pxeboot.0

LABEL abort
MENU LABEL Abort PXE
Kernel	abortpxe.0

LABEL linuxpxe
  MENU LABEL Linux PXE server...
  KERNEL pxechain.com
  APPEND 192.168.4.33::pxelinux.0
  #IP address above is Linux PXE host

To activate, run these two commands from a command prompt on the WDS server:

wdsutil /set-server /bootprogram:boot\x64\pxelinux.0 /architecture:x64
wdsutil /set-server /N12bootprogram:boot\x64\pxelinux.0 /architecture:x64

Action!

Boot a machine from the network and you should get a PXELinux menu that offers a choice:

One other note: the Linux PXE server doesn’t actually need to be on the same network, it just needs to be reachable from the client.

What’s your preferred PXE deployment scenario?

Related posts:

1. VMware ESXi 5 Interactive PXE Installation Improvements
2. Which guest operating systems can be customized by SCVMM?
3. Installing vCenter on Linux Technical Preview
4. Getting eth0 back in a SLES for VMware clone

When initially announced last year, access to SLES and ongoing patch downloads were offered to customers that purchased vSphere after June 9, 2010.  With this recent change, VMware is extending rights to SLES for practically all customers current on SnS.

Please see the official VMware announcement for all the details.

Related posts:

1. SLES for VMware – First Look
2. Installing VMware Tools OSPs in SLES for VMware
3. Getting eth0 back in a SLES for VMware clone
4. What is Red Hat Enterprise Virtualization?

It’s a simple fact: VMware vSphere supports many more guest OSs — dozens more — than Hyper-V.  Microsoft defends their short list by claiming that they provide full support for the guest operating systems.  Sounds like a pretty convincing argument.  But is it true?

Microsoft is also quick to point out that they only support two Linux distributions because those are the only ones for which they can truly provide full support.  They are trained to work with specific versions of Red Hat and SLES and won’t bounce you around between vendors if there is a problem.  At least that’s the theory.

Many from the Microsoft Virtualization team, including Ben Armstrong, have articulated the policy in a number of venues, even right here on VCritical, explaining:

If you have an issue with SuSE on Hyper-V and contact Microsoft product support – our support engineers will work directly with the Novell support engineers to solve the problem.

We will not bounce you between the two companies to try and find where the fault actually lies.

Certainly sounds feasible.

Linux on Hyper-V: Can we fix it?

I recently ran into a networking issue after cloning a SLES 11 VM on Hyper-V and thought it would be a good time to see what would happen if I opened a case with Microsoft Support for assistance.  Since the problem was not related to a production outage, I was categorized as “severity C” — they would call me back after A and B were taken care of.

The next day, a support engineer called me to troubleshoot and, in in the interest of speeding thing along, I agreed to let him log into my server remotely.

If only I would have noticed the disclaimer on their remote support tool:

The Microsoft engineer checked a few things and determined that everything was working properly with Hyper-V but had no idea how to troubleshoot the Linux guest.  He put me on hold a few times to discuss the situation with his technical lead and management, finally asking if he could follow up the next day after doing more research.

Later that evening, I received a status update email with this clarification:

Scope Agreement: In this case we can provide our best effort support. we will work on Hyper-V and if there is nothing wrong with the Hyper-V settings and configuration we will consider the case resolved.

The next day, the engineer called me again and explained that they were not trained on Linux and could not troubleshoot the issue.  His manager joined via conference call and admitted that they can’t fix third party issues.  He apologized for the situation and emphasized that Microsoft would not charge me for the incident.

Sure enough, the next day I was notified via email that the case was closed:

Cause – Could not diagnose the issue as it was Third party server (LINUX).

Resolution – Unresolved

Although the support engineer did poke around my Hyper-V host, he never once touched the guest — where the problem was.  Evidently, basic Linux troubleshooting is beyond the scope of Microsoft Support and crediting the charges for this incident is further proof that they are not up to the task of fully supporting non-Windows operating systems.

Microsoft Marketing vs. Reality

The Hyper-V guys were sure right about one thing: they won’t bounce customers around between vendors.

But seriously, all this talk about “fully supporting guest operating systems” is pure nonsense.  Your mileage may vary, but considering Microsoft Support spent several days collaborating on this case before giving up, I suspect it is far from an isolated incident.

Few enterprises have the luxury of standardizing on a tiny set of operating systems.  If your datacenter requires exceptional support for a wide range of environments — get VMware vSphere.

No Microsoft support engineers were harmed in the making of this article.

Related posts:

1. Even GPL can’t make Hyper-V Linux VMs well
2. Hyper-V Linux integration components no longer Connected
3. Hyper-V Linux Smokescreen
4. Linux apps run directly on Windows with virtualization!

After cloning a Linux VM, you might find your network interface is no longer named eth0, taking on eth1 instead.  Fortunately, this doesn’t cause any functional problems with the guest and can be left as-is.  However, if you are not satisfied with this scenario, read on…

SLES for VMware, which is SLES 11 SP1, uses udev to provide persistency to various devices.  While this model is regarded by most as a big step forward from the semi-random device name assignments of the past, one side-effect is that a new MAC address — pertinent when cloning VMs — is regarded as an additional interface and not a replacement.  Thus, a newly-cloned SLES VM powers up with eth1 as the NIC name, not eth0.

Fortunately, this situation is easy to fix.  Simply log into the VM and edit:

/etc/udev/rules.d/70-persistent-net.rules

Which should look something like this:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:97:00:35", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
 
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:50:56:97:00:38", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

In the above example, the first line contains the MAC address of the original template VM and the second line is the new NIC/MAC found in the clone.

There are two ways to fix this issue:

• Completely delete the file — it will be created again on boot and the first NIC will be assigned eth0, OR
• Delete the line containing the old entry that references eth0 and change “eth1″ to “eth0″ in the remaining line.

Note: if a static IP has been configured, go to /etc/sysconfig/network/ and update the files ifcfg-eth0 and route accordingly.

Reboot the VM and verify that the NIC(s) are named to your liking.

No real breaking news here, but given the newly available SLES for VMware, some evaluators may run into this situation.

Related posts:

1. Installing VMware Tools OSPs in SLES for VMware
2. SLES for VMware Entitlement Expands Broadly
3. Start and Manage a VM Without Using vSphere Client
4. SLES for VMware – First Look

In this article, I will walk you through the process of installing VMware Tools on SLES for VMware using the VMware Operating System Specific Packages (OSPs).   These pre-built packages are designed especially for the most popular Linux distributions so that native package managers can be used.  The package manager for SLES is called zypper.

Traditionally, Tools are installed from one of several ISO images that ship as part of VMware vSphere.  While it may be tempting to install VMware Tools on SLES for VMware using the vSphere Client, do not do this:

Unless you have software development packages installed in your guest OS — not a great strategy for production servers — the VMware Tools installation will not succeed.  Part of the installation requires gcc to compile kernel modules and will fail:

This is where OSPs come in.  Setting them up is not a challenge for experienced Linux administrators — the OSP documentation clearly explains how to configure everything.  Here is the process to get Tools up and running on SLES for VMware:

# wget http://packages.vmware.com/tools/VMWARE-PACKAGING-GPG-KEY.pub
 
# rpm --import VMWARE-PACKAGING-GPG-KEY.pub
 
# zypper addservice --type=YUM http://packages.vmware.com/tools/esx/4.1latest/sles11sp1/x86_64 vmware-tools-collection
 
# zypper install -c vmware-tools-collection vmware-tools
 
# reboot

And here is part of the process in action:

After rebooting the VM, the vSphere Client will report that VMware Tools are Unmanaged.  This may be an unfortunate choice in terminology, but what it means is that Tools did not come from the vSphere ISO images — they are OSP Tools.

VMware Tools provide optimized drivers for guest operating system devices as well as the balloon driver needed to overcommit memory.  Hopefully this overview gives you a jump start on getting the most out of SLES for VMware.

Related posts:

1. SLES for VMware – First Look
2. SLES for VMware Entitlement Expands Broadly
3. Network World weighs in on SCVMM-VI3 Management
4. Getting eth0 back in a SLES for VMware clone

The agreement also calls for VMware to begin using SLES for VMware as the base OS for virtual appliances.

Tour de SLES

Let’s take a look at how to get started.

Initial ISO boot menu:

Midway through the installation wizard, downloading latest patches:

Login screen with VMware branding:

SLES for VMware default desktop:

Parting Thoughts

I’m excited about this new arrangement and have recently started using SLES for some internal projects with no loss of productivity, having come from a Red Hat background.

In case you are wondering why VMware did not choose another distribution, such as Ubuntu, it all came down to support for enterprise applications.  SLES is certified by more ISVs than any other Linux distribution, so customers can rest assured knowing that all critical workloads — CRM, database, middleware, and more — are all fully supported for production.

For more information, please review the FAQ.

Related posts:

1. SLES for VMware Entitlement Expands Broadly
2. Which guest operating systems can be customized by SCVMM?
3. What is Red Hat Enterprise Virtualization?
4. Dear Red Hat…

I know it’s been a while — I’ve just needed some time to process what happened between us.

It’s hard to believe that we’d end up here, after all we’ve been through together.  When I needed a service console to manage my hypervisor, you were my first choice — and you were always there for me.  Well, except for those times when I badly needed some upstream RPMs updated… but I’m over that now.  Just about.

But over the years you changed and you are just not the distro I once knew.  I tried to look the other way when you started running around with Xen.  I knew it wouldn’t last.  Talk to Xen much anymore?  I didn’t think so.

How could you drag licensing into the picture?  For all the talk of open source this and GPL2 that, it never made sense that you would let anyone run unlimited RHEL guests only when you are a Xen Dom0 — but not when I am the hypervisor.  Isn’t a guest OS a guest OS?  I guess not.  You got selfish and frankly, people thought you were being a bully.

So you got tired of Xen and started looking around for satisfaction from another, huh?  How’s that KVM working out for you?  I hate to be the one to point this out, but your virtualization manager runs exclusively on Windows and is only accessible through Internet Explorer.  Have you completely forgotten that you are a Linux distribution! I hate for you to hear this from me, but Ubuntu and SUSE have been making fun of you for months.

You and your KVM are going to be too Linux-y for the Windows guys, and too Windows-y for the open source crowd.  I’m concerned about your reckless behavior.  That makes Red Hat Enterprise Virtualization the worst of both worlds.  You’re not thinking about hurting yourself, are you “RHEV”?  I would not even be surprised to find out that you use Bing as your search engine now.  Sorry, that was a low blow.

So you heard about the ESXi no-more-service-console thing, huh?  Well, I moved on, lost some weight, and am ready for the next phase now.

If you ever need a hypervisor to run on, you know where to find me.

Best friends forever,

VMware “Elastic Sky” ESX

[Disclaimer for the humor impaired: Eric Gray does not speak for VMware, nor does he speak for any personified software products.]

Related posts:

1. Red Hat Enterprise Linux is not Enterprise Virtualization
2. Red Hat Enterprise Virtualization: Pentium II Inside!
3. What is Red Hat Enterprise Virtualization?
4. Even GPL can’t make Hyper-V Linux VMs well

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!

Related posts:

1. Layers and Layers of FUD
2. Choose any two: Hyper-V, HA, Linux
3. Even GPL can’t make Hyper-V Linux VMs well
4. Does Microsoft really support Linux on Hyper-V?

I’d like to thank “Gostev” for commenting on that post with a link to the VCritical article on Hyper-V HA Linux VMs.  The Microsoft reply was especially interesting:

“Microsoft does not currently have integrated shutdown capability with Linux and will not have it when we release the Linux integration services (ETA Q3 CY’09). However, we will continue to enhance them with SMP support, integrated shutdown, key value pair exchange, and more and will release a version with these capabilities in the future. “

This new initiative still does not include Linux mouse support.  You need to download a separate package of Linux drivers from Citrix for that. Nor does Linux guest OS customization appear to be on the horizon.  How can Linux be a first-class citizen if administrators cannot deploy and customize new VMs from templates?

Here is the SCVMM user interface showing all of the integration services offered for Windows guests — none of them are available for Linux.  That means you still won’t be able to shut down a Linux VM from SCVMM.

The only enterprise-class virtualization solution that is ready for both Windows and Linux workloads is VMware vSphere — don’t believe the hype… or the Hyper-V.

On a related note, I am currently working on an article that covers templates and guest OS customization techniques for the top three virtualization platforms — please be sure to subscribe to the VCritical RSS feed if you are interested.

Related posts:

1. Hyper-V Linux Smokescreen
2. Hyper-V Linux integration components no longer Connected
3. Choose any two: Hyper-V, HA, Linux
4. Of Mice and Xen