Deploying VMware ESX Server 3.0.0 in RDP 3.00

Updated June 29th, 2006. Future updates may be found at http://www.brianshouse.net/hp/.
This HOWTO will describe the steps necessary to set up VMware ESX Server 3.0.0 in HP's Rapid Deployment Pack 3.00.  By following the steps outlined here, you should be able to successfully deploy any number of statically-configured ESX installs to ProLiant servers using the automated deployment framework provided by the Rapid Deployment Pack, including unique hostnames, IP addresses, and licensing configuration for each server.

NOTE: Due to the delayed release of VMware's Virtual Infrastructure 3.0, the RDP product development team did not have sufficient time to develop full support for ESX 3.0.0 as a deployed OS.  This document provides a temporary workaround for deploying ESX 3.0 using RDP 3.00, until such time as Altiris and HP provide official support for ESX 3.0 deployment in a future release of Rapid Deployment Pack.  I have tried to keep as close as possible to the syntax and methods the product team are either currently using for ESX 2.x deployments, or are likely to use in future releases, but this method is still highly customized, and should only be attempted by customers with a high level of comfort with Rapid Deployment Pack.

Some things you should be aware of:
  • Due to the changes in the Service Console architecture in ESX 3, the Altiris Deployment Linux Agent, adlagent, does not properly discover and report the MAC address of the primary physical NIC of the host server (exposed to the new Service Console as vmnic0). In fact, it doesn't report any MAC address at all. This has the side effect of not enabling the Deployment Server to instruct the PXE Server to listen to a specific MAC address to trigger the target to boot into the correct automation environment. You will need to interact with the console and catch the PXE boot F8 prompt, selecting the "Linux Managed" option, to rebuild a server.

  • The default ESX firewall configuration will not allow the adlagent service to connect to the deployment server or transfer files, unless explicitly configured to do so (see the %post section of the example kickstart file below). In addition, the Deployment Server must be configured to use a specific known port for file transfers, instead of the default dynamically-chosen port. This port will need to be referenced in the kickstart file.

  • The Altiris Deployment Server's capability to query a VirtualCenter server for information about VMs does not support VirtualCenter 2 in native mode. You might have better luck if you select the option to support legacy VirtualCenter connections during VC2 installation.

  • VMware's support for unattended scripted installation of ESX 3.0.0, to put it politely, needs additional refinement. Certain things that used to work properly in ESX 2.5.3 kickstarts don't in ESX 3.0.0 (like VMFS filesystem creation), some things that should be allowed aren't (like creating non-root user accounts and changing the Service Console memory size), and some things that should be simple (like NIC assignments to vSwitches) are far from it. This necessitates some rather irritating scripted workarounds in the post-installation section. Here's hoping that VMware eventually makes this easier.

This document could not have existed this quickly without the efforts and assistance of Shawn K. from the HP Alliance Engineering team, and Chris G. from the RDP product development team.


OBLIGATORY DISCLAIMERS:
This is NOT an official HP or Altiris publication.
This is not intended to replace the installation guides or manuals, so if you're not sure about something referenced here, RTFM.
I make no guarantees that any of this will work for you, as your mileage may vary according to your particular needs.
Some of the modifications contained in this HOWTO may not be officially supported by HP or Altiris, so don't say you weren't warned.
The opinions expressed in this document are entirely my own, and do not reflect those of HP, Altiris, VMware, or the product development teams thereof.
I don't write the software itself, nor am I on the development team, so please don't write to me for bug reports, support or product feature requests - I'm busy enough figuring this stuff out already.
There's a nice RDP knowledgebase here, and support forum here if you need additional assistance.


1. What You Will Need:


2. Prepare the eXpress share for ESX 3.0.0 Deployment

The deployment server must be set up to provide access to the ESX 3.0.0 OS installation files.


3. Configure the Kickstart File

We now need to create a kickstart file with appropriate syntax for ESX 3.0.0 that will be used for our deployments. We will use some of the syntax conventions used for the existing ESX 2.5.3 kickstart file, combined with syntax from VMware's VI3 Installation and Upgrade Guide.

NOTE: When editing text files that will be parsed by Linux-based scripting or deployment utilities like the installation programs for Linux and VMware ESX Server, the files must be saved with the correct UNIX-style text formatting style to prevent the parsing program from choking on extra escape characters present in MS-DOS-style text formatting.  None of the editors included with Windows will properly save these files. Find a Windows text editor (no, not Word - think outside the box, will you?) that will understand and preserve UNIX text formatting. A good one (which I sometimes use to edit this HOWTO) is Notepad++, a free, open source editor with language syntax highlighting and many other nice features, available from http://notepad-plus.sourceforge.net.



A note about Altiris token replacement

Altiris eXpress Deployment Server has the ability to search through text files and replace custom tokens with information from its database.  By specifying the tokens listed above, we can have the deployment server pre-populate the kickstart file with the appropriate values from the database for that target server.  The reason I am using the NetWare- and Windows licensing- specific tokens instead of the default IP configuration tokens is that when the target system is brought up in DOS/Linux/WinPE prior to OS deployment, these fields are often overwritten with the current values obtained from the Bootworks client, e.g., a DHCP-assigned address, while the NetWare-specific tokens are normally applied to Windows hosts after the OS is installed. Since the Altiris client cannot tweak NetWare or Windows Licensing settings on a Linux or ESX host, we can safely hijack these fields in the database for our own purposes, and they will remain in the database after deployment.


4. Modify the Altiris Jobs

Now that we have a customized kickstart file with tokens for Altiris to replace, we will need to make copies of the existing ESX 2.5.3 Altiris jobs from the ProLiant Integration Module, and modify them to deploy ESX 3.0.0.


5. Download and Configure the Management Agents

In order to provide ProLiant hardware monitoring and instrumentation, we will need to download and configure the ProLiant Management Agents version 7.51a for VMware ESX.


6. (Optional) Set Up Lights-Out Configuration

We can piggyback on the deployment job that deploys ESX Server and the ProLiant Support Pack to provide configuration of the iLO as well:
You might want to rename the job to "Deploy ProLiant ML/DL/BL + VMware ESX 3.0.0 + PSP + iLO{LinuxPE}", since now it includes configuring the iLO as well.


7. Preparing For A New Server Deployment (Single Or Few Servers)


WARNING! - WARNING! - WARNING!

DO NOT connect, or leave connected, any SAN volumes to any server while being deployed or redeployed by Rapid Deployment Pack.


Both the Linux and WinPE pre-boot environments will enumerate the SAN volumes ahead of any on-board drives, with the result that the default behavior of the Altiris RDeploy client to drop an image on the primary drive will result in the complete loss of the partition table and file system on the first SAN volume! The only way to avoid this is to know exactly how many SAN volumes will be presented to your target system, and to modify the Distribute Disk Image tasks to reference the correct logical drive number of the first locally-attched drive. Since this is impossible to predict, there is no way to provide a "fail-safe" configuration for the stock jobs included with RDP.

So, make sure to un-zone or un-present any SAN volumes to any server you will deploy or redeploy with RDP.

You have been warned.


Before booting up one (or a few) new server(s) for ESX server deployment, create an entry in the database for it pre-populated with the various information required for the deployment:
When the system is booted for the first time, it will PXE boot and register with the Altiris server (provided you set up everything properly with your PXE configuration), and start running the deployment job.


8.  Preparing For Mass Deployments (Many Servers)


WARNING! - WARNING! - WARNING!

DO NOT connect, or leave connected, any SAN volumes to any server while being deployed or redeployed by Rapid Deployment Pack.


Both the Linux and WinPE pre-boot environments will enumerate the SAN volumes ahead of any on-board drives, with the result that the default behavior of the Altiris RDeploy client to drop an image on the primary drive will result in the complete loss of the partition table and file system on the first SAN volume! The only way to avoid this is to know exactly how many SAN volumes will be presented to your target system, and to modify the Distribute Disk Image tasks to reference the correct logical drive number of the first locally-attched drive. Since this is impossible to predict, there is no way to provide a "fail-safe" configuration for the stock jobs included with RDP.

So, make sure to un-zone or un-present any SAN volumes to any server you will deploy or redeploy with RDP.

You have been warned.



Using a spreadsheet program, open the template CSV text file <eXpress share>\Samples\ImportComputer55.txt.

Create a new line for each machine to be deployed, filling in the values for the following columns:
Save the file, and use the following steps to import the data:
Drag and drop the deployment job onto the new systems in the same manner as the single-computer import described above.