We have installed SF HA 5.0MP3 on Sparc Solaris 10. There is a new service group with a single DiskGroup and a number of Mount resources. I have created it yesterday, and switched it back and forth several times, without any problem. Today, however, switch did not work. All filesystems failed to be unmounted.
Upon investigation, I found the following in the engine_A.log
2009/05/08 09:45:46 VCS NOTICE V-16-1-10300 Initiating Offline of Resource hspnfs3_mnt_patches (Owner: unknown, Group: HSPNFS3_grp) on System hqub5503c
2009/05/08 09:45:46 VCS ERROR V-16-2-13064 (hqub5503c) Agent is calling clean for resource(hspnfs3_mnt_patches) because the resource is up even after offline completed.
2009/05/08 09:45:46 VCS ERROR V-16-2-13070 (hqub5503c) Resource(hspnfs3_mnt_patches) - clean not implemented.
2009/05/08 09:46:47 VCS ERROR V-16-2-13077 (hqub5503c) Agent is unable to offline resource(hspnfs3_mnt_patches). Administrative intervention may be required.
(Same sequence of messages were created for every FS).
Further, I found a document
http://seer.entsupport.symantec.com/docs/313851.htm
that describes the same situation. From this doc:
"This is for cases where VCS service groups having DiskGroup resources configured with UnMountVolumes attribute set and the volumes are mounted outside of VCS control (this is not very common)."
In my case, UnMountVolumes is NOT set, and all filesystems had been mounted using VCS as part of switching the service group.
This leads me to think of two possible bugs.
1. Under certain conditions, VCS fails to unmount filesystems mounted using VCS. I do not know what these conditions are.
2. VCS fails to force unmounting the filesystems after calling "clean" procedure. This is because /opt/VRTSvcs/bin/Mount/clean script does not have umount option `-o mntunlock=VCS' which I think it should. Maybe this should be conditional, something like "if VxFSMountLock is set".
As a workaround, I am going to disable VxFSMountLock in all Mount resources.
If extra information/debugging is needed, please let me know.
Thanks,
Andy