티스토리 툴바


AIX2012/02/17 10:08

UPDATED: Grow your rootvg on the fly (from 6.1 TL 4)

AnthonyEnglish| Oct 11 2010 | Tags:  volume_group resize rootvg 6.1 7.1 extendlv spare aix 5.3 chvg growth backend disk san lun| Comments (11)  |  Visits (5,543)
There are lots of good reasons for having spare disk for rootvg, as I looked at in the post make way for rootvg. With virtual disks you can resize your volume group on the fly:
 

Increase rootvg dynamically


If your rootvg “disk” is actually virtual, such as a SAN LUN or a logical volume on the VIO server, then it usually can be expanded on the SAN (or using extendlv on the VIOS) and then recognised on the AIX LPAR using the -g flag of the chvg command:

chvg -g rootvg


 Note: this is supported for rootvg and concurrent vgs from AIX 6.1 TL 4. See IBM technote IZ80021 http://bit.ly/cmHjmy

 Resizing the rootvg disk
 
 I tried to increase rootvg on an LPAR running AIX 5.3 TL 11 and hit the following error:
 

 aix53_lpar # chvg -g rootvg

0516-1380 chvg: Re-sizing of the disks is not supported for the rootvg.

 0516-732 chvg: Unable to change volume group rootvg.

Looks like the volume group needed to be varied off and varied on again. For rootvg, that means a reboot.

No reboot on AIX 6.1

In AIX 6.1 (from TL 4 - use oslevel -sto check your AIX level), you can increase rootvg on the fly.

 aix61_lpar:/# chvg -g rootvg

 0516-1164 chvg: Volume group rootvg changed.  With given characteristics rootvg can include up to 16 physical volumes with 2032 physical partitions each.

 Sounds like yet another reason to migrate to AIX 6.1.

이 글은 스프링노트에서 작성되었습니다.

Posted by ultrasound
AIX2012/01/11 09:59

Dynamic Tracking of Fibre Channel devices

AIX® supports dynamic tracking of Fibre Channel (FC) devices.

Previous releases of AIX required a user to unconfigure FC storage device and adapter device instances before making changes on the system area network (SAN) that might result in an N_Port ID (SCSI ID) change of any remote storage ports.

If dynamic tracking of FC devices is enabled, the FC adapter driver detects when the Fibre Channel N_Port ID of a device changes. The FC adapter driver then reroutes traffic destined for that device to the new address while the devices are still online. Events that can cause an N_Port ID to change include moving a cable between a switch and storage device from one switch port to another, connecting two separate switches using an inter-switch link (ISL), and possibly rebooting a switch.

Dynamic tracking of FC devices is controlled by a new fscsi device attribute, dyntrk. The default setting for this attribute is no. To enable dynamic tracking of FC devices, set this attribute to dyntrk=yes, as shown in the example:

chdev -l fscsi0 -a dyntrk=yes

In this example, the fscsi device instance is fscsi0. Dynamic tracking logic is called when the adapter driver receives an indication from the switch that there has been a link event involving a remote storage device port.

Dynamic tracking support requires the following:
  • A switched environment. It is not supported in arbitrated loop environments, including public loop.
  • FC 6227 adapter firmware, level 3.22A1 or higher.
  • FC 6228 adapter firmware, level 3.82A1 or higher.
  • FC 6239 adapter firmware, all levels.
  • All subsequent FC adapter releases support Fast I/O Failure.
  • The World Wide Name (Port Name) and Node Names devices must remain constant, and the World Wide Name device must be unique. Changing the World Wide Name or Node Name of an available or online device can result in I/O failures. In addition, each FC storage device instance must haveworld_wide_name and node_name attributes. Updated filesets that contain the sn_location attribute (see the following bullet) must also be updated to contain both of these attributes.
  • The storage device must provide a reliable method to extract a unique serial number for each LUN. The AIX FC device drivers do not autodetect serial number location, so the method for serial number extraction must be explicitly provided by any storage vendor in order to support dynamic tracking for their devices. This information is conveyed to the drivers using the sn_location ODM attribute for each storage device. If the disk or tape driver detects that the sn_location ODM attribute is missing, an error log of type INFO is generated and dynamic tracking is not enabled.
    Note: The sn_location attribute might not be displayed, so running the lsattr command on an hdisk, for example, might not show the attribute even though it could be present in ODM.
  • The FC device drivers can track devices on a SAN fabric, which is a fabric as seen from a single host bus adapter, if the N_Port IDs on the fabric stabilize within about 15 seconds. If cables are not reseated or N_Port IDs continue to change after the initial 15 seconds, I/O failures could result.
  • Devices are not tracked across host bus adapters. Devices only track if they remain visible from the same HBA that they were originally connected to.

    For example, if device A is moved from one location to another on fabric A attached to host bus adapter A (in other words, its N_Port on fabric A changes), the device is seamlessly tracked without any user intervention, and I/O to this device can continue.

    However, if a device A is visible from HBA A but not from HBA B, and device A is moved from the fabric attached to HBA A to the fabric attached to HBA B, device A is not accessible on fabric A nor on fabric B. User intervention would be required to make it available on fabric B by running thecfgmgr command. The AIX device instance on fabric A would no longer be usable, and a new device instance on fabric B would be created. This device would have to be added manually to volume groups, multipath device instances, and so on. This is essentially the same as removing a device from fabric A and adding a new device to fabric B.

  • No dynamic tracking can be performed for FC dump devices while an AIX system dump is in progress. In addition, dynamic tracking is not supported when booting or running the cfgmgr command. SAN changes should not be made while any of these operations are in progress.
  • After devices are tracked, ODM might contain stale information because Small Computer System Interface (SCSI) IDs in ODM no longer reflect actual SCSI IDs on the SAN. ODM remains in this state until cfgmgr is run manually or the system is rebooted (provided all drivers, including any third party FC SCSI target drivers, are dynamic-tracking capable). If cfgmgr is run manually, cfgmgr must be run on all affected fscsi devices. This can be accomplished by running cfgmgr without any options, or by running cfgmgr on each fscsi device individually.
    Note: Running cfgmgr at run time to recalibrate the SCSI IDs might not update the SCSI ID in ODM for a storage device if the storage device is currently opened, such as when volume groups are varied on. The cfgmgr command must be run on devices that are not opened or the system must be rebooted to recalibrate the SCSI IDs. Stale SCSI IDs in ODM have no adverse affect on the FC drivers, and recalibration of SCSI IDs in ODM is not necessary for the FC drivers to function properly. Any applications that communicate with the adapter driver directly using ioctl calls and that use the SCSI ID values from ODM, however, must be updated (see the next bullet) to avoid using potentially stale SCSI IDs.
  • All applications and kernel extensions that communicate with the FC adapter driver, either through ioctl calls or directly to the FC driver's entry points, must support the version 1 ioctl and scsi_buf APIs of the FC adapter driver to work properly with FC dynamic tracking. Noncompliant applications or kernel extensions might not function properly or might even fail after a dynamic tracking event. If the FC adapter driver detects an application or kernel extension that is not adhering to the new version 1 ioctl and scsi_buf API, an error log of type INFO is generated and dynamic tracking might not be enabled for the device that this application or kernel extension is trying to communicate with.

    For ISVs developing kernel extensions or applications that communicate with the AIX Fibre Channel Driver stack, refer to the Required FCP, iSCSI, and Virtual SCSI Client Adapter Device Driver ioctl Commands and Understanding the scsi_buf Structure for changes necessary to support dynamic tracking.

  • Even with dynamic tracking enabled, users should make SAN changes, such as moving or swapping cables and establishing ISL links, during maintenance windows. Making SAN changes during full production runs is discouraged because the interval of time to perform any SAN changes is too short. Cables that are not reseated correctly, for example, could result in I/O failures. Performing these operations during periods of little or no traffic minimizes the impact of I/O failures.

The base AIX FC SCSI Disk and FC SCSI Tape and FastT device drivers support dynamic tracking. The IBM® ESS, EMC Symmetrix, and HDS storage devices support dynamic tracking provided that the vendor provides the ODM filesets with the necessary sn_location and node_name attributes. Contact the storage vendor if you are not sure if your current level of ODM fileset supports dynamic tracking.

If vendor-specific ODM entries are not being used for the storage device, but the ESS, Symmetrix, or HDS storage subsystem is configured with the MPIO Other FC SCSI Disk message, dynamic tracking is supported for the devices in this configuration. This supersedes the need for the sn_location attribute. All current AIX Path Control Modules (PCM) shipped with the AIX base support dynamic tracking.

The STK tape device using the standard AIX device driver also supports dynamic tracking provided the STK fileset contains the necessary sn_locationand node_name attributes.
Note: SAN changes involving tape devices should be made with no active I/O. Because of the serial nature of tape devices, a single I/O failure can cause an application to fail, including tape backups.

Devices configured with the Other FC SCSI Disk or Other FC SCSI Tape messages do not support dynamic tracking.

이 글은 스프링노트에서 작성되었습니다.

Posted by ultrasound
AIX2011/12/22 10:40
Technote (FAQ)
 
Question
How to NFS Mount a cdrom Filesystem
 
 
Answer

Following are the steps required to mount a CD-ROM as a cdrom filesystem, export the NFS filesystem from the server and NFS mount the filesystem on the client. This document applies to AIX Versions 4.3 and above.

On the server
On the client
Troubleshooting

On the server

  1. Check the status of portmap and the NFS daemons:
    • Enter lssrc -s portmap.
    • Enter lssrc -g nfs.
    • If they are not active, start them by running startsrc -s portmapand then startsrc -g nfs.

     

  2. Mount the CD-ROM:
    • Enter mkdir /cdrom to create a mount point, if one does not already exist.
    • Load the CD into the CD-ROM drive.
    • Enter smitty cdrfs.
    • Select Add a CDROM File System.
    • Select your device from the F4 list.
    • Enter the mount point you just created for MOUNT POINT.
    • If you want the filesystem to mount on a reboot, change Mount AUTOMATICALLY at system restartto yes. 
      NOTE: If you specify yesfor Mount AUTOMATICALLY at system restart, you must have media in the CD-ROM drive when you reboot or the mount will fail.
    • Enter mount /cdrom.

     

  3. To add the filesystem for NFS exporting:
    • Enter smitty mknfsexp.
    • Enter the PATHNAME of the directory to export (for example,/cdrom).
    • Change the MODE of export directory to read-only.
    • Enter the HOSTS & NETGROUPS allowed client access.
    • Enter HOSTS allowed root access.
    • Press Enter to export the filesystem.
      NOTE: If you are going to be installing on the client machine, you MUST enter the client name for HOSTS allowed root access.

     

  4. Verify that the filesystem is exported:
    • Enter showmount -e and find it in the list.

On the Client

  1. Check the status of portmap and the NFS daemons:
    • Enter lssrc -s portmap.
    • Enter lssrc -g nfs.
    • If they are not active, start them by running startsrc -s portmapand then startsrc -g nfs.

     

  2. Verify that the server has the filesystem exported:
    • Enter showmount -e <server_name>.
      NOTE<server_name> will be the hostname of the server.

     

  3. Create the directory you will be using to access the software.
    • Enter mkdir /cdrom.

     

  4. To NFS mount the filesystem on the client:
    • Enter smitty mknfsmnt.
    • Enter the PATHNAME of the mount point (for example, /cdrom).
    • Enter the PATHNAME of the remote directory (for example,/cdrom).
    • Enter the HOST where the remote directory resides.
      NOTE: HOST will be the hostname of the server.
    • Change the MODE for this NFS file system to read-only.
    • Press enter to NFS mount the filesystem.

On AIX 4.x BOS installation CD-ROMs and most LPP CD-ROMs, the install images are now located in /cdrom/usr/sys/inst.images. On some LPP CD-ROMs, the install images are located in /cdrom. To check which directory the install images are on, check for the existence of a .toc file in the directory. Once you have determined the directory with the .toc file, use the full pathname of the directory as your <input device> in SMIT when you perform your install.


Troubleshooting

Look for the following errors:

   mount: 1831-011 access denied for ...
   mount: 1831-008 giving up on ...
If they occur, try the following suggestions:
  1. Make sure that the client's hostname and IP address are resolvable by the server. Also, make sure that the server's hostname and IP address are resolvable by the client. You can do so by running the following:

    On the server:

            host <client_hostname>
            host <client_ipaddress>
    

    The output of these lines has to match EXACTLY.

    On the client:

            host <server_hostname>
            host <server_ipaddress>
    

    The output of these lines has to match EXACTLY.

  2. On the client, enter netstat -in. If there is more than one network interface, make sure all IP addresses of the client are resolvable by the server. You can do this by running (on the server):
             host <ipaddress>
    

    Execute this command for each IP address listed in the netstat -in output.

  3. If you are still getting errors:

    On the server, enter smitty rmnfsexp.

    • Enter the PATHNAME of the exported directory (for example,/cdrom).
    • Press Enter to remove the directory from the exports list.
    • Enter umount /cdrom.
    • Enter rmdir /cdrom.
    • Return to step 1 of the section "On the server". If you still cannot get the CD-ROM NFS mounted, contact your AIX support center for further assistance.

이 글은 스프링노트에서 작성되었습니다.

Posted by ultrasound
AIX2011/12/21 15:40
  1. ISO image 만들기

#mkisofs -r -o cdimage [디렉토리]

예) /test/jaeho1 Directory의 내용을 jaeho_1.iso라는 ISO Image File로 생성.

#mkisofs -r -o jaeho_1.iso /test/jaeho1 <- ISO image 생성

 

  1. iso(cd-image) Filesystems 처럼 mount 하여 사용

1) iso 파일보다 약간 큰 logical volume 생성

2) /etc/filesystems에 LV에 대한 정보 추가

/isoCD:

dev = /dev/imagelv

vfs = cdrfs

mount = false

options = ro

account = false

3)mount point 생성

#mkdir /isoCD

4)iso image를 해당 LV에 dd로 copy

#dd if=jaeho_1.iso of=/dev/imagelv bs=64k

5) read-only mount 하여 사용

#mount -r /dev/imagelv /isoCD

이 글은 스프링노트에서 작성되었습니다.

Posted by ultrasound
AIX2011/11/14 12:59

Managing the Time Zone Variable

 

 Technote (FAQ)
 
Question
Managing the Time Zone Variable
 
 
Answer

This document discusses the Time Zone (TZ) variable and how to change to and from Daylight Savings Time (DST). This document applies to all versions of AIX.

PLEASE NOTE: The default timezone format for AIX 6.1 and AIX 7 is Olson Time, this technote does not apply to Olson Time, but standard POSIX timezone formatting. I am including APARs that are for Olson Time below for completeness.

About DST 
Enabling DST 
Disabling DST 
Changing the effective date to switch to DST 
How switching to DST affects cron jobs 
Manually Changing DST for 2007 
Recommended fixes

About DST

If the Daylight Savings Time option is enabled, the default in AIX is for the system time to move forward 1 hour (to DST) at 2:00am the second Sunday in March, and move back one hour (to Standard Time) at 2:00 a.m. on the first Sunday in November (prior to The Energy Policy Act of 2005 (Public Law 109-58)2007, this switch occured on the first Sunday in April and ended the last Sunday in October). The default is hard coded and is not stored in any user accessible file. However, the date and time at which the switch to DST and ST occurs can be customized by root (global environment) or by users (user environment) by setting the $TZ environment variable. To see if DST is enabled, echo $TZ; if the time zone variable ends in DT, DST is enabled.


Enabling DST

If your time zone uses Daylight Saving Time , you can enable it with SMIT. Enter:

     smit chtz
     Answer "1 yes" to "Use Daylight Savings Time?"

Disabling DST

If Daylight Savings Time does not apply to your location, you can turn this option off with the following SMIT menu:

     smit chtz
     Answer "2 no" to "Use Daylight Savings Time?"

Changing the effective date to switch to DST

If you wish to change the date or time at which the system switches to DST and back to Standard Time from the defaults for your zone, edit the TZ line in/etc/environment. Change the line to read something like the following:

     TZ=CST6CDT,M3.2.0/2:00:00,M11.1.0/2:00:00

The above example would effect a change to Daylight Savings Time at 2:00 AM on the second Sunday in March and change back at 2:00 AM on the first Sunday in November, and keep the US Central Time Zone time offset from GMT. The breakdown of the string is:

  • CST6CDT is the time zone you are in;
  • M3 is the third month;
  • .2 is the second occurrence of the day in the month;
  • .0 is Sunday;
  • /2:00:00 is the time.

In more detail, the format is TZ = local_timezone,date/time,date/time. Here date is in the form of Mm.n.d, day d(0-6) of week n (1-5, where week 5 means "the last d day in month m" and which may occur in either the fourth or the fifth week) of month m of the year. Week 1 is the first week in which the day d occurs. Day zero is Sunday. This format is compliant with POSIX 1003.1 standards for Extensions to Time Functions.

NOTE: This can be changed in the smit chtz panel as well.


How switching to DST affects cron jobs

If you have a cron job that is to be run at 2:01am and it is the time of year when the time springs forward, this job will not run. The time skips from 2:00am to 3:00am. On the other hand, when the time is being set back one hour, jobs that run between 1:00am and 2:00am will run twice.

So, for jobs set between 2:00am and 3:00am, in the spring it is necessary to either change the time for these jobs to run, run them manually, or wait until the following day to run them. The cron daemon does not need to be stopped; however, if changes are made to the TZ variable, then kill the current cron daemon so that it will automatically respawn and recognize the new TZ setting.

NOTE: Daylight savings time is just a way in which time is displayed to the user. Time is still kept the same internally, so programs such as dce which use time as it is stored internally will not be affected by daylight savings time.


Manually Changing DST for 2007

If the APARs mentioned in Tech Doc titled "New Daylight Saving Time for 2007" are not installed, the TZ field may be changed manually as below. The changes necessary for each of the standard US timezones would be as follows:

Eastern Time Zone:

# chtz EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00

Central Time Zone:

# chtz CST6CDT,M3.2.0/2:00:00,M11.1.0/2:00:00

Mountain Time Zone:

# chtz MST7MDT,M3.2.0/2:00:00,M11.1.0/2:00:00

Pacific Time Zone:

# chtz PST8PDT,M3.2.0/2:00:00,M11.1.0/2:00:00

The "M3.2.0" means to go on DST starting in month 3 (March), week 2, and Day 0 (Sunday).
The "M11.1.0" means to switch back 1st Sunday in November.

The system would have to be rebooted before March, 2007 for the changes to take place. Otherwise, all processes that were running prior to the change will continue to use the older value.

Recommended fixes

AIX 5.1

IY75214 DAYLIGHT SAVING TIME DEFAULT CHANGING IN 2007
IY34203 SMITTY CHTZ APPENDING 2 COMMAS AFTER TZ
IY49871 SMITTY CHTZ_USER LIMITS THE EDITING OF TIMEZONE TO THREE CHARACTERS
IY21283 PROBLEM WITH SMITTY CHTZ_USER MENU WHEN SOME FIELD ARE LEFT BLANK
IY75214 DAYLIGHT SAVING TIME DEFAULT CHANGING IN 2007

AIX 5.2

IY75213 DAYLIGHT SAVING TIME DEFAULT CHANGING IN 2007
(This APAR is included in Technology Level 5200-08 and later.)
IY35629 SMITTY CHTZ APPENDING 2 COMMAS AFTER TZ
IY49813 SMITTY CHTZ_USER LIMITS THE EDITING OF TIMEZONE TO THREE CHARACTERS
IY39159 DEFAULT DST TZ SETTINGS WITH AN OFFSET FAILS TO RETURN TO STD
IY39312 SETTING TZ FAILS WITH QUOTED TIMEZONES
IY43243 CRITICAL FIXES FOR AIX 5.2 AS OF APRIL 2003
IY44169 WLM CONFIGURATION SET DOESN'T WORK RIGHT WHEN CHANGING TZ (TIME ZONE)
IY37121 IN UDF FILESYSTEMS, LOSTFILES.DIR HAS OLD DATE
IY37445 TIMEZONE DEFAULTS FOR NEW ZEALAND INCORRECT
IY75213 DAYLIGHT SAVING TIME DEFAULT CHANGING IN 2007

AIX 5.3

IY75211 DAYLIGHT SAVING TIME DEFAULT CHANGING IN 2007
(This APAR is included in Technology Level 5300-04 and later.)
IZ82425 5300-09-08-1036 ZDUMP REPORTS INCORRECT DST DATE FOR EASTERN AUSTRALIA REGIONS
IZ82692 5300-10-05-1036 ZDUMP REPORTS INCORRECT DST DATE FOR EASTERN AUSTRALIA REGIONS
IZ82189 5300-11-05-1036 ZDUMP REPORTS INCORRECT DST DATE FOR EASTERN AUSTRALIA REGIONS
IZ81579 5300-12-02-1036 ZDUMP REPORTS INCORRECT DST DATE FOR EASTERN AUSTRALIA REGIONS
IZ82703 5300-10-05-1036 CRON DOES NOT RUN A 3AM JOB WHEN DST OCCURS
IZ82201 5300-11-05-1036 CRON DOES NOT RUN A 3AM JOB WHEN DST OCCURS
IZ81589 5300-12-02-1036 CRON DOES NOT RUN A 3AM JOB WHEN DST OCCURS
IZ11729 5300-07-02-0806 Date gives wrong output for certain time zones.
IZ09392 5300-08 Date gives wrong output for certain time zones.
IZ11383 5300-09 Date gives wrong output for certain time zones.

AIX 6.1

IZ79512 6100-02-09-1034 ZDUMP REPORTS INCORRECT DST DATE FOR EASTERN AUSTRALIA REGIONS
IZ67738 6100-03-06-1034 ZDUMP REPORTS INCORRECT DST DATE FOR EASTERN AUSTRALIA REGIONS
IZ78940 6100-04-06-1034 ZDUMP REPORTS INCORRECT DST DATE FOR EASTERN AUSTRALIA REGIONS
IZ78883 6100-05-02-1034 ZDUMP REPORTS INCORRECT DST DATE FOR EASTERN AUSTRALIA REGIONS
IZ78949 6100-04-06-1034 CRON DOES NOT RUN A 3AM JOB WHEN DST OCCURS
IZ78896 6100-05-02-1034 CRON DOES NOT RUN A 3AM JOB WHEN DST OCCURS
IZ74244 6100-06 CRON DOES NOT RUN A 3AM JOB WHEN DST OCCURS
IZ68046 6100-04-03-1009 UNEXPECTED OLSON TZ CHANGE FOR AMERICA/SAO_PAULO.
IZ67981 6100-05 UNEXPECTED OLSON TZ CHANGE FOR AMERICA/SAO_PAULO.
IZ67948 6100-06 UNEXPECTED OLSON TZ CHANGE FOR AMERICA/SAO_PAULO.
IZ09600 6100-00-02-0750 Date gives wrong output for certain time zones.
IZ12763 6100-01 Date gives wrong output for certain time zones.
IZ12630 6100-02 Date gives wrong output for certain time zones.
 
 
 
 
Historical Number
isg1pTechnote0395
 

이 글은 스프링노트에서 작성되었습니다.

Posted by ultrasound
AIX2011/11/03 10:50

#loopmount -i cdrom.iso -o "-V cdrfs -o ro" -m /aix6.1

 

Loopback Device Support in AIX

 

 Technote (FAQ)
 
Question
This technote discusses the use of the loopback device to mount file or disk images in AIX
 
 
Answer
Introduction
In AIX 6100-04-00-0943 (6.1 TL4) support for a loopback device was added to AIX and VIOS (PowerVM). This device can be used as a block device to provide access to file images.

The file image can be an ISO image, a disk image, a filesystem or a logical volume. These images can be mounted into the filesystem tree via the /usr/sbin/loopmount command.

A loopback device can be created before mounting a file image using /usr/sbin/mkdev or the loopmount command can automatically create it.

According to the AIX 6.1 manuals on Infocenter, there are some restrictions to the loopback device:

* The varyonvg command on a disk image is not supported.
* A CD ISO, and DVD UDF+ISO, and other CD/DVD images are only supported in read-only format.
* An image file can be associated with only one loopback device.
* Loopback devices are not supported in workload partitions.

Mounting a File
To mount a file on the loopback device, the loopmount command is used. In the example below the loopback device is created automatically by the command.

Remember unlike crfs the mount point directory must already exist.

# mkdir /cdmount
# loopmount -i /backup/cd_image_327874 -l loop0 -o "-V cdrfs -o ro" -m /cdmount

# df
/dev/loop0       1678304         0  100%   419576   100% /cdmount

# lsdev -C | grep loop
loop0      Available       Loopback Device

# cd /dev
# ls -l loop*
brw-rw----    1 root     system       34,  0 Nov 27 06:43 loop0

During its existence the loopback device is listed in the CuAt, CuDv and CuDvDr ODM object classes.


Unmounting a File
To unmount a file mounted on the loopback device, use /usr/sbin/loopumount. If the regular /usr/sbin/umount command is used the dynamically created loopback device will not be unconfigured.

# loopumount -l loop0 -m /cdmount

Notice that since the loop0 device was created dynamically in the previous mount it will be deleted when not needed any more.

# df | grep loop
<nothing returned>

# lsdev -C | grep loop
<nothing returned>


Possible Problems and Solutions
---------------
# loopmount -i /images/IBM.iso -l loop0 -o "-V cdrfs -o ro" -m /cdmount
1320-003 loopmount: Specified loopback device is not found in ODM
                        Customized Database

Using the -l option assumes the loopback device already exists in /dev and the ODM classes.

If the device doesn't exist you can create it with mkdev:

# mkdev -c loopback -s node -t loopback
loop0 Available
Then use loopmount with -i and -l options to mount into the filesystem tree.

---------------
# loopmount -i /images/IBM.iso -o "-V cdrfs -o ro" -m /cdmount
1320-007 loopmount: Failed to mount the imagefile

Make sure the mount point directory exists
Check the mount options. Readonly must be supplied.

이 글은 스프링노트에서 작성되었습니다.

Posted by ultrasound
AIX2011/10/22 16:10

 

Purpose

Renames a device.

Syntax

rendev
-l Name -n NewName [-u]

Description

The rendev command enables devices to be renamed. The device to be renamed, is specified with the -l flag, and the new desired name is specified with the -n flag.

The new desired name must not exceed 15 characters in length. If the name has already been used or is present in the /dev directory, the operation fails. If the name formed by appending the new name after the character r is already used as a device name, or appears in the /dev directory, the operation fails.

If the device is in the Available state, the rendev command must unconfigure the device before renaming it. This is similar to the operation performed by the rmdev -l Name command. If the unconfigure operation fails, the renaming will also fail. If the unconfigure succeeds, the rendev command will configure the device, after renaming it, to restore it to the Available state. The -u flag may be used to prevent the device from being configured again after it is renamed.

Note:

Start of change

Disk drive devices that are members of the root volume group, or that will become members of the root volume group (by means of LVM or install procedures), must not be renamed. Renaming such disk drives may interfere with the ability to recover from certain scenarios, including boot failures.

End of change

Some devices may have special requirements on their names in order for other devices or applications to use them. Using the rendev command to rename such a device may result in the device being unusable.

Note:
To protect the configuration database, the rendev command cannot be interrupted once it has started. Trying to stop this command before completion, could result in a corrupted database.

Flags

 

-l Name Specifies the device, indicated by the Name parameter, to be renamed in the customized devices object.
-n NewName Specifies the new name, indicated by the NewName parameter, to be assigned to the device.
-u Optional flag, which indicates that the device is not to be configured after it is renamed.

Examples

 

  1. To rename disk hdisk5 to hdisk2, enter:
    rendev -l hdisk5 -n hdisk2
    
  2. To rename disk hdisk3 to ootvg, enter:
    rendev -l hdisk3 -n ootvg
    

The second command fails because ootvg appended to r results in the name rootvg, which conflicts with the rootvg volume group name.

이 글은 스프링노트에서 작성되었습니다.

Posted by ultrasound
AIX2011/10/11 10:33

/usr/DynamicLinkManager/bin/~

 

#dlnkmgr view -path [-c] : path

#dlnkmgr view -lu -c -item vg : lun

#dlnkmgr view -drv : hdisk

이 글은 스프링노트에서 작성되었습니다.

Posted by ultrasound
AIX2011/10/10 11:20

fget_config alternate command is mpio_get_config

 

 

 

Alternate command for fget_config –Av is mpio_get_config -Av

 

fget_config is not giving any outputs about storage disk details on VIOS2.1 without any errors.

 

# which fget_config

/usr/bin/fget_config

 

 

$ ioslevel

2.1.2.10-FP-22.1

 

 

On VIOS 2.1 and AIX 6.1 fget_config command is not showing storage disk information. As per my finding there is alternate command to get storage information mpio_get_config

 

# which mpio_get_config

/usr/bin/mpio_get_config

 

 

mpio_get_config -l hdisk4

The system displays a message similar to the following message:

Storage Subsystem Name = 'DS4400_1'
hdiskLUN #OwnershipUser Label
hdisk40A (preferred)lun0
hdisk51B (preferred)lun1
hdisk62A (preferred)lun2

To make run fget_config on VIOS2.1

Software requirements:

Check the versions of the following software prerequisites:

_ AIX Version 6.1 or VIO 2.1

_ IBM RDAC Driver: devices.fcp.disk.array.rte.6.1.4.1,

_ Other required PTF filesets

.

PTF filesets Version

devices.fcp.disk.array.diag

devices.fcp.disk.array.rte

devices.fcp.disk.rte

devices.common.IBM.fc.rte

devices.pci.df1000f7.com

devices.pci.df1000f7.rte

devices.scsi.scarray.rte

이 글은 스프링노트에서 작성되었습니다.

Posted by ultrasound
AIX2011/10/06 13:38

Currently C-SPOC is unable to provide functionality for dynamic volume

expansion. The chvg command does not support use in volume groups varied on

in enhanced concurrent mode. If you want to increase the size of a shared LUN

allocated to your cluster, follow this process:

1. Bring the volume group offline (stop the cluster on all nodes).

2. On the first cluster node:

 a. Run cfgmgr

 b. Varyon the volume group in normal mode: varyonvg vgname

 c. Run lsattr -El hdisk# to check the size of the disk.

 d. To update the size of the disks in the VG, run chvg -g vgname (this will determine if VG factor change is required to meet the correct 1016 multiplier).

 e. Run lsvg vgname to check the new size.

 f. Varyoff the volume group: varyoffvg vgname

3. On subsequent cluster nodes that share the VG:

 a. Run cfgmgr

 b. Run lsattr -El hdisk# to check the size of the disk.

 c. Import the volume group which you have changed: importvg -L vgname hdisk#

4. Back on the first cluster node:

 a. Varyon the volume group: varyonvg vgname

 b. Run smitty hacmp  Extended Configuration  Extended Verification and Synchronization and ensure there are no errors.

이 글은 스프링노트에서 작성되었습니다.

Posted by ultrasound