VMware

PowerCLI: Adding New PortGroups

I’m sure that someone somewhere has written a script exactly like this in the past but I wanted to write my own for a number of reasons. While I’ll probably never be a PowerCLI hero, it really doesn’t hurt to keep in practice and hone your skills.

Let’s start with what I want to accomplish. I’m working with an ESX 3.5 web hosting environment and there’s a new project in the pipelines. A brace of new servers are required and they’ll be on a new VLAN. The VLAN has been created and configured on the various switches that the ESX hosts connect to but now of course a corresponding PortGroup is required. (Actually two are needed – complex project.) Now we’re not talking about a huge number of hosts here. It would probably only take 10 minutes to do it by hand using the VI client. It’ll take me longer to write this post! However, it is something that happens relatively often in this environment so it’s worth taking the time to write a script. More >

Review: vSphere 4.0 Quick Start Guide

I was planning to do this over the Christmas break but I hardly turned my computers on. I did pop a quick review on Amazon but I wanted to expand on it a bit.

I first heard about the book in the run up to VMworld 2009 back in September. I would very much have like to go but could not. I gather that some preview copies of the book were given away there. Luckily I know and live quite close to one of the authors and managed to get my hands on a copy. I can’t recall what my expectations were but the book that I started reading that night was easier to read and more compelling than anything that I’d picked up for a while.

The structure of the book is fairly loose – there are no chapters. It is broken down into different sections covering vCenter, Networking, Storage etc and in turn each of those is broken down into sub topics. These take the form of FAQ type questions that are then answered or are descriptive sections of text. Throughout the book are helpful scripts or commands that can be used, the majority being written in PowerShell.

The quality of the content is very high and should appeal to seasoned vExperts and relative beginners alike. While reading it I certainly found areas where my knowledge was rusty or non-existent and many other areas where the book will serve as a handy reference when I can’t remember something. And given the size of the book (~240 pages and pocket sized) it’s very easy to carry around.

There is talk of further titles coming from the same authors and if this volume is indicative of the quality that we can expect then I am looking forward to seeing more. I also hope that it inspires other people to consider sharing their knowledge like this.

VMTools Version Mismatch

Before I get started, I just want to say that I don’t know for sure if this is an issue that is causing problems for some VMs that I have been looking at or not. I’d welcome any feedback, comment or help anyone has to offer on the topic. I thought that I’d share this just in case it helps anyone at any point.

The environment that I’ve been working in is a shared web hosting platform built on ESX 3.5 and vCenter 2.5. Recently the focus of effort has been on data centre migrations, service migrations and office moves. Business as usual (BAU) activities have taken a back seat because of resource constraints. That includes upgrading the virtual infrastructure to the latest version. Currently vCenter is at Update 4 (build 147633) and needs to be brought up to date following the release of Update 5 a few weeks ago. The ESX hosts are slightly further downlevel however. Two thirds of them are on Update 3 (build 123630) with a couple of extra patches applied to bring them up to build 143128. The other third is on Update 2 (build 110268).

Windows Server 2008 R2 has recently started to be used for some of the VMs and this is not officially supported until Update 5. Some of these VMs have had minor issues, things like random slowness and occasional failures to remove snapshots following their scheduled backups. While looking into these issues I discovered quite a variety of VMTools versions being used.

Ideally all ESX hosts in a cluster should be on the same update level. The version of VMTools that a VM uses should ideally match the lowest build version of ESX that is being used in a cluster as the VM could potentially run on any host in the cluster. On one VM vCenter said that the VMTools version was “OK” but I wanted to run a manual “Install / Upgrade” on the VMTools anyway just to run a repair and make sure that the drivers were installed correctly. When I tried to do this, the installer popped back an error stating that a newer version was already installed.

That got me thinking, which versions are installed on all the VMs? Now I could have used the excellent RVTools or something like that or I could craft my own brief PowerCLI script. I couldn’t resist the latter…

$vmhosts = get-vmhost | sort Name

$myCol = @()
foreach ($vmhost in $vmhosts)
{
   $vmhostdetail = $vmhost | get-view
   $versionmajor = $vmhostdetail.config.product.version
   $versionbuild = $vmhostdetail.config.product.build
   $vms = $vmhost | get-vm | sort Name
   foreach ($vm in $vms)
   {
      $myObj = "" | Select Host,Version,Build,Guest,ToolsVersion
      $vmdetail = $vm | get-view
      $vmtoolsversion = $vmdetail.config.tools.toolsversion
      $myObj.Host = $vmhost.Name
      $myObj.Version = $versionmajor
      $myObj.Build = $versionbuild
      $myObj.Guest = $vm.Name
      $myObj.ToolsVersion = $vmtoolsversion
      $myCol += $myObj
   }
}

$myCol | Export-Csv -NoTypeInformation "C:\VMToolsVersions.csv"
ii "C:\VMToolsVersions.csv"

Running this script produces a CSV file with a line for each VM show the host, host version and build number, guest name and VMtools version for each VM. I’ve simplified the output that I got to remove the host names and guest names and also I’ve removed duplicate combinations of version numbers. That just leaves the following:

screenshot_2009-12-18_08-22-28

This shows the different combinations of ESX hosts versions and VMTools versions being used. What’s very interesting are the VMs running VMTools version 164009. That is the build number for vSphere 4.0.0!

I know how this has come about. Rather than using templates, the preference here is to use a Windows ISO file that has been customised to be a practically unattended install that also includes a number of automatically installed applications. One of these is the VMTools installation. As there is a vSphere infrastructure here also the ISO has been modified to include the latest tools version so that one ISO fits all. But does it? The VMs are running butis the version of VMTools causing problems? That’s the bit that I don’t know the answer to yet. If anyone does know, please feel free to comment.

For now the way forward is going to be creating multiple ISO files or removing the VMTools installation from the ISO altogether. That way new builds will get their VMTools installed from the ESX server that they’re running on. An upgrade to Update 5 is also called for and with next week looking to be a bit quieter I think that it’ll be planned then to be executed early in the new year.

SQL VM CPU Spikes

Some people still aren’t convinced by virtualisation and while it’s true that there are some situations that it’s not especially suited for they are relatively few in my experience. I know a few people who are yet to be convinced completely. One’s a SQL DBA and there are times when she has a point. I thought that this might be one of them until I started poking around.

screenshot_2009-12-04_18-25-21Initially I was asked about what was causing a SQL VM to respond slowly and use 100% CPU. I had a look in vCenter and while it looked slightly busy it didn’t seem over worked. As the graph to the right shows, it was using only about half of the available 3Ghz CPU it had access to. Perhaps I should explain further at this point that my client’s practice when it comes to VMs is to provision them with a single vCPU and add more if they are required. It seems that if this was normal load for the VM that 1 vCPU should be enough.

Looking back through the VM’s performance history I could see nothing particularly wrong either. Occasional CPU spikes in the past possibly indicating reboots or overnight processing. Oddly though there were random plateaus of activity for several hours at a time. Mostly overnight the VM would idle along using practically no CPU resource but during the day there were long periods where it looked a lot like the activity above. Time to look at the guest OS.

The picture inside Windows is slightly different. Opening up task manager shows frequent bursts of 100% CPU usage (see below). Actually you could call them regular. And, more worringly, it transpires that the server is not yet in production – it’s still being configured.

screenshot_2009-12-04_18-18-30

The offending process is services.exe so it’s not immediately obvious what the issue is. Purely by coincidence I asked the DBA if she could log off for a while so that I could look into what was going on. When she did, the strangest thing happenned:

screenshot_2009-12-04_18-27-18

See how the CPU usage dropped back down to idle and stayed there. That begged the question “What were you running?”.

It turns out that the culprit was none other than SQL Management Studio. When opened and connected it polls the server’s status every 10 seconds. Strangely though, instead of polling just the SQL services it polls all services on the server (this can be seen using Process Monitor) which seems a bit excessive to me. Due to the way that hypervisors share resources, what would be a small blip on a physical host is magnified within the VM somewhat. Microsoft have acknowledged that this happens but to my knowledge haven’t done much about it. There is a registry key that can be modified to adjust Management Studio’s behaviour. For SQL 2005 SP1 onwards (it’s not available before that) it is:

HKLM\Software\Microsoft\Microsoft SQL Server\90\Tools\Shell\PollingInterval

Setting it to 600 will reduce the frequency of polls to once a minute. Alternatively, just don’t leave SQL Management Studio open longer than you have to and wait for Microsoft to fix it.

ESX 3.5 U5

I mentioned ESX 3.5 Update 5 only yesterday in my post about VMtools on Windows 2008 R2. Little did I know that 16 hours later I’d be writing about it again to say that it had been released!

The update can be downloaded from VMware’s website as usual. Shamelessly copied from the release notes, here’s what you can expect to have changed:

Enablement of Intel Xeon Processor 3400 Series – Support for the Intel Xeon processor 3400 series has been added. Support includes Enhanced VMotion capabilities. For additional information on previous processor families supported by Enhanced VMotion, see Enhanced VMotion Compatibility (EVC) processor support (KB 1003212).

Driver Update for Broadcom bnx2 Network Controller – The driver for bnx2 controllers has been upgraded to version 1.6.9. This driver supports bootcode upgrade on bnx2 chipsets and requires bmapilnx and lnxfwnx2 tools upgrade from Broadcom. This driver also adds support for Network Controller – Sideband Interface (NC-SI) for SOL (serial over LAN) applicable to Broadcom NetXtreme 5709 and 5716 chipsets.

Driver Update for LSI SCSI and SAS Controllers – The driver for LSI SCSI and SAS controllers is updated to version 2.06.74. This version of the driver is required to provide a better support for shared SAS environments.

Newly Supported Guest Operating Systems – Support for the following guest operating systems has been added specifically for this release:

For more complete information about supported guests included in this release, see the VMware Compatibility Guide: http://www.vmware.com/resources/compatibility/search.php?deviceCategory=software.

  • Windows 7 Enterprise (32-bit and 64-bit)
  • Windows 7 Ultimate (32-bit and 64-bit)
  • Windows 7 Professional (32-bit and 64-bit)
  • Windows 7 Home Premium (32-bit and 64-bit)
  • Windows 2008 R2 Standard Edition (64-bit)
  • Windows 2008 R2 Enterprise Edition (64-bit)
  • Windows 2008 R2 Datacenter Edition (64-bit)
  • Windows 2008 R2 Web Server (64-bit)
  • Ubuntu Desktop 9.04 (32-bit and 64-bit)
  • Ubuntu Server 9.04 (32-bit and 64-bit)

Naturally you’ll need to upgrade vCenter to Update 5 to gain some of these benefits. The release notes for that mention only one significant enhancement:

Support for High Consolidation in VMware HA Clusters – VirtualCenter 2.5 Update 5 includes significant performance and scalability improvements to VMware HA. Use VirtualCenter 2.5 Update 5 for environments with more than 35 virtual machines per host in an HA cluster.
For information on the ESX Server host settings required for this scalability improvement, see ESX Server host settings required for environments with up to 80 virtual machines per host in an HA Cluster (KB 1012002).

I think that there is a good chance that Update 5 may be the last major update that the 3.5 line of products receives. Or at least it will be for some time. I’ll have some upgrades to do as a result of this release but I’m pushing for upgrades to vSphere like crazy. You know it makes sense.