Posts Tagged ‘vCenter Server’

vSphere Upgrade Path

October 11th, 2010

Old habits can be hard to break.  Such was the case today when I called out an individual for producing an ESXi 4.0 Update 2 upgrade document without referencing the requirement to upgrade vCenter 4.0 Update 1 to Update 2 first as a prerequisite. 

Up until the release of vSphere 4.0 Update 1 back in November of 2009, the VMware virtual infrastructure upgrade path was such that the vCenter Server was upgraded to the newer release, then the ESX(i) hosts were upgraded afterward.

As shown in the ESX and vCenter Server Compatibility matrix below, beginning with vSphere 4.0 Update 1, ESX(i) hosts can be upgraded ahead of their vCenter Server counterparts.  In fact, VMware allows a radically wider in versioning variation in that vCenter 4.0 (released May 2009, with no update) is compatible with ESX(i) 4.0 Update 2 which was released in June 2010, over a year later.

SnagIt Capture

After being corrected, I recalled hearing of this new compatibility some time back but the bits had fallen off the platter.  For the record, I’m not always right.  I’m fine with being wrong.  It happens plenty enough.  For me, it’s all about the learning.  Retaining the knowledge is an added benefit but isn’t always guaranteed if not used on a regular basis.

This mantra will provide some flexibility which may be needed to upgrade smaller groups of clusters or hosts (say for troubleshooting purposes) without impacting the centralized vCenter Server which in turn would impact the remaining clusters or hosts it manages by way of agent upgrades blasted out to each attached host.

Before you celebrate in the end zone Dallas Cowboys style, do note from the chart above that the upgrade to vSphere 4.1 reverts back to the old methodology of upgrading the vCenter Server first, and the attached ESX(i) hosts afterward.  In other words, ESX(i) 4.1 is ONLY compatible with vCenter Server 4.1.

Go Vikings!

Open in New Window

September 22nd, 2010

The VMware vSphere Client has a right-click menu option for most objects called Open in New Window

For instance, when right-clicking on a cluster object, the Open in New Window menu item appears:

SnagIt Capture

SnagIt Capture

SnagIt Capture

After choosing Open in New Window, a new vSphere Client window indeed appears.  Like many common tasks in the vSphere Client, this procedure has a shortcut key combination (CTRL + ALT + N).  Does this imply this is a commonly used feature? 

It’s not a commonly used feature by me.  To be honest, I didn’t know this feature existed until this week.  I was intrigued and played around with it for about 15 minutes.  First I tried to understand where this feature was presented.  I found it on most objects.  When I saw this, I looked for a way to exploit it.  The result was a rather anticlimactic failure.

This still left me wondering what the use case was for this feature.  There is one which comes to mind but I’m going to keep that to myself for now.  I’d like to hear from you.  Do you use this feature?  What are the use cases?  If you don’t use the feature, can you imagine a use case?  Open the vSphere Client and give it a try.  Be sure to try different infrastructure views.  There’s really no defined set of correct answers here, I’m looking for practical or creative ideas around the feature.

Respond in the comment section below.  The first responder with a relevant or interesting use case will be the winner of a VMware vSphere video training package from Train Signal.

vCenter Server JVM Memory

September 6th, 2010

For those of you who have installed VMware vCenter Server 4.1, have you noticed anything new during the installation process?  A new screen was introduced at the end of the installation wizard for specifying the anticipated size of the virtual infrastructure which the respective vCenter Server would be managing.  There are three choices here: Small, Medium, & Large.  Sorry, no Supersize available yet.  If you require this option, I’m sure VMware wants to talk to you.

SnagIt Capture

The selection you make from the installation wizard not only defines the Maximum Memory Pool value for the Java Virtual Machine, but also the Initial Memory Pool value.  Following is a chart which takes a look at vCenter Server 4.0 & 4.1 JVM Memory Configuration comparisions:

vCenter/JVM Initial Memory Pool Max Memory Pool Thread Stack Size
4.0 128MB 1024MB 1024KB
4.1 Small (<100 hosts, default) 256MB 1024MB 1024KB
4.1 Medium (100-400 hosts) 256MB 2048MB 1024KB
4.1 Large (> 400 hosts) 512MB 4096MB 1024KB

As noted by the table above, in vCenter Server 4.0, the JVM Maximum Memory Pool was configured by default at 1024MB.  The vCenter Server 4.1 installation also defaults to 1024MB (Small <100 hosts) if left unchanged. One other comparison – pay attention to the difference in Initial Memory Pool. By default, vCenter 4.1 uses twice the amount of RAM out of the gate than previous versions.

Although the installation wizard JVM tuning component is new in 4.1, the ability to tune the JVM for vCenter is not.  The Configure Tomcat application has been available in previous versions of vCenter.  Some organizations with growing infrastructures may have been instructed by VMware support to tune the JVM values to overcome a vCenter issue having to do with scaling or some other issue.

SnagIt Capture

SnagIt Capture

Judging from the table, one can assume that the 1024MB value was appropriate for managing less than 100 hosts in vCenter 4.0.  As a point of reference, the Configuration Maximums document states that 300 hosts can be managed by vCenter 4.0.  This would imply that managing 100 hosts or more with vCenter 4.0 requires an adjustment to the out of box setting for the JVM Maximum Memory Pool (change from 1024MB to 2048MB). 

With vCenter 4.1, VMware has improved scaling in terms of the number of hosts a vCenter Server can manage.  The Configuration Maximums document specifies vCenter 4.1 can manage 400 hosts but the table above implies VMware may be preparing to support more than 400 hosts in the near future.  And that’s awesome because vCenter Server sprawl sucks. Period.

So have fun tuning the JVM but before you go, a few parting tips:

  • The Initial Memory Pool value defines the memory footprint (Commit Size) of the Tomcat process when the service is first started.  The Maximum Memory Pool defines the memory footprint which the Tomcat process is allowed to grow to.  Make sure you have sufficient RAM installed in your server to accommodate both of these values.
  • Setting the Initial Memory Pool to a value greater than the Maximum Memory Pool will prevent the Tomcat VJM from starting.  I thought I’d mention that before you spend too much time pulling your hair out.
  • If you would like to learn more about tuning Tomcat, vast resources exist on the internet.  This looks like a good place to start.

Unable To Retrieve Health Data

September 5th, 2010

SnagIt CaptureA number of people, including myself, have noticed that after upgrading to VMware vCenter 4.1, the vCenter Service Status shows red and displays the error message:

Unable to retrieve health data from https://<VC servername or IP address>/converter/health.xml

VMware has provided a workaround to this issue in KB 1025010.  The workaround involves installing the ldp.exe application binary from Microsoft, however, since I’m running vCenter Server on Windows Server 2008 R2, the binary is already in place by default and no download and installation was required. I’ve applied the workaround and after a service restart and a brief wait, the Service Status health went completely green, which is desired.

It’s worth nothing for posterity that step 3a is missing a small piece which I have provided in red below:

Double-click DC=virtualcenter,DC=vmware,DC=int, then double-click
-OU=Health,DC=virtualcenter,DC=vmware,DC=int
-OU=ComponentSpecs,OU=Health,DC=virtualcenter,DC=vmware,DC=int
-CN=<GUID>.vpxd,CN=<GUID>,OU=ComponentSpecs,OU=Health,DC=virtualcenter,DC=vmware
-CN=com.vmware.converter,CN=<GUID>,OU=ComponentSpecs,OU=Health,DC=virtualcenter,DC

OVF? OVA? WTF?

July 2nd, 2010

If you’ve worked with recent versions of VMware virtual infrastructure, Converter, or Workstation, you may be familiar with the fact that these products have the native ability to work with virtual machines in the Open Virtualization Format, or OVF for short.  OVF is a Specification governed by the DMTF (Distributed Management Task Force) which to me sounds a lot like RFCs which provide standards for protocols and communication across compute platforms – basically SOPs for how content is delivered on the internet as we know it today.

So if there’s one standard, why is it that when I choose to create an OVF (Export OVF Template in the vSphere Client), I’m prompted to create either an OVF or an OVA?  If the OVF is an OVF, then what’s an OVA?

 7-2-2010 8-00-01 PM

Personally, I’ve seen both formats, typically when deploying packaged appliances.  The answer is simple: Both the OVF and the OVA formats roll up into the Specification defined by the DMTF.  The difference between the two is in the presentation and encapsulation.  The OVF is a construct of a few files, all of which are essential to its definition and deployment.  The OVA on the other hand is a single file with all of the necessary information encapsulated inside of it.  Think of the OVA as an archive file.  The single file format provides ease in portability.  From a size or bandwidth perspective, there is no advantage between one format or the other as they each tend to be the same size when all is said and done.

7-2-2010 8-13-26 PM

The DMTF explains the two formats on pages 12 through 13 in the PDF linked above:

An OVF package may be stored as a single file using the TAR format. The extension of that file shall be .ova (open virtual appliance or application).

An OVF package can be made available as a set of files, for example on a standard Web server.

Do keep in mind that which ever file type you choose to work with, if you plan on hosting them on a web server, MIME types will need to be set up for .OVF, OVA, or both, in order for a client to download them for deployment onto your hypervisor.

At 41 pages, the OVF Specification contains a surprising amount of detail.  There’s more to it than you might think, and for good reason:

The Open Virtualization Format (OVF) Specification describes an open, secure, portable, efficient and extensible format for the packaging and distribution of software to be run in virtual machines.

Open, meaning cross platform (bring your own hypervisor).  Combined with Secure and Portable attributes, OVF may be one of the key technologies for intracloud and intercloud mobility.  The format is a collaborative effort spawned from a variety of contributors:

Simon Crosby, XenSource
Ron Doyle, IBM
Mike Gering, IBM
Michael Gionfriddo, Sun Microsystems
Steffen Grarup, VMware (Co-Editor)
Steve Hand, Symantec
Mark Hapner, Sun Microsystems
Daniel Hiltgen, VMware
Michael Johanssen, IBM
Lawrence J. Lamers, VMware (Chair)
John Leung, Intel Corporation
Fumio Machida, NEC Corporation
Andreas Maier, IBM
Ewan Mellor, XenSource
John Parchem, Microsoft
Shishir Pardikar, XenSource
Stephen J. Schmidt, IBM
René W. Schmidt, VMware (Co-Editor)
Andrew Warfield, XenSource
Mark D. Weitzel, IBM
John Wilson, Dell

Take a look at the OVF Specifications document as well as some of the other work going on at DTMF. 

Have a great and safe July 4th weeekend, and congratulations to the Dutch on their win today in World Cup Soccer.  I for one will be glad when it’s all over with and our Twitter APIs can return to normal again.

vSphere Upgrade Prerequisites Checklist

May 27th, 2010

Upgrading your virtual infrastructure to vSphere?  Be sure to check out this handy reference from VMware:  vSphere Upgrade Prerequisites Checklist.  There are several areas which need to be considered and this document covers them all, including both requirements and recommendations.  If you’re a consultant who visits new customer sites on a regular basis, it wouldn’t be a bad idea to bring this with to each engagement, or at least a condensed version of it.

Happy Birthday vSphere!

May 21st, 2010

birthday-cake

I was reminded by today’s vCalendar page that vSphere was launched by VMware one year ago today.  Happy Birthday Buddy – you set the bar which all other hypervisors aspire to be at one day.

On this day in 2009, VMware vSphere, the next generation datacenter virtualization product and successor to Virtual Infrastructure 3 (VI3), was released boasting approximately 150 new features, new license tiers, and an amazing 350,000 I/O operations per second (IOPS). vSphere is a 64-bit only ESX host OS.

Don’t have a vCalendar yet?  Get one!