VXVM Interview Question and answers

VXVM Interview Question and answers 1. Name the mandatory disk group in VxVM 3.5 ? How will you configure VxVM in 3.5 ? ANS: rootdg is the mandatory disk group in VxVM 3.5, vxinstall is the command to configure VxVM, It will create the disk groups, initializes the disks and adds them to the group. 2. How will you create private and shared disk group using VxVM ? ANS: For Private DG: Command: vxdg init For Shared DG: Command: vxdg -s init < disk1 disk2 disk3 > 3. Which are the different layouts for volumes in VxVM ? ANS: mirror, stripe, concat (default one), raid5, stripe-mirror, mirror-stripe. 4. What is the basic difference between private disk group and shared disk group ? ANS: Private DG: The DG which is only visible for the host on which you have created it, if the host is a part of cluster, the private DG will not be visible to the other cluster nodes. Shared DG: The DG which is sharable and visible to the other cluster nodes. 5. How will you add new disk to the existing disk group ? ANS: Run vxdiskadm command, which will open menu driven program to do various disk operations, select add disks option or you can use another command vxdiskadd. 6. How will you grow/shrink the volume/file system ? What is the meaning of growby and growto options ? What is the meaning on shrinkto and shrinkby options ? ANS: vxassist command is used to do all volume administration, following is the description and syntax. Growby option: This is will grow your file system by adding new size to the existing file

system. Growto option: This will grow your file system as per the new size. This WILL NOT ADD new size to the existing one. Shrinkby option: This will shrink your file system by reducing new size from existing file system. Shrinkto option: This will shrink your file system as per the new size. This WILL NOT REDUCE the file system by reducing new size. Command: vxassist -g [growto, growby, shrinkto, shrinkby] length 7. How will you setup and unsetup disks explicitly using VxVM ? ANS: You can use /etc/vx/bin/vxdiskunsetup to unsetup the disk, and /etc/vx/vxdisksetup to setup the disk. 8. How will you list the disks, which are in different disk groups ? ANS: vxdisk list is the command will list the disks from the DG which is currently imported, you can check the same using vxprint command too. vxdisk -o alldgs list command list all the disks which are in different dg's. 9. What is the private region in VxVM ? ANS: Private region stores the structured VxVM information, it also stores the disk ID and disk geometry. In short words it has metadata of the disk. 10. If, vxdisk list command gives you disks status as "error", what steps you will follow to make the respective disks online ? ANS: If you faced this issue because of fabric disconnection then simply do vxdisk scandisks, otherwise unsetup the disk using using /etc/vx/bin/vxdiskunsetup and setup the disks again using /etc/vx/bin/vxdisksetup, this will definitely help! [ /etc/vx/bin/vxdiskunsetup will remove the private region from the disk and destroys data, backup the data before using this option]

Veritas cluster services Interview questions

1. How do check the status of VERITAS Cluster Server aka VCS ? Ans: hastatus sum3 2. Which is the main config file for VCS and where it is located? Ans: main.cf is the main configuration file for VCS and it is located in /etc/VRTSvcs/conf/config. 3. Which command you will use to check the syntax of the main.cf? Ans: hacf -verify /etc/VRTSvcs/conf/config 4. How will you check the status of individual resources of VCS cluster? Ans: hares state 5. What is the service group in VCS ? Ans: Service group is made up of resources and their links which you normally requires to maintain the HA of application. 6. What is the use of halink command ? Ans: halink is used to link the dependencies of the resources 7. What is the difference between switchover and failover ? Ans: Switchover is an manual task where as failover is automatic. You can switchover service group from online cluster node to offline cluster node in case of power outage, hardware failure, schedule shutdown and reboot. But the failover will failover the service group to the other node when VCS heartbeat link down, damaged, broken because of some disaster or system hung. 8. What is the use of hagrp command ? Ans: hagrp is used for doing administrative actions on service groups like online, offline, switch etc.

9. How to switchover the service group in VCS ? Ans: hagrp switch -to 10. How to online the service groups in VCS ? Ans: hagrp online -sy

Interview Questions with answers : Veritas Cluster Server

Admin on Wed Jul 08, 2009 5:55 pm

1. How do check the status of VERITAS Cluster Server aka VCS ? Ans: hastatus sum 2. Which is the main config file for VCS and where it is located? Ans: main.cf is the main configuration file for VCS and it is located in /etc/VRTSvcs/conf/config. 3. Which command you will use to check the syntax of the main.cf ? Ans: hacf -verify /etc/VRTSvcs/conf/config 4. How will you check the status of individual resources of VCS cluster? Ans: hares state 5. What is the service group in VCS ? Ans: Service group is made up of resources and their links which you normally requires to maintain the HA of application. 6. What is the use of halink command ? Ans: halink is used to link the dependencies of the resources 7. What is the difference between switchover and failover ? Ans: Switchover is an manual task where as failover is automatic. You can switchover service group from online cluster node to offline cluster node in case of power outage,

hardware failure, schedule shutdown and reboot. But the failover will failover the service group to the other node when VCS heartbeat link down, damaged, broken because of some disaster or system hung. 8. What is the use of hagrp command ? Ans: hagrp is used for doing administrative actions on service groups like online, offline, switch etc. 9. How to switchover the service group in VCS ? Ans: hagrp switch -to 10. How to online the service groups in VCS ? Ans: hagrp online -sys

UNIXLOG
Archive for the veritas volume manager Category
cfgadm:::Device being used by VxVM
leave a comment root@abc>/> cfgadm -c unconfigure c1::dsk/c1t0d0 cfgadm: Component system is busy, try again: failed to offline: /devices/ssm@0,0/pci@1c,700000/pci@1/SUNW,isptwo@4/sd@0,0 Resource Information /dev/dsk/c1t0d0s2 Device being used by VxVM cfgadm unconfigure command fails here. The way to resolve this is to disable the disks path from DMP control. Since there is only one path to this disk, the -f (for force) option needs to be used: root@abc>/> vxdmpadm -f disable path=c1t0d0s2 root@abc>/> vxdmpadm getsubpaths ctlr=c1 NAME STATE[A] PATH-TYPE[M] DMPNODENAME ENCLR-TYPE ENCLR-NAME ATTRS ======================================================= ========================= c1t0d0s2 DISABLED c1t0d0s2 Disk Disk c1t6d0s2 ENABLED(A) c1t6d0s2 Disk Disk You can see the path now disabled from DMP. root@abc>/> cfgadm -c unconfigure c1::dsk/c1t0d0 cfgadm goes through fine. root@abc>/>
Written by krishsubramanian November 3, 2010 at 1:40 pm Posted in Solaris, veritas volume manager

Rootdg corruption Server fails to boot

with one comment There are times when one has to go through the cut Server has a bad panic/power trip and it corrupts the rootdg badly and the server is unable to boot with VxVM. Here is a procedure to recover from the situation. 1. Boot from the cdrom or from the network 2. Mount the rootdisk. 3. Once mounted, disable the start up of VxVM. - Edit /a/etc/system. Comment out the vx parameter as follow: *rootdev:/pseudo/vxio@0:0 *set vxio:vol_rootdev_is_volume=1 - cd /a/etc/vx/reconfig.d/state.d/ - rm root-done - touch install-db - cp -p /a/etc/vfstab /a/etc/vfstab.withvm

- cp -p /a/etc/vfstab.prevm /a/etc/vfstab - init 6 4. Ensure the server comes up without veritas starting up. 5. Manually start the veritas volume manager. - vxiod set 10 - ps -ef |grep vxconfigd. If vxconfigd is not running, then run /usr/sbin/vxconfigd -m disable - vxdctl mode. Should see it is in disabled mode. - vxdctl init - vxdctl enable - vxdctl mode 6. Check the diskgroups. - vxdg list 7. Deport the rootdg so that it does not come up again. - vxdg deport rootdg 8. Zero out private and public region partitions from the disks on the rootdg. - format -d <c#t#d#> 9. Once this is done, the disks should show as error. - vxdisk list 10. Re encapsulate the disk. - cd /etc/vx/reconfig.d/state.d/ - rm install-db - vxdiskadm. Option 2 to encapsulate the primary bootdisk - Reboot machine upon completed Option 2 above. 11. Verify for the boot and all volumes coming up clean. - vxprint -ht, to verify all the volume are enabled. If the volume not started, then run vxvol -g groupname startall to start the volume. - Revert back the /etc/vfstab.withvm to /etc/vfstab - mount all the volume and verify. 12. Mirror to second bootdisk - vxdiskadm. Option 1 to Add or initialize the second bootdisk - vxdiskadm. Option 6 to mirror the secondary bootdisk
Written by krishsubramanian May 1, 2010 at 4:32 pm Posted in veritas volume manager

VxVM Upgrade
leave a comment Lets look at VxVM Upgrade this week The setup is a) Solaris 9 b) VxVM 4.0 / VxDMP > No powerpath c) Oracle databases. I upgraded to Storage Foundation 5.0 MP3. The tech plan is as below:

1. Install the VRTSspt Package. Down load the package from symantec website 2. Run the VRTSexplorer and keep the file at a safe location if you may need it in case you run in any issue. 3. Break the rootmirror 4. Unencapsulate the rootmirror. # mount /dev/dsk/c0t1d0s0 /alt.root # cd /alt.root/etc # touch /alt.root/etc/vx/reconfig.d/state.d/install-db rootdev:/pseudo/vxio@0:0 set vxio:vol_rootdev_is_volume=1 Remove the above lines from /alt.root/etc/system file Make changes to /etc/vfstab to ensure the system boots from the mirror disk ( c#t#d#) 5. Boot the server from rootmirror and verify for the server coming up. 6. Boot again from the rootdisk. 7. Check for the pre-requiste packages. Solaris 9 for Storage Foundation need SUNWcfcl,SUNWcfclr, SUNWcfclx packages and patch 114477-04. 8. Install the packages first and then the patches. Packages and patches can be downloaded from http://www.sun.com/downloads and choose A-Z downloads 9. Verify the pre-staged software is not corrupted and working fine. ( You can do this by doing a tar and keeping the software ready) 10. Ensure all applications/Databases are shutdown and the file-systems are down. 11. Ensure all the apps/dbs are umounted clean . # echo 8192B.p S | fsdb -F vxfs <Raw_Device> | grep clean Receive: flags 0 mod 0 clean clean_value Note: A clean_value value of 0x5a indicates the file system is clean, 0x3c incidates the file system is dirty, and 069 indicates the file system is dusty. A dusty file system has pending extended operations. Note: If a file system is not clean, enter the following commands for that file system: Enter: fsck -F vxfs filesystem Enter: mount -F vxfs [Block_Device] [mountpoint] Enter: umount [mountpoint] Note: This should complete any extended operations that were outstanding on the file system and unmount the file system cleanly. 12. Run the upgrade_start -check

# /storage_foundation/scripts/upgrade_start -check -Note: this is a veritas check script that will check to see if this machine is eligible for upgrade. 13.Ensure that the root mirror is removed from rootdg. # /sbin/vxdg g rootdg f rmdisk rootmirror 14. Un encapsulate the rootdisk Remove the following lines from /etc/system rootdev:/pseudo/vxio@0:0 set vxio:vol_rootdev_is_volume=1 Prevent veritas from starting up. #/usr/bin/cd /etc/vx/reconfig.d/state.d #/usr/bin/rm root-done #/usr/bin/touch install-db 15 . Deport all appdiskgroups. 16. Reboot the node to single user mode. 17. Remove all packages that start with VRTS but for VRTSvlic. Dont remove the VRTSvlic packages. I believe you can remove this as well, but I have not tried it myself. # pkginfo | grep VRTS # pkgrm VRTSxxxx 18. Install the Veritas 5.0 Software # ./installer Note : Answer the questions and complete the installation. Insome cases veritas may not start correctly and will require a reboot. 19. If you are upgrading from 4.0 or later the licenses should take of themselves. 20. Manually Encapsualte the rootdisk after upgrade. # vxdiskadm Choose option 2 and give the root disk for encapsulation. 21. Import the disk groups and mount the filesystems. 22. Ensure applications are working fine 23. Remirror the rootdrive follow standard procedures.
Written by krishsubramanian February 13, 2010 at 4:50 pm Posted in veritas volume manager

Extending Filesystems in Sun Cluster using VxVM

leave a comment I did an activity to add LUNS to existing database file systems running sun Cluster 3.1, Solaris 9 OS with VxVM. The steps I followed are : a) Get the LUN information from Storage and update the sd.conf accordingly on both the servers

b) Make the LUNS Visible on the server. Run the command on both the nodes #update_drv -f sd c) Verify for the LUNS present; # format d) Configure emcpower devices. Run on both the servers. # /etc/powermt config # /etc/powermt save e) Create the Sun Cluster DID devices. Run on both nodes if required. # devfsadm # scgdevs f) Verify the sun Cluster DID devices. # scdidadm -L g) Add the disks to veritas diskgroup ; # vxdiskadm h) Grow the FS
Written by krishsubramanian October 25, 2009 at 6:27 am Posted in Solaris, Sun cluster, veritas volume manager Tagged with Sun cluster, Veritas

Identifying multiple paths for a disk under VxVM control

leave a comment This is a routine task for people dealing with VERITAS volume manager. There are times when one need to confirm the number of paths for the disk. This can be accomplished by the below command. # vxdisk list <diskname> In this one can look at the numpaths value at the bottom of the output.
Written by krishsubramanian December 8, 2008 at 2:49 pm Posted in veritas volume manager

Mirroring an Empty volume under VxVM

leave a comment If you are mirroring empty Veritas plexes, this post is for you. Normally we would wait ensuring the plexes are in sync. If the plex size is large, then the waiting time is more. A workaround is # vxassist -g <dgname> make testvol 1g layout=mirror init=active dgname01 dgname02 init=active is the keyword here. This should save lot of time.
Written by krishsubramanian November 14, 2008 at 12:09 pm Posted in veritas volume manager

Identifying and Replacing failed disks in V880

leave a comment

Hi, recently i ran in to a problem of failed disk with V880. I wanted to make sure if the disk has indeed failed. Server was running VxVM. Did these commands to identify the disk failure. V880 has internal FCAL loop. So to identify that #luxadm probe Found Enclosure: SUNWGS INT FCBPL Name:LoopA Node WWN:508002000011d7d8 Logical Path:/dev/es/ses0 #luxadm display LoopA SUNWGS INT FCBPL DISK STATUS SLOT DISKS (Node WWN) 0 On (O.K.) 2000002037f87099 1 On (O.K.) 2000002037f39796 2 On (Login failed) 3 Not Installed 4 Not Installed 5 Not Installed 6 Not Installed 7 Not Installed 8 Not Installed 9 Not Installed 10 Not Installed 11 Not Installed SUBSYSTEM STATUS FW Revision:9218 Box ID:0 Node WWN:508002000011d7d8 Enclosure Name:LoopA SSC100s 0=Base Bkpln, 1=Base LoopB, 2=Exp Bkpln, 3=Exp LoopB SSC100 #0: O.K.(11.A) SSC100 #1: O.K.(11.A) SSC100 #2: Not Installed SSC100 #3: Not Installed Temperature Sensors 0 Base, 1 Expansion 0:21C 1:Not Installed Here we can identify the disk failure at the slot no 2. This is a good way to identify the failed disk under internal FCAL loop. Since its a VxvM disk, make sure its in failed was or removed state. # vxdisk list DEVICE TYPE DISK GROUP STATUS c1t0d0s2 sliced rootdisk rootdg online c1t1d0s2 sliced disk01 rootdg online c1t1d0s2 sliced online disk02 rootdg failed was:c1t2d0s2 Run vxdiskadm option 4 to remove the disk for replacement. After running vxdiskadm the output should look similar to this: # vxdisk list DEVICE TYPE c1t0d0s2 sliced c1t1d0s2 sliced DISK rootdisk disk01 GROUP rootdg rootdg STATUS online online

c1t2d0s2 sliced online disk02 rootdg removed was:c1t2d0s2 1. Put the disk into offline state; # vxdisk offline c1t2d0s2 2. VxVM is ready for removal of the disk, run the luxadm offline to remove the WWN entries and device links for the failed drive ; # luxadm -e offline /dev/rdsk/c1t2d0s2 3. Do the luxadm to remove the device. ; #luxadm remove_device /dev/rdsk/c1t2d0s2 4. check the device file ; #devfsadm -C ; # ls -ld /dev/rdsk/c1t2d0* 5. Replace the disk physically 6. Run the devfsadm ; # devfsadm 7. verify with luxadm display ; # luxadm display LoopA 8. label the disk ; use format and label 9. # vxdctl enable 10. # vxdisk list ; you would see a new disk. 11. Now use vxdiskadm option 5 to replace the disk. Give yes to the access question. 12. Verify the sync ; # vxtask list Thats it you should see the replaced disk doing just fine.
Written by krishsubramanian October 17, 2008 at 5:12 pm Posted in Servers, veritas volume manager

Veritas recovery features

leave a comment In this post i will explain the volume recovery and disk group recovery in veritas volume manager. As an admin, we may face situations where one deletes a volume accidentally or destroy a dg by mistake. If we do not have configuration backups of the objects, we are in for some trouble. In order to save our a** its always better to be proactive and do the objects backups. From 3.5 MP3 ( if am correct) vxvm offers vxconfigbackup & vxconfigrestore options for automatic object backups. vxconfigbackupd is a daemon which runs in the background and do upto date backups of all the disk group and the objects associated with it. All the backups are stored in /etc/vx/cbr/bk/dgnamedirectory. Whenever a configuration change occurs, vxconfigbackupd daemon updates the directories with the latest configuration. One can also manually do the object backups using the vxconfigbackupcommand. One can use the -l option to change the default location of the backups. vxconfigbackup -l /var/vxvmbackups datadg This would update all the configuration backups to /var/vxvmbackups directory for datadg. If we need to recover the configuration information for the entire datadg, we can use the vxconfigrestore option. There can be situations where the configuration information is completely lost due to system outages or reboots. /etc/vx/bin/vxconfigrestore -p /var/vxvmbackups datadg # to precommit the changes /etc/vx/bin/vxconfigrestore -c /var/vxvmbackups datadg # to commit the changes A vxprint output will give the confirmation vxprint -g datadg I just explained how to go about backingup and recovering configuration data using the vxconfigbackup and vxconfigrestore options. There may be situations when someone accidentally deletes the volume of a diskgroup. In such situations, backups of individual object information will come in handy You can schedule a cron to backup individual object configuration

/usr/sbin/vxprint -rhmvps ${volume_name} > ${DIR_NAME}/${volume_name}.$ {DATE} using the backed up file and vxmake we can easily recover the deleted volume configuration vxmake -g <dgname> -d <file_name> Verify the recovery using vxprint ; vxprint -g datadg -hrt Start the volume ; vxvol -g <dgname> start <vol_name> Volume is ready to do I/O. As with the case with any recovery options, these options should be experimented before using in the production setup.
Written by krishsubramanian August 19, 2008 at 7:03 am Posted in Recovery, veritas volume manager

Converting a volume from gen to fsgen

with 10 comments There might be situations where one has to convert a volume from gen type to fsgen type. Before going any further on the topic lets see what really fsgen and gen mean. fsgen assumes that the volume contains a filesystem while gen assumes there is no filesystem. fsgen and gen volume types provide similar but not identical semantics for operations using the vxplex utility. In particular fsgen usage type attempts to flush inmemory data cached for the filesystem residing on the volume. For most file systems this is the calling of sync to attempt to flush all in-memory data to disk. I believe it is for this reason we associate all volumes that are using filesystems to be of fsgen type. vxassist uses fsgen as the default type, where as vxmake uses gen as the default type Conversion of volume from one usage type to other cannot be done on the fly, it requires a volume downtime. Lets take a look at this output v simplevol gen ENABLED ACTIVE 8388608 SELECT pl simplevol-01 simplevol ENABLED ACTIVE 8392167 CONCAT RW sd simple01-01 simplevol-01 simple-01 0 8392167 0 c1t0d0 ENA As you can see from the output, we have a gen volume named simplevol, we now need to convert this simplevol from gen to fsgen type. These are the steps that needs to be followed. 1. vxprint -g dgname -rhmvps simplevol > simplevol.vxout 2. open the file simplevol.vxout using your fav editor and change the use_type field alone from gen to fsgen. 3. save the file. make sure you edit the use_type field alone 4. Umount the filesystem ; umount /simplevol 5. stop the volume ; vxvol -g dgname stop simplevol 6. remove the volume ; vxedit -g dgname -rf rm simplevol 7. using vxmake rebuild the volume from the saved file ; vxmake -g dgname -d simplevol.vxout 8. check the vxprint out; vxprint -g dgname -hrt ; check for the usage type; it would be fsgen 9. start the volume; vxvol -g dgname start simplevol 10. do a fsck for the volume; fsck -y /dev/vx/rdsk/dgname/simplevol 11. mount the filesystem ; mount /simplevol You are ready to perform I/O for the filesystem..