Overview

This section provides guidelines for provisioning physical servers in the BMC Cloud Lifecycle Management environnment. It is addressed to cloud administrators who are knowledgeable about BMC BladeLogic Server Automation and the concepts and tasks related to physical server provisioning, specifically the configuring of PXE and TFTP servers. These guidelines assume that you can perform the step-by-step actions required to complete the procedures and processes.

Background

This topic describes some of the more important BMC BladeLogic Server Automation objects that control the provisioning actions. These objects include

• PXE datastore
• Provisioning image
• System package

• Preboot image

  Warning

  Note

  The system package is the only BMC BladeLogic Server Automation object that is exposed directly in the BMC Cloud Lifecycle Management interface.

PXE datastore

The PXE datastore is a list of one or more file servers. You define this list and other attributes of the PXE datastore in the property dictionary.

When provisioning a device, you specify the combination of system package (see below) and PXE datastore to use. BMC BladeLogic Server Automation assumes that the OS and Agent installers exist on the PXE datastore at the file path string you have entered for the provisioning image object.

You must ensure that

• the file server you specified from the PXE datastore has the file path defined in its configuration

• you entered a valid file path string when you created the provisioning configuration

  Error

  Warning

  The system does not validate the file path string you enter on the provisioning image for the OS or Agent installer.

When you execute the provisioning job from BMC Cloud Lifecycle Management, it searches for a pod name as it browses the list of available datastores. BMC Cloud Lifecycle Management uses the pod name to select a datastore when it provisions a device.

The Modify Instance dialog for the PXE datastore lists the Name attributes. The FULL_PATH property name defines the root path of the file server for BMC BladeLogic Server Automation, as shown by the C:\datastore entry in the example below:

Provisioning image

The provisioning image encompasses the combination of OS and agent installers.

For each installer, you specify a file path string. This file path is relative to the root path of the file server you specify when you provision a device. Because the system does not validate the file path string, you must ensure that it matches the file path you defined for the file server.

No absolute path name is entered for the installers. Remember to use the appropriate path separator in the path name: backslash for Windows and forward slash for UNIX or Linux. Refer to the following example:

System package

The system package specifies a provisioning image together with a set of rules and scripts. This set enable you to execute the OS installer through a specific provisioning image. You can customize how a given OS is installed by re-using a provisioning image with a different set of rules and scripts (a different system package) during installation.

If you add or modify any BMC Cloud Lifecycle Management system packages in BMC BladeLogic Server Automation, you must inform BMC Cloud Lifecycle Management about the new or updated packages.

The Publish Product Catalog job in BMC BladeLogic Server Automation publishes the set of system packages in a specially named BMC BladeLogic Server Automation folder (Depot -> CSM_OS_Packages) to a specified BMC Atrium Enterprise CMDB instance. You specify the BMC Atrium CMDB instance from the BMC BladeLogic Server Automation client interface through the Configuration -> Atrium Integration -> Configuration menu item. You initiate the publication from the BMC BladeLogic Server Automation client interface by executing a Publish Product Catalog job.

These system packages are viewable in a list format in the BMC Cloud Lifecycle Management interface. A BMC Cloud Lifecycle Management routine retrieves them from the BMC Atrium CMDB instance and makes them available in a list format in the BMC Cloud Lifecycle Management interface.

Preboot image

The preboot image in BMC BladeLogic Server Automation is an object that contains a small operating system. This operating system, in turn, specifies how to fetch the actual operating system onto the machine.

When executing a provisioning command, you indicate which preboot image to use. BMC Cloud Lifecycle Management retrieves the preboot image in either of two ways:

• by selecting a hard-coded BOOT_IMAGE_ID property definition on the device. This property definition can have a default value if all your physical server devices use the same boot image.

• by attempting to match an appropriate boot image ID from the manufacturer attributes in BMC Cloud Lifecycle Management with the device. BMC Cloud Lifecycle Management uses the PRODUCT_MANUFACTURER property on the BMC BladeLogic Server Automation provisioning image to determine the appropriate match.

  Warning

  Note

  The preboot image is supposed to have The PRODUCT_MANUFACTURER property automatically defined from the image type.

See also Notes and tips.

Provisioning in BMC Cloud Lifecycle Management

Follow these guidelines to help you provision physical servers in BMC Cloud Lifecycle Management.

Before you begin

In BMC BladeLogic Server Automation, do the following tasks:

• Complete the BMC BladeLogic Server Automation related provisioning actions described in Configuring-the-PXE-and-TFTP-servers and related subtasks.
• Ensure that the device is in the "Discovered" or "Pre-Discovered" state in BMC BladeLogic Server Automation. The device must be in the Discovered or Pre-Discovered state so that it is visible in BMC Cloud Lifecycle Management for onboarding. You can check the device status by verifying the value of the PM_STATE parameter in the extended property list. If necessary, set the device to Discovered or Pre-Discovered by right-clicking on the device and choosing Reprovision later.

In BMC BladeLogic Network Automation, verify the following:

• Enable custom actions for physical server provisioning.

In BMC Cloud Lifecycle Management, perform the following:

• Ensure that the cache between BMC Cloud Lifecycle Management and BMC BladeLogic Network Servers has been executed. It runs every 30 minutes by default. If necessary, you can force the caching by restarting BMC Cloud Platform Manager (OSGi). You restart BMC Cloud Platform Manager (OSGi) by restarting the BMC_CSM service.

• Onboard the physical server as you would a virtual cluster.

To enable custom actions for physical server provisioning in BMC BladeLogic Network Automation

In BMC BladeLogic Network Automation v. 8.1.02 or later, custom actions are automatically enabled at installation.

In BMC BladeLogic Network Automation v. 8.1.01 or earlier, you must manually enable the custom actions. Follow these guidelines:

1. Choose Admin -> Device Adapters -> Custom Actions, and open the Switch Port Provisioning folder in the Device Adapters dialog box.
   
   
2. Enable (choose Yes from the drop-down list) Provision Switch Port and Add VLAN to Switch Trunk Port.
3. Click the corresponding check box in the Actions column.
4. Click OK at the confirmation prompt.

To configure BMC Cloud Lifecycle Management for physical server provisioning

The following guidelines are common to both Linux and Windows 2008 operating systems.

• Add one or more datastores to the Property Dictionary: for example, Datastore.Pxe DataStore -> Instances. Each datastore references an http server where multiple files reside. These http servers are usually arranged based on geographical preferences.
  
  BMC Cloud Lifecycle Management assumes there will be a datastore per pod. You should name the datastore accordingly: name of the datastore plus the name of the pod to be onboarded, as in "CSM Datastore - Pod1". BMC Cloud Lifecycle Management uses the pod name to select a datastore when provisioning a device.

  Warning

  Note

  The BMC Cloud Lifecycle Management install planner creates the CSM_OS_Packages folder and the CSM scripts.

• Add one or more system packages to a Depot folder named "CSM_OS_Packages".
• After adding the system package, execute the Publish Product Catalog Job to export information about the system packages into the specified BMC Atrium CMDB instance.

• Add an nsh script called "CSM_Delayed_Reboot" to the Depot folder "CSM_Scripts":

  Type 1 (Execute the script separately against each target host.)

  Script: sleep 60 nexec $1 reboot

  Parameter: hostname, default value TARGET.NAME

• To allow reprovisioning, which requires a server reboot, ensure that each agent that will be reprovisioned has a user mapping in the exports file, as follows:

<Agent's hostname> rw,user=root
where <Agent's hostname> is the host name or IP address of the Agent server host.

• Add the following properties to the Device class in the Property Dictionary:

  Warning

  Note

  If autodiscovery of unprovisioned devices is working correctly, you do not need to populate the CPU_COUNT (Integer), CPU_FAMILY (String), and RAM_MB (Integer) properties when you see devices in the user interface displaying the correct values for the corresponding properties.

  Property	Value
  CPU_COUNT (Integer)	number of CPUs for the device. If devices display in the interface showing the correct number of CPUs, you do not need to set a value for this property.
  CPU_FAMILY (String)	the CPU family for the device. If devices display in the interface showing the correct CPU family, you do not need to set a value for this property. Set the CPU family value to a valid BMC Atrium CMDB value. Choose among the following: Alpha AS400 ESA_390 IA_64 MIPS MIPS_64 PA_RISC PowerPC PowerPC_64 SPARC SPARC_64 StrongARM Unknown X86 X86_64 zArchitecture (This listing will be updated with regular expression logic to cover likely discovered values.)
  RAM_MB (Integer)	the correct amount of memory for the device. If devices display in the interface showing the correct CPU family, you do not need to set a value for this property.
  NIC_DETAILS (List of Strings)	You must always enter this value. It is an entry for each network interface card (NIC) in the following format: mac-address, switch name, switch port. For example: 32:9C:53:50:AF:15,fooswitch,10 56:0C:FF:72:CC:46,fooswitch,11

   

  Linux provisioning guidelines

• When provisioning multiple network interface cards/addresses on Linux systems, add local properties to the system package using the following formats.

  Warning

  Note

  Exclude the first address on the first network interface card. The first network interface card is assumed to be used for network booting.

  Address	Format
  Primary address on a network interface card, where <x> is the NIC number, beginning with 0	ETH<x>_MAC_ADDRESS ETH<x>_MAC_ADDRESS_CD ETH<x>_BOOTPROTO ETH<x>_IPADDR ETH<x>_NETMASK ETH<x>_GATEWAY
  For supplemental IP addresses on a network interface card, where <y> is the IP address, beginning with 1	ETH<x>_<Y>_IPADDR ETH<x>_<Y>_NETMASK ETH<x>_<Y>_GATEWAY

• When provisioning multiple network interface cards/addresses on Linux systems, edit the system package boot loader scripts by adding the local properties listed above.
  
  The following example is for kickstart purposes and is added to the "Additional entries for the kickstart file." It assumes that the first network interface card has just one address and does not need to be covered; it assumes that the second network interface card has two addresses on it.

  echo "DEVICE=eth1" > /etc/sysconfig/network-scripts/ifcfg-eth1
  echo "HWADDR=??ETH1_MAC_ADDRESS_CD??" >> /etc/sysconfig/network-scripts/ifcfg-eth1
  echo "BOOTPROTO=??ETH1_BOOTPROTO??" >> /etc/sysconfig/network-scripts/ifcfg-eth1
  echo "ONBOOT=yes" >> /etc/sysconfig/network-scripts/ifcfg-eth1
  echo "IPADDR=??ETH1_IPADDR??" >> /etc/sysconfig/network-scripts/ifcfg-eth1
  echo "NETMASK=??ETH1_NETMASK??" >> /etc/sysconfig/network-scripts/ifcfg-eth1
  echo "GATEWAY=??ETH1_GATEWAY??" >> /etc/sysconfig/network-scripts/ifcfg-eth1
  
  echo "DEVICE=eth1:0" > /etc/sysconfig/network-scripts/ifcfg-eth1:0
  echo "HWADDR=??ETH1_1_MAC_ADDRESS??" >> /etc/sysconfig/network-scripts/ifcfg-eth1:0
  echo "BOOTPROTO=??ETH1_BOOTPROTO??" >> /etc/sysconfig/network-scripts/ifcfg-eth1:0
  echo "ONBOOT=yes" >> /etc/sysconfig/network-scripts/ifcfg-eth1:0
  echo "IPADDR=??ETH1_1_IPADDR??" >> /etc/sysconfig/network-scripts/ifcfg-eth1:0
  echo "NETMASK=??ETH1_1_NETMASK??" >> /etc/sysconfig/network-scripts/ifcfg-eth1:0
  echo "GATEWAY=??ETH1_1_GATEWAY??" >> /etc/sysconfig/network-scripts/ifcfg-eth1:0

Windows 2008 provisioning guidelines

• When provisioning multiple network interface cards/addresses on Windows 2008, add a property named WINDOWS_UNATTEND to the system package. Edit the system package Unattend entries as follows:

1. Under Additional Unattend Entries, click the Plus sign.
2. In the top-left panel, expand the Specialize listing, and select the Microsoft-Windows-TCPIP node. To display this node, specify a static IP address (the IP address is ignored).

3. In the Add/Replace XML Component, paste the following XML code:

   <component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" language="neutral" name="Microsoft-Windows-TCPIP" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" versionScope="nonSxS">
   ??WINDOWS_UNATTEND?? </component>
4. Ensure that "Replace the selected node" is selected.

Windows and Linux provisioning notes

• If provisioning back and forth from Windows to Linux operating systems, use the following script for Windows system packages to avoid errors because of old drive mappings:

1. In the Pre-Install tab of the system package, click the Plus sign.

2. Add a script called RemapCCdrive with the following contents:

   @ECHO OFF
   ECHO list volume >fixpart.txt
   ECHO select volume C >>fixpart.txt
   ECHO assign letter Y >>fixpart.txt
   DiskPart /S fixpart.txt
   Del fixpart.txt
   

Notes and tips

The provisioning workflow requires that BMC Cloud Lifecycle Management specify a boot image ID to Device objects in BMC BladeLogic Server Automation. In earlier versions of BMC Cloud Lifecycle Management, the boot image ID was assigned by matching the ID with the object based on the manufacturer listing in the BMC Cloud Lifecycle Management configuration. The supported default operating systems were limited to Redhat Linux and Windows Server 2008.

You can now create a new BMC BladeLogic Server Automation property called BOOT_IMAGE_ID in the Property Dictionary view of the Device object. Using this property, you can configure any boot image on the BMC BladeLogic Server Automation provisioning server. BMC Cloud Lifecycle Management queries BMC BladeLogic Server Automation for the BOOT_IMAGE_ID and applies it to the provisioning workflow, where it can be can assigned to a device object.

When you create the BOOT_IMAGE_ID property, a default value is assigned to it on all Device objects in BMC BladeLogic Server Automation. If you do not explicity specify a default value, BMC Cloud Lifecycle Management retrieves an empty string in API calls for this property.