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 vCenter or ESX servers.
Before you begin
- 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
- VMware ESX Version
3.5
- VMware vSphere Version
4.0 and Version 4.1, both 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 Version
3.5 or VMware ESXi servers in VMware vSphere Version 4.0 and Version
4.1.
- vCenter server:
Refers to VMware VirtualCenter
Version 2.5 or VMware vCenter
servers in VMware vSphere
Version 4.0 and Version 4.1.
- 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 thevCenter or ESX servers. You
also must configure your key stores to retrieve signers from the vCenter or 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. Set the custom
properties on the cell level by clicking .
- If you are using only 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 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 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
- If you are configuring WebSphere Virtual Enterprise to communicate with
avCenter server:
- Retrieve and store a signer certificate from the vCenter server
and configure WebSphere Virtual Enterprise to
communicate with the vCenter server:
./wsadmin.sh -lang jython -f retrieveVMwareCertificate.py
-host:<vmware_virtual_center_host_name> -port:<vmware_virtual_center_ssl_port_number>
-user:<vmware_user_id>
-password:<vmware_password>
Where <vmware_virtual_center_host_name> is
the host name of the vCenter server, <vmware_virtual_center_ssl_port_number> is
the secure SSL port of the vCenter server, <vmware_user_id> is
the VMWare userid that is used to access the vCenter server,
and <vmware_password> is the password associated with the <vmware_user_id>.
- If you are configuring WebSphere Virtual Enterprise to communicate with ESX servers:
- Retrieve and store a signer certificate from the ESX server and configure WebSphere Virtual Enterprise to communicate with
the ESX server.
./wsadmin.sh -lang jython -f retrieveVMwareCertificate.py
-host:<vmware_esx_server_host_name> -port:<vmware_esx_server_ssl_port_number>
-user:<vmware_user_id>
-password:<vmware_password>
Where <vmware_esx_server_host_name> the
host name of the ESX server, <vmware_esx_server_ssl_port_number> is
the secure SSL port of theESX server, <vmware_user_id> is
the VMware userid that is used to access the ESX server, and <vmware_password>
is the password associated with the <vmware_user_id> value.
You should use host names are used for the -host parameter
instead of an IP address.
- Repeat the previous step for all of your ESX servers by using
the script to retrieve and store a signer certificate for eachESX server.
Results
By configuring WebSphere Virtual Enterprise to
work with vCenter or ESX,
better service differentiation management results than using vCenter or ESX alone. With WebSphere Virtual Enterprise, 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 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.