To configure Intelligent Management to
work with VMware Infrastructure 3 platforms,
you must configure security so that the servers can communicate with
each other and configure custom properties on your deployment manager
to define the vCenter or ESX servers.
Before you begin
- Your VMware Infrastructure 3 platforms environment
must be on servers that are running Solaris Operating Environment
on Intel hardware, Windows, or Linux x86
operating systems.
- You must use VMware products
that support VMware Infrastructure 3 platforms.
The supported versions are:
- VMware VirtualCenter
Version 2.5
- VMware ESX Versions
3.5, 4.0, 4.1 and 5.0
- VMware vSphere Version
4.0, Version 4.1, Version 5.0 all of which include VMware ESXi and VMware vCenter Server
The documentation generically refers to these servers with the
following terminology:- ESX server:
Refers to VMware ESX Versions
3.5, 4.0, 4.1, 5.0 or a VMware ESXi server in VMware vSphere Version
4.0, Version 4.1 and Version 5.0.
- vCenter server:
Refers to VMware VirtualCenter
Version 2.5 or a VMware vCenter
server in VMware vSphere
Version 4.0, Version 4.1 and Version 5.0.
About this task
When you have multiple nodes running on a physical computer
with VMware Infrastructure 3 platforms, Intelligent Management can contact VMware through Web services.
You can configure this communication in the administrative console
by creating cell-wide custom properties. These custom properties define
the URL, user ID, and password for the vCenter or ESX servers.
You also must configure your key stores to retrieve signers from the vCenter or ESX servers.
The
Intelligent Management configuration depends
on your
VMware configuration.
Create the custom properties for the servers in your environment so
that
Intelligent Management can monitor
all of the virtual machines and physical computers. To set the custom
properties on the cell level, click .
- If you are using only ESX servers, you must
configure enough of the individual servers to make Intelligent Management aware of the physical
servers and virtual machines in the environment.
- If you are using a vCenter server
to manage your environment, you can connect to the vCenter server,
which establishes communication with all of the virtual machines and
servers that the vCenter server
manages. You do not need to connect to each ESX server. If a vCenter is available,
the best practice is to connect to the vCenter server
instead of each ESX server.
- If you are running multiple vCenter servers
with a Microsoft Cluster
Server (MSCS) to provide high availability, you can configure the
key stores and custom properties for each vCenter server.
If you do not configure Intelligent Management to work with VMware Infrastructure 3 platforms, the Intelligent Management environment does not
understand that the nodes are on virtual machines, and as a result,
the machine processor or memory might be overloaded.
Procedure
- If you are configuring Intelligent Management to communicate with
a vCenter server:
- Retrieve a signer from the vCenter server
and store the signers in the CellDefaultTrustStore key
store. To retrieve the signer, you can either use the
administrative console or run the retrieveVMwareCertificate.py script.
To retrieve the signer certificate by running the script:
./wsadmin.sh -lang jython -f retrieveVMwareCertificate.py
-host:<vmware_virtual_center_host_name> -port:<vmware_virtual_center_ssl_port_number>
Where <vmware_virtual_center_host_name> is
the host name of the vCenter and <vmware_virtual_center_ssl_port_number> is
the secure SSL port of the vCenter.
To
retrieve the signer certificate using the administrative console:
- Navigate to the signer certificates administrative console panel.
In the administrative console, click .
- Enter the host and port information for the vCenter server
and an alias or name for the certificate. The alias should follow
the syntax: <vmware_virtual_center_short_host>-vmware.
For example, if the hostname of the vCenter server
is myvmwarevc.foo.net, the alias name would
be myvmwarevc-vmware. For Hypertext Transfer
Protocol Secure (HTTPS), the default port value is 443.
- Click Retrieve signer information.
- Click Apply. This action indicates that
you accept the credentials of the signer.
The signer certificate that is retrieved from the vCenter server
is stored in the CellDefaultTrustStore keystore.
- Configure custom properties for the vCenter server
so that Intelligent Management can use
Web services to communicate with the VMware Infrastructure SDK (VI SDK). In
the administrative console, click . Create the following cell-wide custom properties:
- vmware.service.unique_id.url
- vmware.service.unique_id.userid
- vmware.service.unique_id.password
Note: For the vmware.service.
unique_id.userid
custom property, the following privileges are required by
Intelligent Management to read certain
properties and to perform various operations:
- System.Anonymous
- System.Read
- System.View
- Sessions.TerminateSession
The unique_id value is a unique identifier
that represents the vCenter. For
example, if the host name of the vCenter server
is myvmwarevc.foo.net and the port is 443,
the unique_id value would be myvmwarevc_foo_net_443.
Following the same example, the names of the custom properties would
be: vmware.service.myvmwarevc_foo_net_443.url
vmware.service.myvmwarevc_foo_net_443.userid
vmware.service.myvmwarevc_foo_net_443.password
- If you are configuring Intelligent Management to communicate with ESX servers:
- Retrieve a signer from the ESX server and store
the signers in the CellDefaultTrustStore key
store. To retrieve the signer, you can either use the
administrative console or run the retrieveVMwareCertificate.py script.
To retrieve the signer certificate by running the script:
./wsadmin.sh -lang jython -f retrieveVMwareCertificate.py
-host:<vmware_esx_server_host_name> -port:<vmware_esx_server_ssl_port_number>
Where <vmware_esx_server_host_name> is
the host name of the ESX server
and <vmware_esx_server_ssl_port_number> is the
secure SSL port of the ESX server.
To
retrieve the signer certificate using the administrative console:
- Navigate to the signer certificates administrative console panel.
In the administrative console, click .
- Enter the host and port information for the ESX server and an alias
name for the certificate. The alias should follow the syntax: <vmware_esx_server_short_host>-vmware.
For example, if the hostname of the ESX server is myvmwareesx.foo.net,
the alias name would be myvmwareesx-vmware.
For Hypertext Transfer Protocol Secure (HTTPS), the default port
value is 443.
- Click Retrieve signer information.
- Click Apply. This action indicates that
you accept the credentials of the signer.
The signer certificate that is retrieved from the ESX server is stored
in the CellDefaultTrustStore keystore.
- Configure custom properties for the ESX servers so that Intelligent Management can use Web services
to communicate with the VMware Infrastructure SDK (VI SDK). In
the administrative console, click . Create the following cell-wide custom properties:
- vmware.service.unique_id.url
- vmware.service.unique_id.userid
- vmware.service.unique_id.password
The unique_id value is a unique identifier
that represents the ESX server.
For example, if the host name of the ESX server is myvmwareesx.foo.net and
the port is 443, the unique_id value
would be myvmwareesx_foo_net_443. Following
the same example, the names of the custom properties would be: vmware.service.myvmwareesx_foo_net_443.url
vmware.service.myvmwareesx_foo_net_443.userid
vmware.service.myvmwareesx_foo_net_443.password
Repeat these steps for each ESX server in your
configuration.
Results
By configuring Intelligent Management to
work with vCenter or ESX,
you obtain better service differentiation management results than
by using vCenter or ESX alone.
With Intelligent Management, you can
add application-level goals and characteristics, so that the autonomic
managers can perform the necessary flow control in your virtualized
environment.
What to do next
If timeout errors occur, you can increase the com.ibm.websphere.webservices.http.connectionTimeout and com.ibm.websphere.webservices.http.SocketTimeout custom
property values from the default of 300 seconds to 600 seconds. Consider
making this change when you have a virtualized environment with a
large number of physical and virtual machines. For example, if your
environment has 400 physical machines, when requests are sent from Intelligent Management to the hypervisor for
configuration information, the hypervisor contacts each of the 400
physical machines. If each request takes 1 second to complete, the
default timeout of 300 seconds is not long enough to process all of
the requests, and a read timeout results. For more information about
the custom properties, read about HTTP transport custom properties
for Web services applications.
Configure middleware servers
on your WebSphere® nodes.