Archive for the ‘Virtualization’ category

VMware VI network communications and port usage diagram

November 6th, 2008

Nigel Metheringham has taken the information I posted here and updated it with information from page 179 of the VMware ESX Server 3 Configuration Guide

The result is a current diagram of VMware Virtual Infrastructure network communications and port usage which applies to both ESX and ESXi.  Nigel sent me the updated document via email so that I can update the information on the VMware Communities, however, they are currently unavailable due to planned maintenance so in the mean time I’m making the document available here.  Thank you Nigel!

Download from the link below:


Will our children know what DAS stood for?

November 6th, 2008

Duncan Epping of the highly talented VMware employee pool and Yellow Bricks stardom has released for us a great VMware High Availability (HA) Implementation Notes document. In it, you will find some advanced configuration options for VMware HA – real good stuff that is sure to put your significant other to sleep.

Throughout the document, “das.” appears. What is das and what does it have to do with high availability? For the sake of my kids (whom I hope grow up to be virtualization evangelists and successors to my blog), I’ll explain. Back in the days of the VI3 beta, DAS was an acronym for Distributed Availability Service. But it was not to see the light of day, for VMware often becomes discontent with technology names and acronyms, usually after the labels have already been permanently etched in documentation, books, hundreds or thousands of lines of code, and our brains.

  • .dsk files became .vmdk files
  • DAS became HA
  • ESX Server became ESX
  • Most recently, Continuous Availability became FT (Fault Tolerance)

7-30-2010 9-53-34 AM

So as seen in the examples above, DAS is nothing more than the “old” name for HA. Apparently, there is more to updating code than using “find and replace” so VMware opted to leave das. configuration instances in the HA product that exists today.

It’s hard to second guess the creative minds at VMware.  Maybe they thought DAS would be confused with DRS which was releasing at the exact same time.  They would have been right.  There are still people walking around today that explain DRS as “Dynamic Resource Scheduler” which is incorrect and drives me up the wall.  Distributed.  Distributed.

Hyper9 – All admins are worth saving (even the bad ones)

November 6th, 2008


It looks like @gabvirtualworld can keep his job. He’s been using the beta version of Hyper9 which intuitively discovered that he had three VM snapshots open for nearly a year. Hey, anyone can forget. To forget is human. Forgetting about snapshots doesn’t make you a bad admin, but Hyper9 can make you a better one.

See what Hyper9 is all about and grab one of the few remaining beta program invites today!

Microsoft Windows x64 (64-bit) and the VI

November 4th, 2008

32-bit computing is still very much alive, well, and very much supported today which may be one of the primary reasons you have not investigated 64-bit yet or invested the time it takes to migrate your software and/or servers to 64-bit architecture.  Part of the adaptation process is learning and understanding the underlying mechanics behind a technology to be sure it makes good sense from an economical, roadmap strategy, and business need standpoint.  I think 64-bit is one of those technologies that is so deep and covers so much territory that there is a chance for the spread of misinformation. 

As VMware Administrators, at one point or another our careers intersect with Microsoft Windows technologies.  For some like myself, the Windows experience is a daily tradition.  Everyone who is running VirtualCenter is using Microsoft Windows as both the server and client platform.  VMware Update Manager users are using Windows.  License Manager runs on Windows.  Even those without VirtualCenter are probably using the Virtual Infrastructure Client which runs on Windows.  My point is that although this is mainly a VMware virtualization centric blog, we can’t completely ignore Windows.  Understanding the benefits that 64-bit Windows technologies provides might help our virtual infrastructures run faster and more efficiently.  In the long term, I think it’s going to allow our VI to scale up.

Fortunately for those who have not yet rolled up their sleeves and gotten dirty with 64-bit, there’s an IT Architect by the name of Helge Klein who has written an absolutely fantastic seven part series entitled “Windows x64 – All the Same Yet Very Different” in terms that I think most of us can understand.  Even if you’re not a big fan of Windows, some of the content is universal and applies to many platforms.  If you maintain a 3-ring binder of good stuff you’ve found on the internet, I think this series would belong there.

SSL integration with VirtualCenter

November 4th, 2008


Are you tired of seeing the Security Warning splash screen when launching the Virtual Infrastructure Client to connect to VirtualCenter?  Do you feel a sense of guilt clicking the Ignore button or checking the “Do not display any security warnings for…” box?  Are you flirting with real world dangers or risking termination for fostering a less secure virtual infrastructure?  Would you like to correct the situation the right way by integrating SSL certificates and securing VIC/VirtualCenter communication at the same time?  Here are the step by step instructions (originally created by VMTN forum member astrolab and refined by myself).

In this exercise, I’ll be using a Microsoft Active Directory integrated enterprise certificate authority (CA) to generate a certificate for the VirtualCenter host which resides in the same AD domain.  We’ll begin with the assumption that the enterprise CA has already been built as well as the VirtualCenter Management Server (VCMS).  We will also assume that the enterprise CA is listed as a Trusted Root Certification Authority on the client that will be connecting to the VCMS via the VIC.  To validate this in Internet Explorer, choose Tools|Internet Options|Content|Certificates|TRCA tab

  1. Download and install Win32 OpenSSL Light onto the VCMS
  2. Back up the existing RUI.CRT, RUI.KEY, and RUI.PFX files located in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\
  3. Generate an RSA private key and a certificate-signing request (the openssl binary comes from the installation of Win32 OpenSSL Light in step 1 above)
    1. From a command prompt, change to the C:\openssl\bin\ directory and issue the command openssl genrsa 1024 > rui.key
    2. From a command prompt, change to the C:\openssl\bin\ directory and issue the command openssl req -new -key rui.key > rui.csr
      1. Provide the appropriate information.  Your Name/Common Name is the FQDN of your VCMS (ie.
  4. Request a certificate from the Microsoft enterprise CA
    1. In an IE browser, browse to http://enterprise_ca_domain_controller/certsrv/
    2. Click Request a certificate
    3. Click advanced certificate request
    4. Click Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file
    5. Open the rui.csr file with MS wordpad and copy the entire contents (including the BEGIN and END lines) into the “Saved Requst” field of the certificate request in the web browser.  Alternatively, you can click the “Browse to insert” link to simply attach the rui.csr file
    6. Change the Certificate Template to Web Server
    7. Click the Submit button
    8. On the next screen, choose “Base 64 encoded” and click the “Download certificate” link
    9. When prompted, save the certificate to C:\openssl\bin\  with the file name rui.crt
  5. Create a .pfx (personal individual exchange) file for rui.crt on the VCMS
    1. From a command prompt, change to the C:\openssl\bin\ directory and issue the command openssl pkcs12 -export -in rui.crt -inkey rui.key -name -out rui.pfx
  6. Move rui.cft, rui.key, and rui.pfx from C:\openssl\bin\ to C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\
  7. Disconnect all ESX hosts from the VCMS (you can safely leave the guest VMs running or whatever state they are in).  This step needs to be done because after the VCMS loads the new certificates, it will not be possible to gracefully shut down the VMs from the VIC, though it could still be done through RDP or COS.  It’s best to perform this step to avoid future headaches.
  8. Stop the VMware VirtualCenter Server service
  9. From a command prompt, change to the C:\Program Files\VMware\Infrastructure\VirtualCenter Server\ directory and issue the following command to re-encrypt the VCMS database password):  vpxd -p (when prompted, type the password used for the VCMS database)
  10. Start the VMware VirtualCenter Server service
  11. Reconnect all ESX hosts
  12. The steps are complete, but there is one important note going forward that deals with the inherent behavior of certificates and our certificate request outlined above:  Use the Virtual Infrastructure Client to connect to the VirtualCenter Management Server using the FQDN (ie.  You can connect to the short NetBIOS name of the VCMS but at that point your connection won’t be covered by your certificate and you’ll once again receive the Security Warning dialogue box shown at the beginning of this article.

Hyper9 beta invitations available

November 3rd, 2008

Hyper9 feels the pain of the virtual administration world, and is building a product that will change the way things are done forever. Currently in beta testing, the new Hyper9 product addresses all of the challenges above and then some, and is receiving rave reviews from those who have already put it to work. In short, those who’ve seen it agree – Hyper9 is about to rock the world of virtualization administration.”

The Hyper9 beta program is currently full, however, I’ve been extended the opportunity to offer exclusive beta invitations to a limited number of people. If you are interested in joining the beta program, please contact me.

There are a few guidelines and requirements to becoming full members of the Beta experience, and I hope you are able to meet these.

Beta Participant Minimum Environment Requirements

  • VMwareä ESX 3.0+
  • (1) VMware VirtualCenter Instance
  • (2) VMware ESX Host Servers

· (20) Virtual Machines

Additional Requirements

  • If selected, you must download and install the software within five (5) days of receiving the beta software. Can you do this?
  • When you have completed the installation process of Hyper9’s software, we ask that you notify us that this action has been completed. Can you do this?
  • Users from competitor companies are not eligible for participation.
  • Users will have to provide Hyper9 with their company’s name and Web site information.
  • Users will have to provide Hyper9 with their company email address for verification.

63% not utilizing Resource Pools

November 2nd, 2008

A one month long Virtual Infrastructure poll wrapped up over on the VMware VMTN Community forums and produced some intuitive findings. The poll results reflect that the majority of respondents are not using or not effectively utilizing VMware Resource Pools. Myself included. To tell the truth, I have the resource pools set up (shares configured only, no reservations or limits), but we’re not pushing the virtual infrastructure hard enough for them to provide the benefit they were designed to deliver which is guaranteed resource allocation and resource allocation weighting in a heavily used infrastructure where there is resource contention.

What does this mean? In my case, and I’ll go out on a limb and suspect much of the same is true in other environments, the virtual infrastructure isn’t filled to the capacity that it was designed to handle. More virtualization is needed.

A link to the poll: