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:
- 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.
- 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.
- 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.
- 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.
- Deploying virtual system, applications, and appliances to the cloud for testing, development, or production purpose.
- 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 220.127.116.11. Figure 1 shows the necessary steps in the recommended order.
Figure 1. 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
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:
- 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.
- 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. 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
<IWDHostname/IPAddress> is the Workload Deployer appliance's
hostname or IP address that you set up using the serial console. The login window
Figure 2. 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:
- Click System and select Users from the Workload
Deployer admin console.
Figure 3. Open Users window from Workload Deployer admin console
- Select Administrator on the left pane. The details of the cbadmin user are displayed on the right pane.
- Click Edit in the Password section of the details pane.
Figure 4. Edit the cbadmin user's password
- 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
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:
- 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
- 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
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:
- Create the user or user groups.
- 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.
- 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
- 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 18.104.22.168 virtual image
Figure 10. A list of licenses to accept for the virtual image
Figure 11. All licenses have been accepted for the virtual image
- 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
- Enable the advanced features of the virtual image if you are entitled (purple arrow in Figure 12).
- 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
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
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
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
To enable IBM Web Application Pattern 2.0:
- 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
Figure 18. Details of the virtual application pattern
- Click Web Application Pattern Type 22.214.171.124 on the left pane of the Pattern Types window (green arrow in Figure 18).
- 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:
- Enable the prerequisite pattern types, which is the Foundation Pattern Type 126.96.36.199 (yellow arrow in Figure 18).
- Accept the license for the current pattern type (blue arrow in Figure 18).
- 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
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 188.8.131.52 is not configured.
Figure 20. Disabled plug-ins required for configuration of IBM Transactional Database Pattern
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.
- Click the name of the system plug-in on the Pattern Details window (green arrow in Figure 20).
- Open the System Plug-ins window from menu bar. This path is useful if the current window is not Pattern Types.
- 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
Figure 22. Select Pattern Types in the System Plug-ins window
- From the System Plug-ins window, click the drop-down list on the left pane and select IBM Transactional Database Pattern 184.108.40.206. See Figure 22. The OLTP plug-in displays on the left pane (red arrow in Figure 23).
- Click Cloud from the menu bar and select System Plug-ins, shown in Figure 21. The System Plug-ins window opens. See Figure 22.
Display details of the targeted system plug-in
Click oltp (220.127.116.11) from the left pane. The OLTP details display on the right pane.
Figure 23. 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
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
Figure 26. OLTP is not listed as disabled system plug-ins for IBM Transactional Database Pattern
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
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.
- 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
- 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
Create a new IP group
- 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
- 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
Add IP addresses to the created IP group
There are two ways to do this.
- 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
- 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.
- 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
- Click Cloud from the menu bar and select Cloud Groups from the drop-down list.
Figure 34. Open Cloud Groups window from menu bar
Create a new cloud group
- Open the Describe the cloud you want to create window.
- 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
Figure 36. Describe the Cloud Group window shows ESX is not managed by vCenter
- 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".
- 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"
- 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:
- Check Managed by a Virtual Center in the Describe the cloud you want to create window (red arrow in Figure 38).
- Enter input and click Create.
- 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
Figure 39. Hypervisor certificate window
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
Click Refresh on the right pane to refresh the status. The status
changes to "You must start at least one hypervisor to create virtual
Figure 41. New cloud group 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
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
Table 1 shows the differences between a custom and managed cloud group for various tasks.
Table 1. Difference between two types of cloud groups
|Tasks||Custom||Managed (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
- Click Cloud from the menu bar and select
Hypervisor from the drop-down list.
Figure 44. Open the Hypervisors window from menu bar
- The Hypervisors window opens.
Figure 45. Hypervisors window
Add a new hypervisor
- Click the Add icon in the Hypervisors window
as shown in Figure 45. The Describe hypervisor window opens.
Figure 46. Describe hypervisor window
- Enter the hypervisor information. Enter all the required values and click
OK. The Certificate window opens..
Figure 47. Hypervisor certificate window
- 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.
- 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
- 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
Add hypervisors to a cloud group
- Click Cloud from the menu bar. Then select Cloud Group from the drop-down list. The Cloud Group window displays. See Figure 34.
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
- 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.
Now there are two hypervisors displayed under the Hypervisors section.
Figure 51. Two hypervisors are listed under the Hypervisors section
Now that the cloud groups have hypervisors, it's time to configure them.
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.
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.
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
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
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.
- Expand the Networks section by clicking the Add icon beside it.
- Make sure the In use check box is checked beside each network you want to use for that hypervisor.
- 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).
- Click the Refresh button on the top-right pane until the status changes to
Figure 54. Ready to be started hypervisor is in Maintenance mode
Start a hypervisor
To start a hypervisor:
- Click Start on the top-right pane (blue arrow in Figure 54).
- 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
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
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 18.104.22.168 that requires appliance administration full permission to deploy shared services. This has been fixed in 22.214.171.124.
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.
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.
- The best resource for this article (an expanded version of these topics and even more pertaining the Workload Deployers) can be found at the IBM Workload Deployer information center.
Other resources that support the topic from this article:
- How to deploy cloud applications to IBM Workload Deployer
- Harness the power of the cloud with IBM Workload Deployer V3
- IBM PureApplication System: Developing virtual application patterns for IBM Workload Deployer with Rational Application Developer
- Creating a cloud to consume WebSphere MQ messages using IBM Workload Deployer
- Easy virtual app automation using Workload Deployer
- Cloud computing with a pattern-based approach
- Configure a complex cloud app test system using IBM Workload Deployer
- Learn more about cloud computing technologies at cloud at developerWorks.
- IBM has encapsulated the most-expert best practices for cloud application deployment and systems configuration in the IBM PureSystems family of expert integrated systems; get started at PureSystems at developerWorks.
- Attend an event to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
- Follow developerWorks on Twitter.
- Watch developerWorks demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
Get products and technologies
- Access IBM SmartCloud Enterprise.
- Access more information on IBM PureSystems expert integrated systems.
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
- Get involved in the developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.