Configure the cloud for Workload Deployer

Learn how to set up Workload Deployer for a production deployment environment

A cloud administrator has full authorization to a private cloud that is managed by IBM® Workload Deployer. Prior to deploying applications, initial steps must be taken to prepare Workload Deployer so that it is ready for development and test use. The authors describe the procedure for setting up and configuring the cloud to deploy applications using the Workload Deployer Version 3.1 user interface. VMware ESX 4.1 or PowerVM hypervisor is used in the examples.

Share:

Aimin Wu, System Performance Analyst, IBM China

Photo of author Aimin WuAimin worked as a software developer in DB2 for 10 years for various DB2 features in multiple DB2 releases. Aimin now is focusing on expert integrated system optimization.



Courtney D. Mauney, Information Developer, IBM

Courtney is a member of the information development team for IBM Workload Deployer.



03 October 2012

Also available in Chinese Japanese Portuguese

IBM® Workload Deployer is a hardware appliance that provides access to IBM middleware virtual images and patterns allowing you to create application environments that can be securely deployed and managed in a private cloud. Workload Deployer provides a web-based user interface tool and a command-line interface tool making deployment of virtual images, appliance, and application patterns automated, quick, consistent, and repeatable.

Typical steps to deploy and configure Workload Deployer and to set up the private cloud are as follows:

  1. Physical installation of the appliance, including installing the appliance in a rack, connecting it to the network, plugging in the power cable, and connecting it to a serial console.
  2. Initial configuration of the appliance through the connected serial console, including accepting license terms, configuring the IP address, DNS and default gateway. After this step, the Workload Deployer administrative console can be accessed through a supported web browser from a different machine that connects to the Workload Deployer.
  3. Additional configuration of the appliance, including adding more network adapters, DNS servers and a mail server, configuring backup and restore for Workload Deployer, and establishing the time zone. These can all be performed by the cbadmin user through the web administrative console.
  4. After all the resources to be used in the private cloud, such as ESXi hypervisors, IP addresses are prepared, add the resources to Workload Deployer and configure the cloud environment in it. There are three types of tasks:
    • Creating users and user groups as needed.
    • Enabling required virtual images and pattern types.
    • Adding resources like IP groups, cloud groups, and hypervisors and deploying shared services.
  5. Deploying virtual system, applications, and appliances to the cloud for testing, development, or production purpose.
  6. Maintaining and monitoring the cloud.

This article focuses on how to configure a cloud environment using the Workload Deployer web-based user interface tool. The screen captures in this article show VMware ESX hypervisors from within IBM Workload Deployer 3.1.0.1. Figure 1 shows the necessary steps in the recommended order.

Figure 1. Cloud environment configuration steps
Cloud environment configuration steps

It is important to properly configure the cloud environment for an application. In Workload Deployer, only a cloud administrator has the authority to set up the cloud environment, even though developers and testers will use it to run applications. If the cloud environment is not properly configured, developers and testers may not be able to address any issues that arise because they don't have access. It is not always obvious to testers or developers what they should ask the cloud administrator to do in order to fix a problem.

Let's look at some considerations and procedure basics when it comes to configuring the cloud environment for application deployment.

Basics of cloud environment configuration

Configuration considerations

There are several factors that a cloud administrator should consider in configuring the cloud environment.

Authority required to configure a cloud environment
Most subtasks in the cloud environment configuration — except for the user and user group creation and management — can be achieved by a Workload Deployer user who has cloud administrator rights with full permission. User and user groups can only be managed by a Workload Deployer user that has appliance-administrator-with-full-permission rights.

The cloud administrator role in reality is not a direct mapping to the Workload Deployer cloud administrator permission. In this article, cloud administrator refers to the real user role. Workload Deployer permissions required for each step are clearly stated.

User and user group authority to use the cloud environment
After a cloud environment is configured, user IDs need to be created in order to use the new cloud. The cloud administrator should consider what permissions need to be given to each specific user depending on their user role.

Preparation of resources
Physical servers should have hypervisors installed and configured. VMware ESX hypervisors should be added to VMware vCenter server if vCenter is used to manage the ESX servers. IP addresses should be configured with hostnames that can be resolved by DNS, and VLAN configurations should be established if it will be used.

Initial configuration steps

To set up Workload Deployer to create and deploy virtual application patterns, virtual database patterns, and virtual system patterns, some initial steps must be taken.

Before configuring the cloud environment, there are several actions that should be taken:

  1. Hypervisors (Use VMware ESX as example here)
    • Configure IP addresses, hostname, DNS and default gateway for servers that already have ESX installed.
    • Configure storage and virtual switches.
    • Register ESX hypervisors to the vCenter server if you use vCenter to manage ESX.
  2. Network
    • Assign enough IP addresses to be used by virtual machines to be managed and deployed on hypervisors. These IP addresses should have hostnames that are searchable through a DNS server.
    • Configure VLAN properly if it is intended to be used.

The remaining sections take you through the configuration tasks and subtasks necessary to configure the cloud environment.


Update the cbadmin profile

While this step is not part of the cloud environment setup, it's worth attention for security reasons. cbadmin is the default user for logging into Workload Deployer's web admin console. cbadmin has complete authority so it's strongly recommend that this user's password be changed as soon as possible.

After installing the appliance in the appropriate rack, the user can connect the appliance to a serial console to do an initial configuration such as reading and accepting the license agreement, configuring the network adapter, and setting the default gateway.

Next, the user can connect to the web-based user interface with the default cbadmin user ID. The following section discusses how to change the default user cbadmin password and update its profile using the web-based admin console. It is very important that the cbadmin password does not get lost. If the password is lost, it is not the end of world assuming the back door to reset the password through the serial console is enabled.

Log into the user interface as cbadmin

The default cloud administrator's user ID and password is cbadmin/cbadmin. The supported web browsers are

  • Mozilla Firefox Extended Support Release (ESR)
  • Microsoft Internet Explorer 7, 8, 9

In a browser window, type in the admin console address https://<IWDHostname/IPAddress>/login, where <IWDHostname/IPAddress> is the Workload Deployer appliance's hostname or IP address that you set up using the serial console. The login window opens.

Figure 2. Workload Deployer admin console login window
Workload Deployer admin console login window

Change password for cbadmin

We strongly recommend that you change the password for the default admin account. To change the password:

  1. Click System and select Users from the Workload Deployer admin console.
    Figure 3. Open Users window from Workload Deployer admin console
    Open Users window from Workload Deployer admin console
  2. Select Administrator on the left pane. The details of the cbadmin user are displayed on the right pane.
  3. Click Edit in the Password section of the details pane.
    Figure 4. Edit the cbadmin user's password
    Edit the cbadmin user's password
  4. Enter the new password in the two text fields, as indicated in Figure 5. Click Submit to change the password.
    Figure 5. Enter the new password for the cbadmin user
    Enter the new password for the cbadmin user

Enable cbadmin's password reset from serial console

If you think you might lose the cbadmin password, you can enable a back door that allows you to reset the password through the serial console.

To enable password reset through the serial console:

  1. Click System from the menu bar and select Security to open the Security window.
    Figure 6. Open the Security window from the System menu bar
    Open the Security window from the System menu bar
  2. In the Security window, under Permissions, change Allow password reset from the serial console to Enable in the drop-down list.
    Figure 7. Allow password reset from the serial console
    Allow password reset from the serial console

Create user and user groups

Only a Workload Deployer user with appliance administration full permission can create or modify user or user groups. The default user cbadmin has the required permission to complete this step.

In theory, this step can be done at any time. Practically speaking, if the users and user groups are created before other cloud objects, then users who create the cloud objects can take advantage of the object-level access control in Workload Deployer with several simple steps.

Permissions for user and user groups in Workload Deployer are based on roles. After a user logs into the admin console, only the objects that the user has permission to access are displayed. Therefore, when creating user and user groups, keep the user's role in mind.

Another level of the permission control is given to the owner of an object in the cloud. An object owner can grant read, write, or full permission to users or user groups that are not the creator of the object, but have permission to access the type of object. This is very useful when multiple users share the same role.

For example, User1 created a virtual application pattern so User1 is the owner of this pattern. User2 has Create Patterns permission. User1 can allow User2 to have different access to this pattern including read, write, or all.

For details on permissions, visit the Workload Deployer InfoCenter.

Creating a user or user group is straightforward in the admin console. It includes two steps:

  1. Create the user or user groups.
  2. Configure the permissions of the user or user groups.

Enable all entitled virtual images

Users that have create-catalog-content permission can perform this step if not using the default user cbadmin.

Virtual images provide the operating system and product binary files that are required to create a virtual system instance.

Workload Deployer has a bunch of pre-built virtual images that user can use out of the box. Workload Deployer also provides user flexibility to build their own virtual images and import them to Workload Deployer. To use the embedded virtual images, simply accept the licenses of virtual images you are entitled.

Accepting the license of a virtual image is a one-time action that is sometimes forgotten. The mapping between virtual applications and the virtual images are not always obvious; it is recommended that you enable all the virtual images that you are entitled to use with the appliance to be best prepared for your private cloud. You can also control which users can access the images at any time.

  1. Open the Virtual Images window. Click Catalog and then select Virtual Images, as indicated in Figure 8. The virtual images window displays with all the available virtual images listed on the left pane.
    Figure 8. Open the Virtual Images window
    Open the Virtual Images window
  2. Accept the license agreement for the virtual images, as indicated in Figures 9, 10, and 11.
    Figure 9. Accept license for the WebSphere Application Server 7.0.0.19 virtual image
    Accept license for the WebSphere Application Server 7.0.0.19 virtual image
    Figure 10. A list of licenses to accept for the virtual image
    Window with a list of licenses to accept for the virtual image
    Figure 11. All licenses have been accepted for the virtual image
    Window showing all licenses have been accepted for the virtual image
  3. After you accept all the licenses, the status of the virtual image is then updated as indicated in Figure 12.
    Figure 12. Status of the virtual image after licenses are accepted
    Status of the virtual image after licenses are accepted
  4. Enable the advanced features of the virtual image if you are entitled (purple arrow in Figure 12).
  5. Repeat the previous steps to enable the other virtual images.

Configure default deploy settings

Users that have cloud administration full permissions can perform this step if not using default user cbadmin.

The Default Deploy Settings should be configured properly before any virtual images can be deployed. This is a one-time configuration, which is often overlooked.

Open Default Deploy Settings window

Click Cloud and then select Default Deploy Settings as indicated in Figure 13. The Default Deploy Settings window opens. See Figure 14.

Figure 13. Open the Default Deploy Settings window
Open the Default Deploy Settings window

Configure and verify the Default Deploy Settings

Depending on the hypervisor type in your private cloud, you may have to ensure that there is at least one default image for each hypervisor type to be used in the Default Deploy Settings. If there are no default images available for the target hypervisor type, follow this step to enable virtual images to be used, then repeat the step to configure the default deploy settings.

Figure 14 is an example that shows the VMware ESX hypervisor type has valid default image settings, indicated by the red arrow, while the IBM PowerVM® hypervisor type does not contain a default image.

Figure 14. Default Deploy Settings window
Default Deploy Settings window

Enable all entitled pattern types

Users that have cloud administration full permissions can perform this step if not using default user cbadmin.

A virtual application pattern type is a collection of plug-ins that define components, links, and policies, along with configuration files, packaged in a TGZ file. The virtual application patterns are used to build a virtual application that includes these components, links, and policies.

Workload Deployer includes pre-built pattern types that user can use out of the box. Meanwhile, users can also develop their own plug-ins using the Plug-in Development Kit and import them to Workload Deployer. Workload Deployer provides a tool named the Virtual Application Builder for building virtual application patterns based on a selected virtual application pattern type. To use the pre-packaged pattern types, simply enable them.

Enabling built-in virtual application pattern types is also a one-time task. The pattern types map to the components in the Virtual Application Builder. Only the components whose corresponding pattern type is enabled are displayed in the Virtual Application Builder.

As an example, Figure 15 illustrates the database components that are displayed before you enable IBM Database Patterns 1.1.

Figure 15. Available database components when no database pattern types are enabled
Available database components in the Virtual Application Builder when no database pattern types are enabled

After you enable any one of the database patterns, the new database options are displayed in the Virtual Application Builder. For example, Figure 16 shows the list of available components after you enable IBM Database Patterns 1.1.

Figure 16. Available database components when IBM Database Patterns 1.1 is enabled
Available database components in the Virtual Application Builder when IBM Database Patterns 1.1 is enabled

To enable IBM Web Application Pattern 2.0:

  1. Open the Pattern Types window. Click Cloud from the menu bar and select Pattern Types as in Figure 17. The Pattern Types window opens. See Figure 18.
    Figure 17. Open the Pattern Types window
    Open the Pattern Types window
    Figure 18. Details of the virtual application pattern
    Details of the virtual application pattern
  2. Click Web Application Pattern Type 2.0.0.0 on the left pane of the Pattern Types window (green arrow in Figure 18).
  3. Click Enable All in the Status section on the details pane, as indicated by the red arrow in Figure 18. The Enable All action is equivalent to the following tasks if you complete them separately:
    1. Enable the prerequisite pattern types, which is the Foundation Pattern Type 2.0.0.0 (yellow arrow in Figure 18).
    2. Accept the license for the current pattern type (blue arrow in Figure 18).
    3. Enable the current pattern type.

After the virtual application pattern is successfully enabled, a window similar to Figure 19 opens. The green arrows show the status change of the enabled pattern type.

Figure 19. Enabled virtual application pattern
Enabled virtual application pattern

Repeat the same steps to enable the other pattern types to which you are entitled.

Tip: The built-in virtual images and patterns are easy to use out of the box. Do not delete any of them if you are unsure whether or not they are needed. If any of the shipped virtual images and patterns are removed, it takes some time to reload them to the appliance and you might need to contact IBM support to get the correct image level.


Configure the system plug-ins

Users that have create-catalog-content permission can perform this step if not using default user cbadmin.

Some patterns have system plug-ins that you may consider configuring to get them ready for building virtual applications.

You can check which plug-ins require configuration in the Pattern Types details window. For example, Figure 20 shows that the OLTP system plug-in for the Transactional Database Pattern 1.1.0.0 is not configured.

Figure 20. Disabled plug-ins required for configuration of IBM Transactional Database Pattern
Disabled plug-ins required for configuration of IBM Transactional Database Pattern 1.1.0.0

The following steps use the OLTP system plug-in as an example to describe how to configure system plug-ins.

Open the System Plug-ins window

Use one of the following two ways to open the System Plug-ins window.

  1. Click the name of the system plug-in on the Pattern Details window (green arrow in Figure 20).
  2. Open the System Plug-ins window from menu bar. This path is useful if the current window is not Pattern Types.
    1. Click Cloud from the menu bar and select System Plug-ins, shown in Figure 21. The System Plug-ins window opens. See Figure 22.
      Figure 21. Open System Plug-ins window from the menu bar
      Open System Plug-ins window from the menu bar
      Figure 22. Select Pattern Types in the System Plug-ins window
      Select Pattern Types in the System Plug-ins window
    2. From the System Plug-ins window, click the drop-down list on the left pane and select IBM Transactional Database Pattern 1.1.0.0. See Figure 22. The OLTP plug-in displays on the left pane (red arrow in Figure 23).

Display details of the targeted system plug-in

Click oltp (1.1.0.0) from the left pane. The OLTP details display on the right pane.

Figure 23. System plug-in OLTP details
System plug-in OLTP details

Configure the system plug-in

Click the Configure button on top of the right-side pane (blue arrow in Figure 23). The configuration window opens, shown in Figure 24. Depending on your intention for the usage environment, select one of the options from the drop-down list. In this example, Both is selected.

Figure 24. OLTP configuration window
OLTP configuration window

Verify plug-in status after configuration

You can verify the status of the OLTP plug-in either by the System Plug-ins window or Pattern Types window. See Figure 25 and Figure 26 for details.

Figure 25. Configure OLTP status
Configure OLTP status
Figure 26. OLTP is not listed as disabled system plug-ins for IBM Transactional Database Pattern
OLTP is not listed as disabled system plug-ins

Create IP groups and add IP range for each IP group

Users that have cloud administration full permission can perform this step if not using default user cbadmin.

An IP group is a logical grouping of IP addresses used by a specific hypervisor. Your network administrator may assign a big range of IP addresses for the cloud. As a cloud administrator, you can create one IP group with a big pool of IP addresses that is shared among all hypervisors within one cloud group as shown in Figure 1. This simplifies the management of cloud groups and ensures all virtual machines to be deployed have access to the same subnet.

Another option is to segment the available IP addresses into multiple IP groups. Then each hypervisor can use one IP group. The benefit is it is clear which IP addresses are used by which hypervisor. The drawback is if there are a considerable number of hypervisors, it is complicated to manage and is quite error-prone. For example, if you need to add IP addresses to each group, you have to modify each and every IP group. If subnet is different among hypervisors, the virtual machines created might not be able to communicate with each other. An example setting is shown in Figure 27.

Before you can assign IP addresses to the IP group, the IP address should be resolvable through DNS. You can always come back to change the IP address range if more IP addresses needed for the IP group.

Figure 27. Cloud environment: Each hypervisor has its own IP group
Cloud environment in which each hypervisor has its own IP group

Rule of thumb is to have the IP groups used by hypervisors inside one cloud group in the same subnet.

When deploying virtual systems or virtual applications, Workload Deployer automatically assigns IP addresses to virtual machines with a one-to-one mapping. When there are no free IP addresses in the IP group, deploying virtual systems or virtual applications fails to reserve resources. It is a good idea to allocate enough IP addresses to the IP group.

This section shows how to create a new IP group and add an IP range for the new group.

Open the IP Groups window

There are two paths to go to the IP Groups window.

  1. Click Welcome then click Setting up your private cloud. Go to Step 2: Set up the cloud and click the Add IP groups link.
    Figure 28. Open the IP Groups window from the Welcome window
    Open the IP Groups window from the Welcome window
  2. Click Cloud on the menu bar and select IP Groups in the drop-down list.
    Figure 29. Open the IP Groups window through the menu bar
    Open the IP Groups window through the menu bar

Create a new IP group

  1. Click the Add icon on the top-left side of the IP Groups window. The Describe IP Group window opens.
    Figure 30. Describe IP Group window
    Describe IP Group window
  2. After providing all values in the Describe IP Group section, click the Create button. The current window is dismissed and the display goes back to the IP Groups window. Click on the newly created IP group on the left pane. The details display on the right pane as shown in Figure 31.
    Figure 31. IP group window with details pane
    IP group window with details pane

Add IP addresses to the created IP group

There are two ways to do this.

  1. Enter all hostnames in the text area separated by a space in the IP Addresses section (red arrow in Figure 31). Click Add Hostnames. The status shows whether hostnames are added successfully or not. See Figure 32 for hostnames added successfully. Click [show more] to list all IP addresses if the list is long.
    Figure 32. Hostnames added successfully
    Hostnames added successfully
  2. To add the IP range, enter the starting and ending IP addresses in the two text fields (red arrows in Figure 32). Click the Add button (blue arrow). Each IP address and its hostname are added to the list of hosts in the IP Address section, similar to the ones added by hostnames as shown in the red rectangle in Figure 32.

There is a status icon in front of each IP address and hostname pair:

  • The green check mark icon means the IP is used by a virtual machine.
  • The forward slash in the white box icon means the IP is valid and is available to use.
  • The white exclamation point in red sphere icon means the IP is not valid and an error message is displayed with the IP. You can remove an invalid IP by clicking on [remove] beside the target IP.

Create cloud groups

Users that have cloud administration full permission can perform this step if not using default user cbadmin.

A cloud group is a logical grouping of hypervisors that provides a level of isolation to different applications running in the private cloud. There are two types of cloud groups — managed and custom.

Managed cloud groups usually have software that manages all the hypervisors outside of Workload Deployer such as VMware vCenter for ESX and IBM Systems Director VMControl™ for PowerVM. Workload Deployer connects to the hypervisors through the management software such as vCenter or VMControl.

A custom type cloud group connects to each hypervisor directly.

By creating a managed cloud group, all the hypervisors managed by vCenter or VMControl are automatically added to the new cloud group.

When creating a custom cloud group, Workload Deployer only creates a cloud group without any hypervisors. You need to manually add hypervisors one by one and register them to the cloud group.

After the hypervisors are added to a cloud group, configuring and starting hypervisors is the same for both the custom and managed cloud groups.

The next section shows you how to create a managed cloud group using ESX hypervisors managed by VMware vCenter as a primary example followed by a PowerVM example to show the difference. We recommend that you have hypervisors and vCenter properly configured before starting this step, especially if you're using multiple external storage, virtual switches, and a VLAN.

Open the Cloud Groups window

Choose one of the following two options to open the Cloud Groups window.

  1. Click the Add cloud groups link from the welcome screen under Setting up your private cloud > Step 2: Set up the cloud. See the red rectangle in Figure 33.
    Figure 33. Open the Cloud Groups window from the welcome screen
    Open the Cloud Groups window from the welcome screen
  2. Click Cloud from the menu bar and select Cloud Groups from the drop-down list.
    Figure 34. Open Cloud Groups window from menu bar
    Open Cloud Groups window from menu bar

Create a new cloud group

  1. Open the Describe the cloud you want to create window.
  2. Click the green Add icon from the top-left pane of the Cloud Groups window. See Figure 35. The Describe the cloud you want to create window opens as in Figure 36.
    Figure 35. Cloud Groups window
    Cloud Groups window
    Figure 36. Describe the Cloud Group window shows ESX is not managed by vCenter
    Describe the Cloud Group window shows ESX is not managed by vCenter
  3. To create a custom type cloud group, you must provide information for the new cloud group. There are two types of cloud groups for the ESX type of hypervisor: Managed by a vCenter (managed type) and not managed by a vCenter (custom type). Different types of cloud groups require different input.

    As in Figure 36, you can create a custom cloud group in which hypervisors are not managed by a virtual center. After clicking the Create button, the newly created cloud group's status is "No hypervisors in cloud group", shown by the red arrow in Figure 37. The blue arrow shows the cloud group type as "Custom cloud group".

  4. After successfully creating a custom cloud group, you can create new hypervisors and add them to a cloud group.
    Figure 37. The custom cloud group first state is "no hypervisors in cloud group"
    Workload Deployer configuration practices
  5. To create a managed type cloud group with vCenter-managed ESX, make sure you have vCenter server up and running with hypervisors registered to the vCenter server before starting this step. As shown in Figure 38, you can create a managed cloud group. Detailed steps are listed below.

To create a managed cloud group:

  1. Check Managed by a Virtual Center in the Describe the cloud you want to create window (red arrow in Figure 38).
  2. Enter input and click Create.
  3. The Accept certificate window opens. Click Accept (see Figure 39) to accept the certificate. If the certificate is not accepted, the hypervisor is still added to the cloud group but won't be usable. You can accept the certificate from the hypervisor window later.
    Figure 38. Cloud group with hypervisors managed by a virtual center
    Cloud group with hypervisors managed by a virtual center
    Figure 39. Hypervisor certificate window
    Hypervisor certificate window
  4. In the Cloud Groups window, the status of the newly created cloud group is "Discovering hypervisors, networks and storage devices"" as shown in Figure 40.
    Figure 40. Cloud group details with vCenter managed hypervisor
    Cloud group details with vCenter managed hypervisor
  5. Click Refresh on the right pane to refresh the status. The status changes to "You must start at least one hypervisor to create virtual systems".
    Figure 41. New cloud group successfully added
    A new cloud group is successfully added

Now you are ready to configure the hypervisors.

You can also verify the newly added hypervisors in this step by clicking the Cloud menu bar and selecting Hypervisors. Check the list of hypervisors in the left pane of the Hypervisors window.

Now let's create a managed type cloud group with a system director VMControl-managed PowerVM. This is similar to creating a managed type cloud group with a vCenter-managed EXS. Let's look at the differences.

Before creating a cloud group, ensure System Director with VMControl plug-in is up and running. PowerVM is used in the cloud with NIM server and VIOs that are configured and available in VMControl.

The input of the cloud group window is shown in Figure 42. User name is the user to access VMControl.

Figure 42. Cloud group description window
Cloud group description window

All hypervisors and attached storages and networks are automatically discovered. If no hypervisor is discovered, click the Discover button on the top-right corner of the cloud group details window to launch discovery again. Refresh the details window until the discover action is complete.

On success, all hypervisors managed by the VMControl are added to the hypervisor list and to the cloud group just created. Status of the cloud group is changed to "Current status: ! You must start at least one hypervisor to create virtual systems". Start all the hypervisors you want and the cloud group status is changed to "Current status: Connected". A detailed window of a connected cloud group is shown in Figure 43.

Figure 43. Cloud group details with PowerVM hypervisor in connected state
Cloud group details with PowerVM hypervisor in connected state

Table 1 shows the differences between a custom and managed cloud group for various tasks.

Table 1. Difference between two types of cloud groups
TasksCustomManaged (by vCenter)
How to add a hypervisor to Workload Deployer.As described in this step, add hypervisors one by one.Hypervisors are added as part of the create cloud group step.
How to add a hypervisor to cloud group.In the Cloud Group window, select the hypervisor from the Hypervisors section.Add hypervisors managed by the same vCenter server to the cloud.
How to switch a hypervisor between cloud groups.In the cloud group details pane, click Remove beside the hypervisor you want to remove from the cloud group. In another cloud group details window, add the target hypervisor.Remove the hypervisor from the Hypervisor window.

Click the Reset action button on the top-right corner of the Cloud Group window to rediscover the hypervisors. This adds the hypervisor back but won't add the hypervisor to the current cloud group.

Add the hypervisor to another cloud group using the details pane of the target cloud group similar to custom cloud group type.

Now that the cloud group is created successfully, it is almost ready to deploy applications. There must be at least one hypervisor started in the cloud group. To ensure the hypervisor can be started, you need to finish configuring the storage and network setup of the hypervisor in the cloud group, following steps to create IP groups and create cloud groups for custom cloud groups or just the step to create cloud groups when working with managed cloud groups.

As a best practice, it is highly recommended to have at least two hypervisors in each cloud group to provide redundancy. For example, two IBM System x3650 servers with VMware ESX 4.1 installed.


Add hypervisors to custom type cloud group

Users that have cloud administration full permission can perform this step if not using default user cbadmin.

This step is only needed in two cases:

  • The hypervisors are not managed by management software such as vCenter.
  • The managed hypervisors are in a different cloud group from the other hypervisors managed by the same vCenter.

Hypervisor is a mandatory resource in a cloud group. All applications and images are deployed as virtual machines running on the hypervisors.

Before starting this step, there must be one or more physical servers with a hypervisor installed. Workload Deployer supports several types of hypervisors such as IBM PowerVM, IBM z/VM® and VMware ESX. For a detailed list of supported hypervisors and versions, refer to the Workload Deployer Information Center.

This step uses ESX 4.1 as an example to show how to add a new hypervisor in Workload Deployer and how to group hypervisors into different cloud groups.

Open hypervisors window

  1. Click Cloud from the menu bar and select Hypervisor from the drop-down list.
    Figure 44. Open the Hypervisors window from menu bar
    Open the Hypervisors window from menu bar
  2. The Hypervisors window opens.
    Figure 45. Hypervisors window
    Hypervisors window

Add a new hypervisor

  1. Click the Add icon in the Hypervisors window as shown in Figure 45. The Describe hypervisor window opens.
    Figure 46. Describe hypervisor window
    Describe hypervisor window
  2. Enter the hypervisor information. Enter all the required values and click OK. The Certificate window opens..
    Figure 47. Hypervisor certificate window
    Hypervisor certificate window
  3. Click Accept in the Certificate window after reading the certificate. If you click Cancel, the hypervisor is still added but it won't be usable.
  4. Verify the hypervisor has been added. The newly created hypervisor is listed on the Hypervisors window on the left pane. If you click on the new hypervisor, the details pane displays the hypervisor information on the right side as shown in Figure 48. In this example, the newly created hypervisor is called ESX-hyper-1.
    Figure 48. Hypervisor ESX-hyper-1 details window
    Hypervisor ESX-hyper-1 details window
  5. Check the hypervisor status. Click Refresh on the top-right corner of the details pane until you see the current status change to maintenance mode as in Figure 49. The hypervisor has been added successfully. Repeat the same steps to add more hypervisors.
    Figure 49. Hypervisor has been added successfully and is in maintenance mode
    Hypervisor has been added successfully and is in maintenance mode

Add hypervisors to a cloud group

  1. Click Cloud from the menu bar. Then select Cloud Group from the drop-down list. The Cloud Group window displays. See Figure 34.
  2. Click the target cloud group on the left pane of the Cloud Groups window. The details of the target cloud group displays on the right pane (blue arrow in Figure 50).
    Figure 50. Add a hypervisor to the cloud group from the cloud group details window
    Add a hypervisor to the cloud group from the cloud group details window
  3. Under the Hypervisors section in the cloud group details pane, shown by the red arrow in Figure 50, click the text field to open the drop-down list of hypervisors. Select ESX-hyper-1 to add it to the default ESX cloud group. Repeat the same step to add ESX-hyper-2 to the same cloud group.
  4. Now there are two hypervisors displayed under the Hypervisors section.
    Figure 51. Two hypervisors are listed under the Hypervisors section
    Two hypervisors are listed under the Hypervisors section

Now that the cloud groups have hypervisors, it's time to configure them.


Configure hypervisors

Users that have cloud administration full permission can perform this step if not using default user cbadmin.

A hypervisor has different states. For details, refer to the section on hypervisor states in the IBM Workload Deployer Information Center. You can see most of them during configuration. Tip: Click the Refresh button after each configuration step to ensure the state is updated properly.

After the hypervisor has been successfully added either by creating cloud groups or adding hypervisors, the status of the hypervisor is "Maintenance mode (must select a storage to use to start)".

There are two major configurations for each hypervisor — storage and network. More precisely, the hypervisor uses the storage and network selected from a list of discovered storages and networks.

Configure storage

Workload Deployer automatically discovers all storage devices configured for a hypervisor. In this step, choose the expected storage device to use with a hypervisor for the private cloud. Workload Deployer only deploys virtual machines to storage devices that are selected in this step.

After a hypervisor is added successfully, the status of the hypervisor is "Maintenance mode". You must select storage devices to use to start.

Figure 52. Select the storage devices to be used with a hypervisor
Select the storage devices to be used with a hypervisor

Expand the Storage devices section in the hypervisor's details pane by clicking the Add icon in front of the Storage devices (red arrow in Figure 52). Select the check box beside all the storage devices that you want to use with the hypervisor.

Click the Refresh button on the top-right pane until the status changes to "Maintenance mode (must select a network to use to start)".

Figure 53. Configure the network for a hypervisor
Configure the network for a hypervisor

Configure network

Workload Deployer also auto-discovers all configured networks for a hypervisor and displays them in the details pane. The next step is to select all expected networks to be used by the hypervisor and assign proper VLAN and IP groups to each network. VLAN and network configuration are not included in Workload Deployer. VLAN is optional.

  1. Expand the Networks section by clicking the Add icon beside it.
  2. Make sure the In use check box is checked beside each network you want to use for that hypervisor.
  3. Expand each network by clicking the Add button beside it, then enter the VLAN number and select the IP group. VLAN is optional. At least one network with an IP group is required for a hypervisor (red arrows in Figure 53).
  4. Click the Refresh button on the top-right pane until the status changes to "Maintenance mode".
    Figure 54. Ready to be started hypervisor is in Maintenance mode
    Ready to be started hypervisor is in Maintenance mode

Start a hypervisor

To start a hypervisor:

  1. Click Start on the top-right pane (blue arrow in Figure 54).
  2. Click Refresh to refresh the hypervisor state. It should be in "Started (move to maintenance mode to make changes)" state. The red arrows in Figure 55 show all the indicators of the hypervisor status after it is started and ready to use.
    Figure 55. A hypervisor in started mode
    A hypervisor in started mode

Verify the cloud group status

Check the state of the cloud group to which the started hypervisor belongs. It should be in a Connected state as shown in Figure 56.

Figure 56. Cloud group in a connected state
Cloud group in a connected state

Repeat the same steps to configure and start all hypervisors in the targeted cloud group to prepare for the private cloud.


Deploy shared services

Users that have cloud administration full permission can perform this step if they are not using default user cbadmin.

Note that there is a bug in Workload Deployer 3.1 and 3.1.0.1 that requires appliance administration full permission to deploy shared services. This has been fixed in 3.1.0.2.

Workload Deployer includes shared services that are ready to be deployed into a cloud group right out of the box. Shared services enable different functionalities depending on which service you need. This list is growing with new fix packs. Each cloud group can have only one instance of each shared service type. The one instance is shared among all applications in one cloud group. It is a good idea to deploy the needed shared services before any applications are deployed to the targeted cloud group to take advantage of shared services.

View the Information Center for details of provided shared services in Workload Deployer 3.1.


Other Considerations

There is another level of isolation that a cloud administrator can take advantage of in Workload Deployer. An environment profile can be created and shared between different cloud groups. It can be separated between testing and production environment for applications running in same cloud group.

A user with create-new-environment-profiles permission can create environment profiles. Environment profiles also have object-level access control that allows sharing among multiple users.

If used properly, the cloud administrator can benefit from this feature to manage the private cloud.

For more details, view the environment profiles overview in the IBM Workload Deployer Information Center.

Resources

Learn

Get products and technologies

Discuss

  • Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Cloud computing on developerWorks


  • Bluemix Developers Community

    Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.

  • developerWorks Labs

    Experiment with new directions in software development.

  • DevOps Services

    Software development in the cloud. Register today to create a project.

  • Try SoftLayer Cloud

    Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Cloud computing, WebSphere
ArticleID=836242
ArticleTitle=Configure the cloud for Workload Deployer
publish-date=10032012