Build your own cloud sandbox, Part 3: Configuring an IBM Workload Deployer virtual appliance

ESX Server Edition

This article continues our discussion from Part 1 and Part 2 of this series on how to build and configure your own cloud sandbox using a Workload Deployer virtual appliance. After securing IBM Workload Deployer (IWD), as covered in Part 2, you are ready to continue configuring the appliance. This article explains how to define cloud resources such as IP groups, cloud groups, hypervisors, and environment profiles.

As illustrated in Part 1 and Part 2, the terms Virtual Pattern Kit for Developers (VPKD), IWD, and Workload Deployer are used interchangeably throughout this series. This series complements the Navigating the IBM Cloud article series.

Apurv Johar (ajohar@us.ibm.com), Senior Software Engineer, IBM

Photo of Apurv JoharApurv Johar is a Senior Software Engineer and Solution Architect on the IBM Software Services for WebSphere for IBM (I4I) team. Apurv is an IBM Certified IT Architect and IBM Certified SOA Solution Designer. Apurv has over 17 years of experience as a software engineer and architect in the IT industry, including 14 years at IBM. In his current project, Apurv is the technical lead and development lead for the Integrated Sales Portal (ISP) application, which is available to all IBM sellers and sales managers worldwide via the IBM OnDemand Workplace (ODW).



José De Jesús (jdejesus@us.ibm.com), Executive Architect, IBM

Photo of Jose De JesusJosé De Jesús is a Senior Certified Architect on the IBM Software Services for WebSphere (ISSW) for IBM (I4I) team. José is the Non-SAP Infrastructure team lead for the Blue Harmony internal IBM project, as well as the ISSW Certification lead. He is also leading the I4I Cloud Initiative and the I4I Technical Vitality Initiative and is a member of the Distributed Management Task Force. José has a BS degree in Computer Science from Fordham University and an MS degree in Management of Technology from the University of Miami.


developerWorks Contributing author
        level

Michael Nassar (michael.nassar@wipro.com), Enterprise Architect and Senior Manager, Wipro Limited

Photo of Michael NassarMichael Nassar is a Senior IT Consultant and Certified Enterprise Integration Architect with experience in the full life cycle management of solution oriented software development. He works with client leaders to understand their needs and develops roadmaps to address business pain points and realized value. Michael designs, develops, and delivers engagements for a variety of industries and clients. He has experience leading onsite and offshore development teams.



18 December 2013

Also available in Russian

Introduction

IBM Workload Deployer supports a "bring your own cloud" model, which means it leverages existing infrastructure and existing resources. The physical network and storage resources that comprise the cloud environment must be available and ready for use prior to defining the cloud resources in the appliance.


Creating cloud resources

The following are the main activities involved in configuring cloud resources in Workload Deployer:

Let us first level set with some definitions within Workload Deployer:

  • IP groups are sets of IP addresses that can be dynamically assigned to virtual machines at deployment time.
  • Cloud groups are collections of configured hypervisors of a certain type (for example, ESX).
  • Hypervisors are configured connections to platform virtualization servers (hypervisors) capable of provisioning and running virtual machines.
  • Environment profiles are configured deployment targets that specify environment-specific policies for virtual machine placement, naming conventions, and resource constraints.

Configuring these cloud resources allows you to create cloud environments that are customized for different types of users, such as developers and testers.

This article walks you through the process of creating a relatively simple cloud that is logically partitioned into two separate environments: development and test, as illustrated in Figure 1.

Figure 1. Example of a cloud environment
Example of a cloud environment

Click to see larger image

Figure 1. Example of a cloud environment

Example of a cloud environment

Gathering information about your network

Before you can create IP groups, you must gather some important information about the network environment. Specifically, you will need the following information about the network for each IP group that you plan to create (recall that many of these values were determined in Steps 9 to 11 of Part 1 in this series):

  • Subnet address
  • Subnet mask
  • Gateway address
  • Domain Name Server (DNS) addresses
  • Range of IP addresses that are available for use (these are also registered with their hostnames in the DNS servers

If you did not set up the network that you plan to use, you will need to get this information from your network administrator.

Alternatively, if you are planning to use the same subnet for your IP group that the Workload Deployer virtual appliance uses and you have administrative access to the virtual appliance, you can also get information about the network from the Workload Deployer virtual appliance console. You can access the Workload Deployer virtual appliance console either from the VMWare vSphere Client (console connections to a virtual machine can be opened from the Summary or Console tabs for the virtual machine) or by opening an SSH connection to the virtual machine that is running the VPKD. You will need to login with the administrator user ID (such as "cbadmin") to access the console.

Once connected, you can use the netif show, show status netif, and get-dns-servers commands from the command console to determine network information for each of the virtual appliance's configured network interfaces.

As depicted in Figure 2, you can run the netif show command to determine the configured network interfaces available to Workload Deployer.

Figure 2. netif show console command
netif show console command

The netif show [interface] console command, as shown in Figure 3, displays the default gateway address and displays the Classless InterDomain Routing (CIDR) prefix at the end of the IP address as configured for the specified network interface (such as "eth0"). Recall from Step 9 in Part 1 of this article series that you can use the CIDR prefix to determine the subnet mask (for example, "/25" is equivalent to 255.255.255.128). Also recall that you can determine the subnet address from the subnet mask and IP address (for example, for subnet mask 255.255.255.128 and IP address 9.51.153.201 the subnet address is 9.51.153.128) and determine the range of IP addresses in the subnet. If you are not the network administrator, you will need to check with your network administrator as to which IP addresses have been allocated for use in your subnet.

Figure 3. netif show [interface] console command
netif show [interface] console command

Click to see larger image

Figure 3. netif show [interface] console command

netif show [interface] console command

If you do not want to calculate the subnet mask from the CIDR prefix or just want to verify your subnet mask calculation is correct, it is also possible to directly obtain the subnet mask (and other information about the network interface) from the show status netif [interface] console command. This command, shown in Figure 4, displays the status of the specified network interface.

Figure 4. show status netif [interface] console command
show status netif [interface] console command

Finally, as depicted in Figure 5, you can use the get-dns-servers console command to determine the DNS servers that are available for the network.

Figure 5. get-dns-servers console command
get-dns-servers console command

Once you have gathered the appropriate network settings for each available network that you plan to use for your cloud environment, you are now be ready to set up IP groups.

However, it is important to note that only one IP group can be mapped to each virtual network provided by the hypervisor. Depending on how you plan to partition your cloud for different groups of users, you may also determine that you (or your network administrator) first need to set up additional virtual networks in the hypervisor environment to use all of the IP groups. Therefore, prior to discussing the creation of IP groups, we will first go over an example of setting up a virtual network in the ESX hypervisor in the next section.

Create additional ESX hypervisor virtual networks (optional)

If you determine that your hypervisor does not have enough virtual networks defined for the number of IP groups that you plan to create, you will need to create additional virtual networks in the hypervisor environment. If you do not need to do this, you can skip this section.

For VMWare ESX hypervisors, you can create virtual networks (also known as port groups in VMWare) using the VMWare vSphere Client. The steps below illustrate how to create an additional virtual machine network on an ESX hypervisor. More information about ESX server networking configuration is available in the VMWare vSphere Networking Guide.


Side note

The discussion in the remainder of this section covers an example of adding a virtual network to an existing vSphere standard switch and adapter. It is important to note that it is also possible to create a separate network on a different standard switch. In that case, a different network adapter is used and a new VLAN ID can also be added. That option is available from the "Add Networking ..." link at the top right of the Networking configuration panel of the VMWare vSphere Client as depicted in Figure 6 (you may have to scroll to the right to see it).

The process of creating a separate virtual network on a different switch and network adapter is outside the scope of this article, but is similar to the process described in the remainder of this section. If you need to set up a virtual network using a different switch in your environment, you can review the VMWare vSphere Networking Guide for further guidance.
Figure 6. ESX Networking configuration panel
ESX Networking configuration panel
  1. Using the VMWare vSphere Client, go to the Configuration tab for the ESX server and click on Networking in the menu on the left side. This displays information about the configured switches, adapters, and virtual networks that have been configured. It also displays which virtual machines are currently registered in each virtual network (see Figure 7).
    Figure 7. ESX Networking configuration panel
    ESX Networking configuration panel

    Click to see larger image

    Figure 7. ESX Networking configuration panel

    ESX Networking configuration panel
  2. Click on the Properties... link above an existing network switch to view and edit the Networking properties for the switch (see Figure 8).
    Figure 8. ESX networking switch properties
    ESX networking switch properties

    Click to see larger image

    Figure 8. ESX networking switch properties

    ESX networking switch properties
  3. On the Ports tab, click on the Add... button to add a new network (see Figure 9).
    Figure 9. Add network wizard main screen
    Add network wizard main screen

    Click to see larger image

    Figure 9. Add network wizard main screen

    Add network wizard main screen
  4. Leave the Virtual Machine option selected to specify that the network is for virtual machine traffic. Click the Next button (see Figure 10).
    Figure 10. Add network wizard connection settings screen
    Add network wizard connection settings screen

    Click to see larger image

    Figure 10. Add network wizard connection settings screen

    Add network wizard connection settings screen

    A unique network label is generated by default. You can edit the label name if necessary. You can also optionally select an existing Virtual Local Area Network (VLAN) identifier that is appropriate to use for your virtual machine network environment. In networks, VLANs are used to segment network resources into different broadcast domains. This allows network administrators to either logically isolate or group together different network resources based on requirements and attributes other than just physical location. In our example, we just use the same VLAN identifier for both virtual machine port groups, but you may want to configure different VLANs to use for each port group in your network depending on your resource isolation requirements (see Figures 11a and 11b).

    Figure 11a. VLAN ID selector
    VLAN ID selector

    Click to see larger image

    Figure 11a. VLAN ID selector

    VLAN ID selector
    Figure 11b. VLAN ID selected
    VLAN ID selected

    Click to see larger image

    Figure 11b. VLAN ID selected

    VLAN ID selected
  5. Click the Next button to view the Summary screen, as shown in Figure 12.
    Figure 12. Add network wizard Summary screen
    Add network wizard Summary screen

    Click to see larger image

    Figure 12. Add network wizard Summary screen

    Add network wizard Summary screen
  6. Review the settings and click the Finish button to complete the updates. You will see the new network port group in the list and can select it to see its properties (see Figure 13).
    Figure 13. ESX networking switch properties with new network port group
    ESX networking switch properties with new network port group

    Click to see larger image

    Figure 13. ESX networking switch properties with new network port group

    ESX networking switch properties with new network port group
  7. Review the properties and click the Close button to return to the Networking configuration page, which now also displays the new network as shown in Figure 14.
    Figure 14. ESX Networking configuration panel with new network port group
    ESX Networking configuration panel with new network port group

    Click to see larger image

    Figure 14. ESX Networking configuration panel with new network port group

    ESX Networking configuration panel with new network port group

You have now created a new virtual machine port group on the ESX hypervisor, which is treated as a separate logical virtual network by the Workload Deployer virtual appliance. You can repeat this process as many times as needed to create a separate virtual machine port group for each IP group that you plan to use with the ESX hypervisor.


Creating IP groups

An IP group contains subnet configuration information and a list or range of IP addresses that you can select to use with specific hypervisors. The IP addresses in an IP group will be dynamically assigned at deployment time to the virtual machines that get provisioned to the hypervisor virtual network that uses the IP group.

You can segment your available IP addresses into separate IP groups for use by different sets of users. For example, you could potentially split 100 available IP addresses into four sets of 25 IP addresses to be used by four different departments in your organization. Although these 100 IP addresses might be all on the same subnet, creating the IP groups allows you to logically isolate them. You can then ensure that each IP group is only used for a particular purpose and by a particular group of users.

As previously mentioned, in this article we will go through the process of creating a simple cloud that is logically partitioned into separate "development" and "test" environments. Therefore, we will create two separate IP groups (one for each environment). If you do not need to partition your sandbox cloud environment, then you only need to create a single IP group if your available IP addresses are all on the same subnet.

In order to administer IP groups, you must have either cloud administration full permissions or appliance administration full permissions.

  1. To start creating IP groups, navigate to Cloud > IP Groups in the VPKD web interface.
  2. On the IP Groups page, click the green plus (+) icon to add a new IP group (see Figure 15).
    Figure 15. Adding an IP Group
    Adding an IP Group

    Click to see larger image

    Figure 15. Adding an IP Group

    Adding an IP Group
  3. In the dialog, enter the IP group name and the appropriate network settings that you collected earlier. In our example, we are creating an IP group named "IPGroup_ESX_Dev" indicating that the IP group is for our development environment. In the IP Group dialog, shown in Figure 16, click the Create button to add the IP group.
    Figure 16. Add IP group dialog
    Add IP group dialog

    The IP group is created and the properties are displayed. In the IP Addresses section, you can add either a range of IP addresses or a list of hostnames that represent the available servers in the IP group.

  4. In the IP Addresses section, specify the IP addresses or hostnames that will comprise the available servers in the IP group and click the Add button. The IP group properties will then display the addresses available, as shown in Figure 17.
    Figure 17. IP group properties
    IP group properties

    Click to see larger image

    Figure 17. IP group properties

    IP group properties

    To create the "IPGroup_ESX_Test" IP group for the test environment, we can follow the same sequence of steps that were used to create the "IPGroup_ESX_Dev" IP group. Note that to ensure logical isolation, the set of IP addresses or host names must be unique to each IP group (for example, no overlap of IP addresses or host names among different IP groups is allowed). Figure 18 shows the IP Groups page with both IP groups created.

    Figure 18. IP Groups page with two IP groups
    IP Groups page with two IP groups

    Click to see larger image

    Figure 18. IP Groups page with two IP groups

    IP Groups page with two IP groups

IP group properties and maintenance

After the IP groups are created, you can manage and update the IP groups as needed throughout their lifecycles. Each configured IP group has a set of properties, most of which you can edit. IP groups also have action links available that you can use to either refresh or delete the IP group. Figure 19 shows the action links that are available on the top right of an IP group's properties page. Table 1 provides a listing of the different actions that are available and Table 2 shows the different IP group properties.

More information about IP group maintenance is available in the IBM Workload Deployer Information Center.

Figure 19. IP group Action links
IP group Action link
Table 1. IP group actions
ActionDescription
Refresh This updates the IP group's properties page with any applicable status updates.
Delete This removes the IP group from Workload Deployer. The IP group cannot be deleted from Workload Deployer if any hypervisor is currently using the IP group. The IP group must be removed from any hypervisor that is using it before the IP group can be deleted.
Table 2. IP group properties
PropertyDescriptionEditable
Version This is the IP version of IP addresses used for the IP group (either IPv4 or IPv6). No
Subnet address This the IP address of the network subnet to use for the IP group. Yes
Netmask This is the netmask value to use for the IP group (only applicable for IPv4 IP groups). Yes
Gateway This is the IP address of the network gateway to use for the IP group. Yes
Primary DNS This is the IP address of the primary Domain Name Server (DNS) to use for the IP group. Note that if IP addresses for DNS servers are not set up correctly, deployments can fail. Yes
Secondary DNS This is the optional IP address of a secondary DNS to use for the IP group. Note that if IP addresses for DNS servers are not set up correctly, deployments can fail. Yes
Hypervisors A link to the hypervisor of which the IP group is a member (use the Hypervisor properties page to map an IP group to a hypervisor's network) No
IP Addresses This is a listing of IP addresses that have been added to the IP group. You can add new IP addresses to the IP group and remove existing IP addresses from the IP group. Only IP addresses that are not currently in use by a virtual machine. Yes

Creating cloud groups

A cloud group is a collection of hypervisors. Though a hypervisor can belong to only one cloud group, a cloud group can contain one or more hypervisors. Each cloud group can only contain hypervisors of the same type, meaning from a single vendor. In the VPKD, clouds groups are deployment targets for virtual pattern deployments.

Cloud groups can be one of two types: managed or custom. Managed cloud groups are sets of hypervisor systems that are managed by a single administrative endpoint outside of Workload Deployer, such as by the VMWare VirtualCenter Server for VMWare ESX hypervisors. In managed cloud groups, the available hypervisor systems are discovered when the cloud group is created. Custom cloud groups are collections of configured hypervisor connections that are created and maintained in the VPKD. In custom cloud groups, the hypervisor systems are not automatically discovered when the cloud group is created; you must define them separately and add them to the cloud group.

In order to administer cloud groups, you must have either cloud administration full permissions or appliance administration full permissions.

  1. To start creating cloud groups, navigate to Cloud > Cloud Groups in the VPKD web interface.
  2. In the Cloud Groups page, click the green plus (+) icon to add a new cloud group.
  3. Figure 20 shows the dialog to add a cloud group. In the dialog, add a name and optional description for the cloud group. Also specify the hypervisor type, which is ESX in our case (ESX, PowerVM, and z/VM are the currently supported hypervisor types). With ESX hypervisors, you can also specify whether the deployments of virtual images to the hypervisors in the cloud group will be managed by an instance of VMWare VirtualCenter, or whether they will be managed by Workload Deployer (for example, a managed cloud group vs. a custom cloud group).
  4. If you have VirtualCenter deployed in your environment to manage a group of ESX servers, you can select the Managed by a Virtual Center option and specify the connection properties for the VirtualCenter server. Upon cloud group creation, Workload Deployer will discover the available hypervisors, storage, and network connections from the VirtualCenter instance. In this article, we will go down the path of creating a custom cloud group. Click the Create button to complete the cloud group creation.
    Figure 20. Add Cloud Group dialog
    Add Cloud Group dialog

    Click to see larger image

    Figure 20. Add Cloud Group dialog

    Add Cloud Group dialog
  5. The cloud group is created and its properties are displayed, as shown in Figure 21. Note that the cloud group type is "Custom cloud group", which indicates that Workload Deployer manages its hypervisor connections. A custom cloud group was created because you did not select the "Managed by a Virtual Center" option on the previous dialog. There is also a warning message indicating that no hypervisors have been added to the cloud group. You will resolve that after you create the hypervisor connection in the Defining the hypervisors section.
    Figure 21. Cloud Group properties after creation
    Cloud Group properties after creation

    Click to see larger image

    Figure 21. Cloud Group properties after creation

    Cloud Group properties after creation
  6. After a cloud group is created, the administrative user who created the cloud group is its owner and has all access rights. You will likely also want to grant read access to the users or user groups that will be allowed to use the cloud group as a deployment target when deploying patterns to the cloud. You can use the Add more... selector in the Access granted to section of the cloud group properties page to add any users or user groups that need access to the cloud group.

    In our example, we assume that separate user groups, "DevUsers" and "TestUsers", have been previously created in Workload Deployer for development and test users, respectively (see Part 2 of this article series for more information about creating user groups). We are granting read access to the "DevUsers" and "TestUsers" user groups, as Figure 22 shows.

    Figure 22. Cloud group access properties
    Cloud group access properties

Cloud group properties and maintenance

After the cloud groups are created, you can manage and update the cloud groups as needed throughout their lifecycles. Each configured cloud group has a set of properties, many of which you can edit. Cloud groups also have action links available that you can use to either refresh or delete the cloud group, similar to what you see under the IP groups action links. Table 3 provides a listing of the different actions that are available and Table 4 shows the different cloud group properties.

More information about cloud group maintenance is available in the IBM Workload Deployer Information Center.

Table 3. Cloud group actions
ActionDescription
Refresh This updates the cloud group's properties page with any applicable status updates.
Delete This removes the cloud group from Workload Deployer. The cloud group cannot be deleted from Workload Deployer if there are any virtual machines deployed to it, even if they are stopped. All deployed virtual machines must be deleted before the cloud group can be deleted.
Table 4. Cloud group properties
PropertyDescriptionEditable
PropertyDescriptionEditable
Description This is the optional cloud group description. Yes
Created on This is the time stamp when the cloud group was created. No
Type This is the cloud group type (custom or managed). No
Current status This is the collective current state of the hypervisor(s) in the cloud group. No
Updated on This is the time stamp of the last update to the cloud group. No
Hypervisor type This is the hypervisor platform type (for example, ESX). No
Version This is the version of the VMWare Virtual Center Server (managed cloud groups only). No
Use linked clones Linked clones are supported by VMWare ESX environments. A clone is a copy of an existing (parent) virtual machine. ESX hypervisors support two types of clones: full clones and linked clones. Full clones are completely independent copies of the parent virtual machine, whereas linked clones are copies of the parent virtual machine that share virtual disks with the parent. Therefore, linked clones require less storage space by linking to the virtual disk resources without using the full amount of storage they actually require. (Default value: Enabled) Yes
Overcommit storage by A percentage value from 0 to 100 that represents the amount of additional storage capacity to calculate when determining whether the hypervisor contains enough space to store new virtual images that are to be deployed.

When IBM Workload Deployer deploys new virtual machines, it calculates whether the hypervisor has enough remaining storage capacity to accommodate the new virtual machines with the assumption that each new virtual machine will require its maximum disk size. If the calculation determines there is not enough remaining space on the hypervisor, the deployment will fail.

When the "Use linked clones" property is enabled, the VMWare ESX hypervisor uses various optimization techniques to minimize the amount of physical storage used. Therefore, a virtual image might use much less actual storage than full amount of storage configured for the image. You can use the "Overcommit storage by" property in conjunction with the "Use linked clones" property to tell Workload Deployer to add an additional percentage of hypervisor storage capacity to use when calculating whether enough space exists for new virtual images. As a rule of thumb, we recommend that you do not to use a value of more than 30 percent so as to reduce the chances of overcommitting physical storage and potentially causing hypervisors and existing virtual machines using that storage to fail. (Default value: 0%)
Caution: This feature is not intended for use in production environments. Furthermore, you should use it very cautiously in development and test environments. When using this feature, you need to manually monitor your storage consumption on the hypervisor. If hypervisor runtime conditions change that cause the hypervisor to use all of its committed storage and the physical storage capacity is not available, the existing resources (hypervisors and virtual machines) using the storage may fail.
Yes
CPU allocation This is the percentage of available CPU to be allocated for deployments (default value: 100%). Yes
Cloud memory allocation This is the percentage of available memory to be allocated for deployments (default value: 100%). Yes
Hypervisors This section displays a list of hypervisors that are included in the cloud group. You can add hypervisors to the cloud group by selecting the Add more ... option (custom cloud groups only). Yes
Hardware PVUs This is the number of licenses represented as processor value units (PVUs) that the hardware resources contain for all systems in the cloud group. No
URL This is the URL to reach the manager for the hypervisors in the cloud group (managed cloud groups only). Yes
Security certificate This field indicates whether the security certificate for the managed cloud group has been accepted and stored by Workload Deployer (managed cloud groups only). Yes
Cloud hardware This section displays a list of hypervisors that are included in the cloud group. You can add hypervisors to the cloud group by clicking the icon to reset connections. The reset connections action rediscovers available hypervisors as well as network and storage connections that are available for the hypervisors (managed cloud groups only). Yes
Login information This section displays the login fields for logging on to VMWare Virtual Center and for logging on to the operating system (managed cloud groups only). Yes
Access granted to This section specifies which users or user groups have access to the cloud group and what level of access they have. By default, the user who created the cloud group is the owner and has access. The Add more ... selector allows adding additional users or user groups. Once a user or user group is added, it has Read permissions, but you can toggle the permissions to allow Write or All access if necessary. There is also a remove link next to each added user or user group to remove access. Yes

Defining the hypervisors

A hypervisor is platform virtualization software that allows multiple operating systems to run on a host computer concurrently. For example, VMWare ESX/ESXi is a hypervisor platform that supports running multiple concurrent operating systems on the platform. The primary roles of hypervisor systems in a cloud environment are to provision and host the virtual machines that run the deployed software applications, middleware, and operating systems.

When you are using a custom cloud group, you must also create and start at least one hypervisor connection that the custom cloud group will use. In order to administer hypervisors, you must have either cloud administration full permissions or appliance administration full permissions.

  1. To start creating hypervisor connections, navigate to Cloud > Hypervisors in the VPKD web interface.
  2. On the Hypervisors page, click the green plus (+) icon to add a new hypervisor.
  3. Figure 23 displays the dialog to add a hypervisor connection. In the dialog, specify a name for the hypervisor, select its type (ESX in our case), and specify the host name (can be the IP address), and login parameters. Click OK to request the creation of the hypervisor.
    Figure 23. Add Hypervisor dialog
    Add Hypervisor dialog
  4. The Workload Deployer virtual appliance can successfully connect to the hypervisor using the connection properties that you provided, you are prompted to accept the hypervisor's security certificate, as shown in Figure 24. This stores the hypervisor's security certificate in the Workload Deployer virtual appliance's local storage and allows the Workload Deployer virtual appliance to subsequently communicate with the hypervisor server securely in a trusted manner. Click the Accept button to store the certificate.
    Figure 24. Hypervisor security certificate confirmation
    Hypervisor security certificate confirmation

    The Workload Deployer virtual appliance will then communicate with the hypervisor server to discover its available networks and storage devices. This may take several seconds. You can click the Refresh button to refresh the hypervisor status.

  5. After the discovery completes, the hypervisor connection will initially appear in Maintenance mode, as shown in Figure 25. When a hypervisor is in Maintenance mode, you can edit its properties. Before you can start the hypervisor, you must configure the network and storage settings.
    Figure 25. Hypervisor status after initial resource discovery
    Hypervisor status after initial resource discovery

    Click to see larger image

    Figure 25. Hypervisor status after initial resource discovery

    Hypervisor status after initial resource discovery
  6. Expand the Storage devices section to view available storage devices and select the ones that can be used. Select the In use checkbox next to each storage device that you plan to use (see Figure 26).
    Figure 26. Enable hypervisor storage connections
    Enable hypervisor storage connections

    Click to see larger image

    Figure 26. Enable hypervisor storage connections

    Enable hypervisor storage connections
  7. Clicking the Refresh button indicates that you still need to configure the hypervisor networks to use.
  8. Expand the Networks section to view the available hypervisor networks and select the ones that can be used. Select the In use checkbox next to each network that you plan to use and specify the IP group to use for each network. You need to specify the IP groups that you created earlier (see Figure 27).
    Figure 27. Enable/configure hypervisor network connections
    Enable/configure hypervisor network connections

    Click to see larger image

    Figure 27. Enable/configure hypervisor network connections

    Enable/configure hypervisor network connections

    Clicking the Refresh button now indicates that the hypervisor still needs to be added to a cloud group before it can be started.

  9. To add the hypervisor to a cloud group, go back to the Cloud Groups page at Cloud > Cloud Groups and select the cloud group that you created earlier. In the Hypervisors section of the cloud group properties, click the Add more option to select the hypervisor connection (see Figures 28 and 29).
    Figure 28. Cloud group hypervisor selection option
    Cloud group hypervisor selection option

    Click to see larger image

    Figure 28. Cloud group hypervisor selection option

    Cloud group hypervisor selection option
    Figure 29. Cloud group select hypervisor connection
    Cloud group select hypervisor connection
  10. The cloud group properties refreshes with a new warning message indicating that you must start at least one hypervisor before being able to deploy virtual systems to the cloud. You can click on the link for the configured hypervisor connection to return to its properties page and start it (see Figure 30).
    Figure 30. Cloud group status after adding hypervisor
    Cloud group status after adding hypervisor

    Click to see larger image

    Figure 30. Cloud group status after adding hypervisor

    Cloud group status after adding hypervisor

    On the hypervisor properties page, you now see that the hypervisor is a member of the cloud group and that the Start link is now enabled, as shown in Figure 31.

    Figure 31. Hypervisor status after adding to a cloud group
    Hypervisor status after adding to a cloud group

    Click to see larger image

    Figure 31. Hypervisor status after adding to a cloud group

    Hypervisor status after adding to a cloud group
  11. Click the Start link to start the hypervisor connection. The status changes to "Started". Once the hypervisor connection is started, it can receive virtual pattern deployment requests from IBM™ Workload Deployer.

At this point, your cloud environment is ready to accept virtual pattern deployment requests. However, depending on your resource constraints and usage needs, it may also be beneficial to create deployment policies and resource constraints for pattern deployments in your configured environments ("development" and "test" environments in our example). This is done by creating environment profiles, which can add the benefits of providing control over resource usage in the environments and better resource isolation. Information about configuring environment profiles is provided in the Creating environment profiles section.

Hypervisor properties and maintenance

After the hypervisor configurations are created, you can manage and update the configured hypervisors as needed throughout their lifecycles. Each configured hypervisor has a set of properties, many of which you can edit. In most cases, the hypervisor must be in maintenance mode before you can change the properties. Configured hypervisors also have several action links available that you can use to change the hypervisor state or to perform various activities on the hypervisor. Figure 32 shows the action links that are available on the top right of a hypervisor's properties page, and Table 5 provides a listing of the different actions that are available.

More information about hypervisor maintenance is available in the IBM Workload Deployer Information Center.

Figure 32. Hypervisor action links
Hypervisor action links
Table 5. Hypervisor actions
ActionDescription
Refresh This updates the hypervisor's properties page with any applicable status updates.
Move This moves a virtual machine from a source hypervisor to a compatible target hypervisor. The source hypervisor must be in quiesce mode before any virtual machines can be moved from it.
Start This starts the hypervisor in Workload Deployer. When a hypervisor is in the started state, it is available to accept virtual pattern deployment requests.
Quiesce This places the hypervisor in a suspended state. In the quiesce state, a hypervisor cannot accept new deployment requests.
Maintain This places the hypervisor in maintenance mode. In maintenance mode, a hypervisor cannot accept deployment requests and its configuration can be updated. A hypervisor cannot be put in maintenance mode if it has virtual system instances running. Any started virtual system instances on the hypervisor must be stopped before the hypervisor can be placed in maintenance mode.
Discover This forces Workload Deployer to rediscover the hypervisor's networks and storage devices. This is useful when network or storage updates have been made on the hypervisor server and the updates need to be reflected in the hypervisor's properties in Workload Deployer. The hypervisor must be in maintenance mode to rediscover its networks and storage devices.
Delete This removes the hypervisor configuration from Workload Deployer. The hypervisor cannot be deleted from Workload Deployer if there are any virtual pattern instances deployed to it, even if they are stopped. All virtual pattern instances on the hypervisor must be deleted before the hypervisor can be deleted.

Table 6 lists the different hypervisor properties. Most editable properties can only be modified when the hypervisor is in maintenance mode. The properties that can be edited when the hypervisor is started are noted in their respective descriptions.

Table 6. Hypervisor properties
PropertyDescriptionEditable
Type This is the type (such as ESX) of the hypervisor platform. No
Version This is the version of the hypervisor platform. No
URL This is the URL to reach the hypervisor (this field is provided for hypervisors in custom cloud groups only). Yes
User name This is the user name to authenticate with the hypervisor (this field is provided for hypervisors in custom cloud groups only). Yes
Password This is the password to authenticate with the hypervisor (this field is provided for hypervisors in custom cloud groups only). This field can be updated even when hypervisor is in the started state. Yes
Security certificate This field indicates whether the hypervisor's X.509 certificate has been accepted and stored by Workload Deployer. Workload Deployer does not deploy patterns or send other requests to the hypervisor until it has an accepted certificate (this field is provided for hypervisors in custom cloud groups only). Yes
Current status This is the current hypervisor state (use Action links to update status). No
In cloud group This is a link to the cloud group of which the hypervisor is a member (use Cloud Group properties page to add hypervisor to a cloud group). No
Performance This section provides a graphical view of the CPU and memory usage status for the hypervisor. By default, this view shows only the status of active virtual machines. Clicking the "Show more" link shows additional status information. No
Hardware This section provides details about the hardware characteristics of the hypervisor system.
Note that this section is only partially editable. The Hardware PVUs (Processor Value Units) field is editable. That field represents the hardware license capacity (represented as PVUs) for the hypervisor system. The rest of the section is not editable.
Yes
Deployment statistics This section provides summary information about successful and failed deployments. No
History This section displays a listing of relevant high-level actions, events, and status updates for the hypervisor with timestamps for each entry. No
Virtual machines This section provides information about the virtual machines that have been deployed or registered on the hypervisor with the current status of each virtual machine. You can drill down to see detailed information about each virtual machine. You can also perform virtual machine actions such as stop, start, and delete either on individual virtual machines or on the entire group of virtual machines. The virtual machine actions are also available when the hypervisor is in the started state. Yes
Networks This section provides summary information about the hypervisor's networks as well as information about each network's VLAN identifier. You can choose whether to enable a network for use by Workload Deployer as well as which IP group a network should use. Yes
Storage devices This section provides details on each of the storage devices that are available to the hypervisor. You can choose whether to enable a storage device for use by Workload Deployer. There is also a cleanup link, which causes Workload Deployer to remove all unused virtual images from the virtual image cache on the storage device. This helps to preserve storage capacity but can also lead to delayed startup times for future deployments if any new virtual machines need any of the virtual images that were removed. In such a case, the virtual machine startup would be delayed while the virtual image gets copied to the hypervisor. The cleanup link can be used even when the hypervisor is in the started state. Yes

Creating environment profiles (optional)

An environment profile is a configured deployment target which allows you to specify environment-specific policies for virtual machine placement, virtual machine naming conventions, and resource limits. As a deployment target, an environment profile provides you with a more advanced level of control and flexibility over virtual machine configuration and placement than a cloud group provides.

While in this article our simple sandbox cloud environment only contains one cloud group, a larger cloud environment could potentially contain multiple cloud groups. An environment profile allows you to specify multiple cloud groups and IP groups that can be used for virtual machine deployments. If an environment profile contains multiple cloud groups and IP groups, a pattern deployer using the environment profile as the deployment target can place different parts of a virtual system pattern in different cloud groups and IP groups at deployment time. This provides the flexibility to deploy, for example, the web tier, application tier, and data tier of an application in different segments of the cloud. This can be important for patterns that contain components that need to be isolated or separated across different network segments.

Environment profiles also give you the flexibility to attempt to optimize cloud resource usage in your cloud environments based on requirements, expected usage patterns, and resource constraints for each environment. When a virtual pattern is deployed using an environment profile, the Workload Deployer virtual appliance will verify whether the deployment of the virtual pattern instance can occur within the specified resource limits and constraints in the target environment.

To learn more about planning for optimizing resource usage in your cloud environment, see Bobby Woolf's developerWorks article, Managing application runtime environments in IBM PureApplication System, which provides an excellent primer. Although that article is written for cloud environments using IBM PureApplication™ Systems, most of the information is also relevant for cloud environments using Workload Deployer.

In the previous sections, we went through the process of creating a simple cloud that is logically partitioned into separate "development" and "test" environments. Therefore, we will also create two separate environment profiles (one for each environment).

In order to create environment profiles, you must have either create new environment profiles permission or appliance administration full permissions. Access to each individual environment profile is restricted to the owner (for example, creator) of the environment profile and to any users or user groups to which the owner has granted access.

  1. To start creating environment profiles, navigate to Cloud > Environment Profiles in the VPKD web interface.
  2. On the Environment Profiles page, click the green plus (+) icon to add a new environment profile.
  3. Figure 33 shows the dialog to add an environment profile. In the dialog, specify the environment profile name, an optional description, hypervisor type (ESX in our case), and environment type. The environment type is used to group environment profiles by the type of environment. During pattern deployment, the deployer can then choose to filter deployment targets by environment type. In this case, we are creating an environment profile for the "development" environment and will, therefore, choose "Development" for the environment type. Click the OK button to create the environment profile.
    Figure 33. Add Environment Profile dialog
    Add Environment Profile dialog

    The Environment Profiles page will display the properties of the environment profile that you just created. Notice that there is a warning message indicating that you still need to associate the environment profile with an active cloud group (see Figure 34).

    Figure 34. Environment Profile properties after initial creation
    Environment Profile properties after initial creation

    Click to see larger image

    Figure 34. Environment Profile properties after initial creation

    Environment Profile properties after initial creation

    You can map the environment profile to the cloud group that you created earlier by selecting the Add more... option under the Deploy to cloud groups section. After selecting the cloud group, you must then select which IP group to use in the cloud group, as shown in Figure 35.

    Figure 35. Environment Profile select cloud group
    Environment Profile select cloud group

    Click to see larger image

    Figure 35. Environment Profile select cloud group

    Environment Profile select cloud group
  4. You can select the In use checkbox for the IP group that you want to use for the environment profile. In this case, since this is our development profile, we chose the IP group for the development environment (for example, IPGroup_ESX_Dev). Once the IP group has been added, the environment profile can be used as a target for deployments (see Figure 36).
    Figure 36. Environment Profile status after specifying the IP group
    Environment Profile status after specifying the IP group

    Click to see larger image

    Figure 36. Environment Profile status after specifying the IP group

    Environment Profile status after specifying the IP group

Environment profiles allow you to control resource limits for any deployments that use the profile. Thus, different environment profiles with different environment limits specified would result in different resource policies and limits applied to any deployed pattern instances, even if the same pattern is deployed in both environments. The Environment limits section is where you can optionally set the resource limits across all deployments in the environment. This enables you to try to optimize resource usage based on how the cloud environment is expected to be used. You can set limits as needed on the number of virtual CPUs, amount of virtual memory, amount of storage, and number of product licenses to use in the environment.

For example, a development environment may require fewer dedicated resources than a test environment where heavier workloads may be tested. You can, therefore, allow larger resource limits in a test environment than you would allow in a development environment. By default, no limits are initially set in an environment profile (see Figure 37). Therefore, you need to specify values that are appropriate for your environment.

As previously noted, the developerWorks article Managing application runtime environments in IBM PureApplication System is an excellent resource for understanding the concepts behind optimizing resource usage in your cloud environments.

Figure 37. Environment Profile environment limits section
Environment Profile environment limits section

Click to see larger image

Figure 37. Environment Profile environment limits section

Environment Profile environment limits section

Like cloud groups, environment profiles are considered deployment targets and can be used to deploy patterns to the cloud. After an environment profile is created, the administrative user who created the environment profile is its owner and has all access rights. You will likely also want to grant read access to the users or user groups that will be allowed to use the environment profile as a deployment target when deploying patterns to the cloud. You can use the "Add more..." selector in the Access granted to section of the environment profile properties page to add any users or user groups that need access to the environment profile. In our example, for the development environment, we grant read access to the "DevUsers" user group. Thus, development users can use the environment profile to deploy patterns to the development environment.

After creating the environment profile for the development environment, you can also create a second environment profile for the test environment. This can be done by following the same process you used to create and configure the environment profile for the development environment. In this case, you can set the environment type to "Test", configure the environment profile to use the "IPGroup_ESX_Test" IP group, and grant read access to the "TestUsers" user group. You can also set any environment limits that are expected to be needed for resources in the test environment. Note that since each environment profile represents a separate logical deployment target with presumably different resource and usage requirements, you need to set appropriate environment limits for each environment profile that you create.

Figure 38 shows the Properties view of an environment profile created for the test environment.

Figure 38. Environment Profile properties updated with user group
Environment Profile properties updated with user group

Click to see larger image

Figure 38. Environment Profile properties updated with user group

Environment Profile properties updated with user group

Environment profiles properties and maintenance

After the environment profiles are created, you can manage and update the environment profiles as needed throughout their lifecycles. Each configured environment profile has a set of properties, many of which you can edit. Environment profiles also have action links available that you can use to refresh, clone, or delete the environment profile. Figure 39 shows the action links that are available on the top right of an environment profile's properties page. Table 7 provides a listing of the different actions that are available.

More information about environment profile maintenance is available in the IBM Workload Deployer Information Center.

Figure 39. Environment profile Action links
Environment profile Action links
Table 7. Environment profile actions
ActionDescription
Refresh This updates the environment profile's properties page with any applicable status updates.
Clone This makes a copy of the environment profile, which can then be independently modified as needed.
Delete This removes the environment profile from Workload Deployer. The environment profile cannot be deleted from Workload Deployer if there are any virtual machines deployed to it, even if they are stopped. All deployed virtual machines must be deleted before the environment profile can be deleted.
Table 8. Environment profile properties
PropertyDescription Editable
Description This is the optional environment profile description. Yes
Hypervisor type This is the hypervisor platform type (for example, ESX). No
Environment This is the environment category to which the environment profile belongs. This value is used to filter environment profiles when selecting deployment targets during pattern deployment. Yes
Created on This is the time stamp when the environment profile was created. No
Current status This is the environment profile status. No
Updated on This is the time stamp of the last update to the environment profile. No
Virtual machine name format This field allows you to optionally specify a naming convention for virtual machines that get deployed to the environment profile. In VMWare ESX environments, there are three pre-defined variables that you can use to define virtual machine naming patterns: ${hostname}, ${n-counter}, and ${vs-name}.

${hostname} is replaced with the virtual machine's hostname in the naming pattern. Note that underscore characters are not valid characters in the virtual machine's host name when using this variable.
Example: VM_${hostname}_ESX_Dev

${n-counter} is replaced with a counter of n digits in the naming pattern with leading zeroes. For example, if the variable ${2-counter} is specified then the variable will be replaced with "01", "02", "03", and so on. Similarly, if ${5-counter} is specified then the variable will be replaced with "00001", "00002", "00003", and so on.
(Example: VM_${hostname}_${3-counter}_ESX_Test)

${vs-name} is replaced with the name of the virtual system for virtual system pattern deployments. To guarantee unique names in clustered deployments, you cannot use this variable alone and it must be used with one of the other formatting variables.
(Example: VM_${vs-name}_${3-counter}_ESX_Dev)
Yes
IP addresses provided by This field indicates whether the target IP addresses are determined by the associated IP groups, or whether they are to be provided by the pattern deployer at deployment time. It is important to note that if the latter option is chosen, the pattern deployer cannot choose to deploy to an IP address that is already included in any of the IP groups in Workload Deployer. Yes
Deploy to cloud groups In this section, you can specify the cloud groups to which the environment profile can deploy patterns. Within each cloud group, you can specify which IP groups are to be used to determine the target IP addresses. Yes
Environment limits In this section, you can specify usage limits on virtual CPU, virtual memory, storage capacity, and product licenses across the virtual machines included in the environment profile. The current usage and reserved usage for each category are also displayed. Yes
Access granted to This section specifies which users or user groups have access to the environment profile and what level of access they have. By default, the user who created the environment profile is the owner and has access. The "Add more ..." selector allows adding additional users or user groups. Once a user or user group is added, it has Read permissions, but you can toggle the permissions to allow Write or All access if necessary. There is also a Remove link next to each added user or user group to remove access. Yes
Comments This section allows administrators to communicate information about the environment profile with each other. Yes

Conclusion

This concludes our third and last article in this series. You learned how to create IP groups and cloud groups, as well as to define hypervisors and environment profiles. These elements are key to configuring your different environments and establishing the right separation of duties.

Resources

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.

  • Cloud digest

    Complete cloud software, infrastructure, and platform knowledge.

  • 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=957990
ArticleTitle=Build your own cloud sandbox, Part 3: Configuring an IBM Workload Deployer virtual appliance
publish-date=12182013