AIX Down Under

Show disk size with getconf DISK_SIZE /dev/hdisk0

AnthonyEnglish Marcações: mb size lsdev lspv getconf volume_group aix gb deprecated disk "lspv_size" vios bootinfo san lun physical ‎ 6 Comentários ‎ 126.810 Visualizações

Give bootinfo the boot

If you want to get the size of a disk (virtual or physical), you can use the AIX getconf command.

getconf DISK_SIZE /dev/hdisk0
140013

The size is reported in MB, so the disk above is a 140 GB disk.

You could use the bootinfo -s, but that command is

deprecated!

so I'm not even going to give you a link to its man pages.

Maybe you're not exactly sure what "deprecated" means, but it sounds bad, doesn't it? According to Wikipedia, "deprecated" derives from the Latin verb deprecare, meaning "to ward off (a disaster) by prayer". So don't use bootinfo, OK?

Back to AIX and disk sizes.

To display disk sizes you could, of course, use the AIX lspv command, but that only works if the disk is in a volume group.

If the disk (be it physical or virtual) is on the VIOS, you can display it using the VIOS command lspv -size. Unlike the AIX lspv command, this VIOS command should show the size, even if the disk is not assigned to a volume group on the VIOS.

For more on getconf and the deprecated bootinfo command, see this IBM technote.

If you like this tip, get some practical, actionable steps in your inbox weekly. http://tiny.cc/AIXquicktips

Modificado em por AnthonyEnglish

UPDATED: Load ISO images via VIO server and AIX

AnthonyEnglish Marcações: recovery dr mkdvd mkcd devices virtual vmlibrary mksysb mkvdev vio file-backed nim disaster mkrep loadopt media aix ‎ 18 Comentários ‎ 72.602 Visualizações

Updated 28 January 2011
A few notes and clarifications:

What I call the Virtual Media Library is often also called the Virtual Media Repository (VMR). IBM documentation uses both terms.
the syntax for creating the virtual optical device was incorrect. Details within the body of the post below.
You may also be interested in an article of mine in the IBM Systems Magazine on the Virtual Media Library: Media Release - Keep software and OS backups handy with VIOS virtual media library

Using ISO Images Effectively

The VIO server's virtual media library allows you to load ISO images onto the VIO server and share them with VIO clients. It is remarkably quick to set up and learn, and is a simple way of loading software. AIX 6.1 TL 4 introduced the loopmount command which allows you to mount an ISO image without a VIO server VM Library. We'll look at both methods here.

VIO Virtual Media Library

The VIO server's Virtual Media Library is so useful, I know people who say they would be lost without it. It's been called a smart man's NIM. It can be used to clone LPARs, install or update AIX (including migrating to AIX 6.1), as well as for sharing any files which can be put into ISO format. The VIO server version 1.5.2 introduced the Virtual Media Library. To determine your VIO server level log in as padmin and run the ioslevel command. The latest VIO server updates are available from the IBM Virtual I/O Server Support page.

Clone / upgrade / install via ISO

On AIX the mkdvd (and mkcd) commands allow you to create or convert mksysb backup files in ISO format which can then be shared via the VIO server. This is a great way of cloning LPARs without using NIM and without the need for physical media. This might be a central part of your DR strategy.

You can also use VM Library for upgrading AIX. My compatriot Chris Gibson has an excellent article showing how he did an AIX Migration with File-Backed VIOS Devices. It's also easy to create ISO images on AIX of any directory and share those around by mounting them on the VIO server VMLibrary. I use the mkisofs command from the AIX Toolbox for Linux, but there are other ways of creating images in ISO format.

Use the HMC GUI ...

If you're using an HMC, and it's at level 7.3.4 SP 2 or later, you may be able to do all of this through the HMC GUI. As we saw in a recent post on AIX Down Under, you can update your HMC remotely. There are some other prerequisites for the VIO server and system firmware, all of which are explained in the Hardware GUI for Virtual I/O Server Commands wiki. There is a movie which covers this on the IBM Wiki Movies page (movie 63 - HMC GUI for VIOS Commands).

... or the VIO Command line

If your configuration is not quite up to date, or your preference is for the command line, using ISO images is very straightforward.

After creating the VMLibrary using mkrep, I like to give each LPAR its own specially named optical device:

Correction: the following line in the original post was incorrect:

~~mkvdev -vhost0 -fbo -dev lpar1_cd0~~

Correct syntax is:

mkvdev -vadapter vhost0 -fbo -dev lpar1_cd0

Once you've copied the ISO image into the VM Library, you can easily load the image using loadopt without looking up the virtual optical device name using lsmap:

loadopt -vtd lpar1_cd0 -disk mydvd.iso

You should then be able to see the ISO image on the VIO client, either through SMS menus or (usually) by mounting a CD file system. Unloading the image so you can mount another one is done with the unloadopt command.

Sharing ISOs to several VIO clients

You can set permissions on the ISO image to be read only, using either mkvopt when loading the images into the VM library, or chvopt after they've been loaded. This allows you to load the same ISO image onto other virtual optical devices, making it available to several LPARs at once. That's easier than copying files around or using NFS mounts. More detailed explanations can be found on the VIOLoadISO and VIOS_Optical_Commands wikis.

Loading ISO images on AIX command line

You can now mount ISO images directly onto an AIX LPAR using the loopmount command. This was introduced into AIX 6.1 TL 4 (use the oslevel -s to check your current level). The man page for loopmount provides this example:

loopmount -i cdrom.iso -o "-V cdrfs -o ro" -m /mnt

Make use of virtualisation

If you don't have access to a VIO server VM Library, and your AIX is not yet at 6.1 TL 4, there is a workaround for loading ISO images. But as Nigel Griffiths explains in the AIXpert blog, it's time to ask Are you up to date with AIX? If you do have the VIO Virtual Media Library, it will make your AIX updates and administration a whole lot easier.

Modificado em por AnthonyEnglish

How to remove empty directories (rmdir -r?)

AnthonyEnglish Marcações: mkdirhier cleanup mkdir remove empty_directory yuk rmdir directory ‎ 3 Comentários ‎ 65.294 Visualizações

Someone asked me to remove all empty directories in a particular path.

Option 1: rm -r

You can remove ALL directories and all files using

rm -r

You will end up with a nice clean system that way, and a new line on your resumé explaining why you left your job at short notice.

DON'T TRY THIS AT WORK!

For that matter, don't try any of these "solutions" until you've tried them somewhere which doesn't leave you wishing you'd never heard of AIX Down Under. Whenever I run any command to remove files or directories, I waste two seconds staring at the Enter key and thinking about it.

If you wipe out your system, your company and your career, remember one thing: it wasn't me who pressed the Enter key.

Option 2: rmdir -p

Remember, the aim is to remove empty directories. Now just as you can create a directory structure using

mkdir -p

you can also clean up a directory structure using
rmdir -p

Let me explain.

As the documentation for the mkdir command explains, the -p flag creates missing intermediate path name directories. For example, instead of creating a directory hierarchy one at a time:

mkdir /a
mkdir /a/very
mkdir /a/very/long
mkdir /a/very/long/directory # well you get the idea

You can do it with a single command using the -p flag:

mkdir -p /a/very/long/directory/structure/which/nobody/will/ever/find

(Incidentally, there's a command like this called mkdirhier. It creates the directory hierarchy just like mkdir -p, but it doesn't give you the permissions options which are available with mkdir.)

Well, you can remove the directory structure using rmdir -p:

rmdir -p /a/very/long/directory/structure/which/nobody/will/ever/find

The rmdir command will remove directories in reverse (assuming you have write permissions), so that command is like running:
rmdir /a/very/long/directory/structure/which/nobody/will/ever/find # "find" directory removed

Then
rmdir /a/very/long/directory/structure/which/nobody/will/ever # "ever" is gone

Then will, then nobody and so on.

rmdir will stop removing directories once it gets to one that is not empty.

This option is pretty good, but it does have one drawback: you need to know the bottom of the directory path before you can remove it. If someone asked to remove all the empty directories under a certain branch of the directory structure, you could

saw off the entire branch (using rm -r); or
find all the empty directories (the dead branches) and just prune them.

If it's the latter, then you need to hunt your way down the very end of the path before you can run a command to clean it up. If you're going to do that, it's probably time to create a script ... or use the find command.

Option 3: find command with rmdir

find . -type d -exec rmdir {} \;

The type -d limits the search to directories, and the rmdir will remove them.

cd /a/very
find . -type d -exec rmdir {} \;

rmdir: 0653-610 Cannot remove current directory ..
rmdir: 0653-611 Directory ./long is not empty.
rmdir: 0653-611 Directory ./long/directory is not empty.
find: 0652-081 cannot change directory to </a/very/long/directory/structure>:
: A file or directory in the path name does not exist.

However, as you can see, this crashes on the rocks. I think what's happening here is that the find command is storing a list of directories up front, and then traversring the tree, running rmdir first (which fails for all parent directories, since they're not empty) followed by cd to the sub-directory (which fails for the very last child directory). I'm not sure of this, but I'd be interested in your comments.

So, if we were to hard-code this in script form, it would look something like this:
directory_list=". ./long ./long/directory ./long/directory/structure"
for eachdir in $(echo $directory_list)
do
rmdir $eachdir
cd $eachdir
done

The rmdir fails most of the time with the error:
rmdir: 0653-611 Directory [directory name] is not empty

and then does the cd

It gets to remove the bottom directory, since it is empty, and then attempts to cd into it, which produces the error:

find: 0652-081 cannot change directory to </a/very/long/directory/structure>:
: A file or directory in the path name does not exist.

Option 4: find command with -depth and rmdir

Fortunately, the find command has an option which lets you cd first, and then do the -exec rmdir. In other words, it goes from the bottom of the directory hierarchy and then heads up the tree. The option is -depth, which as the find command documentation explains:

-depth
Always evaluates to the value True. Causes the descent of the directory hierarchy to be done so that all entries in a directory are affected before the directory itself is affected.

find . -depth -type d -exec rmdir {} \;
rmdir: 0653-610 Cannot remove current directory ..

This is pretty close to where we want to be.

You could ignore that error by redirecting STDERR to /dev/null

but that's a bit inelegant. Perhaps you could start from the directory below the one you're in.

Other options

There are many other ways of removing empty directories. Most of them involve the find command. That's a smart way, if you're careful not to find too much and remove too much.

Some run commands such ls or du, and check the results are what you'd expect from an empty directory, maybe using wc to check the word count. YUK.

Some of the solutions are more elaborate than others, and mostly involve a script. I really wish there were simply an option which let you do

rmdir -r

but only get rid of the empties.

If you still have an AIX system, you may be interested in following me on Twitter. That's https://twitter.com/#!/AIXDownUnder

List file systems in a volume group: lsvgfs

AnthonyEnglish Marcações: systems list aix awk paste cut volumes lvm lsvgfs putty logical edit lv file ‎ 1 Comentário ‎ 61.611 Visualizações

If you've ever needed to list the file systems in a volume group, you've probably done something like this:

lsvg -l rootvg | awk '{ print $NF }'

You would then need to strip out the header line and any logical volumes not associated with a file system, such as jfslogs, system dumps and the boot logical volume. Well, there's a simpler way: the lsvgfs command.

The syntax is very simple, as the man page for lsvgfs explains:

Understanding AIX levels

AnthonyEnglish Marcações: sp tl release commit upgrade aix migration technology_level fileset reject service_pack oslevel apply patch update ‎ 60.818 Visualizações

What do all those numbers mean on oslevel -s?

If you're looking for some guidance on understanding exactly what level of AIX you're running, you may like to read my article in the IBM Systems Magazine on Understanding AIX versions. It answers questions such as:

What's a TL?
What's a Service Pack?
When you run oslevel -s, what do all the numbers mean?
Should you run a migration or a smitty update_all?
What's the difference between applying and committing updates?
Why does my oslevel go backwards after installing new software?

Here's an extract:

If your system is running AIX 5.3 TL 6 or anything later, “oslevel -s” will look something like this: 6100-02-06-0943. Breaking that down, the first four numbers show the AIX base level. In this example, it’s 6100, which means we’re running AIX 6.1. Next is the Technology Level (TL), followed by the number of the Service Pack (SP).The last four digits show the release date of the Service Pack using the format YYWW (YY for the year, then WW for the week of the year). So, if your “oslevel -s” command reports 6100-02-06-0943, then you know you’re on AIX 6.1, running TL 2, with SP 6. The “0943” tells you that Service Pack came out in week 43 of 2009. It’s time to update your system.

"oslevel -s" examples

Or, if you like, you can read the full article on Understanding AIX versions.

UPDATED: Migration to AIX 7.1 in 35 minutes

AnthonyEnglish Marcações: vios virtual_media installation upgrade file_backed power aix download vmlibrary migration vio_server iso ‎ 5 Comentários ‎ 49.760 Visualizações

Virtually converted to AIX 7

I just did my first migration of an LPAR to AIX 7.1. I chose to migrate my AIX 6.1 NIM server.

I first downloaded AIX 7.1 from the Entitled Software Support web site.

I copied the two ISO images to the Virtual Media Library on the VIO server, and I broadly followed the procedure outlined by my compatriot Chris Gibson in his article AIX Migration with File-Backed VIOS Devices. I gave the two ISO images shorter names when I copied them into /var/vio/VMLibrary. You can also rename them using the VIO server mkvopt or chvopt commands.

The fine print

All up, the migration took about 35 minutes from the SMS menus to the login prompt following the reboot. I migrated from AIX 6.1 on a virtualised LPAR (no dedicated physical adapters) and there were 555 filesets to install. Most of my time was spent speed reading copyright notices.

Hardware requirements

Given my reluctance to open data centre doors, and the fact that it's spring in Sydney so I didn't bring my winter woollies with me, I decided to do it all from the comfort of my desk.

Here is the list of hardware I was in physical contact with:

a keyboard
a mouse
a chair
a coffee cup

df shows free space (see update below)
After the reboot, I noticed a small but significant change to the df command in AIX 7. It now displays free space by default, without using the -I flag. I still like to have the sizes in Gigabytes, so I used df -g

# df -g
Filesystem    GB blocks      Free %Used    Iused %Iused Mounted on
/dev/hd4           0.38      0.17   55%    10177    18% /
/dev/hd2           2.00      0.32   84%    41293    30% /usr
/dev/hd9var        0.56      0.22   62%    12238    17% /var
/dev/hd3           1.06      1.06    1%       69     1% /tmp
/dev/hd1           0.06      0.06    1%       13     1% /home
/dev/hd11admin      0.12      0.12    1%        5     1% /admin
/proc                 -         -    -         -     - /proc
/dev/hd10opt       4.94      1.34   73%    98194    20% /opt
/dev/livedump      0.25      0.25    1%        4     1% /var/adm/ras/livedump
/dev/fslv01        0.12      0.04   65%       13     1% /tftpboot
/dev/eznim        16.00      5.74   65%    64201     5% /export/eznim

Update:

The default output of the df command hasn't changed from AIX 6 to AIX 7. It just took me to do a migration to notice!

AIX 7 migration - a positive experience

It was a very straightforward migration with no surprises, apart from some warnings about missing filesets to do with virtual devices. I ignored them and they went away (the warnings, not the devices).

I am tempted to use the VM Library rather than NIM for the other LPARs I have to do, as most of the LPARs are on the one physical server and are clients of the same VIO server.

Installing AIX 7.1 was a very positive experience.

From my desk in the remote antipodes, I'm reaping the benefits of virtualisation on IBM Power Systems. Looks to me that IBM has done a great job with AIX 7.1.

Remove a single failed path (without spitting the dummy)

AnthonyEnglish Marcações: pdev parent device rmpath lspath cfgmgr vios aix cfgdev dev connection odm ‎ 1 Comentário ‎ 48.139 Visualizações

I noticed that the VIO server (VIOS) error log was reporting some failed paths for LUNs connecting to the SAN. The VIOS command errlog -ls (the equivalent of the AIX command errpt -a) showed errors on the Fibre Channel adapter fscsi2:

Diagnostic Analysis
Diagnostic Log sequence number: 1126130
Resource tested: fscsi2
Menu Number: 2603902
Description:

Error Log Analysis has detected multiple communication
errors. These errors can be caused by attached devices,
a switch, a hub, or a SCSI-to-FC convertor.

If connected to a switch, refer to the Storage Area
Network (SAN) problem determination procedures for
additional problem resolution.

Multiple path Redundancy

Each LUN that had a failed path still had other paths on this VIOS functioning correctly. In addition, each of the LUNs is presented to the VIO client via MPIO through this and another VIO server. That makes for a lot of redundancy, which gave us some breathing space to sort out the real cause of one of the many paths being lost. In the meantime, it's quite easy to remove the failing path on the VIOS using the rmpath command.

View paths for a LUN

First, I used the VIOS lspath command from the VIOS restricted shell to look at a single PV. This showed that there were multiple paths from the VIOS through to the SAN (in this case going to SVC).

lspath -dev hdisk63

Or via the AIX shell after logging in to the VIOS as padmin and running oem_setup_env:

lspath -l hdisk63

Whichever version of the lspath command you use, here's the output showing several paths for the same disk.

status name parent connection

Enabled hdisk63 fscsi0 500507680110239f,3d000000000000 < Four
Enabled hdisk63 fscsi0 50050768014025bd,3d000000000000 < paths
Enabled hdisk63 fscsi0 50050768011025bd,3d000000000000 < via
Enabled hdisk63 fscsi0 500507680140239f,3d000000000000 < fscsi0
Enabled hdisk63 fscsi1 500507680130239f,3d000000000000 < Another
Enabled hdisk63 fscsi1 500507680120239f,3d000000000000 < four
Enabled hdisk63 fscsi1 50050768013025bd,3d000000000000 < from
Enabled hdisk63 fscsi1 50050768012025bd,3d000000000000 < fscsi1
Enabled hdisk63 fscsi2 500507680110239f,3d000000000000 < Three good paths on fscsi2
Failed hdisk63 fscsi2 50050768014025bd,3d000000000000 <--- This failed path needs to be removed or recovered
Enabled hdisk63 fscsi2 50050768011025bd,3d000000000000 < Three good paths on fscsi2
Enabled hdisk63 fscsi2 500507680140239f,3d000000000000 < Three good paths on fscsi2

Option 1: Sledgehammer special

Removing all the paths for hdisk63 via fscsi2 would work, but it would remove the successful paths to fscsi2 at the same time. A bit drastic, but let's face it, sledgehammers had to be invented for a reason. Anyway, as there are several other paths to the same LUN - four via fscsi0 and another four via fscsi1, removing three good paths from fscsi2, as well as the one that has failed isn't really a problem. After all four fscsi2 paths are exterminated, you can rediscover the three good paths using the VIOS cfgdev command or the AIX command cfgmgr.

Here are the steps I took to remove all four paths for fscsi2 from hdisk63:

rmpath -dev hdisk63 -fscsi2

lspath -dev hdisk63
status name parent connection

Enabled hdisk63 fscsi0 500507680110239f,3d000000000000
Enabled hdisk63 fscsi0 50050768014025bd,3d000000000000
Enabled hdisk63 fscsi0 50050768011025bd,3d000000000000
Enabled hdisk63 fscsi0 500507680140239f,3d000000000000
Enabled hdisk63 fscsi1 500507680130239f,3d000000000000
Enabled hdisk63 fscsi1 500507680120239f,3d000000000000
Enabled hdisk63 fscsi1 50050768013025bd,3d000000000000
Enabled hdisk63 fscsi1 50050768012025bd,3d000000000000
Defined hdisk63 fscsi2 500507680110239f,3d000000000000
Defined hdisk63 fscsi2 50050768014025bd,3d000000000000
Defined hdisk63 fscsi2 50050768011025bd,3d000000000000
Defined hdisk63 fscsi2 500507680140239f,3d000000000000

Aussie Cultural Lesson

Here's a little aside for the benefit of readers not overly familiar with Australian slang. A "dummy" is a pacifier / comforter sometimes given to babies to, well, pacify them. On occasion some babies have been known to expunge the said dummy with speed and skill of Olympian standards.

Well, the rmpath command didn't actually remove the paths. It kept them Defined in the ODM. When I ran cfgdev (or cfgmgr), the command spat the dummy.

Some error messages may contain invalid information
for the Virtual I/O Server environment.

Method error (/usr/lib/methods/cfgscsidisk -l hdisk63 ):
0514-082 The requested function could only be performed for some
of the specified paths.

At this point, lspath shows that the three good paths have recovered, but the failed path is still Defined and the cause of the above error.

lspath -dev hdisk63
status name parent connection

Enabled hdisk63 fscsi0 500507680110239f,3d000000000000
Enabled hdisk63 fscsi0 50050768014025bd,3d000000000000
Enabled hdisk63 fscsi0 50050768011025bd,3d000000000000
Enabled hdisk63 fscsi0 500507680140239f,3d000000000000
Enabled hdisk63 fscsi1 500507680130239f,3d000000000000
Enabled hdisk63 fscsi1 500507680120239f,3d000000000000
Enabled hdisk63 fscsi1 50050768013025bd,3d000000000000
Enabled hdisk63 fscsi1 50050768012025bd,3d000000000000
Enabled hdisk63 fscsi2 500507680110239f,3d000000000000
Defined hdisk63 fscsi2 50050768014025bd,3d000000000000
Enabled hdisk63 fscsi2 50050768011025bd,3d000000000000
Enabled hdisk63 fscsi2 500507680140239f,3d000000000000

Option 2: Search and destroy

We would have been better to remove the fscsi2 paths from the ODM altogether, using the rmpath command with the -rm flag. This is similar to the -d flag on the rmdev command, as it deletes the references from the ODM.

rmpath -dev hdisk63 -pdev fscsi2 -rm
paths Deleted

Now all the paths via fscsi2 for this hdisk are gone:

lspath -dev hdisk63
status name parent connection

Enabled hdisk63 fscsi0 500507680110239f,3d000000000000
Enabled hdisk63 fscsi0 50050768014025bd,3d000000000000
Enabled hdisk63 fscsi0 50050768011025bd,3d000000000000
Enabled hdisk63 fscsi0 500507680140239f,3d000000000000
Enabled hdisk63 fscsi1 500507680130239f,3d000000000000
Enabled hdisk63 fscsi1 500507680120239f,3d000000000000
Enabled hdisk63 fscsi1 50050768013025bd,3d000000000000
Enabled hdisk63 fscsi1 50050768012025bd,3d000000000000

Then when you rediscoveri the paths via cfgdev / cfgmgr it only brings back the three good ones. No error message on cfgdev this time:

cfgdev
lspath -dev hdisk63
status name parent connection

Enabled hdisk63 fscsi0 500507680110239f,3d000000000000
Enabled hdisk63 fscsi0 50050768014025bd,3d000000000000
Enabled hdisk63 fscsi0 50050768011025bd,3d000000000000
Enabled hdisk63 fscsi0 500507680140239f,3d000000000000
Enabled hdisk63 fscsi1 500507680130239f,3d000000000000
Enabled hdisk63 fscsi1 500507680120239f,3d000000000000
Enabled hdisk63 fscsi1 50050768013025bd,3d000000000000
Enabled hdisk63 fscsi1 50050768012025bd,3d000000000000
Enabled hdisk63 fscsi2 500507680110239f,3d000000000000
Enabled hdisk63 fscsi2 50050768011025bd,3d000000000000
Enabled hdisk63 fscsi2 500507680140239f,3d000000000000

Option 3: Can you be more specific?

A better solution would be to remove just the bad path. As hdisk63 is already fixed, let's do it on a different LUN which also has a bad path:

lspath -dev hdisk54
status name parent connection

Enabled hdisk54 fscsi0 500507680110239f,34000000000000
Enabled hdisk54 fscsi0 50050768014025bd,34000000000000
Enabled hdisk54 fscsi0 50050768011025bd,34000000000000
Enabled hdisk54 fscsi0 500507680140239f,34000000000000
Enabled hdisk54 fscsi1 500507680130239f,34000000000000
Enabled hdisk54 fscsi1 500507680120239f,34000000000000
Enabled hdisk54 fscsi1 50050768013025bd,34000000000000
Enabled hdisk54 fscsi1 50050768012025bd,34000000000000
Enabled hdisk54 fscsi2 500507680110239f,34000000000000
Failed hdisk54 fscsi2 50050768014025bd,34000000000000
Enabled hdisk54 fscsi2 50050768011025bd,34000000000000
Enabled hdisk54 fscsi2 500507680140239f,34000000000000

The rmpath command allows you to narrow the path you want to remove down to a single connection. Here's an extract from the command documentation for the VIOS rmpath command:

rmpath command
Purpose

Removes from the system a path to an MPIO-capable device.
Syntax
rmpath { [ -dev Name ] [ -pdev Parent ] [ -conn Connection ] } [ -rm ]

Once again, I'll use the -rm flag to remove the path from the ODM. Otherwise it would simply go from Available to Defined and still report a problem when running cfgmgr. But this time, I can narrow the path down to a single connection using the -conn flag:

rmpath -dev hdisk54 -pdev fscsi2 -conn "50050768014025bd,34000000000000" -rm

path Deleted
lspath -dev hdisk54
status name parent connection

Enabled hdisk54 fscsi0 500507680110239f,34000000000000
Enabled hdisk54 fscsi0 50050768014025bd,34000000000000
Enabled hdisk54 fscsi0 50050768011025bd,34000000000000
Enabled hdisk54 fscsi0 500507680140239f,34000000000000
Enabled hdisk54 fscsi1 500507680130239f,34000000000000
Enabled hdisk54 fscsi1 500507680120239f,34000000000000
Enabled hdisk54 fscsi1 50050768013025bd,34000000000000
Enabled hdisk54 fscsi1 50050768012025bd,34000000000000
Enabled hdisk54 fscsi2 500507680110239f,34000000000000
Enabled hdisk54 fscsi2 50050768011025bd,34000000000000
Enabled hdisk54 fscsi2 500507680140239f,34000000000000

It seems smarter not to throw out the good paths with the bad one and then repair the damage.

Looking for failure

The lspath command allows you to list paths by their status. This allows you to list all of the failed paths.

lspath -status failed
status    name    parent connection

~~Available ses1    sas0   a00,0~~   < What are these guys
~~Available ses2    sas0   20a00,0~~ < doing here?
Failed    hdisk3 fscsi2 50050768014025bd,1000000000000 < This line is where we want to start
Failed    hdisk4 fscsi2 50050768014025bd,2000000000000
Failed    hdisk6 fscsi2 50050768014025bd,19000000000000
Failed    hdisk7 fscsi2 50050768014025bd,1a000000000000
Failed    hdisk8 fscsi2 50050768014025bd,1b000000000000
Failed    hdisk9 fscsi2 50050768014025bd,1c000000000000
Failed    hdisk10 fscsi2 50050768014025bd,1d000000000000
Failed    hdisk11 fscsi2 50050768014025bd,e000000000000
Failed    hdisk12 fscsi2 50050768014025bd,23000000000000
Failed    hdisk13 fscsi2 50050768014025bd,24000000000000
Failed    hdisk16 fscsi2 50050768014025bd,5000000000000
Failed    hdisk17 fscsi2 50050768014025bd,6000000000000
Failed    hdisk18 fscsi2 50050768014025bd,7000000000000
Failed    hdisk20 fscsi2 50050768014025bd,9000000000000
Failed    hdisk22 fscsi2 50050768014025bd,b000000000000
Failed    hdisk32 fscsi2 50050768014025bd,16000000000000
Failed    hdisk21 fscsi2 50050768014025bd,a000000000000
Failed    hdisk25 fscsi2 50050768014025bd,f000000000000
Failed    hdisk26 fscsi2 50050768014025bd,10000000000000
Failed    hdisk27 fscsi2 50050768014025bd,11000000000000
Failed    hdisk28 fscsi2 50050768014025bd,12000000000000
Failed    hdisk29 fscsi2 50050768014025bd,13000000000000
Failed    hdisk33 fscsi2 50050768014025bd,17000000000000
Failed    hdisk34 fscsi2 50050768014025bd,18000000000000
Failed    hdisk35 fscsi2 50050768014025bd,1e000000000000
Failed    hdisk36 fscsi2 50050768014025bd,1f000000000000
Failed    hdisk37 fscsi2 50050768014025bd,20000000000000
Failed    hdisk38 fscsi2 50050768014025bd,21000000000000
Failed    hdisk39 fscsi2 50050768014025bd,22000000000000
Failed    hdisk40 fscsi2 50050768014025bd,26000000000000
Failed    hdisk41 fscsi2 50050768014025bd,27000000000000
Failed    hdisk42 fscsi2 50050768014025bd,28000000000000
Failed    hdisk43 fscsi2 50050768014025bd,29000000000000
Failed    hdisk44 fscsi2 50050768014025bd,2a000000000000
Failed    hdisk47 fscsi2 50050768014025bd,2d000000000000
Failed    hdisk48 fscsi2 50050768014025bd,2e000000000000
Failed    hdisk49 fscsi2 50050768014025bd,2f000000000000
Failed    hdisk50 fscsi2 50050768014025bd,30000000000000
Failed    hdisk51 fscsi2 50050768014025bd,31000000000000
Failed    hdisk5 fscsi2 50050768014025bd,3000000000000
Failed    hdisk45 fscsi2 50050768014025bd,2b000000000000
Failed    hdisk52 fscsi2 50050768014025bd,32000000000000
Failed    hdisk53 fscsi2 50050768014025bd,33000000000000
Failed    hdisk19 fscsi2 50050768014025bd,8000000000000
Failed    hdisk61 fscsi2 50050768014025bd,3b000000000000
Failed    hdisk64 fscsi2 50050768014025bd,3e000000000000
Failed    hdisk65 fscsi2 50050768014025bd,3f000000000000
Failed    hdisk66 fscsi2 50050768014025bd,40000000000000
Failed    hdisk67 fscsi2 50050768014025bd,41000000000000
Failed    hdisk68 fscsi2 50050768014025bd,42000000000000
Failed    hdisk70 fscsi2 50050768014025bd,44000000000000

It's easy enough to script this now:

lspath -status failed | grep Failed | while read status hdisk parent connection
do
rmpath -dev $hdisk -pdev $parent -conn $connection -rm
done

In this post we've looked at

VIOS commands lspath, rmpath, errlog, cfgdev
AIX commands lspath, rmpath, errpt, cfgmgr
spitting the dummy

I hope you feel you've got your money's worth.

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

AnthonyEnglish Marcações: disk growth chvg aix resize spare volume_group backend lun 7.1 extendlv 5.3 6.1 rootvg san ‎ 13 Comentários ‎ 45.347 Visualizações

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 -s to 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.

Sizing up your file system space (and your worth)

AnthonyEnglish Marcações: system decrease jfs2 disk nanoseconds guru chfs gigabyte lv space logical_volume increase aix jfs precious block_size file ‎ 8 Comentários ‎ 44.916 Visualizações

YOUR TIME IS PRECIOUS!

When you need to increase a file system, you can use our old friend smitty. But stepping through the SMIT menus could take a good 3 seconds (at least!) And as a good AIX guru, your time is precious. In a perfect world AIX gurus like you should

charge your time by the nanosecond!

(Just go tell your boss that the bloke who writes AIX Down Under said so.)

Alas, the world is not perfect, as you may have discovered after that friendly chat with the boss. Even so, you can save a few seconds when you have to increase a file system. Here's how:

Use the command line
Specify the size to increase in Gigabytes (or MB or KB)

Working examples

When you use the chfs command, you can specify the new size in blocks.

Option 1: Specify new size of file system in blocks

chfs -a size=54132736 /oracle/staging

This, of course requires you to do a calculation or a guestimate of how many blocks the file system should be.

Or you could do that using the much easier G (for GB), M (MB) or K (KB) - at least on recent releases of AIX. Note that these three abbreviations are in upper case.

Option 2: Specify new size of file system in Gigabytes

chfs -a size=24G /oracle/staging

That's easier, isn't it?

Or even easier, you can specify the amount to increase using the += (plus equals) followed by the amount in Gigabytes / Megabytes / Kilobytes.

Option 3: Specify amount to increase file system in Gigabytes

chfs -a size=+4G /oracle/staging

Update: this originally showed the command operators as += instead of =+ , but as a kind reader has commented, the original syntax I had was incorrect.

This increases the file system by 4 GB.

You can reduce it - provided you have sufficient working space - using the -= (minus equals)

Option 4: Reduce file system by 500 Megabytes

chfs -a size=-500M /oracle/staging

Update: this originally showed the command operators as += instead of =-

Space and time

When you increase a file system, you'll need to have enough disk space on the logical volume on which the file system sits. That may mean expanding an existing LUN or adding a new one, or maybe increasing virtual disk supplied via the VIO server. In fact, come to think of it, there are few things you need to think about when you increase file system space.

You may also need to increase the maximum size of the logical volume that the file system is associated with. You can use the chlv command with the -x flag from the command line.

Or, you could just use SMIT. Sure, it will take a few seconds more, but you've got the time, haven't you?

Just ask your boss.

Modificado em por AnthonyEnglish

UPDATED: Long user names in AIX

AnthonyEnglish Marcações: long login names user max_logname find cut aix permission login_name_max paste truncate chown putty tar who ‎ 3 Comentários ‎ 43.517 Visualizações

User names on AIX used to be restricted to eight characters. That's still the default setting but since AIX 5.3 you can increase the length up to an amazing 256 characters, if users really want to spend the morning logging in.

You can view the current maximum login name using:

lsattr –El sys0 | grep max_logname

Update: I incorrectly had listed the parameter as max_login. The correct parameter is max_logname. Thanks to jabber44 for the correction.

or via smit

System Environments -> Change / Show Characteristics of Operating System

then arrow down to the next page to see:

Maximum login name length at boot time [9] +#

You can change this setting here, or using the chdev command on the command line:

chdev -l sys0 -a max_logname=N

(Corrected here as well).

Whichever way you change it, it will only take effect from next time you reboot the OS.

Note from a kind reader: the value returned by max_logname appears to be an "x+1", so to allow 9 character usernames. set value to 10 or greater (and reboot).

The long and the short of user names

Why would you do this? Primarily to have user names consistent with network logins, such as when you use Kerberos to authenticate against Active Directory.

When you list files using the command ls -l, by default you only see the first eight characters of the owner's user name.

-rw------- 1 a_long_u system 0 May 13 09:53 file1

This can be misleading.

If you try to change ownership of a file via chown using that truncated name, you'll get a message that the user doesn't exist. So the ls command needs to be able to display the full name, which you can do using the -X flag:

ls -Xl

-rw------- 1 a_long_username system 0 May 13 09:53 file1

There are other commands which require special options to display user names longer than 8 characters, such as

find (use -long)

tar which uses -E (-X is already used for something else)

and

who (-X again, just like the ls command)

Extravagance and inelegance

A couple of warnings. If you decide to revert to short names again, you may lock out users who had more extravagant login names before the reboot. It would not be an easy task to identify all the files which were owned by users with long names.

The other point to note is that long lists of files may result in the jagged-edge effect, which is exactly the reason those of us with a sense of symmetry keep logical volume names under 9 characters. If that's not reason enough, it can also make it hard to use that selection of a rectangle in Putty which I mentioned at the end of my blog entry on how to list file systems in a volume group.

Modificado em por AnthonyEnglish

Feed para Entradas de Blog Feed para Comentários de Blog

Blogs

AIX Down Under

▼ Marcações

▼ Blogs Semelhantes

Chris's AIX B...

Asset Managem...

Application P...

Application I...

AIXpert Blog

▼ Blogs de Ideias Semelhantes

IBM PureData-...

IBM Forms Exp...

Rational Soft...

IBM Tunisia H...

主机知刊

▼ Archive

▼ Links

▼ Autores do Blog

AIX Down Under

Show disk size with getconf DISK_SIZE /dev/hdisk0

UPDATED: Load ISO images via VIO server and AIX

How to remove empty directories (rmdir -r?)

List file systems in a volume group: lsvgfs

Syntax

Description

Parameters

Examples

Understanding AIX levels

UPDATED: Migration to AIX 7.1 in 35 minutes

Remove a single failed path (without spitting the dummy)

rmpath command

Purpose

Syntax

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

Sizing up your file system space (and your worth)

UPDATED: Long user names in AIX