Extend filesystem using VxVM on Linux

In this scenario I’m using SLES 10, Veritas Dynamic Multipathing ,Veritas Volume Manager 5 MP3 and Hitachi SAN storage.

First scan for newly provided LUNs on Linux using following command:

# for i in `seq 0 3`; do echo ” – - – ” > /sys/class/scsi_host/host$i/scan; done

Once you verify you can see newly added LUNs from “fdisk -l” , use “vxdctl enable” command to rebuild the volume device node directories and to update the DMP internal database to reflect the new state of the system.

You can also use the “vxdisk scandisks” command to scan devices in the operating system device tree, and to initiate dynamic reconfiguration of multipathed disks.

If you want VxVM to scan only new devices that have been added to the system, and not for devices that have been enabled or disabled, specify the -f option to either of the commands,

# vxdctl -f enable

# vxdisk -f scandisks

In this case disk “sdy” is a new device that have been added to the system

# vxdisk list

DEVICE       TYPE              DISK         GROUP            STATUS
sdb          auto:cdsdisk    testvg01    testvg           online nohotuse
sdc          auto:cdsdisk    testvg02    testvg           online nohotuse
sdd          auto:cdsdisk    testvg03    testvg           online nohotuse
sde          auto:cdsdisk    testvg04    testvg           online nohotuse
sdf          auto:cdsdisk     testvg05    testvg           online nohotuse
sdy          auto:none             -              -                 error

Sometimes a disk cannot be initialized if it does not have a valid useable partition table. On Linux, you can use “fdisk” command to create an empty partition table on a disk

# fdisk /dev/sdy

Command (m for help): o
Command (m for help): w

” Warning: The fdisk command can destroy data on the disk”

Use “vxdisksetup” command to configure a disk from use with Veritas Volume Manager.

# /etc/vx/bin/vxdisksetup -i sdy format=cdsdisk

Add the new LUN to the existing disk group:

# vxdg -g testvg adddisk testvg06=sdy

# vxdisk list

DEVICE       TYPE              DISK         GROUP            STATUS
sdb          auto:cdsdisk    testvg01    testvg           online nohotuse
sdc          auto:cdsdisk    testvg02    testvg           online nohotuse
sdd          auto:cdsdisk    testvg03    testvg           online nohotuse
sde          auto:cdsdisk    testvg04    testvg           online nohotuse
sdf          auto:cdsdisk     testvg05    testvg           online nohotuse
sdy          auto:cdsdisk    testvg06    testvg            online

To exclude a disk from hot-relocation use,

# vxedit -g testvg set nohotuse=on testvg

# vxdisk list

DEVICE       TYPE              DISK         GROUP            STATUS
sdb          auto:cdsdisk    testvg01    testvg           online nohotuse
sdc          auto:cdsdisk    testvg02    testvg           online nohotuse
sdd          auto:cdsdisk    testvg03    testvg           online nohotuse
sde          auto:cdsdisk    testvg04    testvg           online nohotuse
sdf          auto:cdsdisk     testvg05    testvg           online nohotuse
sdy          auto:cdsdisk    testvg06    testvg            online nohotuse

# df -h

/dev/vx/dsk/testvg/testLV
400G  159G  240G  40% /testmt

To increate a testLV Volume by 100GB use

# /etc/vx/bin/resize -b -F vxfs -g [disk_group] [volume_name] +sizeGB [media_name]

where,

volume_name: Name of the volume that needs an increment.

media_name: Name of disk to use for allocating new space for a volume. (In this case we are not specifying any)

# /etc/vx/bin/vxresize -b -F vxfs -g testvg testLV +100g

Read Full Post »

Adding swap space with VxVM in Solaris

Here’s a simple method to add swap space in VxVM Volume

Creating a secondary swap device using “vxassist”

#vxassist -g rootdg -U swap make swapvol (size) rootdisk

Where,

rootdg = Volume group

swapvol = swap space name

(size) = swap size

rootdisk = disk name

 

Adding Swap space

# swap -a /dev/vx/dsk/rootdg/swapvol

Permanently add swap space in /etc/vfstab

/dev/vx/dsk/rootdg/swapvol – - swap – no –

Read Full Post »

Make VxVM volume permissions persistent across reboots

Details:

By default, a newly created volume will only have permissions for the root user only, i.e below is a ‘test’ volume under disk group testdg:
/dev/vx/dsk/testdg# ls -l
total 0
brw-------   1 root     root      79,76000 Jun  9 14:33 test
The permissions on the volume can be changed by using the chmod command:
/dev/vx/dsk/testdg# chmod 777 test
/dev/vx/dsk/testdg# ls -l
total 0
brwxrwxrwx   1 root     root      79,76000 Jun  9 14:33 test 
However, because chmod is an OS command, after the system reboots, the permissions on the volume are restored to what they were before, root.
In order to permanently change the permissions, a VERITAS Volume Manager command is needed to change the permission records within the disk group configuration:
vxedit set user=username group=groupname mode=xxxx volumename
Here is an example:
/dev/vx/dsk/testdg# ls -l
total 0
brw-------   1 root     root      79,76000 Jun  9 14:33 test
/dev/vx/dsk/testdg# vxedit set mode=777 test
/dev/vx/dsk/testdg# ls -l
total 0
brwxrwxrwx   1 root     root      79,76000 Jun  9 14:33 test     
This will allow the volume to retain its permissions even after the system reboots.

Group Permissions on a Volume

Here is the list of the current permissions on the volumes in testdg for a test system:
# cd /dev/vx/dsk/testdg
# ls -al
total 4
drwxr-xr-x   2 root     root         512 Apr  9 13:20 .
drwxr-xr-x   4 root     root         512 Apr  6 14:46 ..
brw-------   1 root     root     137,10002 Apr  9 13:20 pedvol
brw-r--r--   1 root     root     137,10001 Apr  3 08:31 testvol
brw-------   1 root     root     137,10000 Apr  3 08:21 vol01
To change the group that owns the volume:
# vxedit -g testdg set group=other testvol
The results are shown below:
# ls -al
total 4
drwxr-xr-x   2 root     root         512 Apr  9 13:20 .
drwxr-xr-x   4 root     root         512 Apr  6 14:46 ..
brw-------   1 root     root     137,10002 Apr  9 13:20 pedvol
brw-r--r--   1 root     other    137,10001 Apr  3 08:31 testvol
brw-------   1 root     root     137,10000 Apr  3 08:21 vol01
The group permission was changed from root to other.

Read Full Post »

Delete duplicate entries in vxdisk (VxVM)

Details:

vxdisk list displays duplicate entries for the disk device (c#t#d#s#) along with an error status:
# vxdisk list
DEVICE       TYPE      DISK       GROUP    STATUS
ct0d0s2       sliced    rootdisk      rootdg       online
c4t0d0s2     sliced    rootmirror    rootdg      online
c6t32d0s2   sliced    testdg02     testdg       error
c6t32d0s2   sliced           -            -              error
c6t33d0s2   sliced    testdg03     testdg       error
c6t33d0s2   sliced           -            -              error
c6t34d0s2   sliced           -            -              error
c6t34d0s2   sliced     testdg04     testdg      error
c6t35d0s2   sliced     testdg05     testdg      error
c6t35d0s2   sliced           -            -              error
c6t58d0s2   sliced     testdg06     testdg      error
c6t58d0s2   sliced           -            -              error

However, vxprint -ht -g testdg shows that the testvol volume is ENABLED and ACTIVE:
v  testvol      -                ENABLED  ACTIVE   314572800 RAID     -            raid5
pl testvol-01   testvol     ENABLED  ACTIVE   314592960 RAID     4/32       RW
sd testdg02-01  testvol-01   testdg02 0        17678493 0/0             c6t32d0  ENA
sd testdg03-01  testvol-01   testdg03 0        17678493 0/17678493 c6t33d0  ENA
sd testdg04-01  testvol-01   testdg04 0        17075205 0/35356986 c6t34d0  ENA
sd testdg05-01  testvol-01   testdg05 0        17678493 1/0             c6t35d0  ENA
pl testvol-02       testvol      ENABLED  LOG   7182     CONCAT    -              RW
sd testdg06-01  testvol-02   testdg06 0          7182         0             c6t58d0  ENA
Data on the disks remains accessible through VERITAS Volume Manager (VxVM) and the mounted file system. Therefore, vxdisk list displays incorrect information in regard to the disk group being in an error status.
Possible Root Causes:

• Duplicate entries in the /etc/path_to_inst file.

• Cables are crossed between controllers connecting to the disk array.

Solution:

1. Make sure all the SCSI or fiber channel connections are correct.

2. On Solaris, remove all duplicate entries in the /etc/path_to_inst file. If there are multiple hosts sharing the array, this will apply for all Sun systems.

3. The Sun system or systems must perform two configuration reboots this way: reboot -- -r. 
The results from validating SCSI and fiber connections, clearing out duplicate entries for path_to_inst and rebooting twice:
# vxdisk list
DEVICE       TYPE      DISK       GROUP    STATUS
c3t0d0s2      sliced    rootdisk       rootdg      online
c4t0d0s2      sliced    rootmirror     rootdg     online
c6t32d0s2    sliced    testdg02      testdg      online
c6t33d0s2    sliced    testdg03      testdg      online
c6t34d0s2    sliced    testdg04      testdg      online
c6t35d0s2    sliced    testdg05      testdg      online
c6t58d0s2    sliced    testdg06      testdg      online  

Read Full Post »

Convert from sectors to megabytes/gigabytes

1 kilobyte = 1024 bytes

1 megabyte = 1024 kilobytes

1 gigabyte = 1024 megabytes

Example

The command below creates a 2 gigabytes concat volume, named “vol01″

# vxassist -g datadg make vol01 2g layout=concat init=active

Figure 1

The size of “vol01″, shown in Figure 1, is 4194304 sectors. Another method to retrieve the sector size of a volume is the command

# vxprint -g <dg-name> -Qqv <volume-name> | awk ‘{ print $5 }’

# vxprint -g datadg -Qqv vol01 | awk ‘{ print $5 }’

4194304

4194304 sectors can be converted to 2 gigabytes as follows:

4194304 sectors * 512 bytes per sector = 2147483648 bytes

2147483648 bytes / 1024 bytes per kilobyte = 2097152 kilobytes

2097152 kilobytes / 1024 kilobytes per megabyte = 2048 megabytes

2048 megabytes / 1024 megabytes per gigabyte = 2 gigabytes

Read Full Post »