Thursday, December 30, 2010

File System can not be resize when using the vxresize command

#/etc/vx/bin/vxresize -F vxfs -g sf6ux002-coedg vol_oracle +5g
VxVM vxresize ERROR V-5-1-4283  resizing volume other than FSGEN or RAID5 can result in loss of data. Use -f option to force resize this volume.

To increase the size of the  File System:
First is to increase the volume by using the vxassist command.
Second increase the File System by using the fsadm command.

Example:
#vxprint -htg <diskgroup> <volume>
#vxprint -htg sf6ux002-coedg vol_oracle
snip

v  vol_oracle   -            ENABLED  ACTIVE   14680064 SELECT    vol_oracle-02 gen
pl vol_oracle-02 vol_oracle  ENABLED  ACTIVE   14681600 STRIPE    2/64     RW
sd c3t88d180s2-04 vol_oracle-02 c3t88d180s2 14696960 7340800 0/0  EMC_CLARiiON0_226 ENA
sd c3t88d182s2-04 vol_oracle-02 c3t88d182s2 14696960 7340800 1/0  EMC_CLARiiON0_11 ENA



Run #vxdg -g <diskgroup> free command to verify there is space available
#vxdg -g sf6ux002-coedg free
DISK DEVICE TAG OFFSET LENGTH FLAGS
c3t88d180s2 EMC_CLARiiON0_226 EMC_CLARiiON0_226 23061760 1036800 -
c3t88d180s2 EMC_CLARiiON0_226 EMC_CLARiiON0_226 36170240 5766400 -
c3t88d182s2 EMC_CLARiiON0_11 EMC_CLARiiON0_11 23061760 1036800 -
c3t88d182s2 EMC_CLARiiON0_11 EMC_CLARiiON0_11 36170240 5766400 -
c3t88d183s2 EMC_CLARiiON0_227 EMC_CLARiiON0_227 25646080 524800 -
c3t88d183s2 EMC_CLARiiON0_227 EMC_CLARiiON0_227 30365440 11571200 -
c3t88d184s2 EMC_CLARiiON0_223 EMC_CLARiiON0_223 17267200 1280 -
c3t88d184s2 EMC_CLARiiON0_223 EMC_CLARiiON0_223 25647360 524800 -
c3t88d184s2 EMC_CLARiiON0_223 EMC_CLARiiON0_223 34561280 7375360 -


Increase the volume:
#vxassist -g <diskgroup> growby <volume> size
#vxassist -g sf6ux002-coedg  growby vol_oracle 5g

To view the new size of the volume:
# vxprint -htg <diskgroup> <volume>
# vxprint -htg sf6ux002-coedg vol_oracle
V NAME RVG/VSET/CO KSTATE STATE LENGTH READPOL PREFPLEX UTYPE
PL NAME VOLUME KSTATE STATE LENGTH LAYOUT NCOL/WID MODE
SD NAME PLEX DISK DISKOFFS LENGTH [COL/]OFF DEVICE MODE
SV NAME PLEX VOLNAME NVOLLAYR LENGTH [COL/]OFF AM/NM MODE
SC NAME PLEX CACHE DISKOFFS LENGTH [COL/]OFF DEVICE MODE
DC NAME PARENTVOL LOGVOL
SP NAME SNAPVOL DCO
EX NAME ASSOC VC PERMS MODE STATE
SR NAME KSTATE
v vol_oracle - ENABLED ACTIVE 25165824 SELECT vol_oracle-02 gen
pl vol_oracle-02 vol_oracle ENABLED ACTIVE 25167360 STRIPE 2/64 RW
sd c3t88d180s2-04 vol_oracle-02 c3t88d180s2 14696960 7340800 0/0 EMC_CLARiiON0_226 ENA
sd c3t88d180s2-07 vol_oracle-02 c3t88d180s2 36170240 5242880 0/7340800 EMC_CLARiiON0_226 ENA
sd c3t88d182s2-04 vol_oracle-02 c3t88d182s2 14696960 7340800 1/0 EMC_CLARiiON0_11 ENA
sd c3t88d182s2-07 vol_oracle-02 c3t88d182s2 36170240 5242880 1/7340800 EMC_CLARiiON0_11 ENA
Increase the File System:
#/usr/lib/fs/vxfs/fsadm -b <volume-size>  -r  #/dev/vx/rdsk/dev/vx/dskdiskgroup/volume  /mount-point
#/usr/lib/fs/vxfs/fsadm -b 25165824 -r  /dev/vx/rdsk/dev/vx/dsk/sf6ux002-coedg/vol_oracle  /apps/oracle

"Corrupt label; wrong magic number" message appears in the Solaris syslog (/var/adm/messages)

Exact Error Message
Jul 30 17:14:13 sinatra2 Corrupt label; wrong magic number
Jul 30 17:14:13 sinatra2 scsi: [ID 107833 kern.warning] WARNING: /pci@8,600000/fibre-channel@2/sd@14,1d (sd162):
Details:
This is a message that the operating system displays if a disk has no label on it. Labels are written to the Volume Table of Contents (VTOC) in the first block of the disk.

Cause:
·               This happens when a new disk is presented to the host and the host has not run the format() command to write this label
·               This is normal to see when a new disk has been freshly created and presented to the operating system
·               This can be reported if a healthy disk is written to in a non standard manner where the VTOC has been destroyed with a command such as dd()

Resolution:

1. Run the format() command and choose the disk from the menu. This will label the disk.
2. Run the fmthard() command in a situation where there are many disks and a script should be employed

Note: This could be detrimental to restoring data. Check with your technical experts if critical data is involved since this action could cause a negative impact on attempts to restore lost data.

NFS fix for all vxfs volumes

Applying the NFS fix on all vxfs volumes
----------------------------------------

Before starting the activity make sure application team shutdowns all the application services so that we can umount the desired VXfs volumes.

1. Login as superuser.

2. umount all the volumes in disk groups.

3. Stop all the volumes for all the dg's.
# vxvol -g <dg-name>  stopall
eg,  vxvol -g cipcissdb025bkpdg stopall - will stop all volumes on the dg xxyydb025bkpdg

4. verify that the above volumes where stopped successfully
# vxprint -g <dg_name> | grep ^v

- KSTATE should show as DISABLED.

5. To change minor numbers of the volumes in all diskgroup's to less than 255 - execute the following command for every DG.Note - set minor number different for every DG but it should be less than 255.
# vxdg -g <dg_name> reminor 100

6. verify the minor numbers are changed successfully for all the volumes to less than 255

7. start all the volumes in dg cihcissdb027bkpdb
# vxvol -g <dg_name> startall

8. verify the all the volumes in all dg's started successfully.
# vxprint -g testdg1 | grep ^v

9. Mount all the volumes in dg's - mount -a or mount every volume one by one.

10. verify all the mount points as before umouting the volumes exists 

Volume Manager cannot initialize a disk with no backup slice or a disk with an EFI label

Exact Error Message
VxVM vxdisksetup ERROR V-5-2-3628 The dmpnode <disk_name> is disabled. Can not proceed with vxdisksetup.
VxVM vxdisk ERROR V-5-1-5433 init failed: Device path not valid.
get_geometry_info_common: /dev/vx/rdmp/<disk_name>/fmt_page_code failed. ret 0x6

Details:
The issue:
Using Volume Manager to initialize a disk results in one of the following error messages:
VxVM vxdisksetup ERROR V-5-2-3628 The dmpnode <disk_name> is disabled. Can not proceed with vxdisksetup.
VxVM vxdisk ERROR V-5-1-5433 init failed:  Device path not valid.

The vxconfigd program returns the following error when started or restarted:
get_geometry_info_common: /dev/vx/rdmp/<disk_name>/fmt_page_code failed. ret 0x6

The cause:
Volume Manager requires a backup partition defined as slice 2 on each disk.
A disk that is less than 1.2 Terabytes in size with an EFI label cannot be initialized under Volume Manager.

To solve the issue:
1) Verify the current slice definitions by performing the following:

Note: Complete step a if using Enclosure Based Naming (EBN) or go to step b if using Operating System Native Naming (OSN).

a) Determine the disk Operating System Native name that needs initialization.

# vxdisk list <disk_name>

Make note of the c#t#d# received via the output.

b) Retrieve the slice layout of the disk.

# prtvtoc /dev/dsk/<c#t#d#s0>

example:
# prtvtoc /dev/dsk/c1t0d0s0
* /dev/dsk/c1t0d0s2 partition map
*
* Dimensions:
*     512 bytes/sector
*     424 sectors/track
*      24 tracks/cylinder
*   10176 sectors/cylinder
*   14089 cylinders
*   14087 accessible cylinders
*
* Flags:
*   1: unmountable
*  10: read-only
*
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
      0      2    00          0  40968576  40968575   /
      1      3    01   40968576  51205632  92174207
      4      7    00   92174208  30721344 122895551   /var
      5      0    00  122895552  20453760 143349311   /opt



2) Use the format utility to setup a backup partition and write an SMI label to the disk:
# format -e c1t0d0
At the "format>" prompt, type 'p'
At the "partition>" prompt, type 'p'

Total disk cylinders available: 14087 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders         Size            Blocks
 0       root    wm       0 -  4025       19.54GB    (4026/0/0)   40968576
 1       swap    wu    4026 -  9057       24.42GB    (5032/0/0)   51205632
 3 unassigned    wm       0                0         (0/0/0)             0
 4        var    wm    9058 - 12076       14.65GB    (3019/0/0)   30721344
 5 unassigned    wm   12077 - 14086        9.75GB    (2010/0/0)   20453760
 6 unassigned    wm       0                0         (0/0/0)             0
 7 unassigned    wm       0                0         (0/0/0)             0

Partition 2 will need to be created if it is not configured with the tag 'backup' and defined to span the entire size of the disk.

At the "partition>" prompt, type '2'

Enter partition id tag[unassigned]:
Set ID Tag to 'backup'.

Enter partition permission flags[wu]:
Partition permission flags should be set to 'wm'.

Enter new starting cyl[0]:
Starting cylinder should be '0'.

Enter partition size[0b, 0c, 0.00mb, 0.00gb]:
For partition size take the number for "Total disk cylinders available" from the partition print command (14087 in the example above).

After setting up the backup partition, write the partition table and exit the utility.
At the "partition>" prompt, type 'label'.
At the "Ready to label disk, continue?" prompt, type 'y'.
At the "partition>" prompt, type 'w'
At the "partition>" prompt, type 'q'
At the "format>" prompt, type 'q'

An example of the corrected prtvtoc:
*                          First     Sector    Last
* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory
      0      2    00          0  40968576  40968575   /
      1      3    01   40968576  51205632  92174207
      2      5    00          0 143349312 143349311
      4      7    00   92174208  30721344 122895551   /var
      5      0    00  122895552  20453760 143349311   /opt

Note the existence of slice 2 in the output above.

3) Verify the status of the disk with the following command:

# vxdisk list

If the disk is now shown as "ONLINE INVALID", it can now be initialized.

4) Initialize the disk:
# vxdisksetup -i <disk_name>

5) Verify the disk is now correctly initialized by Volume Manager with the following command:
# vxdisk list

The disk should now be shown as "ONLINE".

Mirroring Boot Drives with Veritas Volume Manager(VxVM)

The purpose of this document is to provide a quick reference as well as additional methods for recovery and adittional best practices.

Introduction

Many administrators choose to use an alternative volume manager to mirror the boot drives because of the difficulties recovering from primary disk failure under VxVM.  Typically, Solsitce Disksuite(free product) is used to mirror the boot drive while VxVM is used for all other storage.  However, if VxVM is installed and configured correctly, the recovery process is greatly simplified.

The problems associated with recovery are associated in part by the way it encapsulates the boot disk(see above articles for details).  We must properly install and configure VxVM so that these issues are avoided.  In simple terms, we must first mirror the root disk.  Second, we will remove the rootdisk from rootdg and reinitialize the drive.  Third, we will add the root disk back into rootdg and re-attach the mirror.

Note:  You may be interested in determining if a system's boot drives have already been mirrored properly.  One method to identify if the rootdisk was properly mirrored is to look for the presence of the "rootdisk-B0" subdisk.  This subdisk is used to map out the boot block of the rootdisk.  Use the "vxprint -ht rootvol" command to verify if it exists.  If it does exist, the boot drive has NOT been mirrored according to these procedures.

Mirror the Drives using VxVM

Identify the root disk and mirror disk.  It is a good idea to have the drives on different controllers if possible for improved redundancy.

# format
Searching for disks...done
AVAILABLE DISK SELECTIONS:
     0. c0t0d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>   <===  Root
          /pci@1f,4000/scsi@3/sd@0,0
     1. c0t1d0 <SUN9.0G cyl 4924 alt 2 hd 27 sec 133>  <=== Root Mirror
          /pci@1f,4000/scsi@3/sd@1,0
Specify disk (enter its number): ^D

Install Veritas Volume Manger according to documentation.  Only encapsulate the root disk.  Do NOT encapsulate any other drives.

NOTE:  You may want to setup your PATH environment variable if you have not already done so.  If you installed in VxVM in the default location you can use the following:

# PATH=$PATH:/usr/lib/vxvm/bin; export PATH

Initialize the root mirror disk.  Add it to "rootdg" group and name the disk "rootmirror".

# vxdisksetup -i  c0t1d0
# vxdg -g rootdg adddisk rootmirror=c0t1d0

Mirror the root disk according to the partition layout. 

If you have /, swap, /var, /opt, and /home defined as partitions 0,1,3, 4, and 7 respectively, you must attach the mirrors in this same exact order.  If you are not sure, Veritas may have created notes in your /etc/vfstab which describe how the partitions were layed before VxVM encapsulated the boot disk.  It is very important to attach each mirror in the exact numerical order as it was originaly carved on the boot disk.

# vxrootmir rootmirror                           <=== partition 0
# vxassist -g rootdg mirror swapvol rootmirror   <=== partition 1
# vxassist -g rootdg mirror var rootmirror       <=== partition 3
# vxassist -g rootdg mirror opt rootmirror       <=== partition 4
# vxassist -g rootdg mirror home rootmirror      <=== partition 7

NOTE:  Be sure to mirror any other volumes configured on the boot disk.  This may be the case if you have additional volumes configured on the boot drive.  Use the "vxprint" command to list all volumes.  You can also use "vxprint -p" to make sure there are 2 plexes associated with each volume.  Remember to modify the remaining commands to include these additional volumes.

Disassociate and remove the existing plexes from the rootdisk:

# vxplex -g rootdg dis rootvol-01 swapvol-01 var-01 opt-01 home-01
# vxedit -g rootdg -fr rm rootvol-01 swapvol-01 var-01 opt-01 home-01
# vxedit rm rootdiskPriv     ### May not be in rootdg - Ignore if Error

Remove the rootdisk from rootdg:

# vxdg -g rootdg rmdisk rootdisk

Re-initialize the rootdisk and add back into rootdg:

# vxdisksetup -i c0t0d0
# vxdg -g rootdg adddisk rootdisk=c0t0d0

Re-attach the mirror in the correct order according to the partition layout:

# vxrootmir rootdisk
# vxassist -g rootdg mirror swapvol rootdisk
# vxassist -g rootdg mirror var rootdisk
# vxassist -g rootdg mirror opt rootdisk
# vxassist -g rootdg mirror home rootdisk

Create the underlying partitions on the rootdisk and mirrordisk - Optional Step - The benefits are worth the effort!

Update:  This step can be automated using the Veritas supplied program: vxbootsetup.  Simply execute the following command:

# vxbootsetup

Or you may do it the manual way as described below:

Notice how you did NOT create the disk partitions manually when you initialized the mirror disk.  This is because VxVM automatically does its partitioning for you.  This is also true for the root disk after it has been re-initialized and brought back into rootdg.  That is, the original rootdisk partition scheme has been replaced by Veritas's partition scheme.  This means that the underlying partitions for each volume(swap, /opt, /var, /home) are not physically layed out on the drives corresponding to the veritas volumes.  In some situations though, you might want to be able to access the partitions corresponding to each volume by manually mounting the slice.  In a recovery situation for example, you may want to boot from cdrom and access the /opt partition by manually mounting the slice without the veritas drivers loaded.  This is not possible unless you create the underlying partition mapping directly to the opt volume using the "vxmksdpart" command.  All underlying partitions except / should be created.  The / partition is automatically created and is mapped correctly to the corresponding veritas root volume. 

One Caveat, you cannot use partition 3 or 4 because this is typically where Veritas stores is private and public region.  The following is snipped from the "format" utility listing the Veritas partitions.  This shows that the root partition exists but the swap, /var, /opt, home partitions are not mapped on the drive(Veritas knows where they exist on the drive because of its private and public regions):

Part      Tag    Flag     Cylinders        Size           Blocks
  0       root    wm       1 - 2282        3.91GB    (2282/0/0) 8194662 <=== "/" exists
  1 unassigned    wm       0               0         (0/0/0)           0                 <=== Unassigned
  2     backup    wm       0 - 4923        8.43GB    (4924/0/0) 17682084
  3          -    wu       0 -    0        1.75MB    (1/0/0)        3591                   <=== Private Region
  4          -    wu       1 - 4923        8.43GB    (4923/0/0) 17678493          <=== Public Region
  5 unassigned    wm       0               0         (0/0/0)           0                       <=== Unassigned
  6 unassigned    wm       0               0         (0/0/0)           0                       <=== Unassigned
  7 unassigned    wm       0               0         (0/0/0)           0                       <=== Unassigned

You may use the unassigned partitions which are 1, 5,6, and 7 to map to the veritas volumes.  Be sure to document which partitions map to the Veritas volumes for future reference. 

The "vxmksdpart" arguments are the subdisk(which maps directly to the volume), slice, tag and flag.  Be sure to use the correct tag and flag for you particular Solaris version.  Reference the man page for "fmthard" for correct options.  Use the "vxprint" command to get the correct subdisk names:

Rootdisk:

# vxmksdpart -g rootdg rootdisk-02 1 0x03 0x01             <=== swap
# vxmksdpart -g rootdg rootdisk-03 5 0x07 0x00             <=== /var   
# vxmksdpart -g rootdg rootdisk-04 6 0x06 0x00             <=== /opt
# vxmksdpart -g rootdg rootdisk-05 7 0x08 0x00             <=== /export/home

Specify the primary swap partition as the dump device:

# dumpadm -d /dev/dsk/c0t0d0s1

RootMirror:

# vxmksdpart -g rootdg rootmirror-02 1 0x03 0x01          <=== swap
# vxmksdpart -g rootdg rootmirror-03 5 0x07 0x00          <=== /var
# vxmksdpart -g rootdg rootmirror-04 6 0x06 0x00          <=== /opt
# vxmksdpart -g rootdg rootmirror-05 7 0x08 0x00          <=== /export/home


For maximum redundancy, configure all private regions to have a copy of rootdg database

# vxedit -g rootdg set nconfig=all rootdg
# vxedit -g rootdg set nlog=all rootdg
# vxdg flush rootdg

Configure VxVM to use host spare rather than hot relocation

# vi /etc/rc2.d/S95vxvm-recover
Comment out the "vxrelocd root &" and uncomment "vxsparecheck root &"

Create OBP device alias for rootdisk and rootmirror.  Set PROM to boot to the aliases.

# vxeeprom devalias rootdisk c0t0d0s0
# vxeeprom devalias rootmirror c0t1d0s0
# eeprom "boot-device=rootdisk rootmirror"

Verify the correct eeprom information:
# eeprom | grep disk

Update:  The previous "vxeeprom" commands may not work for all boot proms.  If you are unable to boot to the "rootdisk" device on reboot, you should set the device alias using the "nvalias" command at the boot prom.  This can be done by first doing a "devalias" to display the PATH of each disk, and use the "nvalias" command to set the rootdisk and rootmirror alias manually.  The following is an example:

ok devalias
…
disk                 /pci@1f,4000/scsi@3/disk@0,0  <=== disk is rootdisk"
disk0                /pci@1f,4000/scsi@3/disk@0,0
disk1                /pci@1f,4000/scsi@3/disk@1,0  <=== disk1 is rootmirror"
…

ok nvalias rootdisk /pci@1f,4000/scsi@3/disk@0,0
ok nvalias rootmirror /pci@1f,4000/scsi@3/disk@1,0
ok boot



How to Recover from Primary Disk Failure

Grab your backup drive from the spare parts shelf with the same exact geometry as the failed drive. You do have one; don't you?

Configure system to see drive

# devfsadm     ### Prior to Solaris 8 try "# drvconfig; disks; devlinks"

Initialize the new drive, add to rootdg as "newdisk", and replace old "rootdisk" with "newdisk":

# vxdisksetup -i c0t0d0
# vxdg -g rootdg adddisk newdisk=c0t0d0
# vxdg repldisk rootdisk=newdisk

Parition the new drive exactly the same as rootmirror:

I have not figured out a way to do this automatically instead of using format.  The fmthard command will not work because it does not allow overlapping partitions.  The dd command should not be used as it also copies over the Veritas diskid.  In which case, there will be duplicate diskid's on each disk causing the system not to boot.  Please use the following procedure instead:

# format
; Enter 0 for the new drive
; Enter p for partition
; Enter p to view current partition layout
; Enter s to select the partition table of rootmirror
; Enter 1 to copy partition table of rootmirror onto new drive
; Enter l to label disk
; Enter y to continue
; Enter q to quit partition menu
; Enter q to quit format utility

Re-attach the mirror for each volume:

# vxplex att rootvol rootvol-01
# vxplex att swapvol swapvol-01
# vxplex att var var-01
# vxplex att opt opt-01
# vxplex att home home-01


How to Recover from Mirror Disk Failure

Grab your backup drive from the spare parts shelf with the same exact geometry as the failed drive. You do have one; don't you?

Configure system to see drive

# devfsadm     ### Prior to Solaris 8 try "# drvconfig; disks; devlinks"

Initialize the new drive, add to rootdg as "newdisk", and replace old "rootmirror" with "newdisk"

# vxdisksetup -i c0t1d0
# vxdg -g rootdg adddisk newdisk=c0t1d0
# vxdg repldisk rootmirror=newdisk

Parition the new drive exactly the same as rootdisk:

I have not figured out a way to do this automatically instead of using format.  The fmthard command will not work because it does not allow overlapping partitions.  The dd command should not be used as it also copies over the Veritas diskid.  In which case, there will be duplicate diskid's on each disk causing the system not to boot.  Please use the following procedure instead:

# format
; Enter 1 for the new drive
; Enter p for partition
; Enter p to view current partition layout
; Enter s to select the partition table of rootdisk
; Enter 0 to copy partition table of rootdisk onto new drive
; Enter l to label disk
; Enter y to continue
; Enter q to quit partition menu
; Enter q to quit format utility

Re-attach the mirror for each volume:

# vxplex att rootvol rootvol-02
# vxplex att swapvol swapvol-02
# vxplex att var var-02
# vxplex att opt opt-02
# vxplex att home home-02

To mirror your root disk onto another disk
  1. Choose a disk that is at least as large as the existing root disk.
  1. If the selected disk is not already under VxVM control, use the vxdiskadd or vxdiskadm command, or the Veritas Enterprise Administrator (VEA) to add it to the bootdg disk group. Ensure that you specify the sliced format for the disk.
  1. Select menu item 6 (Mirror Volumes on a Disk) from the vxdiskadm main menu, or use the VEA to create a mirror of the root disk. (These automatically invoke the vxrootmir command if the mirroring operation is performed on the root disk.)
Alternatively, to mirror only those file systems on the root disk that are required to boot the system, run the following command:
# /etc/vx/bin/vxrootmir altboot_disk
where altboot_disk is the disk media name of the mirror for the root disk. vxrootmir creates a mirror for rootvol (the volume for the root file system on an alternate disk). The alternate root disk is configured to enable booting from it if the primary root disk fails.
  1. Set the value of the EEPROM variable use-nvramrc? to true. This enables the use of VxVM boot disk aliases, which identify mirrors of the root disk from which the system can be booted. If the system is up and running, set use-nvramrc? to true using the following command:
# eeprom use-nvramrc?=true
You can also set use-nvramrc? at the ok boot prompt:
ok setenv use-nvramrc? true
  1. You should now be able to boot the system from an alternate boot disk, vx-altboot_disk, by entering the following command at the ok boot prompt:
ok boot vx-altboot_disk
You can use the devalias command at the boot prompt to discover the alternate disks from which the system may be booted:
ok devalias