Building a Dev/Test environment with HP CloudSystem Enterprise

(1)

Technical white paper

Building a Dev/Test

environment with HP

CloudSystem Enterprise

Reference implementation

Executive summary

HP CloudSystem is the most complete, integrated, open platform that enables enterprises and service providers to build and manage services across private, public and hybrid cloud environments. HP CloudSystem delivers broad application support and helps businesses package, provision and manage cloud services to users regardless of where those services are sourced, whether from HP CloudSystem’s “on-premises” resources or from external clouds. Automated management capabilities help ensure that performance, compliance and cost targets are met by allocating private and public cloud resources based on a client’s pre-defined business policies. As a result, clients can create and deliver new services in minutes.

Based on proven, market leading HP Cloud Service Automation and Converged Infrastructure, HP CloudSystem is tailored to meet the requirements of enterprises and service providers at various stages of cloud maturity with three offerings: • Entry configuration for infrastructure-as-a-service (IaaS) with HP CloudSystem Matrix that lets customers provision

infrastructure and applications in minutes across private, public, and hybrid clouds.

• Full-scale deployment of private and hybrid cloud environments with HP CloudSystem Enterprise, which adds advanced infrastructure-to-application lifecycle management.

• Advanced capabilities for service providers with HP CloudSystem Service Provider, facilitating deployment of public and hosted private clouds that deliver complete service aggregation and management.

To demonstrate a Dev/Test environment, this implementation will show how to develop and test an e-commerce web application. We will start out with the default storefront and then use HP CloudSystem Enterprise to implement a new look-and-feel and then add products to emulate a real e-commerce website. Finally, test servers will be deployed to show how testers could do Quality Assurance (QA) runs to verify the application is ready to be moved into production.

The implementation described in this document details the steps needed to set up HP CloudSystem Enterprise for deploying a Hybrid Dev/Test cloud. An application build server will be deployed which will contain a Subversion source-code repository server and a Jenkins continuous integration build server. A development server will be deployed with the necessary tools to modify and commit code changes. And finally, QA deployments will be deployed into the private or public cloud to verify that the latest version of code meets appropriate standards. To emulate code changes, an open-source e-commerce tool, Magento, will be used to demonstrate how code modifications are propagated through the Dev/Test environment. A Dev/Test data flow, as shown in Figure 1, demonstrates that after an Application Build Server has been instantiated, Developers can make code changes and commit them to the Subversion code repository. At some pre-determined time, the Jenkins server creates a build with the latest code from the code repository. QA runs can be deployed at any time, picking specific builds from the Jenkins server to use as the test data. This implementation does not include feedback loops that include defect submittal/resolution or deployments to staging/production environments, more commonly known as a Dev/Ops (Development/Operations) solution.

Figure 1. Dev/Test Environment

HP Cloud Service Automation (CSA) is used as the deployment trigger point, HP Matrix Operating Environment (Matrix OE) is used as the service broker, and VMware vCenter and HP Cloud Services (HPCS) will provide compute resources when deploying this implementation. Magento was chosen as a sample application because it is an open-source application, has command-line installation and configuration capabilities, and is used by many well-known companies for e-commerce (magentocommerce.com).

(4)

Target audience: The target audience for this implementation is enterprise and service provider personnel who want to understand the capability, flexibility, and features of Dev/Test deployments into the hybrid cloud utilizing HP CloudSystem Enterprise.

This implementation describes testing performed in May 2013.

Assumptions

This implementation assumes that the reader has a general understanding of the HP CloudSystem Enterprise environment and is capable of creating and deploying custom services, is comfortable with CentOS 6 and Red Hat Enterprise Linux (RHEL) 6 distributions, and able to administer these environments. The reader should have basic knowledge about HP CloudSystem Enterprise components including HP Matrix Operating Environment, HP Cloud Service Automation, HP Operations

Orchestration Studio and HP Server Automation. While knowledge about Apache Web Server, MySQL, Jenkins, Ant, Subversion, and Magento are not required per se, a working understanding of these technologies will be helpful for debugging any problems that may arise.

Security in any production environment is extremely important, especially in a cloud environment. However, the focus of this document is to understand the fundamentals of deploying a Dev/Test environment, not the multiple security aspects that could significantly expand the focus of this implementation. Basic security, credentials and security keys, are touched upon but the reader is advised to seek other sources for details for security recommendations.

Error handling, like security, is another important topic in any public deployment. This implementation does not implement error handling in order to focus on the solution, rather than protect from the variety of failure modes. A production implementation should implement error handling to ensure a robust solution.

In a real production environment, one would use the same deployment operating system (OS) for all instances to minimize possible problems. For this implementation, we violate this principle to demonstrate that it is possible to use different OS versions and solutions.

Overview

Today many real-world Dev/Test solutions use a source code revisioning system, a continuous integration build server, and a farm of server hardware to give developers and testers the resources needed to develop and test an application. This implementation shows how HP CloudSystem Enterprise can be used to deploy the developer components into a private cloud and then the testing components into either the private or public cloud. This flexibility provides compute resources on an as-needed basis and more importantly, the ability to release these resources when they are no longer needed.

Magento (open-source e-commerce solution) is used as the main application in this example. Minor changes were made to the solution code to demonstrate a real-world Dev/Test use case.

By leveraging HP CloudSystem Enterprise you can create the application framework once and simply deploy QA test runs with a single mouse-click. In this implementation, developer resources are set up in the private cloud while QA test runs can utilize compute resources in either your private or a public cloud – the framework takes care of adding additional resources while your developers and testers receive the benefit of not having to worry about resource allocation or making sure that they have the latest tools and application code to do their respective tasks.

Table 1 lists the main components used by HP CloudSystem Enterprise to deploy the Dev/Test hybrid cloud solution. Table 1. HP CloudSystem Enterprise components

Component What does it do?

HP Cloud Service Automation HP CSA is the manager that tells the other components what to do and when to do it as part of the cloud solution deployment process. This is where the logical cloud solution is specified and then through the customer portal, cloud solutions can be deployed by a click of the button.

HP Operations Orchestration HP OO is the primary execution engine for HP Cloud Service Automation. It has a collection of workflows – instructions or actions – that perform operations such as initiating API calls to other tools or scripts on individual servers. Inside HP Cloud Service Automation, HP Operations Orchestration workflows are specified as the actions to take during a cloud deployment.

(5)

HP Matrix Operating Environment HP Matrix OE is the service broker that requests the compute, storage, and networking resources from the various infrastructure providers, such as vCenter or HP Cloud Services. During deployment and bursting, HP Cloud Service Automation asks HP Matrix OE to obtain additional compute resources. HP Matrix OE is also used to design the compute, storage, and networking layout of the cloud solution.

HP Server Automation HP SA provides a mechanism to deploy applications to servers that are up and running. HP Server Automation can also deploy the operating system; however, this functionality is not used in this implementation.

HP BladeSystem HP BladeSystem provides the foundation of a self-aware and intelligent converged

infrastructure. Architected for any workload from client to cloud, its modular, future-proof design takes advantage of proven innovations like HP Virtual Connect, Intelligent Infrastructure, and Insight Management. An HP BladeSystem comprised of HP ProLiant Gen8 blade servers provides the physical compute resources for HP CloudSystem Enterprise. For this implementation, we assume that VMware ESXi 5.0 has been installed on at least two of the blades and all private cloud compute resources will be VMware ESXi VM instances.

Table 2 defines the set of Dev/Test components used in this implementation. See the For more information section at the end of this document for links to the respective components.

Table 2. Dev/Test components

Red Hat Enterprise Linux (RHEL) Linux distribution used in the private cloud instances

CentOS Linux distribution used in the public cloud instances

Subversion Source-code revision control system

Jenkins Continuous integration build system

Ant Application build tool

Apache httpd Web Server

MySQL Database

PHP Hypertext preprocessor. General purpose scripting language especially

suited for Web development and can be embedded into HTML

Magento Open-source e-commerce solution

Users will be able to use HP Cloud Service Automation to launch the Application Build Server (which houses the Subversion and Jenkins servers), as shown in the dataflow in Figure 2, and any number of Developer workstations into the private cloud, as shown in Figure 3. Figures 2 and 3 show the primary components used in HP CloudSystem Enterprise and the order they are used during an application build server and developer workstation deployment.

(6)

Figure 2. Application Build Server deployment data flow

Figure 3. Developer Workstation deployment data flow

After a developer has made appropriate code changes and checks the changes into the Subversion source-code repository, the Jenkins build server can be told to run a new build manually, or wait until the next scheduled build completes

automatically. Once the build is complete, developers or QA testers may want to test the most recent code changes. Users can use HP Cloud Service Automation to launch either single or 2-tier QA solutions into either the private or public cloud, specifying which Jenkins build they wish to test against. A single-tier solution would be used to quickly test the code functionality and a two-tier solution would be used to test a scenario that mimics a real-life production environment.

(7)

As shown in Figure 4, a single-tier solution would deploy the latest Magento code and product data from the Jenkins server on top of a Linux-Apache-MySQL-PHP (LAMP) stack. After the deployment has completed, the organization would perform appropriate testing to verify the code is ready to be delivered to production.

Figure 4. Single-Tier QA deployment dataflow

Figure 5 shows a two-tier public cloud deployment, allowing for a testing configuration that is closer to a production deployment.

Figure 5. Two-Tier QA Deployment

In the current implementation, two-tier deployments can be directed to the public cloud. The individual virtual machine instances, or tiers, cannot be split between private and public cloud boundaries. It is technically possible to do so and setup instructions are shown in the Bursting with HP CloudSystem Enterprise document if you wish to add that functionality.

(8)

When a user launches an HP Cloud Service Automation subscription through the HP Cloud Service Automation consumer portal, HP Cloud Service Automation will use an HP Operations Orchestration workflow to instruct HP Matrix Operating Environment to deploy the infrastructure components, as shown in Figure 6.

Figure 6. HP Cloud Service Automation using HP Matrix Operating Environment as a compute provider to deploy virtual machines.

After the VMs have been instantiated, HP Cloud Service Automation will use additional HP Operations Orchestration workflows to instruct HP Server Automation to deploy software policies onto the VM as shown in Figure 7. HP Server Automation software policies contain the packages and scripts to deploy application components. When deploying onto a remote HP Cloud Services instance, HP Cloud Service Automation will first use a separate HP Operations Orchestration workflow to deploy the HP Server Automation agent onto the remote instance. This agent is the hook that allows HP Server Automation to manage servers in both the private and public cloud. Since it was deployed to the vCenter VM template, we do not have to manually add the agent to VMs in the private cloud.

Figure 7. HP Cloud Service Automation using HP Operations Orchestration and HP Server Automation to deploy software policies and agents.

(9)

After the software policies have been deployed, HP Cloud Service Automation will then utilize HP Operations Orchestration workflows to configure the application, as shown in Figure 8. These workflows will execute configuration scripts that were placed onto the respective VM instances when the software policies were deployed. These configuration scripts are specific to the respective tools (such as Apache, Subversion, Jenkins, and MySQL) that were deployed as well as configuring the Magento e-commerce application. If a different application is to be used than Magento, then a different configuration script would need to be created to allow for an automated installation and configuration process.

Figure 8. HP Cloud Service Automation using HP Operations Orchestration to configure the tools on the VM instances.

Definitions

This section defines the cloud computing terms used in this implementation. Table 3. Term definitions

Term Definition

Bursting Augmenting private cloud resources with resources from a different private or public cloud. Dev/Test Development and Testing resources and processes used to create and validate an application before

releasing it into production.

Cloud A collection of compute, storage, and network resources that are offered and accessed as services. Additional resources can be added or removed as needed.

Private Cloud Cloud behind an organization’s firewall and owned/controlled by a single organization.

Public Cloud Cloud offered by a third party, such as HP, for other organizations to use. Generally available via the public Internet or outside of an organization’s firewall.

Hybrid Cloud Combination of private and public clouds used together.

Deployment The process of instantiating new cloud services, deploying an operating system (OS) onto the compute resources, setting up middle-ware applications (such as databases, application servers, or load balancers) and then deploying some set of end-user applications that are effectively the core of the web offering.

Prerequisites

• To implement the solution described in this document, your HP CloudSystem Enterprise environment should already be installed, configured, and functioning correctly. Each component must be verified to work individually and as a complete HP CloudSystem Enterprise environment. Links to the documentation for installing, configuring, and verifying these components and their interoperability can be found in the For more information section at the end of this document. • Upgrade the HP CloudSystem Enterprise components as necessary to the component versions as shown in Table 4 in the

(10)

• You will need a copy of the Cloud bursting with HP CloudSystem Matrix infrastructure orchestration: Matrix-to-Matrix, HP Matrix KVM Private Cloud, HP Cloud Services, and Amazon EC2 white paper, which can be found under the white papers section at hp.com/go/matrixoe/docs.

• Specific networking ports will need to be open between the HP CloudSystem Enterprise environment and the public Internet. These ports and the IP ranges are listed below in the Networkingsection.

• An HP Cloud Services account, from hpcloud.com, is required for bursting into the HP Cloud Services public cloud.

Distribution file

Download the HP_DevTest_in_Hybrid_Cloud-1.0.zip file from the HP website at

http://h71028.www7.hp.com/enterprise/downloads/HP_DevTest_in_Hybrid_Cloud-1.0.zip and unpack the contents to a temporary location that is available to the HP Matrix OE environment. This distribution includes scripts and resource files that will be used in the system configuration. See Appendix C – HP_DevTest_in_Hybrid_Cloud-1.0.zip for a list of the distribution contents and a description of each file.

Application RPM and ZIP packages

Locate the Apache Web Services, PHP, MySQL, Jenkins, Ant, and Subversion RPM packages as specified in Appendix G – Software policies and make them available to the HP Matrix OE environment. These packages may exist on a local repository, the original OS media, or from the Red Hat Network. If not, then you will need to do Internet searches to download respective packages. See Appendix G – Software policies for details.

System configuration

Before we can use HP CloudSystem Enterprise to deploy the Dev/Test components into a Hybrid cloud, there are several configuration requirements for your environment. This section will detail these requirements and specify how to configure your HP CloudSystem Enterprise system so it is ready to deploy the Dev/Test example.

HP CloudSystem Enterprise components

The HP CloudSystem Enterprise solution is comprised of many integrated parts. The versions of these components used during the development of this implementation are shown in Table 4.

Table 4. HP CloudSystem Enterprise components.

Component Version

Management Server HP ProLiant DL360p Gen8

HP Blade Servers HP ProLiant BL460c Gen8

Storage HP 3PAR StoreServ Storage, HP StoreFabric Switches

Networking HP 5820 Switch Series

HP Onboard Administrator 3.71

HP Virtual Connect Manager 3.75

HP Integrated Lights-Out 1.20 (iLO 4)

HP Matrix Operating Environment 7.2

HP Server Automation 9.14

HP Operations Orchestration 9.05

HP Cloud Service Automation 3.10

(11)

Network pool requirements

For the private cloud environment, separate production and management networks are required to separate internal maintenance traffic from external production traffic. The production network must also be able to connect to the public Internet. As listed in Table 5, the Name in service template values can be different for your environment but you will need to make appropriate changes in your HP infrastructure orchestration templates to reflect these network names.

Table 5. Network pool requirements

Network name Name in service template Notes

Production network PROD_A Production network for communication between the load balancer, web

server, and the database server in the private cloud. This network also has connectivity to and from the public Internet.

Management network MGMT_A The deployment network used to install the OS and software policies

using HP Server Automation in the private cloud.

Upon deployment, each server will obtain its networking information via DHCP; verify that there are enough free DHCP addresses on both the management and production networks to cover the number of systems you plan on deploying. For the initial deployment there will be a single system – the Application Build Server. As Developer Workstation and Testing QA servers are added to the private cloud additional IP addresses will be required.

Storage requirements

A VMware datastore must be available for virtual machine provisioning. 100GB gives a fair amount of leeway to expand disk usage for individual VMs in the local private cloud. If you plan to deploy primarily into your local private cloud, then adjust the VM datastore size accordingly. For this implementation we have set the individual VM disk size to be 10GB.

Table 6. Storage requirements

Description Total # LUNs Size Redundant paths

to storage Disk is bootable

VM datastore N/A 100 GB Yes No

Server pool requirements

The table below lists the minimum requirements for virtual servers. These values are specified in the HP infrastructure orchestration templates and may be adjusted for your environment. Two different HP infrastructure orchestration templates were created and are included in the distribution file. Instructions are included below on how to load the templates into HP infrastructure orchestration. The vCenterRHEL template was used to deploy VM instances into the local private cloud and the vm-HPCS template was used to deploy VM instances into the HP Cloud Services public cloud. Table 7. Server pool requirements

Server Group name Minimum CPU frequency Minimum CPU cores Minimum memory

vCenter 1.0 GHz 2 cores 512 MB

(12)

Networking

The following ports (Table 8) need to be open in your firewall to allow communication between HP CloudSystem Enterprise, the private cloud, and the HP Cloud Services public cloud instances. HP CloudSystem Enterprise requires permissions to communicate with HP Cloud Services over these ports in order to enable deployment into the public cloud.

For additional security you may wish to restrict the traffic to a set of destination IP addresses. HP Cloud Services publishes the range of IP addresses that can be assigned to a public VM instance.HP Cloud Services uses 15.185.0.0/16 as the range of available public IP addresses. The network protocol for all ports listed in Table 8 is TCP.

Table 8. HP Cloud Services firewall ports

Source Destination Port Description

SA/OO/CSA HPCS instance 22 SSH

SA HPCS instance 1002 SA core manage target

SA HPCS instance 1023 SA core deploy policy

HP IO/HP Matrix OE HPCS identity 35357 HPCS/OpenStack

HPCS Instance SA 3001 SA client registration

HPCS instance Private DB instance 3306 MySQL

End user (Internet) Apache Web Server 80 Application (HTTP)

VMware vCenter

This implementation uses VMware vCenter v5.0. A Red Hat Enterprise Linux (RHEL) 6.2 x64 VM template using only the Core and Base packages must be created. See Appendix A – Creating a Red Hat Enterprise Linux 6.2 VMware template for details.

HP Cloud Services

See hpcloud.com for details on acquiring an HP Cloud Services account if you have not already done so. To configure HP Cloud Services, complete the following steps:

1. Access your HP Cloud Services account at https://console.hpcloud.com/login

2. Determine which HP Cloud Compute region and zone you wish to deploy servers. At the writing of this implementation, there are numerous regions and zones to pick from. The US West Availability Zone 1 compute region will be used in this implementation.

3. Click on the API Keys menu item at the top of the page. Note the Access Key ID, the Secret Key (you have to click on the Show Secret Key link to make it visible), Tenant ID, and Service Endpoints Identity URL. These values will be needed when configuring HP Matrix OE. If an Access Key does not exist, click on the Manage Keys button and then the + New Key button to create an Access Key.

4. Click on the Dashboard  Compute menu item and then the Manage button for the Availability Zone 1. Here we are going to create a private/public key pair. The private key will be used to access the servers that are deployed in HP Cloud Services.

a. Click on the Key Pairs button and then the + Add Key Pair button.

b. Supply a Key Name value (such as hpcsAccess) and then click Create Key. You can supply your own public key if you choose, see the HP Cloud Services documentation (https://docs.hpcloud.com/) for details.

c. An RSA private key will be shown. Copy the contents to a file on your local system and save the file as <key name>.key. When you leave this page, the private key will be gone and irretrievable from HP Cloud Services. If you lose the private key, you will not be able to access the servers that have been created with this key pair.

d. This .key file will need to be copied into the /Keys directory on the HP Server Automation server and into the C:\Keys directory on the HP Operations Orchestration server. In order to communicate with HP Cloud Services VM instances using SSH, the .key file will need to be available to both servers.

(13)

HP CloudSystem Matrix Operating Environment

The Cloud bursting with HP CloudSystem Matrix infrastructure orchestration: Matrix-to-Matrix, HP Matrix KVM Private Cloud, HP Cloud Services, and Amazon EC2 white paper, which can be found under the white papers section at

hp.com/go/matrixoe/docs, provides instructions on how to enable the HP Cloud Services compute provider in an HP CloudSystem Enterprise environment.

HP infrastructure orchestration templates

For this implementation, two different HP infrastructure orchestration templates specify the networking, server, and storage requirements for the VM instances that make up the Dev/Test hybrid cloud solution. One template is used to deploy instances into the private cloud. The other template is used to deploy into the HP Cloud Services public cloud environment. If you are unfamiliar with the steps needed to import an HP infrastructure orchestration template, see Appendix B – Matrix infrastructure orchestration template for step-by-step instructions for creating new templates and importing existing templates.

The two HP infrastructure orchestration templates used in this implementation are included in the

HP_DevTest_in_Hybrid_Cloud-1.0.zip package in the HP IO Templates folder. You will most likely need to modify both of the templates to configure the networking components so they match your production, management, and HP Cloud Services networking setup. You may need to modify the software components to match software template names in your environment, as well as any changes made to HP Cloud Services software components. After importing the templates, the Validation Status may be marked with a red X, which indicates that there are errors with the template and you need to modify the parameters to match those that work in your environment.

Each HP infrastructure orchestration template will have a set of common attributes, as listed in Table 9. Table 9. HP infrastructure orchestration template common attributes

Attribute Value

Server Type Virtual

Number of Servers Initial: 1 Maximum: 4

Processors per Server Initial: 1 Maximum: 2

Memory Size Initial: 512MB Maximum: 1024MB

Network Assignment Type Automatic

The attributes listed in Table 10 are the values used in this implementation for each of the respective HP infrastructure orchestration templates. You can use the templates found in the HP_DevTest_in_Hybrid_Cloud-1.0.zip package as a starting guide, but expect to modify the networking names and software templates to match your environment and any changes that occur in the HP Cloud Services software list. Note that the ‘#’ in the Hostname column will be replaced by values supplied by HP CloudSystem Enterprise during deployment. If you change the template names, then you will also need to modify the corresponding TEMPLATENAME values in the HP Cloud Service Automation service designs.

Table 10. HP infrastructure orchestration template requirements Template

Name Network Software Group Name Hostname Disk Cloud

vCenterRHEL Prod, Mgmt RH62x64_Template vCenter lx-# 10GB No

vm-HPCS az-1.region-a.geo-1 CentOS 6.2 Server 64-bit

20120125 HPCS hp-tc-# 10GB Yes

For the HP Cloud Services template, we also needed to configure the firewall settings (the templates in the distribution file already have the proper firewall settings). During deployment, HP CloudSystem Enterprise will create a security group and populate it with these firewall settings. The new security group is then assigned to the deployed VM instance for the life of the instance. Table 11 lists the firewall settings that were set for the vm-HPCS template. Figure 9 shows a screen shot of the firewall configuration dialog.

(14)

Note

In the Configure Server Group popup window, the Firewall tab will be disabled unless Require In Cloud is enabled in the Config tab.

Figure 9. HP infrastructure orchestration Template Firewall configuration dialog

Table 11. HP infrastructure orchestration template inbound firewall settings

Protocol Port IP Sources

TCP 22 0.0.0.0/0 TCP 80 0.0.0.0/0 TCP 1002 0.0.0.0/0 TCP 3001 0.0.0.0/0 TCP 8009 0.0.0.0/0 TCP 8080 0.0.0.0/0 TCP 3306 0.0.0.0/0

HP Server Automation

Networking

The HP Server Automation server must be configured with two NICs in order to access both the management and production networks. On the HP Server Automation server, verify that dhcpdtool (located in

/opt/opsware/dhcpd/sbin) has been used to configure DHCP for both the management and production networks. The production network must have a DNS resolver capable of resolving Internet hostnames to enable communication with remote VM instances. Such a resolver is also required to configure HP Cloud instances so they are aware of the Jenkins or Subversion server’s public IP address. Without the ability to connect to the public Internet, the scripts on the Developer Workstation or QA Test Run servers that determine the respective server’s public (NAT) IP address will fail.

Script files

The HP Server Automation server will need to have the copyAndInstallAgent.sh file deployed in the /usr/local/SAcomm directory on the HP Server Automation server. This script file can be found in the

HP_DevTest_in_Hybrid_Cloud-1.0.zip package in the HP Server Automation folder. This script is used to deploy the HP Server Automation agent onto the CentOS instances created in the public HP Cloud Services cloud environment and is

(15)

1. Login to HP Server Automation server: mkdir –p /usr/local/SAcomm

2. Copy the copyAndInstallAgent.sh file to /usr/local/SAcomm (using a tool like scp). chmod +x /usr/local/SAcomm/copyAndInstallAgent.sh

Private keys

Access to public deployed VMs is controlled by SSH keys, and these keys need to be added to the HP Server Automation environment to allow management of the remote VMs. For the purposes of this example these keys are stored in the /Keys directory. You may create an alternate location; however, if you use a different directory, change the KEYPAIRPATHSA property in the HP Cloud Service Automation service designs.

1. Create a /Keys directory on the HP Server Automation server.

2. Copy the private key files for HP Cloud Services to the /Keys directory on the HP Server Automation server. Software policies

There are numerous software policies that need to be created in HP Server Automation. Primarily, these software policies contain RPM (Red Hat Package Manager) and ZIP packages that will need to be loaded into HP Server Automation so that the software applications can be installed onto the VM instances after they have been deployed into the private or public clouds. The RPM packages may already be installed on a local repository, available on the original distribution OS media, or available to you on the Red Hat Network (RHN). If you do not have access to these RPM packages, you will need to download them from the Internet, see Appendix G – Software policies for instructions.

Appendix F – Creating an HP Server Automation software policy details how to create a software policy if you are unfamiliar with the steps.

Note

When importing items into HP Server Automation and creating software policies, make sure that the items are stored in the /Package Repository/All Red Hat Linux/Red Hat Enterprise Linux Server 6 X86_64 folder and that both the CentOS 6 X86_64 and Red Hat Enterprise Linux 6 X86_64 OSs are selected. HP Server Automation will show this as Some Linux.

HP Operations Orchestration

HP Operations Orchestration is a workflow engine that is used by HP Cloud Service Automation to execute custom tasks, allowing HP Cloud Service Automation to take advantage of content that was developed after a development release. If you are unfamiliar with HP Operations Orchestration, see the product page hp.com/go/oo.

For this implementation, make sure you are working with the full HP Operations Orchestration software that was deployed as part of HP Cloud Service Automation.

Networking

The HP Operations Orchestration server requires access to both the management and production networks. Private keys

SSH key pairs were created when you set up the HP Cloud Services account. These keys now need to be copied to the HP Operations Orchestration server in your HP CloudSystem Enterprise environment. When certain workflows are executed, if they are operating on a remote instance that was created in the public cloud, they will use SSH to invoke commands on the remote VM. The private key is required for SSH access. Without it, SSH communication, and setup operations, will fail when HP CloudSystem Enterprise tries to deploy application software to the remote VM.

To configure private keys, complete the following steps:

1. Create a C:\Keys folder on the HP Operations Orchestration server. You can create and configure a different folder in the HP Cloud Service Automation service design, but this implementation assumes that private keys are stored in C:\Keys.

2. Copy the hpcsAccess.key file for HP Cloud Services and store it in the C:\Keys folder on the HP Operations Orchestration server.

(16)

Content Patch

Some environments may require Hotfix #157291, which addresses issues seen when using Matrix Operating Environment and HP Server Automation together. Please contact your Hewlett-Packard support representative to determine if this patch should be applied to your HP Cloud Service Automation content.

Workflows

HP Operations Orchestration workflows are the equivalent of an application tool that has been programmed to complete a very specific task. Workflows by themselves are a collection of tasks that when combined together, perform some operation that does useful work from start to finish. Through these workflows, HP Cloud Service Automation can act as the glue between the various components in HP CloudSystem Enterprise and automate tasks that would normally fall upon an individual to perform manually.

For this implementation, workflows were created that would configure Jenkins and Subversion, install Magento, add a new presentation theme to Magento, install the HP Server Automation agent on a public cloud virtual machine instance, tell HP Server Automation to deploy a software policy, and download a Jenkins build from the Jenkins server and deploy it onto a local server.

Import the workflows

The distribution file contains the HP Operations Orchestration workflows jar file, in the oo-flows folder, required to implement the service design and run the appropriate workflows. Make sure the Dev-Test-Hybrid-Cloud-ContentInstaller.jar file is accessible from the HP Operations Orchestration server in your HP CloudSystem Enterprise environment.

To make these workflows available to HP Cloud Service Automation, you must first import them into the HP Operations Orchestration repository.

To import the workflows, complete the following steps on the HP Operations Orchestration server: 1. Open a command line window.

2. Change folders to the location containing the jar file. 3. Enter the following command:

java –Xmx1024m –jar Dev-Test-Hybrid-Cloud-ContentInstaller.jar –centralUsername <admin_user> -centralPassword <password>

4. Upon completion, the workflows are automatically imported into HP Operations Orchestration in the /Library/CSL/Contrib/CSA3.1/DevTest in Hybrid Cloud folder. Verify that the folder structure shown in Figure 10 has been created in the HP Operations Orchestration library:

(17)

Run process definition tool

A process definition tool is set up during installation and configuration of HP Cloud Service Automation. This tool ensures that HP Cloud Service Automation can correctly locate the HP Operations Orchestration workflows needed by the HP Cloud Service Automation Service Offerings. These steps assume that the HPOOInfoInput.xml file is used to define the content available to HP Cloud Service Automation.

To run the process definition tool, complete the following steps: 1. Open the following file in a text editor:

%ProgramFiles%\Hewlett-Packard\CSA\Tools\ProcessDefinitionTool\HPOOInfoInput.xml.

2. Manually add the following lines at the end of the file, inside the </ooengine></ooengines> XML tags: <folder update="true" flow="false" path="/Library/CSL/Contrib/CSA3.1/DevTest in Hybrid Cloud" recursive="true"/>

3. Run the following command from the process definition folder: a. For Oracle :

java -Done-jar.class.path=ojdbc6.jar -jar process-defn-tool.jar -d db.properties -i HPOOInfoInput.xml

b. For Microsoft® SQL Server:

java –jar process-defn-tool.jar –d db.properites –i HPOOInfoInput.xml This last step makes the imported HP Operations Orchestration workflows available to HP Cloud Service Automation and can take several minutes to complete. When done, the tool should report that the process definitions were created. The db.properties file should have been created when HP Cloud Service Automation was installed and the original content was loaded.

System Accounts

The credentials for two system accounts need to be set up in HP Operations Orchestration Studio. SASSH will contain the credentials for the root user on the HP Server Automation server that can execute SSH scripts. vcenterRH will contain the credentials for the root user on the instantiated VMs that are created inside vCenter. These credentials are required to allow the workflows to execute scripts on the remote VM. These accounts should have already been created when importing the HP Operations Orchestration workflows, but you will need to modify the credentials to match your system.

To modify a system account, follow these instructions:

1. Launch HP Operations Orchestration Studio at (https://<OO_Server>:8443) or launch the tool from the Windows Start menu at All Programs  Hewlett-Packard  Operations Orchestration  HP Operations Orchestration Studio.

2. Navigate to Configuration  System Accounts.

3. Double-click the system account (either SASSH or vcenterRH). 4. Click on the Check-Out icon to unlock the account.

5. Click on Assign Password and enter the appropriate password for SASSH or vcenterRH. 6. Click the Save icon and then the Check-In icon to add a new version in the repository. 7. Click the OK button in the Check In window to commit the changes.

HP Cloud Service Automation

HP Cloud Service Automation and HP CloudSystem Enterprise really provide value with their ability to automate the entire deployment process – reduce the entire infrastructure, platform (tools), and application deployment down to a single click. HP Cloud Service Automation acts as the glue for all of the other HP CloudSystem Enterprise components allowing you to set up an infrastructure once and deploy it multiple times. For example, you can create one infrastructure for different groups in your organization or set up and tear down an infrastructure easily for QA or development test runs.

(18)

HP Cloud Service Automation, like most technologies, has its own vocabulary. Table 12 highlights the most important terms but the reader should refer to the documentation (see For more information section) for more details and a complete list. Table 12. HP Cloud Service Automation definitions

Term Definition

Catalog Collection of Subscriptions that a user can pick from.

Resource Provider A management platform that provides either Infrastructure-as-a-Service (IaaS) or Software-as-a-Service (SaaS) to the cloud. For example, a provider such as HP CloudSystem Matrix deploys virtual machines, while a provider such as HP SiteScope monitors applications.

Resource Offering A resource offering corresponds to a capability offered by a provider (or a group of providers) that can be provisioned by HP Cloud Service Automation. For example, you can create a resource offering that corresponds to a specific VMware vCenter VM template that can be cloned by HP Cloud Service Automation to create a VM.

A resource offering includes a user-specified set of lifecycle actions that are executed during the provisioning of the resource offering. A resource offering can also include actions that will be exposed to a subscriber in the Cloud Subscriber Portal.

Service Design A template or blueprint for an orderable service.

Service Offering An instance of a service design that can be selected for deployment.

Subscription A deployed service offering.

Service Access Point The URL that points to a communication handle of a resource provider that will allow HP Cloud Service Automation to communicate with the resource provider.

Resource providers

A resource provider is a management platform that provides either Infrastructure-as-a-Service (IaaS) or Software-as-a-Service (SaaS) to the cloud. For example, a provider such as HP CloudSystem Matrix deploys virtual machines, while a provider such as HP SiteScope monitors applications.

There are three primary resource providers utilized in the service designs for this implementation; HP Matrix OE, HP Server Automation, and HP Operations Orchestration. For each resource provider, a Service Access Point (SAP) is required. We also need to specify the credentials that allow HP Cloud Service Automation to communicate with the device. In the Name column in Table 13, Matrix refers to the HP Matrix OE server and its SOAP API, SA refers to the Server Automation server and secure HTTP, and OO refers to the HP Operations Orchestration workflow engine.

The names given for each resource provider are examples and you can substitute values that are appropriate for your environment. However, when you create resource offerings in a later step, you will need to use the resource provider names you specified. Some of the resource providers shown in Table 13 may have already been added in your environment. The HP Operations Orchestration provider category is not provided out of the box. This entry will be created when the related resource offerings are imported. The process is to import the resource offerings related to a resource provider and then update the Service Access Point values and credentials for these providers to match your environment.

Table 13. HP Cloud Service Automation Resource Providers

Resource provider type Name Service Access Point

HP Matrix Operating Environment Matrix https://<Matrix OE_IP>:51443/hpio/controller/soap/v4

HP Server Automation SA https://<SA_IP>:443

Operations Orchestration OO http://<OO_IP>:8080/PAS

To define a resource provider, follow these steps:

1. Launch HP Cloud Service Automation (https://<CSA_Server>:8444/csa) and log on with appropriate credentials. 2. Make sure the resource device is up and running.

(19)

4. If a specific type is not present, click on the Edit Provider Types icon , and when the Edit Provider Types window comes up, click on the Create New Provider Type icon . Then supply the name using the value listed under the Resource provider type column in Table 13 and change the icon image as appropriate. Finally, click on the Create button to create a new provider type.

5. Select the appropriate provider type and then click on the Create New Provider icon. a. Supply the name and click on the Next> button.

b. Supply the credentials and the service access point (from Table 13) and then click on the Create button.

Import and configure the service designs

Service designs are the architectural blueprints that define how a subscription should be deployed, what resource offerings should be used, and any customizable properties that should be specified for a resource offering. For this implementation, we are going to use five difference service designs, each with its own set of service offerings and properties. See Appendix E – Service designs for the list of service designs used in this implementation. A list of resource offerings are shown in tables 15 and 16 in Appendix D – Resource offerings to match up with the HP Operations Orchestration workflows that will be used for executing specific actions during subscription deployment.

Before importing the blueprints, complete the following steps:

1. Log on to the HP Cloud Service Automation Administrator portal using an account with administrator privileges. 2. Select the Service Design tab.

3. Select Component Types on the left side menu.

4. Add Software Component as a child to Infrastructure Service.

a. Select Infrastructure Server and then the Supported Children tab. b. Click on the + and then select Software Component.

c. Click on the Add button and then the Close button. 5. Add Application category to Infrastructure Service.

a. Select Infrastructure Server and then the Supported Categories tab. b. Click on the + and then select Application.

c. Click on the Add button and then the Close button.

To import the service designs, listed in tables 17-21 in Appendix E – Service designs, complete the following steps for each service design:

1. Log on to the HP Cloud Service Automation Administrator portal using an account with administrator privileges. 2. Select the Service Design tab and then then Service Designs button on the left.

3. Click Import Service Design .

4. Browse to the service-designs folder in the distribution file and select the service design.

5. Click Save to import the service design. Click on the service design to bring up the summary page and then click on the Designer tab to see the tree layout.

6. Select the All Service Designs button on the left.

7. For the Public QA service design, select the Designer tab, and then select the DB infrastructure service

components, and then the Properties button. Change the KEYPAIRPATHOO and KEYPAIRPATHSA values to match the path of the private key values that were downloaded from HP Cloud Services. The KEYPAIRPATHOO value should not include the C: prefix and should start with the forward slash (‘\’). The KEYPAIRPATHSA value should include the absolute path starting with the back slash (‘/’).

8. For the Public QA (2-tier) service design, do this for both the DB and Web infrastructure service components. Select the Designer tab, and then select the appropriate component and then the Properties button. Change the KEYPAIRPATHOO and KEYPAIRPATHSA values to match the path of the private key values that were downloaded from HP Cloud Services. The KEYPAIRPATHOO value should not include the C: prefix and should start with the forward slash (‘\’). The KEYPAIRPATHSA value should include the absolute path starting with the back slash (‘/’). Each node/component in the service design tree can have a collection of resource bindings (actual resource offerings), lifecycle actions, and property values. Tables 17-21 in Appendix E –Service design lists the detailed settings for each node/component in the five service designs for this implementation. For these service designs, all property values are strings, even those that contain numeric values.

(20)

After importing the service designs, for each of the resource offerings listed in Table 15, verify that a valid resource provider is assigned to each resource offering. Follow the instructions in Appendix D – Resource offerings to associate a resource provider with the resource offerings. An Operations Orchestration resource provider may also need to be created, depending on your environment. See Table 13 for resource provider details.

Create and publish the service offering

A service offering must be created in HP Cloud Service Automation before subscribers can request services based on this service design.

To create the Dev/Test service offerings, complete the following steps for each of the five service designs (as listed in Tables 17-21).

1. Log on to the HP Cloud Service Automation Administrator portal using an administrator account. 2. Select the Service Offerings tab.

3. Click Create Offering in the left panel. The Create New Service Offering dialog will open.

4. Enter a name for the new service offering. This name will be visible to the subscribers of this service. Keep track of this name; you will need to supply it when deploying the service below.

5. Select the appropriate service design. 6. Click Create.

7. After the offering is created, you can modify the pricing information, associated documents, or subscriber options for this subscription, such as the default image to display for the service offering.

HP Cloud Service Automation is installed with a default global catalog named Global Shared Catalog. When you publish a service offering in this global catalog, that service offering will be visible in every organization’s Cloud Subscriber Portal. To publish the service offerings in the default catalog, complete the following steps for each of the five service offerings:

1. Log on to the HP Cloud Service Automation Administrator portal using an account with administrator privileges. 2. Select the Service Catalogs tab.

3. Select Global Shared Catalog in the panel on the left. 4. Select Published Offerings in the central panel. 5. Click the Add Offering button at the bottom of the page.

6. Select the service offering that was created above and click Select. 7. For Select Category, select the Application Services category. 8. Click the Add button and then the OK button.

Application Build Server deployment

Now, after completing the setup of the HP CloudSystem Enterprise components, it is time to start deploying the Dev/Test components. The first deployment will consist of the Application Build Server in the private cloud. This is the virtual machine server that will hold the source code revision control server (Subversion) and the continuous integration build server (Jenkins). These components are sitting on top of a LAMP deployment and an initial build of the Magento e-commerce code will be pre-loaded into Subversion and an initial build has been launched in Jenkins. The application build server is ready to support requests for deploying developer workstations or QA test servers.

Other applications, such as a wiki-server, a blogging tool, a unit test infrastructure, or a defect tracking tool (for example) could also be deployed on the application build server as appropriate for a software development team. This

implementation provides the framework for other tools to be added and does not explicitly limit their addition. To launch the initial deployment, complete the following steps:

1. Launch the HP Cloud Subscriber Portal at https://<CSA_Server>:8444/csp and log on using appropriate credentials. Your organization may have a specific consumer portal which should be used instead of the default consumer portal.

2. Select the Catalog tab at the top of the page.

3. In the New Releases window (on the far right), click on the name of the service offering for the Application Build Server. You could also open the Application Services category type you selected previously, find your service offering in the list and then click on Select….

(21)

6. You can monitor the deployment of your subscription using the HP Cloud Service Automation Service Operations view, the HP Matrix OE infrastructure orchestration Requests view, and HP Server Automation Jobs and Sessions view. The subscription should take less than 30 minutes to complete.

7. In the HP Cloud Subscriber Portal select the Subscriptions tab and find your subscription in the list.

8. The Active icon indicates that your subscription has completed and is an active private cloud. If the Failed icon is displayed, use HP Matrix OE, HP Server Automation, and HP Operations Orchestration tools to determine the root cause. The subscriptions page refreshes itself periodically so manually refresh the screen to see updated status results.

9. Click on the View Details button for the build server subscription and scroll down to the bottom to find the IP addresses assigned to the build server. You may want to record the production IP address, as shown in Figure 11, because you will need it for testing the deployment and later when deploying developer workstations and QA run servers.

Figure 11. Application Build Server Management/Production IP Addresses

10. If you will be deploying QA servers into the public cloud, you will also need to know the public IP address of the application build server. If the server has an IP address that undergoes Network Address Translation (NAT), then the actual public IP address can be found by logging into the application build server and executing curl http://checkip.dyndns.org. The results should include the IP address for the application build server that is seen in the Internet. If the public address is not subject to NAT, then just supply its public IP address. 11. Verify that the server was deployed correctly and the Subversion and Jenkins services are running properly.

a. Verify that Jenkins is up and running by going to the http://<production_IP>:8080 URL. b. Verify that Magento was loaded into Subversion and the first build was success by going to the

http://<production_IP>/magento URL.

QA Run server deployment

–

private cloud

At this point, we can launch a QA Run to verify that the test process is working correctly. This will also allow us to see a before and after picture to verify a developer code change in a later step. Automated test tools and tests could easily be added to the framework to further automate the process for an individual organization. This step will focus on deploying a QA run single-tier server into the private cloud.

To launch the initial deployment, complete the following steps:

1. Launch the HP Cloud Consumer Portal at https://<CSA_Server>:8444/csp and log on using appropriate credentials. Your organization may have a specific consumer portal which should be used instead of the default consumer portal.

3. In the New Releases window (on the far right), click on the name of the service offering for the VMware QA Run. You could also open the Featured Services category type you selected previously, find your service offering in the list and then click on Select….

4. Supply a name for your subscription and an optional description. Leave the requested start/end dates alone. 5. Supply the production IP address for the Jenkins server and the latest successful build number. You can get the

latest successful build by going to the http://<Application_Build_Server_Production_IP>:8080/job/Magento/ URL and looking at the Build History. Since the Jenkins build server is configured to run a build every day, pick the latest build number to ensure that the artifacts are available.

(22)

7. You can monitor the deployment of your subscription using the HP Cloud Service Automation Server Operations view, the HP Matrix OE infrastructure orchestration Requests view, and HP Server Automation Jobs and Sessions view. The subscription should take less than 30 minutes to complete.

10. Click on the View Details button for the QA run subscription and scroll down to the bottom to find the IP addresses assigned to the QA run server. Use the production IP address to verify that the Magento code has been installed: http://<QA_run_production_IP>/magento.

Developer Workstation deployment

Now we can launch a Developer Workstation server for a developer who will be making storefront presentation (the look-and-feel of the website) and product changes to the Magento code and database. While this example will only show deploying a single server, in reality servers could be created for each individual developer and used for the duration of a project, or created to develop a specific task and then torn down when the developer had completed the task. After the VM instance is created, the latest version of the code base will be extracted from the Subversion server and deployed to the developer workstation. The developer can then go make code/product changes and then commit those changes back to the Subversion server.

1. Launch the HP Cloud Consumer Portal at https://<CSA_Server>:8444/csp and log on using appropriate credentials. Your organization may have a specific consumer portal which should be used instead of the default consumer portal.

3. In the New Releases window (on the far right), click on the name of the service offering for the Developer workstation. You could also open the Featured Services category type you selected previously, find your service offering in the list and then click on Select….

4. Supply a name for your subscription and an optional description. Leave the requested start/end dates alone. 5. Supply the production IP address for the Subversion server (the application build server).

6. In the Summary window (on the far right), click Request Now.

10. Click on the View Details button for the developer workstation subscription and scroll down to the bottom to find the IP addresses assigned to the developer workstation server. Use the production IP address to verify that the Magento code has been installed and matches the basic Magento output:

http://<Developer_workstation_production_IP>/magento.

Developer code change

Normally a developer would make appropriate code changes and then check them into Subversion so they could be picked up on the next Jenkins build. For this implementation, an automated way of emulating a code change that a developer could make was created to help focus on the process and not exploring the details of actually making changes to Magento. The code changes include adding a new presentation theme and adding four products into the Magento product database. These changes are then checked into the Subversion repository so they can be picked up by the next Jenkins continuous integration build. In a real-world case, developers would be doing this kind of step continuously and automating it would be

(23)

2. In the HP Cloud Subscriber Portal select the Subscriptions tab and find your Developer Workstation subscription in the list.

3. Click on the View Details button for the developer workstation subscription and scroll down to the Workstation Tier section. Here you will want to select the Developer Code Change Action and then click on the Request Action button, as shown in Figure 12.

Figure 12. Developer Code Change Action

4. You can monitor the code change deployment of your subscription using the HP Cloud Service Automation Service Operations view.

5. Use the production IP address to verify that the Magento code has been updated and matches the output shown in Figure 13 below. http://<Developer_workstation_production_IP>/magento.

Figure 13. Magento Home Page with Appliances Theme

QA Run server deployment

–

public cloud

Now we can launch a QA Run to verify that the code changes are working properly and did not cause other problems. This step will focus on deploying a QA run two-tier server into the public cloud. In this case, the two-tier solution means that the database will be deployed onto one server and the Magento code and web server will be deployed on a second server. The servers in the public cloud will still download the latest build from the Jenkins server (Application Build Server) residing in the private cloud.

(24)

To launch the QA Run Server deployment in the public cloud, complete the following steps:

3. In the New Releases window (on the far right), click on the name of the service offering for the HPCS QA Run (2-tier). You could also open the Featured Services category type you selected previously, find your service offering in the list and then click on Select….

4. Supply a name for your subscription and an optional description. Leave the requested start/end dates alone. 5. Supply the public production IP address for the Jenkins server and the latest successful build number. You can get

the latest successful build by going to the

http://<Application_Build_Server_Production_IP>:8080/job/Magento/ URL and looking at the Build History. Since the Jenkins build server is configured to run a build every day, pick the latest build number to ensure that the artifacts are available. Note that the public production IP address is the address seen by servers in the public Internet. You can find the public production IP value by logging into the Application Build Server and executing

curl http://checkip.dyndns.org.

6. In the Summary window (on the far right), click Request Now.

10. Click on the View Details button for the QA run subscription and scroll down to the bottom to find the IP addresses assigned to the QA run server. Use the public IP address

http://<QA_run_production_IP>/magento to verify that the Magento code has been installed and matches the appliance themed output shown in Figure 13 above.

Tear down

To cancel any of the subscriptions and return the private and public cloud resources, complete the steps below. Note that if you cancel the Application Build Server, you will not be able to deploy Developer Workstation or QA Run servers until another Application Build Server is created.

1. Launch the HP Cloud Subscriber Portal at https://<CSA_Server>:8444/csp and log on with appropriate credentials. 2. Select the Subscriptions tab and find your subscription in the list, then click on the corresponding View Details

button.

3. In the Summary window (on the far right), click Cancel Subscription.

4. Use the HP Matrix OE, HP Server Automation, and HP Operations Orchestration tools to monitor the subscription cancellation.

5. Verify that resources have been returned by monitoring the HP Matrix OE infrastructure orchestration Requests tab.

Summary

This implementation documents how to configure HP CloudSystem Enterprise to deploy and tear down a Dev/Test hybrid cloud environment. HP CloudSystem Enterprise: HP Cloud Server Automation working together with HP Matrix Operating Environment, HP Server Automation, and HP Operations Orchestration to create a Dev/Test hybrid cloud environment utilizing VMware and HP Cloud Services. This guide can be used as a starting point for deploying more advanced or complex applications into a Dev/Test hybrid cloud environment and as a basis for moving code to staging and production

(25)

Appendix A

–

Creating a Red Hat Enterprise Linux 6.2 VMware template

These instructions can be used for creating a Red Hat Enterprise Linux (RHEL) 6.x VMware template; specific instructions for RHEL 6.2 are listed.

1. Access the Central Management Server (CMS). a. Launch the vSphere client.

b. Right-click the Datacenter and select New Virtual Machine. c. Select Typical for the configuration.

d. Name: RH62x64_Template.

e. Select appropriate cluster and datastore. f. Select Linux, Red Hat Enterprise 6 (64-bit). g. Select 1 NIC, Mgmt_A network, E1000 Adapter. h. Select 10GB, Thin Provision.

i. Click Finish.

2. Make sure the Linux Red Hat 6.2 Enterprise CD/DVD ISO image is available and can be seen by the VM image once it is powered on.

3. Create a floppy image using the recommended kickstart file attached to the distribution or from Example 1. 4. See VMware Knowledge Base entry #1739 for details on creating a floppy image (edit kickstart file and create a

floppy out of it):

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1739 a. Name the kickstart file ks.cfg before creating the virtual floppy. The name of the floppy image is not

important, but the extension must be .flp so that it is recognized by vSphere. b. Make sure the floppy image can be seen by the VM image after it is powered on.

5. On the newly created VM, enable the Force BIOS Setup option (click Edit Settings, Options tab, Boot Options). 6. Power on the VM image.

7. When the BIOS window opens, make sure to move the CD-ROM boot device to be the first item in the list. Do NOT exit out of the BIOS window yet.

a. Use the mount floppy icon to mount the floppy image (containing the ks.cfg kickstart file) to the newly created VM.

b. Use the mount CD/DVD icon to mount the Linux Red Hat 6.2 Enterprise CD/DVD ISO image to the newly created VM.

c. After mounting both the floppy and DVD images, it is ok to Save and Exit out of the BIOS application. 8. When the RHEL 6.2 install/upgrade screen is presented, you have 60 seconds to press the Tab key to bring up a

text prompt. Otherwise the manual install/upgrade process will proceed. a. At the prompt, type the following for the boot sequence:

vmlinuz initrd=initrd.img ks=floppy

b. The install should complete without any additional user interaction required.

9. After the VM image has been installed, unmount the CD/DVD and floppy images and reboot. In case the automatic install process has rebooted the server and launched the manual install process, just unmount the images and reboot the server again.

Set up eth0 networking

For Red Hat Enterprise Linux 6.x, when deploying a VMware instance from a template, the new instance retains the original MAC address and networking is effectively disabled. To resolve this issue, execute the following steps to ensure that new VMware instances have knowledge of a single networking device, eth0.

1. Log on to the newly created VM as a root user. Use the password specified in the kickstart (ks.cfg) file. 2. Remove the /etc/udev/rules.d/70-persistent-net.rules file.

Building a Dev/Test environment with HP CloudSystem Enterprise

Technical white paper