Asim
Diskgroup deports are usually fairly quick - we just need to check all the volumes are closed, they don't actually need to be stopped and update the sequence number on the diskgroup config enabled disks in the $DG - nothing more really and of course run a vxdg list to ensure that the $DG is deported for the VCS DiskGroup agent perspective. Not much time at all is required. Now - can I ask if there was a recent upgrade to 5.0MP3 ? The most usual thing we see in Support is that when Agents don't behave as expected - and especially after an upgrade is that people forget to install the correct version types.cf for VCS ( Step 9 in the upgrade process) . More common with agents just don't doing what is expected - arguments for the Agent binaries change - the respective agents ArgList order may and often does change between versions. Commonly the operations we see go strange are in Diskgroup resources - since these are typically at the bottom of the resource hierarchy in the VCS service group - and are run first. And also we do some things in the binary for this one in this release - like panic on DG loss function. This is new so the DiskGroup Agent changed. # diff /etc/VRTSvcs/conf/types.cf /etc/VRTSvcs/conf/config/types.cf If there is adifference # hastop -all -force # cp /etc/VRTSvcs/conf/config/types.cf /etc/VRTSvcs/conf/config/types.cf.oldversion Repeat the following two steps on all nodes ( yes I know there is meant to be a cf snapshot to the joining VCS node when it starts - but I am basically an untrusting person ) # cp /etc/VRTSvcs/conf/types.cf /etc/VRTSvcs/conf/config/types.cf # hastart Stuart ________________________________ From: veritas-vx-boun...@mailman.eng.auburn.edu [mailto:veritas-vx-boun...@mailman.eng.auburn.edu] On Behalf Of William Havey Sent: Friday, 19 March 2010 2:17 AM To: asim.zuberi.1...@njit.edu Cc: Veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Deporting a DG via VCS How many volumes in the Disk Group? More than several hundred would take an agent a long time, such as the totally unexpected 20 minutes. On Thu, Mar 18, 2010 at 11:11 AM, Asim Zuberi <a...@njit.edu> wrote: Yes, the filesystems gets unmounted cleanly without much delay. From: William Havey [mailto:bbha...@gmail.com] Sent: Thursday, March 18, 2010 10:09 AM To: asim.zuberi.1...@njit.edu Cc: Veritas-vx@mailman.eng.auburn.edu Subject: Re: [Veritas-vx] Deporting a DG via VCS First thought is the File System hanging. the Volume waits for its Parents to go offline. Do they? On Thu, Mar 18, 2010 at 11:04 AM, Asim Zuberi <a...@njit.edu> wrote: Hello All - Sorry to post a VCS question on this mailing list. I need a quick answer: When the following command is performed outside the VCS cluster: vxvol -g $DG stopall vxdg deport $DG it works like a charm. But when it is executed via VCS; such as failing over a SG from one node to another: hagrp -switch $SG -to node-name the VOL resource hangs for about 20 minutes and then goes offline. No errors encounters. Just wondering what could be going on. The SF ver is 5.0MP3. Any pointers will be a great help. thanks! --Asim; _______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
_______________________________________________ Veritas-vx maillist - Veritas-vx@mailman.eng.auburn.edu http://mailman.eng.auburn.edu/mailman/listinfo/veritas-vx
