AIX 5L SysAdmin II: (Unit 06) – Disk Management Procedures

Unit Objectives:
————————
1. Replace a disk under different circumstances
2. Recover from a total volume group failure
3. Rectify problems caused by incorrect actions that have been taken to change disks
4. Export and import volume groups

Disk Replacement: Starting Point:
————————————————-
1. Is the disk Mirrored? Yes –> Procedure 1
No…
2. Is the disk still working? Yes –> Procedure 2
No…
3. Is the Volume Group lost? No –> Procedure 3
Yes…
Volume Group is Lost
rootvg –> Procedure 4
not rootvg –> Procedure 5

Procedure 1: Disk Mirrored:
—————————————-
1. Remove all copies from disk:
# lspv -l hdisk1 (list the logical volumes on the physical volumes)
# unmirrorvg lv_xx 1 hdiskX (repeat to unmirror each logical volume)

2. Remove disk from volume group:
# reducevg vg_name hdiskX (updates VGDA information)

3. Remove disk from ODM:
# rmdev -l hdiskX -d (updates the ODM information)

4. Connect new disk to system:
# cfgmgr (if hot-swappable)
# reboot (if not hot-swappable)

5. Add new disk to volume group:
# extendvg vg_name hdiskY

6. Create new copies:
# mirrorvg lv_xx 2 hdiskY
# varyonvg -v vg_name (sychronize information)

Procedure 2: Disk Still Working:
———————————————–
1. Connect new disk to system (non-rootvg)
# cfgmgr (if hot swappable)
# reboot (if not hot swappable)

2. Add new disk to volume group:
# extendvg vg_name hdiskY

3. Migrate old disk to new disk: (* rootvg)
# migratepv hdiskX hdiskY (users can still work on system)

4. Remove old disk from volume group:
# reducevg vg_name hdiskX (updates the VGDA)

5. Remove old disk from ODM:
# rmdev -l hdiskX -d (updates the ODM)

(*): Is the disk in rootvg?
See next foil for further considerations!

Procedure 2: Special Steps for rootvg:
——————————————————-
1. …
2. …
3. Disk contains hd5?
# migratepv – hd5 hdiskX hdiskY
# bosboot -ad /dev/hdiskY (sets it up as a boot logical volume)
# chpv -c hdiskX (clean the boot sector information)
# bootlist … (includes the new disk as a bootable device)

Migrate old disk to new disk:
# migratepv hdiskX hdiskY
4. …
5. …

Procedure 3: Total Disk Failure:
———————————————-
1. Identify all LVs and file systems on failing disk:
# lspv -l hdiskY (display logical volumes) PV STATE: removed/missing

2. Unmount all file systems on failing disk:
# umount /dev/lv_xx (repeat to unmount all logical volumes)

3. Remove all file systems and LVs from failing disk:
# smit rmfs or # rmlv lv_xx

4. Remove disk from volume group:
# reducevg vg_name hdiskY (updates the VGDA)

5. Remove disk from system:
# rmdev -l hdiskY -d (updates the ODM)
# cfgmgr

6. Add new disk to volume group:
# extendvg vg_name hdiskZ

7. Re-create all LVs and file systems on new disk:
# mklv -y lv_xx # smit crfs

8. Restore file systems from backup:
# restore -rvqf /dev/rmt0

Procedure 4: Total rootvg Failure:
————————————————
1. Replace bad disk
2. Boot in maintenance mode
3. Restore from a mksysb tape
4. Import each volume group into the new ODM (importvg) if needed.

Procedure 5: Total non-rootvg Failure:
——————————————————
1. Export the volume group from the system:
# exportvg vg_name

2. Check /etc/filesystems.

3. Remove bad disk from ODM and the system:
# rmdev -l hdiskX -d

4. Connect new disk
# cfgmgr or reboot

5. If volume group backup available (savevg):
# restvg -f /dev/rmt0 hdiskY

6. If no volume group backup available: Recreate…
— volume group (mkvg) – for each volume group
— logical volumes and filesystems (mklv, crfs)

Restore data from a backup:
# restore -rqvf /dev/rmt0

Frequent Disk Replacement Errors (1 of 4):
—————————————————————
Boot problems after rootvg migration:
-Firmware LED codes cycle
Fix:
— Check bootlist (bootlist)
— Re-create boot logical volume hd5 (bosboot)

bosboot -ad /dev/hdisk1

Frequent Disk Replacement Errors (2 of 4):
————————————————————–
hdisk5 is removed from ODM and from the system, but not from the volume group:
# rmdev -l hdisk5 -d

Frequent Disk Replacement Errors (3 of 4):
————————————————————–
# rmdev -l hdisk5 -d (updated ODM but VGDA not updated)
Fix:
# reducevg datavg …555… (Use 32bit PVID instead of disk name)
lqueryvg -p hdisk2 -At (updates the VGDA)

Frequent Disk Replacement Errors (4 of 4):
————————————————————–
# lsvg datavg
unable to find device id …734… in device configuration database
ODM failure!

Analyze failure!
1. Typo in command?
2. Analyze the id of the device: Which PV or LV causes problems?

ODM problem in rootvg
— No –> Export and Import Volume Group
— Yes –> rvgrecover
synclvodm -l lv00vgname

Activity: Migrating rootvg:
————————————-
1. migratepv (hd5, hd3 —-> new disk)
2. mklvcopy (hd5, hd3 —-> new disk)

Exporting a Volume Group:
—————————————-
1. Unmount all filesystems:
# umount /dev/lv10
# umount /dev/lv11

2. Vary off the volume group:
swapoff /dev/paging00 – (Turn off paging space)
# varyoffvg myvg

3. Export volume group:
# exportvg myvg (VG information removed from ODM)

Note: The complete volume group is removed from the ODM.

Importing a Volume Group:
—————————————-
1. Configure the disks
# cfgmgr or reboot

2. Import the volume group:
# importvg -y myvg hdisk3

3. Mount the file systems:
# mount /dev/lv10
# mount /dev/lv11

The complete volume group is added to the ODM.

importvg and Existing Logical Volumes:
———————————————————-
# importvg -y myvg hdisk3
importvg: changing LV name lv10 to lv23
importvg: changing LV name lv11 to lv24

To resolve two lv10s and lv11s that clash

Note: importvg can also accept the PVID in place of the hdisk name

importvg and Existing FileSystems (1 of 2):
—————————————————————
/dev/lv10: /home/sarah
/dev/lv11: /home/michael (name clash)
/dev/loglv00: log device
datavg

/dev/lv23: /home/peter
/dev/lv24: /home/michael (name clash)
/dev/loglv01: log device
hdisk3 (myvg)

# importvg -y myvg hdisk3
# mount /home/michael
Note: Cannot mount /dev/lv11 onto /home/michael

# umount /home/michael
# mount -o log=/dev/loglv01 /dev/lv24 /home/michael

importvg and Existing FileSystems (1 of 2):
—————————————————————
# vi /etc/filesystems
add the additional filesystems to /etc/filesystems

# mkdir /home/michael_moon
# mount /home/michael
# mount /home/michael_moon –> Mount point must exist

importvg -L (1 of 2):
—————————-
No exportvg!!!
# importvg -y myvg hdisk3
# mklv lv99 myvg
# importvg -L myvg hdisk9
-L – Learn about possible changes!
# varyonvg myvg
==> importvg -L fails, if a name clash is detected

Unit Summary:
———————–
Different procedures are available that can be used to fix disk problems under any circumstance:

Procedure 1 – Mirrored Disk
Procedure 2 – Disk still working (rootvg specials)
Procedure 3 – Total disk failure
Procedure 4 – Total rootvg failure
Procedure 5 – Total non-rootvg failure

Note: exportvg and importvg can be used to easily transfer volume groups between systems.

FAQs:
———–
Q: Where are disk errors sent to?
A: Hardware as well as software errors are sent to the error log.? This log can be viewed with the errpt command.
?????
Q: In the different disk replacement procedures in unit 6, the steps reducevg and rmdev are listed in the same order through out the different procedures.? Why is it necessary to follow that order?
A: It’s important to follow that order to make sure that the information pertaining to the device is removed properly from the ODM and the reducevg command takes care of that.? The rmdev command will make sure that any other definitions on the system are also removed such as entries in the /dev directory. If the order is altered, for instance, rmdev command is executed first, then it will be necessary to query the VGDA of the volume group to make sure the definition in the ODM is also removed.??

Q: What is the purpose of the chpv -c hdisk# command after unmirroring the rootvg?
A: This -c option will ensure that the boot sector on the disk is cleared.?

Q: Why would one want to export a volume group?
A: Exporting a volume group is useful when you are transfering data between systems.? In this case, instead of transfering a few file systems the entire volume group is transfered to a new system where it can be accessed just as if it was native of the new system.? This saves you from recreating the volume group, its structure and having to restore the data.?

Lab:
——–
lspv
lspv -l hdisk1
mkvg -y datavg hdisk1 (Make a new volume group)
lsvg datavg
lsvg -o (verify both volume groups are active)
smit mklv (Make a new logical volume name: lv_raw)
smit jfs2 (create 2 journaled file systems in datavg)
lsvg -l datavg (List the logical volumes datavg)
mount /home/jupiter
mount /home/mars
lsvg -l datavg (LV STATE = open/syncd)
cd /home/jupiter
touch j1 j2 j3 (create 3 new files)
cd /home/mars
touch m1 m2 m3 (create 3 new files)
cd
pwd
umount /home/jupiter (prepare to export volume group)
umount /home/mars
lsvg -l datavg (LV STATE – closed/syncd)
varyoffvg datavg (turn off the the volume group datavg)
lsvg -o (now only shows rootvg and not datavg)
exportvg datavg (updates the ODM and /etc/filesystems file)
more /etc/filesystems (jupiter and mars is gone)
importvg -y datavg hdisk1
lsvg -o (check to see if active)
lsfs (shows the filesystems /home/jupiter and /home/mars)
more /etc/filesystems (jupiter and mars oar now back)
mount (verify that they are mounted)
mount /home/jupiter
mount /home/mars
ls /home/jupiter
ls /home/mars

unmount /home/jupiter
unmount /home/mars
lsvg -l datavg (shows datavg is inactive = closed)
varyoffvg datavg
exportvg datavg (removes entry from ODM)
lsvg (only shows rootvg not datavg)

smit mklv (Create a logical volume lv_raw in rootvg)
smit jfs2 (Add two file systems to rootvg with mount points
/home/jupiter and /home/mars)

lsvg -l rootvg (shows fslv00 /home/jupiter and fslv01 /home/mars)
mount /home/jupiter
mount /home/mars
cd /home/jupiter
touch j20 j21 j22
cd /home/mars
touch m20 m21 m22
lsvg -l rootvg (all are mounted)
importvg -y datavg hdisk1 (cause problems by importing datavg)
synclvodm: Logical volume name lv_raw changed to fslv02
synclvodm: Logical volume name loglv00 changed to loglv01
synclvodm: Logical volume name fslv00 changed to fslv03
synclvodm: Logical volume name fslv01 changed to fslv04
Warning: mount point /home/jupiter already exists in /etc/filesystems
Warning: mount point /home/mars already exists in /etc/filesystems
Caused name clashing but ODM handles it by renaming
unmount /home/jupiter (in rootvg)
unmount /home/jupiter (in rootvg)
mount -o logs/dev/loglv01 /home/jupiter (errors)
mount -o logs/dev/loglv01 /dev/fslv03 on /home/jupiter (errors)
Errors are because /etc/filesystem is not updated with this information

lsfs (only shows rootvg filesystems)
mkdir -o /datavg/jupiter
mkdir -o /datavg/mars
vi /etc/filesystems
Note: To correct the problem, copy the lines for /home/jupiter and /home/mars and paste them in below. Then change them to /datavg/jupiter and /datavg/mars. Also change the device line from /dev/fslv01 to /dev/fslv03 and /dev/fslv02 to /dev/fslv04. Then change the log entries from /dev/loglv00 to /dev/loglv01 for both.
:wq

mount /datavg/jupiter
mount /datavg/mars
mount /home/jupiter
mount /home/mars
mount (verify that they are all mounted)
ls /datavg/jupiter
ls /home/jupiter
ls /datavg/mars
ls /home/mars (all files are present)

Leave a Reply

Your email address will not be published. Required fields are marked *

*