Build your own cloud sandbox, Part 1: Installing an IBM Workload Deployer virtual appliance

ESX Server Edition

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®. This series complements the Navigating the IBM Cloud article series.

Share:

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

Photo of Jose De JesusJosé De Jesús is an Executive Architect on the IBM Software Services for WebSphere for IBM (I4I) team. José is a member of the IBM Academy of Technology and leads the I4I Cloud Strategic Initiative. He is also the ISSW Certification Lead, and a member of the Distributed Management Task Force (DMTF). José has a B.S. degree in Computer Science from Fordham University, and an M.S. 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.



December 2013 (First published 05 December 2012)

Also available in Russian

Introduction

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
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
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
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 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
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
The Configure Management Network screen

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 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
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
The VMware vSphere Client login screen
Figure 9. The Main vSphere Client screen
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 fileExtracted filePurpose
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:

  1. From the vSphere Client's main page, select the IP address of the ESXi server.
  2. Switch to the Summary tab.
  3. Within the Resources section, select the storage device where you would like to place the VPKD files. Then right-click and select Browse Datastore.
  4. 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.
  5. 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
    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
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
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:

  1. From the vSphere Client's main page, select the IP address of the ESXi server.
  2. Switch to the Configuration tab and then choose Security Profile from the Software section.
  3. Click the Properties link on the right. This will bring up the Firewall Properties window.
  4. Go to the Firewall section, and choose the SSH server.
  5. 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

  1. 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.
  2. 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
ScreenField / CategoryValue
Configuration Configuration Custom
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 Properties dialog.

Figure 13. Adding an additional device to a virtual machine
Adding an additional device to a virtual machine
Table 3. Values to use to configure the Workload Deployer virtual appliance
ScreenField / CategoryValue
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 CompleteVerify 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:

  • Username: cbadmin
  • Password: cbadmin

This brings up the Console prompt as shown in Figure 14.

Figure 14. The Workload Deployer console prompt
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 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 9.51.153.201 and a subnet mask of 255.255.255.128, the subnet address is 9.51.153.128.

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 9.51.153.201 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 9.51.153.128 as the network address. This means the first usable address is 9.51.153.129 because 9.51.153.128 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:

9.51.153.201         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 00001001.00110011.10011001.11111111.

This translates to 9.51.153.255. Since this is the broadcast address, the last available address would be 9.51.153.254, and therefore, the range of available IP addresses would be from 9.51.153.129 to 9.51.153.254.

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: set-ntp-servers X.X.X.X.

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 9.51.153.201, then enter https://9.51.153.201 in your browser. Figure 15 shows you what you should see.

Figure 15. Accepting the connection to the Workload Deployer virtual appliance
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
VPKD login screen

You can now log in with the default user name and password of cbadmin / cbadmin.


Conclusion

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 teaches you how to configure users, IP groups, cloud groups, and other necessary items on the appliance.

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 WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, Cloud computing
ArticleID=848478
ArticleTitle=Build your own cloud sandbox, Part 1: Installing an IBM Workload Deployer virtual appliance
publish-date=12052013