Veritas Cluster Server 5.1 Maintenance Pack 2 Patch 10 for VMware ESX
| Article:TECH158054 | | | Created: 2011-04-13 | | | Updated: 2011-05-13 | | | Article URL http://www.symantec.com/docs/TECH158054 |
Problem
1. An ESXVM resource goes to the faulted state and displays the "Invalid encrypted password specified" error in the ESXVM logs.
2. An ESXDatastore resource hangs while going online/offline.
3. An ESXDatastore or an ESXVM resource, or both, go to the faulted state and display the "Could not connect to ESX web server" error in the appropriate log file.
Error
VCS WARNING V-16-10061-16507 ESXVM:esxVM_ABC:monitor:Invalid encrypted password specified.
Environment
VMware ESX
Veritas Cluster Server 5.1 MP2
Cause
Please refer to the README file of Patch 10.
Solution
VCS 5.1 MP2 Patch 10 for VMware ESX can be applied on top of VCS 5.1 Release Update 1 (RU1).
Please contact Symantec Technical Support if you need to apply the patch.
README file for VCS 5.1MP2 P10
============================
Patch Date: August 3, 2010
OS: ESX
OS Version: ESX 3.5
Fixes Applied for Products:
VRTSvcsag - Veritas Cluster Server Bundled Agents by Symantec
VRTSvcsdns - VERITAS Cluster Server DNS update agent for VMware ESX
PATCH VCS Bundled Agent 5.1MP2P10
VCS DNS update agent for VMware ESX 5.1MP2P10
===============================================================
This README provides information on:
* GETTING STARTED
* CRC AND BYTE COUNT
* FIXES AND ENHANCEMENTS INCLUDED IN THE PATCH
* PACKAGES AFFECTED BY THE PATCH
* INSTALLING THE PATCH
* UNINSTALLING THE PATCH
GETTING STARTED
---------------
This patch applies only to:
VRTSvcsag 5.1MP2P4 or later running on ESX 3.5
VRTSvcsdns 5.1MP2P4 or later running on ESX 3.5
Before you install this patch ensure that your system runs only
supported configurations.
CRC AND BYTE COUNT
------------------
Ensure that the patch file that you have downloaded matches the following checksum and byte count, depending on the OS version you are using.
Use the following command to find the checksum and byte count.
For ESX 3.5:
# cksum VRTSvcsag-5.1.40.10-MP2P10_ESX30.i686.rpm
3957437553 262844 VRTSvcsag-5.1.40.10-MP2P10_ESX30.i686.rpm
# cksum VRTSvcsdns-5.1.40.10-MP2P10_ESX30.i686.rpm
272244611 10752 VRTSvcsdns-5.1.40.10-MP2P10_ESX30.i686.rpm
FIXES AND ENHANCEMENTS INCLUDED IN THE PATCH
--------------------------------------------
Etrack Incidents: 2089711, 2101654
Symptom-Description-Resolution (SDR) of Fixed Symantec Incidents
----------------------------------------------------------------
Symantec Incident: 2089711
Symptom:
1. An ESXVM resource goes to the faulted state and displays the "Invalid encrypted password specified" error
in the ESXVM logs.
2. An ESXDatastore resource hangs while going online/offline.
3. An ESXDatastore or an ESXVM resource, or both, go to the faulted state and display the "Could not connect to ESX web server" error in the appropriate log file.
Description:
1. When an ESX agent tries to log in to the ESX host several times, then the password provided for the login
goes corrupt after the first attempt, and for the subsequent attempt fails and the following error message appears:
"Invalid encrypted password".
2. In a Global Cluster Option (GCO) configuration, when the monitor entry point runs for the datastores that are on the secondary site,
the datastore is not visible on the secondary site. In such a scenario, agents log out from the ESX host
web service and the datastore hangs when the service group is either brought online or offline.
3. When multiple monitor threads try to log in simultaneously, the session object may go corrupt and
subsequent login and logout attempts from the hostd web service may fail. As a result, the ESXVM resource or the ESXDatstore resource
go to the faulted state.
Resolution:
1. Symantec has modified the log in functionality to address the password corruption issue.
2. Symantec has modified the code to prevent the logout from the ESX host, when the datastore is not visible.
3. Symantec has introduced an additional check to ensure that the session object does not go corrupt.
Symantec Incident: 2101654
Symptom:
At the first attempt, a DNS resource does not come online.
Description:
The DNS agent fails to come online in the first attempt because the update sent by the online script through the 'nsupdate'
command may reflect in the dig queries after some time. The online entry point tries to check for the update
immediately after running the 'nsupdate' command and the dig query fails.
Resolution:
The DNS agent now keeps checking for the DNS updates to come into effect before exiting from the Online
entry point. The polling happens at an interval of 10 seconds.
PACKAGES AFFECTED BY THE PATCH
-------------------------------
This patch updates the following VCS packages:
VRTSvcsag from 5.1MP2P4 or higher to 5.1MP2P10
VRTSvcsdns from 5.1MP2P4 or higher to 5.1MP2P10
INSTALLING THE PATCH
--------------------
Run the following steps on all nodes in the VCS cluster:
1. Stop VCS on the cluster node.
2. Install the patch.
3. Restart VCS on the node.
Stopping VCS on the cluster node
--------------------------------
To stop VCS on the cluster node:
1. Ensure that the "/opt/VRTSvcs/bin" directory is included in your
PATH environment variable so that you can execute all the
VCS commands. For more information, refer to the Veritas Cluster
Server Installation Guide.
2. Verify that the version of VRTSvcs is 5.1MP2P4 or higher for
ESX 3.5.
3. Freeze all the service groups persistently.
# haconf -makerw
# hagrp -freeze [group] -persistent
# haconf -dump -makero
4. Stop the cluster on all nodes. If the cluster is writable, you may
close the configuration before stopping the cluster.
From any node, execute the following command.
# hastop -all -force
Verify that the cluster is stopped on all nodes
by running the following command.
# hasys -state
On all nodes, make sure that both had and hashadow processes are
stopped.
Also stop the VCS CmdServer on all nodes.
# CmdServer -stop
Verify that all the agents are stopped on all nodes
by running the following command.
# ps -ef | grep -i agent
5. Log in as the superuser into the system where the patch is to be
installed.
Installing the patch
--------------------
Repeat the following steps on all the nodes.
1. Gunzip and untar the downloaded patch.
2. Change directory to the unzipped patch location.
3. Install the VRTSvcsag patch using the following command:
# rpm -e --nodeps VRTSvcsdns
# rpm -e --nodeps VRTSvcsag
# rpm -ivh --nodeps VRTSvcsdns-5.1.40.10-MP2P10_ESX30.i686.rpm
# rpm -ivh VRTSvcsag-5.1.40.10-MP2P10_ESX30.i686.rpm
4. Verify that the new patches have been installed:
# rpm -q VRTSvcsag
The following information is displayed after successful patch
installation:
VRTSvcsag-5.1.40.10-MP2P10_ESX30
# rpm -q VRTSvcsdns
VRTSvcsdns-5.1.40.10-MP2P10_ESX30
Restarting VCS on the cluster node
-----------------------------------
To restart VCS on the cluster node:
1. At this time, you can start the cluster services on all cluster
nodes.
# hastart
On all the other nodes, start VCS by issuing the hastart command
after the first node goes to LOCAL_BUILD or RUNNING state.
2. Unfreeze all the groups.
# haconf -makerw
# hagrp -unfreeze [group] -persistent
# haconf -dump -makero
UNINSTALLING THE PATCH
----------------------
Removal of the patch will result in removing the whole package
from the system or node. To go back to a previous installed version
of the package, you may need to re-install the package again.
To uninstall the patch:
1. To stop VCS on the node, follow the steps given in the section "Stopping VCS on a node" above.
2. Uninstall the patch by using the following command:
# rpm -e --nodeps VRTSvcsdns
# rpm -e --nodeps VRTSvcsag
3. Verify that the package has been removed:
# rpm -qa | grep VRTSvcsag
The package VRTSvcsag should not be displayed, which confirms
that the package is removed.
# rpm -qa | grep VRTSvcsdns
The package VRTSvcsdns should not be displayed, which confirms
that the package is removed.
4. Install the previous patch version for VRTSvcsag and VRTSvcsdns rpms.
5. Restart VCS on the node following the steps given in the section "Re-Starting VCS on a node" above.
6. Run the preceding steps on all nodes in the VCS cluster.
|
|
Related Articles
Article URL http://www.symantec.com/docs/TECH158054
Terms of use for this information are found in Legal Notices









Thank you.