IBM Workload Deployer is an appliance that can provision virtual images and patterns onto a virtualized environment. It provides a cloud management application as a Web 2.0 interface, pattern modeling technology, and an encrypted image catalog that comes pre-loaded with virtual images, patterns, and script packages.
Workload Deployer can be leveraged as a physical appliance, a virtual appliance, or as an embedded component of the IBM PureApplication™ System. This article helps you configure your cloud environment using the virtual appliance version of Workload Deployer, which is packaged as the Virtual Pattern Kit for Developers (VPKD), and is delivered as a VMware virtual appliance.
Figure 1 illustrates how the VPKD acts as a virtual appliance version of the Workload Deployer physical appliance.
Figure 1. Workload Deployer as a virtual appliance
For more information about Workload Deployer, see the Navigating the IBM Cloud article series.
The VPKD is a full working software version of a Workload Deployer physical appliance. The only difference is that it includes only what is needed to create virtual application patterns. The VPKD does not include the hypervisor images delivered with Workload Deployer or with IBM PureApplication System, but you can import those images into the virtual appliance as Open Virtual Appliance (OVA) files, or create your own virtual images using the ICON tool.
Functionally, the Web 2.0 interface in both the physical and the virtual appliances is exactly the same; the only minor difference is that the text "IBM Workload Deployer" gets replaced with "Virtual Pattern Kit" throughout the GUI to avoid confusion.
The VPKD allows you to:
- Develop and test virtual application patterns.
- Develop and test virtual system patterns, if you add the necessary virtual images to the catalog.
- Promote your virtual application patterns to the IBM PureSystems™ Centre, if you are an IBM Business Partner.
The VPKD includes:
- Web Application Pattern 2.0
- IBM Transactional Database Pattern 1.1
- IBM Data Mart Pattern 1.1
- Plug-in Development Kit (PDK)
- IBM Image Construction and Composition (ICON) Tool
- Base OS (RHEL) image
Step 1: Download and install the ESXi server
The first step is to download a copy of the ESXi server from the VMware site. Burn the ISO image onto a DVD and use it to boot the machine that will serve as the ESXi server, or mount the ESXi 5 ISO image to the DVD drive of the server and boot from the DVD. Figure 2 shows the first screen you see shortly after booting. The installation of ESXi is quite simple and straightforward.
Figure 2. The ESXi server boot menu
From the Boot Menu, press Enter. The system starts loading the ESXi installer and loading any necessary drivers, as shown in Figure 3.
Figure 3. Loading the ESXi installer
Next, you see a series of screens displaying what the system is doing before you get prompted to choose installation options. Rather than include screen shots for each of those steps, here is a summary of what you will see:
- Press Enter to begin choosing installation options.
- You are prompted to press F11 to accept the "End User License Agreement".
- This is followed by a dialog that lets you select on which of your available disks to install the ESXi server.
- The system then asks you to select a keyboard layout.
- Specify a root password.
- Confirm the installation options by pressing F11.
This starts the installation, which takes a few minutes. Once it is done, you are asked to press Enter to reboot the system. After the system reboots, it shows you its main screen, which appears similar to Figure 4.
Figure 4. The ESXi main page
The host name and IP addresses that appear at the bottom (emphasized in blue, italic font) vary depending on your system. The same is true for the machine description and memory amount that appear at the top. We recommend at least 32GB of memory and preferably more, but you can try to make it work with less.
Step 2: Configure the network
To configure the network on the ESXi server, press F2 from the main screen. You are asked to enter the root password before the system displays the System Customization screen as shown in Figure 5.
Figure 5. The System Customization screen
Select the Configure Management Network option, as illustrated in Figure 5, and press Enter. This displays the screen shown in Figure 6. The X's denote the IP address of the ESXi server, the Y's represent the subnet mask (usually 255.255.255.x), and the Z's denote the IP address of the default gateway. Take note of these, as you will need them further below.
Notice that if your network includes a DHCP server, the ESXi server automatically gets assigned an IP address, a subnet mask, and a default gateway (Figure 6). You can also configure these items manually if you prefer by pressing Enter. If you did not install the ESXi server yourself, ask your network administrator for these network settings.
Figure 6. The Configure Management Network screen
Finally, from your client machine, open a browser window and enter the
http://X.X.X.X. This denotes the IP address of
the ESXi server. Doing so will bring up the ESXi web page shown in Figure
7, which provides a link to download the vSphere Client software.
Figure 7. The VMware ESXi 5 Welcome page
Step 3: Download and install the vSphere Client
You will need the vSphere Client software to remotely control and work with the ESXi server. Installing it is also straightforward. You basically run its installation and then execute the program. Note that, as of this writing, vSphere Client only runs on Windows®. When the vSphere Client starts, it prompts you to enter the IP address of the ESXi server you wish to connect to (via a drop-down menu that remembers your choices), as well as the user name and password you specified when installing the ESXi server. Figure 8 shows an example and Figure 9 shows the main screen that appears after you log in.
Figure 8. The VMware vSphere Client login screen
Figure 9. The Main vSphere Client screen
Step 4: Download the VPKD
You can download the IBM Virtual Pattern Kit for Developers for free. If you have not done so already, you are asked to register for an IBM Universal ID.
Note: Since the VPKD files are quite large, keep in mind the location from where you are downloading them. If the ESXi Server is running on an enterprise network and you are accessing it from a remote vSphere Client on a network that is much slower, such as from home, you may want to first create a standard Linux VM on the ESXi server and then download it from that VM instead of from your local machine. Because the next step would be to transfer those files to the ESXi server, it will be faster to do so from a virtual machine located on the ESXi server itself, or at least from a machine on the same network, than from a machine at a remote location.
Step 5: Unzip the VPKD
As of this writing, the VPKD comes with three files shown in Table 1.
Table 1. Files that come with the VPKD
|Compressed file||Extracted file||Purpose|
|IBMVPKFD.zip||IBM_Virtual_Pattern_Dev_Kit.vmdk (1.3 GB)||Virtual machine firmware image|
|N/A||Content.vmdk (21GB)||Data disk image, which contains virtual application pattern types|
|Installation_guide.zip||vpk_guide.pdf (454,441 bytes)||Installation Guide on how to install the VPKD|
Step 6: Transfer the VPKD files to the ESXi server
There are several ways in which you can transfer the VPKD files to the ESXi server.
If you downloaded the files to your local Windows machine, and want to transfer them from there to the ESXi server, you can take the following steps, as illustrated in Figure 10:
- From the vSphere Client's main page, select the IP address of the ESXi server.
- Switch to the Summary tab.
- Within the Resources section, select the storage device where you would like to place the VPKD files. Then right-click and select Browse Datastore.
- From the Datastore browser, create a folder to store the files. This example uses the folder "VPKD", but you can use any name you wish.
- Select the folder you just created. Then click the
Upload button to select files from your local
drive and begin uploading them to the ESXi server.
Figure 10. Transferring files from your local machine to the ESXi server
Another approach is to follow Steps 1 to 4 above to create the folder in the ESXi server, but then transfer the files from a machine local to the ESXi server via the SCP command. Here is the format to use:
scp <filetotransfer> '<user>@<hostname>:<location>'
Figure 11 shows you an example. Make sure you do not miss the single quotes and the colon, marked in red for emphasis.
Figure 11. Transferring the .vmdk files via SCP
To get the location name of the datastore, which must precede the destination folder in the SCP command, go to the Configuration tab of the vSphere client, click Storage, and then select the datastore whose location name you need. The information, in this case a vmfs volume, displays in the Datastores section as illustrated in Figure 12.
Figure 12. Finding a datastore’s location name
For the SCP command to work, the ESXi server must be set to allow incoming SSH connections. You can verify this as follows:
- From the vSphere Client's main page, select the IP address of the ESXi server.
- Switch to the Configuration tab and then choose Security Profile from the Software section.
- Click the Properties link on the right. This will bring up the Firewall Properties window.
- Go to the Firewall section, and choose the SSH server.
- Within the dialog, press the Firewall button and set your rules for allowing this type of connection
If you are not the administrator of the ESXi server, you need to ask the network administrator to configure the ESXi server so that it allows incoming SSH connections.
Step 7: Install and configure the VPKD
As mentioned earlier, the VPDK is a virtual machine version of the Workload
Deployer appliance. It is delivered as a set of
VMDK, which stands for Virtual Machine Disk, is a file format used for
VMware virtual appliances. With the Workload Deployer virtual appliance,
you get two .vmdk files: one for the firmware image and another one for
the content. We will, therefore, divide this step into the following two
- Creating the Virtual Machine Firmware image
- Attaching the data disk containing the pattern types
Creating the Virtual Machine Firmware image
- To begin creating the Workload Deployer virtual appliance, go to the vSphere client and create a new virtual machine on the ESXi server. To do this, go to the Getting Started tab, and select File > New > Virtual Machine. You can also press Ctrl+N, or right-click the IP address of the ESXi server, and select New Virtual Machine.
- In the configuration screens that follow, configure the virtual machine using the values listed in Table 2. For every screen, use the corresponding values listed in Table 2 and press Next.
Table 2. Values to use to configure the Workload Deployer virtual appliance
|Screen||Field / Category||Value|
|Name and Location||Name||IWD Virtual Appliance (VPKD)|
|Storage||Datastore||Choose any available datastore. This example uses a datastore with the name SVC01.|
|Virtual Machine Version||Virtual Machine Version||Choose the default value, which, for this example, is Virtual Machine Version: 8.|
|Guest Operating System||Guest Operating System||Linux|
|Version||Other 2.6.x Linux (64-bit)|
|CPUs||Number of virtual sockets||Minimum of 2|
|Number of cores per virtual socket||Minimum of 1. For this example, we used 2 virtual sockets and 2 cores per socket for a total of 4 cores.|
|Memory||Memory Configuration||Minimum of 8GB, but 16GB is recommended. We use 16GB in our example.|
|Network||How many NICs do you want to connect?||Minimum 1. You need to configure this section based on your network settings and on the IP address that you plan to assign to the Workload Deployer virtual appliance. Select to connect it at "Power On".|
|SCSI Controller||SCSI controller||Select the default value. In our example, the default value is "LSI Logic Parallel".|
|Select a Disk||Disk||Choose to use an existing virtual disk.|
|Select Existing Disk||Disk File Path||Press the Browse button and choose the IBM_Virtual_Pattern_Dev_Kit.vmdk file found in the VPKD directory created earlier.|
|Advanced Options||Virtual Device Node||IDE (0:0)|
|Mode||Default (leave Independent unchecked)|
|Ready to Complete||Edit the virtual machine settings before completion||Click this checkbox, then click Continue.|
Attaching the data disk containing the pattern types
The next part of installing the Workload Deployer virtual appliance is to
attach the data disk (
Content.vmdk) as an independent disk to
your virtual machine. Figure 13 shows what your screen should look like.
Click the Add button and use the settings in Table 3.
Once you are done, click Finish in the Virtual Machine
Figure 13. Adding an additional device to a virtual machine
Table 3. Values to use to configure the Workload Deployer virtual appliance
|Screen||Field / Category||Value|
|Device Type||Hark Disk||Custom|
|Select a Disk||Disk||Use an existing virtual disk|
|Select Existing Disk||Disk File Path||Press the Browse button and choose the Content.vmdk file found in the VPKD directory created earlier.|
|Advanced Options||Virtual Device Node||IDE (0:1)|
|Mode||Independent - Persistent|
|Ready to Complete||Verify your choices||Click Finish.|
Step 8: Start the Workload Deployer virtual machine and verify the installation
Start the virtual machine either by selecting it and clicking the green "Power On" button, by right-clicking the virtual machine and selecting Power > Power On, or by pressing Ctrl+B. Go to the console tab and give the system some time to boot. You may have to press Enter once or twice for the login prompt to appear. Log on with the following credentials:
This brings up the Console prompt as shown in Figure 14.
Figure 14. The Workload Deployer console prompt
Step 9: Determine the CIDR prefix from the subnet mask
After logging on, you need to configure the network for the Workload
Deployer virtual appliance. This involves issuing three commands from the
set-ntp-servers. Before discussing these commands though, let
us review some important terms.
An IP address is a 32-bit binary number, written in dot-decimal notation, which uniquely identifies a device on an IP network. The 32 bits are divided into two portions: the address of the network (network ID) and the address of a device on that network (host ID). The number of bits used for each of these IDs determines the possible size of the network.
The original IP addressing scheme, known as address classes, used the first four bits of the IP address to determine the class of a particular address. Class A networks, for example, start with the first bit as zero and use only 8 bits total for the network ID, and the remaining 24 bits for possible host addresses. Class B networks start with the bits 1 and 0, and use 16 bits total for the network ID and 16 bits for host IDs, and so on. The problem with address classes is the discrepancy it creates between the numbers of hosts allowed for one class of network versus another. For example, each Class A network can accommodate over 16 million hosts, while Class C networks can only accommodate 254.
Notice that, out of the assignable host IDs for a given class, there are always two reserved IDs that cannot be used: the first and the last. Class C addresses, for example, use eight bits for the host ID, which would normally mean 28 or 256 possible hosts (0 to 255). However, a Class C address allows only 254 host IDs. That is because the first host, ending in 0, is always reserved to represent the network itself. This is known as the network address. The last host, ending in 255, is reserved to broadcast messages to all of the hosts on the network. This is known as the broadcast address.
Limiting the Internet to Class A, B, or C addresses (D and E are reserved) would require every network to be allocated either 254, 65 thousand, or 16 million IP addresses for host devices. This leaves no suitable midpoint and creates waste in class addressing. Because of this, as well as the rapid growth of the Internet and the fear of running out of IP addresses, a more efficient method to assign Internet addresses was developed called classless IP addresses. The Classless InterDomain Routing or CIDR notation was developed to assign Internet addresses in a more efficient manner. The idea is to use subnets that basically use the 32 bits in an IP address more efficiently to extend the network ID and, therefore, create networks not limited to Class A, B, or C schemes. With subnets, network IDs can be of any length. Bits are used from the host ID portion to divide a network into smaller subnets.
Eventually, we will be using IPv6, which is a new Internet addressing scheme consisting of 128-bits in length and hexadecimal characters. Discussing IPv6 is beyond the scope of this article, but just note that IPv6 will give you more Internet addresses than you will ever need for a very long time. The number of unique IP addresses that IPv6 offers is a 39 digit number, if you can imagine that.
When you configure the Workload Deployer virtual appliance, one of the parameters you need to know is the subnet mask as well as the corresponding CIDR prefix.
The subnet mask comes from the ESXi server, either via DHCP or from a static definition. If you do not have visibility to the ESXi server, ask your network administrator for the subnet mask, as well as the gateway address.
Calculating the CIDR prefix (also called network prefix) from a subnet mask is easy: first convert the subnet mask to binary, and then count the number of 1's. The bits that correspond to the network ID are set to 1 while the bits that correspond to the host ID are set to 0. For example, assume the subnet mask is 255.255.255.0. If you convert that to binary, you get 11111111.11111111.11111111.00000000, which contains twenty-four 1's. Therefore, the CIDR prefix is "/24", which means the complete network ID is 24 bits long and the host ID portion is 8 bits long. Similarly, if you had a subnet mask of 255.255.255.128, the CIDR prefix would be "/25". 30 is the maximum number of bits you can use for a network ID to make room for the host ID.
Calculating the subnet address
The subnet address, also called the network ID, is basically the IP address of the network itself. Given an IP address and a subnet mask, a router performs a bitwise AND operation between the two to calculate the network ID. For example, given an IP address of 188.8.131.52 and a subnet mask of 255.255.255.128, the subnet address is 184.108.40.206.
Calculating the range of IP addresses
If you have an IP Address and a subnet mask (or CIDR prefix), you can calculate the range of IP addresses that are available on that network. For example, assume you have the IP address 220.127.116.11 and the subnet mask 255.255.255.128. From the previous discussion, you can perform a bitwise AND operation between them to come up with 18.104.22.168 as the network address. This means the first usable address is 22.214.171.124 because 126.96.36.199 is the address of the network itself. To calculate the last address in the range, convert the IP address and the subnet mask to binary and align both binary numbers, as in the following example:
188.8.131.52 00001001.00110011.10011001.11001001 255.255.255.128 11111111.11111111.11111111.10000000
Consider the bits in the IP address where the subnet mask contains 0's.
These appear in bold above for easier reference. For the example above,
consider the last seven bits of the IP address. These are the host bits,
and the rest are network bits. If you change all the host bits to 1 and
convert that last octet to decimal, you would get the broadcast address of
the network. In this example, the resulting binary number would be
This translates to 184.108.40.206. Since this is the broadcast address, the last available address would be 220.127.116.11, and therefore, the range of available IP addresses would be from 18.104.22.168 to 22.214.171.124.
If you are not the administrator for the ESXi server, you may only get a subset of the range that is available. Some environments have restrictions with ports that need to be opened. In that case, your network administrator can give you the range of IP addresses that you are allowed to use. This range would be the available IP addresses that can be assigned to provisioned virtual machines. You also have to use one of these for the Workload Deployer virtual appliance itself.
Step 10: Configure the network
Now you are ready to configure the network for the Workload Deployer virtual appliance. Using the information compiled so far, execute the following commands from the Workload Deployer console:
netif set eth0 enabled=true IPAddress=ipaddress/cidr-prefix DefaultGateway=gatewayaddress
The string eth0 refers to the first Ethernet card. These are labeled ethX, beginning with 0 for the first Ethernet card, 1 for the second one, and so on. The ipaddress is the IP Address you wish to assign to the Workload Deployer virtual appliance. The cidr-prefix refers to its corresponding CIDR prefix, based on the subnet mask. The gatewayaddress points to the default gateway. After entering the netif command, you get the console prompt again.
Step 11: Setting the DNS and NTP servers
There are two other commands you need to issue before rebooting the server
and verifying the installation. The first command is:
X.X.X.X refers to the IP address of the primary DNS server.
You can also specify an additional IP Address for a secondary DNS server
in this format:
set-dns-servers X.X.X.X Y.Y.Y.Y.
Make sure you separate both addresses with a space.
If you control the ESXi server, you can see what these values are by going to the Configure Management Network screen shown in Figure 6 and choosing the DNS configuration. You need at least one DNS server address. If you do not have access to the ESXi server, you need to ask your network administrator for that information.
The other command you need to execute is this:
X.X.X.X refers to the IP address of the Network Time Protocol
Workload Deployer needs to use an NTP server to keep the date and time synchronized across your virtual machines. It is usually an NTP server available in the same subnet, but it does not have to be. When patterns are deployed, for example, Workload Deployer uses the NTP server to establish the system time for your virtual machines.
You can use public NTP servers such as those found in the NTP Pool Project. Or, if you
are working from a corporate network and the ESXi server was installed by
a network administrator, you can ask the network administrator for the IP
address of an NTP server. ESXi also has an NTP daemon that can be
configured so that the hypervisor itself acts as an NTP server, as well,
but how to do that is beyond the scope of this article. After issuing the
set-ntp-servers command, you get the console prompt once
Step 12: Verifying the installation
Finally, you need to restart the device for changes to take effect and
verify your installation. To restart the Workload Deployer virtual
appliance, enter the following command at the prompt:
The system briefly shows a login screen and then quickly begins the reboot
process. Once your device has completely restarted and you have logged on
again, open a browser window and type:
X.X.X.X is the IP address you gave to the virtual machine with
netif command. For example, if the address you assigned
to the Workload Deployer virtual appliance was 126.96.36.199, then enter
https://188.8.131.52 in your browser. Figure 15 shows you
what you should see.
Figure 15. Accepting the connection to the Workload Deployer virtual appliance
Once you add the exception, you get the login screen as shown in Figure 16.
Figure 16. VPKD login screen
You can now log in with the default user name and password of
cbadmin / cbadmin.
This concludes our first article on how to build your own cloud environment. We covered everything you need to know to download and install the Virtual Pattern Kit for Developers from scratch. Part 2 of this series picks up from there to show you how to configure your security options. Part 3 (future article) will teach you how to configure users, IP groups, cloud groups, and other necessary items on the appliance.
- IBM developerWorks Cloud zone
- New to cloud computing
- Cloud computing fundamentals
- Connecting to the cloud, Part 1: Leverage the cloud in applications
- Navigating the IBM Cloud article series
- Virtual appliances and the Open Virtualization Format
- IBM PureSystems Centre
- IBM PureSystems resources on developerWorks
- IBM developerWorks WebSphere zone