Edit: This looks like the last post from 2013 based on the note below. Some links no longer work.
Originally posted December 17, 2013 on AIXchange
**Please note: This blog will be updated on January 7, 2014.**
Two weeks ago I reposted a tip from Russell Adams on displaying disk UUID. Here’s another tip that Russell submitted to a mailing list for IBMers and business partners earlier this fall. In this case he’s taken the time to update it. (Note: There are minor edits for the sake of clarity.)
In AIX 6.1 TL6 and AIX 7.1 a new command was introduced to rename devices in AIX, rendev. This makes keeping your rootvg on hdisk0 (and hdisk1) and preserving device naming consistency across VIO and HACMP nodes simple!
rendev -l device -n newname
A few caveats:
1) Renaming devices should always be done while the device is in a defined state (i.e., after “rmdev -l”); it cannot be used on active PVs in a VG or other online devices. While rendev can perform the rmdev of the device for you, it’s better to take the device offline first.
2) Renaming ethernet (entX) adapters requires either manually renaming the enX and etX adapters, or removing them. Once the entX device has been renamed, cfgmgr will create matching enX & etX devices.
3) Renaming fiber cards (fcsX) requires all that child devices be renamed manually. This includes fcsX, fscsiX, fcnetX, and sfwcommX. Use “rmdev -Rl fcsX” to unconfigure all the parent and child devices into the defined state, and then rename them. cfgmgr does not name the child devices to match.
4) I recommend using rendev for renumbering like devices (e.g., ent2 -> ent11) rather than giving devices new name prefixes (e.g., ent2 -> lan3). Renaming device paths that are used by other device drivers (e.g., Powerpath) may cause issues.
5) You can rename vhost and vfchost devices on VIOS in oem_setup_env *before* they’re mapped (not after). The devices should be manually put into a defined state first, and then can be renamed via rendev.
Example:
– New LPAR ID 5 will be mapped to VIO1 (ID 99) and VIO2 (ID 98)
– LPAR ID 5 is assigned the following virtual adapters in its profile:
– Slot 1-9 for network adapters
– Slot 51 VSCSI to VIO1 (99) slot 51
– Slot 52 VSCSI to VIO2 (98) slot 52
– Slot 53 VFC to VIO1 (99) slot 53
– Slot 54 VFC to VIO2 (98) slot 54
– VIO1 (ID 99) dynamically adds:
– Slot 51 VSCSI to LPAR ID 5 slot 51
– Slot 53 VFC to LPAR ID 5 slot 53
– VIO2 (ID 98) dynamically adds:
– Slot 52 VSCSI to LPAR ID 5 slot 52
– Slot 54 VFC to LPAR ID 5 slot 54
Then on each VIO server, for each vhost and vfchost device:
– lsdev -slots determine hardware location codes of new vhost and vfc devices
– For example, vhost12 is XXXX-V99-C51
– rmdev -l vhost12
– rendev -l vhost21 -n vhost51 (from C/slot number to match LPAR ID and slot)
– cfgmgr (or cfgdev) to activate them
When done, map normally for VSCSI or VFC.
The client LPAR and VIO slot matching numbering system has always been a good idea. Naming the devices significantly increases the readability of the virtual environment. All vhost and vfchost devices will have unique names that link them to the client LPAR.
When coupled with ‘lspv -u’ on the client LPAR and VIO servers to determine client LUN mappings via UUID without manual tracing, this significantly simplifies virtual environments and troubleshooting.
Thanks again to Russell for allowing me to repost this information.