Part 1: Installing an IBM Workload Deployer Virtual Appliance
By José De Jesús and Michael Nassar
This article series helps you create your own cloud environment at home or within a lab environment to work on Proof-of-Concept projects. Part 1 of this 3-part series shows you how to install the ESX server and install a Workload Deployer virtual appliance, which comes packaged as the Virtual Pattern Kit for Developers (VPKD), available for free from IBM®.
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 PureApplicationTM 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.
The following figure illustrates how the VPKD acts as a virtual appliance version of the Workload Deployer physical appliance.
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.
From the Boot Menu, press Enter. The system starts loading the ESXi installer and loading any necessary drivers:
Next, you will 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 to do and 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 this:
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:
Select the Configure Management Network option, as illustrated above, and press Enter. This displays the following screen:
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.
Finally, from your client machine, open a browser window and enter the following URL: http:// X.X.X.X. This denotes the IP address of the ESXi server. Doing so will bring up the following ESXi web page, which provides a link to download the vSphere Client software:
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. The following two figures show an example, followed by the main screen that appears after you log in:
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
The VPKD comes with the three files shown in the table below:
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 steps illustrated in the following figure:
- 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.
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>’
The following figure shows you an example:
Make sure you do not miss the single quotes and the colon, marked above in red for emphasis.
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:
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 files. 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 sections:
• 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 the table below. For every screen, use the corresponding values listed in the table below and press Next.
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. Here is what your screen should look like.
Click the Add button and use the settings in the table below. Once you are done, click Finish in the Virtual Machine Properties dialog.
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:
- Username: cbadmin
- Password: cbadmin
This brings up the Console prompt as shown below:
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 console: netif, set-dns-servers, and 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 220.127.116.11 and a subnet mask of 255.255.255.128, the subnet address is 18.104.22.168.
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 22.214.171.124 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 126.96.36.199 as the network address. This means the first usable address is 188.8.131.52 because 184.108.40.206 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:
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 00001001.00110011.10011001.11111111.
This translates to 220.127.116.11. Since this is the broadcast address, the last available address would be 18.104.22.168, and therefore, the range of available IP addresses would be from 22.214.171.124 to 126.96.36.199.
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: set-dns-servers X.X.X.X.
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 (NTP) server.
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 again.
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: device restart.
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: https://X.X.X.X.
X.X.X.X is the IP address you gave to the virtual machine with the netif command. For example, if the address you assigned to the Workload Deployer virtual appliance was 188.8.131.52, then enter https://184.108.40.206 in your browser. The following figure shows you what you should see:
Once you add the exception, you get the 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 users, IP groups, cloud groups, and other necessary items on the appliance.