To configure WebSphere® Virtual Enterprise 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 VMware VirtualCenter or VMware ESX servers.
Before you begin
New feature: You can configure
VMware Infrastructure 3 platforms and
WebSphere Virtual Enterprise with Version 6.1.0.3
or later.
newfeat
- Configure the VMware Infrastructure 3 platforms environment
on your physical servers. Your VMware Infrastructure 3 platforms environment must
meet the following requirements:
- 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 and VMware ESX Version
3.5.
- Install and configure WebSphere Virtual Enterprise on
each virtual machine.
About this task
When you have multiple nodes running on a physical computer
with VMware Infrastructure 3 platforms, WebSphere Virtual Enterprise 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 theVMware VirtualCenter or VMware ESX servers. You
also must configure your key stores to retrieve signers from the VMware VirtualCenter or VMware ESX servers.
How
you configure your
VMware environment
to work with
WebSphere Virtual Enterprise is
dependent on your
VMware configuration.
You must create the custom properties for enough of the servers in
your environment to make
WebSphere Virtual Enterprise aware
of all of the virtual machines and physical computers.
- If you are using only VMware ESX servers,
you must configure the enough of the individual servers to make WebSphere Virtual Enterprise aware of the physical
servers and virtual machines in the environment.
- If you are using VMware VirtualCenter to manage
your environment, you can connect to the VMware VirtualCenter server,
which establishes communication with all of the virtual machines and
servers that the VMware VirtualCenter server
manages. You do not need to connect to each VMware ESX server. If a VMware VirtualCenter is available,
the best practice is to connect to the VMware VirtualCenter server
instead of each VMware ESX server.
- If you are running multiple VMware VirtualCenter servers
with a Microsoft Cluster Server (MSCS) to provide high availability,
you can configure the key stores and custom properties for each VMware VirtualCenter server.
If you do not configure WebSphere Virtual Enterprise to work with VMware Infrastructure 3 platforms, the WebSphere Virtual Enterprise environment does not
understand that the nodes are on virtual machines, and as a result,
the machine processor or memory might be overloaded.
Procedure
- Retrieve a signer from the VMware VirtualCenter or VMware 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.
Perform this step for the VMware VirtualCenter server,
or for enough of the individualVMware ESX servers to represent
all of the physical servers and virtual machines in the environment.
To
retrieve the signer using the script, perform the following steps:
- Run the retrieveVMwareCertificate.py script.
Use the following syntax:
./wsadmin.sh -lang jython -f retrieveVMwareCertificate.py -host:
vmware_esxorvc_server_host_name -port:vmware_server_ssl_port_number
For example, you might type the following command: ./wsadmin.sh -lang jython -f retrieveVMwareCertificate.py
-host:venus00.rtp.raleigh.ibm.com -port:443
To retrieve the signer using the administrative console, perform
the following steps:
- Navigate to the signer certificates administrative console
panel. In the administrative console, click Security
> SSL certificate and key management > Key stores and certificates
> CellDefaultTrustStore > Signer certificates > Retrieve from port.
- Enter the host and port information for the VMware VirtualCenter or VMware ESX and an alias
or name for the certificate. 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 VMware VirtualCenter or VMware ESX server is
stored in the CellDefaultTrustStore keystore.
- Configure custom properties for the VMware VirtualCenter or VMware ESX servers so
that WebSphere Virtual Enterprise can use Web
services to communicate with the VMware Infrastructure SDK (VI SDK).
- If you are using VMware VirtualCenter, configure
the custom properties for your VMware VirtualCenter server.
You do not need to configure the custom properties for each server
that the VMware VirtualCenter manages.
- If you are using VMware ESX only,
you must configure the custom properties on enough of the VMware ESX servers so that WebSphere Virtual Enterprise knows about all of the
physical servers and virtual machines in the environment.
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 name that
links the three custom properties together. You can also eliminate
the unique_id variable and create custom properties
named vmware.service.url, and so on. For example, if
you are setting the custom properties for the vmwareserver1 server,
you might name the custom properties:
- vmware.service.vmwareserver1.url
- vmware.service.vmwareserver1.userid
- vmware.service.vmwareserver1.password
Results
By configuring
WebSphere Virtual Enterprise to
work with
VMware VirtualCenter or VMware ESX,
better service differentiation management results than using
VMware VirtualCenter or VMware ESX alone. With
WebSphere Virtual Enterprise, you can add application-level
goals and characteristics so that the can perform the necessary flow
control, and so on can occur in your virtualized environment.
What to do next
If timeout errors are occurring, 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 WebSphere Virtual Enterprise 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. See HTTP transport custom properties for Web services
applications for more information about the custom properties.
Configure
middleware servers on your WebSphere nodes.