vmroyale

I was recently involved in a situation where a development group at a SMB was tasked with consolidating two SQL servers into one. These SQL servers were physical servers running old versions of Windows, with equally old versions of SQL Server, on some pretty old hardware. The situation became interesting, when the development group put in the specifications request for the new virtual machine. The request was for a 64-bit Windows 2008 server with 8 GB of RAM, 4 vCPUs and over half a TB of FC SAN disk for storage.

This seemed like a bit of a tall order, so the first thing I did was to compare the specifications in the request with the specifications of the current physical servers. Server 1 had two Pentium III 1.2 GHz processors with 512 MB of RAM and 90 GB of used disk space. Server 2 had two Pentium III 1.0 GHz processors with 2 GB of RAM and 16 GB of used disk space. Even after ignoring the massive storage difference, the requested numbers didn't match up with the 4 vCPUs and 8 GB RAM specified in the request. Next I went to the system baselines, thinking that the systems might be overburdened. The baselines actually revealed that the systems weren't doing much work - 3% CPU average utilization, low disk IOPs, and very low network utilization. Using the perfmon SQLServer:Memory Manager -> Total Server Memory counter did reveal that the SQL servers were actually using the memory they were allocated. The numbers in the request still didn't add up though, and now with data in-hand, it was time to go talk to the requestors.

Ultimately it was discovered that this request was submitted this way to "allow for future growth." Many years ago this may have been standard practice with physical hardware, but in today's virtual environments it just no longer makes any sense. Based on the baseline data, the requested virtual machine could be built with 1 vCPU, 3 GB of memory and less than 100 GB of SATA disk space. If it turns out that the server actually needs more resources in the future, then these resources may be very quickly added with minimal or even no downtime. Gone are the days of provisioning everything up front while allowing room for future growth, hoping the server makes it to the next refresh cycle and then repeating the same process over again. To complement the virtual infrastructure, there must be an awareness of the way this technology fundamentally changes how systems are now provisioned.

Thanks for reading!

I recently was asked to patch an ESX 4 host for a customer. This customer did not make use of VMware's Update Manager, and the customer also wanted a simple set of instructions to be provided for use in future patching. Below is a simplified bullet-item version of the ESX 4 Patch Management Guide that I presented to the customer.

01:
On a Windows box, download the patch bundle directly from VMware. This will be .zip file.

02:
On a Windows box with the vSphere client installed, use the vSphere client's datastore browser to upload the .zip file to a datastore on an ESX 4 host.

03:
Obtain local console access, or SSH (putty), to the ESX 4 host that the bundle file was uploaded to.

04:
Verify that the ESX 4 host disk free space is acceptable (2X the size of the bundle), using the command:

05:
Move the bundle file off of the datastore and into /var/updates, using the command:


Note: The directory /var/updates is used in this document, but any directory on a partition with adequate free space could substituted.
The patch bundle referenced in this document (ESX400-200909001.zip) was for the 09/24/2009 update release. Adjust file names as required, for newer bundles.

06:
Verify that the patch bundles aren't already installed (or if they are required), using the command:


07:
If applicable, use the vSphere client to put the ESX 4 host in maintenance mode. Alternatively, use the command:


The following commands may also be used to list and then shut down virtual machines. This is for environments without VMotion or for single hosts.


08:
To determine which bulletins in the bundle are applicable to this ESX 4 host, use the command:


09:
To check VIB signature, dependencies, and bulletin order without doing any patching (a dry run), use the command:


10:
If the stage (dry run) found no problems, then the bundle can be installed using the command:


11:
When (or IF) prompted to reboot, use the command:


Note: Not all patches will require an ESX host reboot.

12:
After the system boots, verify patch bundles were installed with the command:


13:
If applicable, take the ESX host out of maintenance mode with the command:


14:
If applicable, restart virtual machines using the vSphere client or the following command:


15:
Delete the bundle zip file from the /var/updates folder, using the command:


16:
Verify that host disk free space is still acceptable, using the command:


As always, thanks for reading!