Veritas Cluster Server 5.1 Maintenance Pack 2 Patch 10 for VMware ESX

Article:TECH158054  |  Created: 2011-04-13  |  Updated: 2011-05-12  |  Article URL http://www.symantec.com/docs/TECH158054
Article Type
Technical Solution

Product(s)

Environment

Issue



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.

 

 





Article URL http://www.symantec.com/docs/TECH158054


Terms of use for this information are found in Legal Notices