Late Breaking News ( LBN ) - Updates to the Release Notes for Veritas Cluster Server 5.1 to 5.1 Maintenance Pack 2 for VMware ESX and 5.1 Release Update 1 (RU1) for VMware ESX and cross references to product documentation

Article:TECH52629  |  Created: 2009-01-05  |  Updated: 2009-01-05  |  Article URL http://www.symantec.com/docs/TECH52629
Article Type
Technical Solution

Product(s)

Environment

Issue



Late Breaking News ( LBN ) - Updates to the Release Notes for Veritas Cluster Server 5.1 to 5.1 Maintenance Pack 2 for VMware ESX and 5.1 Release Update 1 (RU1) for VMware ESX and cross references to product documentation

Solution




Patches

Patches are available on Patch Central https://vias.symantec.com/labs/patch 


Cluster Server for VMWare ESX 5.1 Release Update 1 (RU1) on Linux

Cluster Server for VMWare ESX 5.1 Release Update 1 (RU1) on Linux is now available at https://fileconnect.symantec.com 

See the README file for more information at http://support.veritas.com/docs/332664 

5.1 MP2 P4 for VMware ESX cannot successfully migrate virtual machines when the migration is initiated through VCS

In some cases, VCS 5.1 MP2 P4 for VMware ESX cannot successfully migrate virtual machines when the migration is initiated through the VCS command hagrp -migrate. The reason for this is the migrate action fires a probe command for the resource on the target node. In this situation, if the value of MonitorHB attribute of the ESXVM resource is 1, the ESXVM agent marks the resource faulted and called clean entry point if the virtual machine does not have heartbeat at the time of firing the probe command.

Workaround:

The workaround is to comment out the probe line in the migrate action script and do not fire the probe command after starting migration of the virtual machine and for 1 minute after the migration is complete.

Comment out line number 41 of the "/opt/VRTSvcs/bin/ESXVM/actions/migrate" script on all nodes which issue the hares command to probe the ESXVM resource on the "tohost"/target node. The command at line number 41 in migrate action is:

$VCSHOME/bin/hares -probe $ResName -sys $tohost

After the change:

# $VCSHOME/bin/hares -probe $ResName -sys $tohost

Solution:

The workaround will be included in the 5.1 MP3 release.



5.1 MP2 P4 is available at https://vias.symantec.com/labs/vpcs/vpcs/patchinfo/1869 

5.1 MP2 P3 is available at https://vias.symantec.com/labs/patch/php/patchinfo.php?download=yes&release_id=1776 

POINT PATCH FOR ESX AGENTS FOR VERITAS CLUSTER SERVER 5.1MP2 on ESX

is now available at https://vias.symantec.com/labs/patch/php/patchinfo.php?download=yes&release_id=1658 

POINT PATCH FOR VERITAS VIRTUALIZATION MANAGER FOR VERITAS CLUSTER SERVER 5.1MP2P2 on ESX
is now available at https://vias.symantec.com/labs/patch/php/patchinfo.php?download=yes&release_id=1665 

Patches are available on Patch Central https://vias.symantec.com/labs/patch 



VCS versions 5.1 through 5.1 MP2 for VMware ESX are not compatible with ESX version 3.5 Update 2

Some VCS components, including GAB and LLT, cannot load in ESX 3.5 Update 2 due to a broken set of kernel ABI interfaces in this version of ESX.

The errors noticed (in the system logs or at the command prompt) are as follows:

# /etc/init.d/llt start
Starting LLT:
LLT: loading module...
ERROR: No appropriate modules found.
Error in loading module "llt". See documentation.
LLT:Error: cannot find compatible module binary

The patch for this issue is available at http://entsupport.symantec.com/docs/308934 




5.1 Maintenance Pack 2

5.1 Maintenance Pack 2 for VMware ESX is now available at https://fileconnect.symantec.com 


5.1 Maintenance Pack 2 Issues

VCS 5.1 to 5.1 MP2 for VMware ESX cannot take virtual machines offline on NFS datastores when the NFS server or NFS shares are inaccessible http://support.veritas.com/docs/306520 


5.1 Maintenance Pack 1

5.1 Maintenance Pack 1 for VMware ESX is now available.

For more information, see the Release Notes at http://support.veritas.com/docs/296307 


5.1 Issues

Incident 1115392 - The "vxlicrep" Command May Display the Wrong Version

Version 7 may be displayed instead of 5.1 if you use the "vxlicrep" command.  This issue is fixed in 5.1 Maintenance Pack 1 for VMware ESX.

Here is an example:

# vxlicrep

Symantec License Manager vxlicrep utility version 3.02.18.0
Copyright (C) 1996-2006 Symantec Corporation. All rights reserved.

Creating a report on all VERITAS products installed on this system

-----------------***********************-----------------

  License Key                         = ABCD-1234-DFGH-5678-IJKL-XY
  Product Name                        = VERITAS Cluster Server
  Serial Number                       = 1181
  License Type                        = PERMANENT
  OEM ID                              = 2006

Features :=
   Platform                            = VMWare ESX                        
   Version                             = 7
   Tier                                = Unused                            
   Reserved                            = 0

   Mode                                = VCS


Workaround  

Use the "had -version" command.

Veritas Cluster Server 5.1 for VMware ESX will display the values shown in this example:

# had -version

Engine Version    5.1
Join Version      5.0.00.0
Build Date        Wed 15 Aug 2007 02:01:01 AM PDT
PSTAMP            Veritas-5.1.00.0-08/15/07-02:01:01


Supplemental Materials

SourceETrack
Value1115392
DescriptionThe "vxlicrep" Command May Display the Wrong Version


Legacy ID



289940


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


Terms of use for this information are found in Legal Notices