Feeds:
Posts
Comments

Archive for the ‘VxVm’ Category

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

Advertisements

Read Full Post »

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 »

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 »

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 »

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 »

Exact Error Message
cannot open /etc/path_to_inst

Details:

Note : This will only work if the rootdisk is encapsulated. You don’t have to break the root mirror.
Under VERITAS Volume Manager ™ rootdisk encapsulation, the administrator must take an extra step to ensure the path_to_inst file is created and populated. The difference lies in the root device. This value is not the same as the default offered during the boot, use the value specified for rootdev in the /etc/system file.
At the OK prompt, do the following:

1. boot -ar
Rebooting with command: boot -ar                                     
Boot device: /pci@1f,0/pci@1,1/ide@3/disk@0,0  File and args: -ar
2. At the following prompts, just hit enter:
Enter filename [kernel/sparcv9/unix]: << ——–Hit enter
Enter default directory for modules [/platform/SUNW,Ultra-5_10/kernel /platform/sun4u/kernel /kernel /usr/kernel]:
Name of system file [etc/system]:  <<< Hit enter
SunOS Release 5.8 Version Generic_108528-15 64-bit
Copyright 1983-2001 Sun Microsystems, Inc.  All rights reserved.
3. When the system asks about rebuilding the path_to_inst, type yes
The /etc/path_to_inst on your system does not exist or is empty.
Do you want to rebuild this file [n]? yes <<<<————–type yes
root filesystem type [ufs]: <<<<———— Hit enter
4. When you get to the following prompt enter /pseudo/vxio@0:0
Enter physical name of root device [/pci@1f,0/pci@1,1/ide@3/disk@0,0:a]: /pseudo/vxio@0:0 <<<<—- Enter this (this comes from /etc/system).
System will now boot OK.
WARNING: forceload of drv/ide failed
WARNING: forceload of drv/ide failed
WARNING: forceload of drv/pci failed
Starting VxVM restore daemon...
VxVM starting in boot mode...
configuring IPv4 interfaces: hme0.
Hostname: sunhost
VxVM starting special volumes ( swapvol )...
Configuring /dev and /devices
Configuring the /dev directory (compatibility devices)
VxVM general startup...
The system is coming up.  Please wait.
starting rpc services: rpcbind done.
Setting netmask of hme0 to 255.255.248.0
starting internet domain name server.
Setting default IPv4 interface for multicast: add net 224.0/4: gateway sunhost
syslog service starting.
Print services started.
volume management starting.
checking : /usr/sbin/luxadm
checking : /usr/lib/liba5k.so.2
checking : /usr/lib/libg_fc.so.2
checking : /usr/lib/sparcv9/liba5k.so.2
checking : /usr/lib/sparcv9/libg_fc.so.2
The system is ready.

Read Full Post »

Removing and reinstalling VEA packages can correct this symptom in many cases.

In version 5.0 VRTSvmpro has dependencies on VRTSfas.

To be able to remove VRTSvmpro the package VRTSfas must be removed first.

The VEA packages must be removed and re-installed in the order specified below.

1. Un-install the following packages in this order:

VRTSfas

VRTSfspro

VRTSvmpro

VRTSobgui

VRTSob

2. Install packages in this order:

VRTSob

VRTSobgui

VRTSvmpro

VRTSfspro

VRTSfas

NOTE – The VRTSvsvc package is obsolete in version 5.0 and should be removed to prevent any problems.

Refer to LBN article 282024 for additional detail.

Read Full Post »

Older Posts »