Hosted VMware environments and recovery solutions in IBM Bluemix Local System, Part 1
Getting started with hosted VMware environments
This content is part # of # in the series: Hosted VMware environments and recovery solutions in IBM Bluemix Local System, Part 1
This content is part of the series:Hosted VMware environments and recovery solutions in IBM Bluemix Local System, Part 1
Stay tuned for additional content in this series.
IBM® Bluemix® Local System and PureApplication® System (referred to as Bluemix Local System) deliver hybrid cloud solutions that start with fully integrated cloud native services and cloud-enabled middleware that can run in private datacenters. Now, in firmware V2.2.3 (released on 5 May 2017), you can create automatically configured hosted VMware environments for more flexibility on how you run and manage your workloads.
You can use these environments to deploy various workloads that interact with VMware Virtual Center 6.0 and ESXi 6.0 hosts with the convenience of Bluemix Local System to configure and manage all the software and hardware components of the environment. You can also deploy PureApplication Software, which combines pattern-engine-based orchestration for hybrid cloud with the flexibility of these new environments. This concept is referred to as the PureApplication Software workload environment. With existing storage replication capabilities in Bluemix Local System, you can replicate your PureApplication Software workload environments to a second system to deliver a platform-level, zero data-loss disaster recovery solution for all types of workloads.
This series of articles provides a step-by-step guide for users of the W1500, W2500, W3500, and W3550 models to work with these advanced capabilities. To begin, this part, Part 1, shows you how to get started with creating and deploying hosted VMware environments in Bluemix Local System. It shows you how to allocate resources, configure external access to VMware components, and configure and deploy virtual machines in VMware. Then, Part 2 guides you through setting up PureApplication Software workload environments. Finally, Part 3, shows how you can build a disaster recovery solution with PureApplication Software workload environments and Bluemix Local System.
Bluemix Local System organizes compute nodes and storage resources around cloud groups. In VMware Virtual Center, which runs inside Bluemix Local System, one cluster of ESXi hosts corresponds to each cloud group. For typical cloud groups, Bluemix Local System tracks the allocation of network, compute, memory, and storage resources. This resource tracking ensures that deployments have enough resources. When high availability options are enabled, it ensures that enough resources are reserved to recover workload virtual machines when a compute node fails.
Virtual Manager cloud groups
Virtual Manager cloud groups exist specifically for hosted VMware environments. Bluemix Local System does not deploy into these cloud groups. Therefore, you must manage the network, compute, memory, and storage resources yourself.
When you create a Virtual Manager cloud group, the deployment-related settings are disabled because Bluemix Local System does not use these cloud groups for deployment. As shown in the following figure, select any unused VLAN ID for the Management VLAN ID. For more information, see the "Adding cloud groups" topic in the IBM PureApplication Software on IBM Bluemix Local W3550 2.2.3 documentation.
Figure 1. Unused VLAN ID for the Management VLAN ID
Virtual Manager cloud groups do not use IP groups. When you use hosted VMware environments, you or your application must select IP addresses for your deployments and avoid IP conflicts. In Bluemix Local System, IP groups are associated with VLANs. Therefore, associating IP groups with cloud groups dictates which VLANs to use for deployments in the cloud group. When you use Virtual Manager cloud groups, you can place virtual machines on any VLAN that is defined in the system. If you want to use specific VLANs with specific cloud groups, ensure that your deployments use the appropriate VLAN. For more information, see the "Adding connections" and "Private VLAN connections" topics in the IBM PureApplication Software on IBM Bluemix Local W3550 2.2.3 documentation.
You can add compute nodes to Virtual Manager cloud groups as you would for any other cloud group from the cloud group detail pane. Add at least one compute node to each cloud group to have a functional hosted VMware environment. For more information, see the "Viewing and modifying cloud groups" topic in the IBM PureApplication Software on IBM Bluemix Local W3550 2.2.3 documentation.
For conventional cloud groups, Bluemix Local System automatically creates Virtual Machine File System (VMFS)-formatted datastores as required to accommodate deployments and add-on VMFS volumes. When you use Virtual Manager cloud groups, you must manually create block VMFS volumes for this purpose. You can associate block VMFS volumes only with Virtual Manager cloud groups.
When you create a Block VMFS volume, select one or more Virtual Manager cloud groups to create an empty datastore, as shown in the following figure. You can expand the volume later if more storage is required. However, replicated or cloned copies of Block VMFS volumes currently cannot be enlarged. Therefore, create these volumes with the expected size from the beginning, if you plan to use them in a disaster recovery solution with another Bluemix Local System.
Figure 2. Creating a Block VMFS volume
If you create Block VMFS volumes without specifying a cloud group, the volumes are unformatted to allow block storage replication of datastores. After this type of Block VMFS volume has been the target for replication from a Block VMFS volume that has a valid VMFS datastore, you can associate the volume with Virtual Manager cloud groups.
If a Block VMFS volume is not formatted and has not received a valid datastore by using replication, this volume cannot be associated with cloud groups. The operation fails because Block VMFS volumes that are associated with cloud groups must always correspond to a mounted datastore in VMware.
Datastores have a generated name that begins with
p_. You can
identify datastores by this name in VMware Virtual Center and on ESXi
hosts. You can find the name in the volume detail pane, as shown in the
Figure 3. Identifying datastores
You can use the Block or Block Shared volume type to provide more LUNs in your hosted VMware environments, as shown in the following figure. You can use these LUNs as disks for your virtual machines by using Raw Device Mapping. These volumes are unformatted. After you attach them to a virtual machine, format them with the file system of your choice.
Figure 4. Creating a Block volume
After you create the Block or Block Shared volume, you can view its logical unit number (LUN) identifier in the volume detail pane as shown in the following figure. Only the LUN identifier is visible in VMware Virtual Center and on the ESXi hosts.
Figure 5. Identifying LUNs
Block versus Block Shared volumes: Block and Block Shared volumes provide the same functions for the Virtual Manager cloud groups. For conventional cloud groups, they differ only in how they are attached to virtual machines. Therefore, if you plan to move these volumes into conventional cloud groups and use them with virtual machines that are deployed from Bluemix Local System, choose the correct volume type for your Virtual Manager cloud group. You can attach Block Shared volumes, which are most commonly used as storage for IBM General Parallel File System (GPFS) to multiple virtual machines.
Configuring external access to VMware components
To gain access to VMware components within Bluemix Local System, make the components addressable on your network, and generate access accounts.
Setting up networking
Normally, the VMware components are only accessible internally by Bluemix Local System through the IPv6 addresses. However, the system provides two features to add IPv4 addresses for accessing VMware Virtual Center and ESXi hosts:
- Virtual Manager external IP address
- MKS Console IP Group
As a preferred practice, in addition to these two features, configure the System Management virtual local area network (VLAN) on the Bluemix Local System to be an IP Group network or VLAN. By using this approach, all of the VMware components can be on the same flat System Management network or VLAN, without requiring a switch configuration in your core network. When you configure the System Management VLAN, keep these tips in mind:
- You can only access and configure the Virtual Manager external IP address on the System Management network or VLAN. To configure an external IP address for the virtual manager (VMware Virtual Center), select System -> Network Configuration.
- You can only access the MKS Console IP Group on an IP Group network or VLAN. To grant access to the compute nodes, create an IP group called "MKS Console IP Group" with one IPv4 address for each compute node in the system. This same feature allows access to virtual machine consoles through the compute node that they are on. The IP address allows access to the VMware ESXi host that runs on the compute node. Do not associate this IP Group with any cloud group. It is a system-level resource that supplies the IP addresses for all compute nodes across all cloud groups.
Creating an external application
An external application is a collection of accounts that are created on internal components of the system, including VMware Virtual Center and ESXi hosts. The user names and passwords for these accounts are automatically generated. You must configure each external application carefully for its intended purpose. When you create an external application (Figure 6), use the following parameters to define it:
- Name. Use a unique, descriptive name that identifies the intended application, or person who is using the accounts, and the purpose.
- Access Scope. Choose Cloud Groups
for this setting, and then select the Virtual Manager cloud groups
that you created for this hosted VMware environment. The user that
will be created for VMware Virtual Center receives permission to view
and work only with the resources that are associated with these cloud
groups. Although you can select conventional cloud groups, deployment
into these cloud groups is not supported and can interfere with
deployments from Bluemix Local System.
Use the Everything option only when you create an external application for monitoring purposes. When you select the Grant Compute Node Access option, the Access Scope parameter also determines which compute nodes are accessible by this external application. When you choose Cloud Groups, users are created for only the compute nodes that belong to the selected cloud groups.
- Virtual Manager Privilege Set. Choose Default for a hosted VMware environment. You can use Read Only for monitoring or reporting purposes.
- Grant Compute Nodes Access. Select this option for a hosted VMware environment. By using this option, you can connect to the ESXi hosts, which is required for transferring files, such as OS installation media or pre-built virtual machine disks (VMDKs), into the environment.
- Grant Storage Access. To create a monitoring user for the storage controller in addition to the VMware accounts, select this check box. Otherwise, unless storage monitoring is required, leave this check box cleared.
Figure 6. Creating an external application
You can create as many external applications as you want. Use different external applications for each use case so that you can revoke access or regenerate passwords at a sufficiently fine granularity. After you set up an external application, click Show details. A window (as shown in the following figure) opens that lists the external users (accounts) that are associated with the external application. Each row corresponds to a user for one of the internal components of the system and gives the IP address and user name for accessing it. To see the password, click Show Passwords.
Figure 7. Viewing external users
Accessing VMware Virtual Center
In the list of external users for your external application, look in the
Name column for the value
Virtual Manager. This
row gives the IP address and user name for accessing VMware Virtual
You can supply these credentials to applications that use the VMware vSphere API to connect to VMware Virtual Center directly. You can also use the credentials to allow human users to access the vSphere Web Client.
Prerequisite for using the
vSphere Web Client: Before you use the
vSphere Web Client, create an entry in the hosts file of the computer that
you will access the web client from. For this entry, map the host name
purevc to the external IP address that you set up for VMware
Virtual Center. Consult your operating system (OS) documentation for
instructions on creating this host mapping. Log in to the web client at
https://purevc/vsphere-client/, as shown in the following
Figure 8. Logging in to the VMware vSphere Web Client
In some cases, clusters and hosts might not display in the Hosts and Clusters view, and datastores might not display in the Storage view. This issue is known in the vSphere Web Client. To work around this problem, search for the inventory item from the search box in the upper right corner of the user interface.
Accessing ESXi hosts
If you selected the Grant Compute Nodes Access option when you
created your external application, external users were created for each
compute node. In the Name column, the value that displays for
these users is
Compute Node followed by an IPv6 address and
serial number. In VMware, the name of the ESXi host for the compute node
matches the IPv6 address that is shown.
To use the VMware Host Client, log in at
https://<IP Address>/ui/, replacing
<IP Address> with the IP address that is
listed for the external user, as shown in the following figure.
Figure 9. Logging in to the VMware Host Client
You can also use Secure Shell (SSH) protocol or Secure Copy Protocol (SCP) with this ESXi user.
ESXi users: External users for compute nodes have full permission on the ESXi host. Use caution when you use these accounts to access storage and to manage virtual machines. Using them to change the configuration of the ESXi host can interfere with normal operation of Bluemix Local System.
Configuring and deploying virtual machines in VMware
After you allocate resources and have access to the Virtual Center Server, start configuring the environment and deploying virtual machines. The purpose of these new hosted VMware environments is to give you more flexibility in how virtual machines are configured, deployed, and managed. This section provides basic starting points for these things, but they can vary widely depending on your objectives.
Cluster options for high availability
In Bluemix Local System, you can ensure high availability at the cloud group level by managing the resource consumption within conventional cloud groups. As an alternative, you can reserve compute nodes at the system level to be supplied to cloud groups as needed for failover.
Because Bluemix Local System does not monitor or manage deployments in Virtual Manager cloud groups, neither of these high availability options is available for hosted VMware environments. You must decide how you want to provide high availability in your Virtual Manager cloud groups. For conventional cloud groups, the vSphere High Availability (HA) and Distributed Resource Scheduler (DRS) settings on the corresponding clusters are set and monitored by Bluemix Local System. For Virtual Manager cloud groups, both vSphere HA and vSphere DRS are initially disabled. However, you can enable and configure them as you choose, and Bluemix Local System will not change the settings.
If you have multiple compute nodes in the Virtual Manager cloud group, use vSphere HA, and select one of the hosts as a dedicated failover host. If the compute nodes have different memory and CPU capacities, choose the node with the highest capacity. This way, you have high availability if a single compute node failure occurs. The compute node that you select as a dedicated failover host is placed in maintenance mode, and VMware Virtual Center prevents deployment of virtual machines (VMs) on it. Its full capacity is reserved to take on the workload of any other host if a failure occurs. For more information, see vSphere HA Admission Control and Configuring vSphere HA Cluster Settings int he VMware documentation.
Transferring files to and from the hosted VMware environment
You must transfer files that contain OS installations, such as VMDKs and ISO images, into the environment by using the ESXi hosts on the compute nodes. The internal configuration of the VMware components prevents use of the datastore browser in VMware Virtual Center to transfer files.
In Bluemix Local System, the Block VMFS volumes that you create can have
meaningful names that you choose. However, the corresponding datastores in
VMware have automatically-generated names that start with
(See Figure 3 for an example.)
To transfer files onto a datastore:
- Look up the name of the datastore.
- Identify any compute node that is a member of one of the cloud groups and is associated with the Block VMFS volume.
- Retrieve the credentials for that compute node from the external application details dialog box.
You can connect to the ESXi host on the compute node by using a web browser and the VMware Host Client. Then, find the datastore by its name, and use the datastore browser to transfer the files.
For faster transfer of larger files, you can also use an SCP client to connect. The datastore contents are mounted in the /vmfs/volumes directory. For example, the contents of the datastore on the Block VMFS volume that is shown in Figure 3 are in the /vmfs/volumes/p_a1a152fe-6edf-4ce5-8a90-439648ee0d09 directory.
Creating virtual machines
You can use the vSphere Web Client to create VMs by choosing the New Virtual Machine action on a host or cluster. In the wizard that opens, you can choose to create a VM from scratch or from a template. You can also perform several different types of cloning operations.
Figure 10. Creating a new virtual machine
When you select a location for the VM, the vSphere Web Client does not allow you to select the root VM folder (datacenter) if the external application was created with the Cloud Groups access scope. In this case, expand the datacenter, and select the folder with the same name as the cluster in which you are creating the VM (see the following figure).
Figure 11. Selecting the virtual machine location
Also, select a location to store the VM files. This location is a datastore (see the following figure) on one of the Block VMFS volumes that you created and associated with the cloud group. The VM files are stored in a folder in this datastore with the same name as the VM.
Figure 12. Selecting a datastore for the virtual machine
When you configure the hardware for your VM, you can create new disks, select existing disks that you previously transferred into the hosted VMware environment, or do both. If you created a Block volume to use a LUN as an RDM disk, you can identify the LUN by its LUN identifier. For example, the LUN identifier from the Block volume that is shown in Figure 5 appears as part of the name of the target LUN in the New Virtual Machine wizard in the following figure.
Figure 13. Attaching an RDM disk
On the hardware customization step, you can also select the VLAN for your VM. For each network interface that you add, a drop-down list shows the available port groups (see the following figure). Each port group corresponds to a VLAN that is defined in Bluemix Local System. The name of each port group is the same as its VLAN ID.
Figure 14. Selecting a port group for the VLAN
In Bluemix Local System 2.2.3, the Deploy OVF Template action is not supported because of the internal configuration of the VMware components. To deploy an Open Virtualization Format (OVF) template:
- Download the constituent disk images and resource files for the OVF, or extract them from the tar file if you are using an Open Virtualization Appliance (OVA).
- Transfer the files into the hosted VMware environment.
- Create VMs and customize the hardware as specified by the OVF descriptor file.
Accessing virtual machines by using the remote console
The best way to access the consoles of your VMs is to download and install the VMware Remote Console, which is a stand-alone application.
You can start a session by using the VMware Host Client for the specific ESXi host that the VM is running on. (Using the vSphere Web Client is not possible due to the internal configuration of VMware components.)
- Identify the host on which the VM is running by using vSphere Web Client.
- Use the name of the host (which is the IPv6 address of the compute node) to find the IP address and credentials for the compute node.
- Open the VMware Host Client from a web browser at
https://<IP Address>/ui/, and replace
<IP Address>with the IP address that is listed for the compute node.
- Locate the VM, and select Console-> Launch remote console.
Another option is the HTML5-based browser remote console in vSphere Web Client, but it has limitations in the mouse functions, as documented by VMware.
This article introduced you to the advanced features of IBM Bluemix Local System and IBM PureApplication System firmware V188.8.131.52. You learned how you can get started with creating and deploying hosted VMware environments in Bluemix Local System. Specifically, you learned how to allocate resources, configure external access to VMware components, and configure and deploy virtual machines in VMware. In Part 2 of this series, you learn how to set up PureApplication Software workload environments.
The authors extend their appreciation to Gus Parvin, Jessica Stevens, and Joe Wigglesworth for their help with this article.
- IBM Bluemix Local on PureApplication System
- developerWorks Bluemix Developer Center
- PureApplication articles and tutorials in the developerWorks Middleware hub
- Provide high availability and disaster recovery in IBM Bluemix
- VMware Knowledge Base