Renaming devices in AIX 7.1I remember reading this interesting document about some challenges renaming AIX devices.
http
This poor guy had to jump through some hoops to rename some disk and network devices in a clustered AIX (Oracle RAC) environment.
This comment stayed with me:
“The easy way to get network adapters and disk names to match between systems would be to run something like
# chdev –l old_name –n new_name
Except, this command option does NOT exist.”
Since then I’ve always been on the “look out” for an easy way to rename devices in AIX.
In particular in large clustered environments where it is sometimes very important to have the same disk and network device names in sync across all nodes in a cluster. And besides, it’s a lot easier to verify a cluster configuration if the hdisk names are all the same. Matching PVIDs works but it requires a lot more effort! For example, knowing that hdisk123 is the same device on all nodes makes life easier than scanning lspv output for a PVID like 00f6048868b4gead. Of course you can script things to make this easier but it would be great if you didn’t need to do this and that there was a way to rename devices as needed, without resorting to unsupported methods.
Well, this is no longer an issue for AIX.
Starting with AIX 7.1, you can now easily rename devices. A new command called rendev was introduced to allow AIX administrators to rename devices as required.
From the man page:
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.
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.
This functionality was required to help simplify cluster device configuration with the new Cluster Aware AIX (CAA) feature in AIX 7.1.
I’ll be blogging about CAA in a future post.
Here are some examples of using the rendev command on AIX 7.1 (GA) system. In the first example I will rename hdisk3 to hdisk300. Note: hdisk3 is not in use (busy). If the disk had been allocated to a volume group, I would have needed to varyoff the volume group first.
# lspv hdisk0
00f6 hdisk1
00f6 hdisk2
00f6 hdisk4
00f6 hdisk3 00f6
# rendev -l hdisk3 -n hdisk300
# lspv hdisk0
00f6 hdisk1
00f6 hdisk2
00f6 hdisk4
00f6 hdisk300 00f6
Easy!
Next, I’ll rename a virtual SCSI adapter. I renamed vscsi0 to vscsi2. Note: I placed the adapter, vscsi0, in a Defined state before renaming the device.
# rmdev -Rl vscsi0
# lsdev -Cc adapter ent0 Available Virtual I/O Ethernet Adapter (l-lan) ent1 Available Virtual I/O Ethernet Adapter (l-lan) vsa0 Available LPAR Virtual Serial Adapter vscsi0 Defined Virtual SCSI Client Adapter vscsi1 Available Virtual SCSI Client Adapter
# rendev -l vscsi0 -n vscsi2
# lsdev -Cc adapter ent0 Available Virtual I/O Ethernet Adapter (l-lan) ent1 Available Virtual I/O Ethernet Adapter (l-lan) vsa0 Available LPAR Virtual Serial Adapter vscsi1 Available Virtual SCSI Client Adapter vscsi2 Defined Virtual SCSI Client Adapter
Now I’ll rename a network adapter from ent0 to ent10. I bring down the interface before changing the device name
# lsdev -Cc adapter ent0 Available Virtual I/O Ethernet Adapter (l-lan) ent1 Available Virtual I/O Ethernet Adapter (l-lan) vsa0 Available LPAR Virtual Serial Adapter vscsi1 Available Virtual SCSI Client Adapter vscsi2 Defined Virtual SCSI Client Adapter
# ifconfig en0 en0: flag inet 10.1.20.19 netmask 0xffff0000 broadcast 10.153.255.255 tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
# ifconfig en0 down detach
# rendev -l ent0 -n ent10
# lsdev -Cc adapter ent1 Available Virtual I/O Ethernet Adapter (l-lan) ent10 Available Virtual I/O Ethernet Adapter (l-lan) vsa0 Available LPAR Virtual Serial Adapter vscsi1 Available Virtual SCSI Client Adapter vscsi2 Defined Virtual SCSI Client Adapter
# rendev -l en0 -n en10
# chdev -l en10 -a state=up en10 changed # mkdev -l inet0 inet0 Available # ifconfig en10 en10: flag inet 10.1.20.19 netmask 0xffff0000 broadcast 10.153.255.255 tcp_sendspace 262144 tcp_recvspace 262144 rfc1323 1
If you want to be creative you can rename devices to anything you like (as long as it’s not more than 15 characters). For example I’ll rename vscsi2 to myvscsiadapter.
# rendev -l vscsi2 -n myvscsiadapter # lsdev -Cc adapter ent1 Available Virtual I/O Ethernet Adapter (l-lan) myadapter Available Virtual I/O Ethernet Adapter (l-lan) myvscsiadapter Defined Virtual SCSI Client Adapter vsa0 Available LPAR Virtual Serial Adapter vscsi1 Available Virtual SCSI Client Adapter
And in the last example I’ll demonstrate changing virtual SCSI adapter device names on a live system.
This is single disk system (hdisk0), with two vscsi adapters.
# lspv hdisk0 00f6
# lspath Enabled hdisk0 vscsi0 Enabled hdisk0 vscsi1
# lsdev -Cc adapter ent0 Available Virtual I/O Ethernet Adapter (l-lan) ent1 Available Virtual I/O Ethernet Adapter (l-lan) vsa0 Available LPAR Virtual Serial Adapter vscsi0 Available Virtual SCSI Client Adapter vscsi1 Available Virtual SCSI Client Adapter
We ensure the adapter is in a Defined state before renaming it. This will fail otherwise.
# rmdev -Rl vscsi1 vscsi1 Defined # lsdev -Cc adapter | grep vscsi vscsi0 Available Virtual SCSI Client Adapter vscsi1 Defined Virtual SCSI Client Adapter
Now we rename the adapter vscsi1 to vscsi3.
# rendev -l vscsi1 -n vscsi3
# lsdev -Cc adapter | grep vscsi vscsi0 Available Virtual SCSI Client Adapter vscsi3 Defined Virtual SCSI Client Adapter
That was easy enough. Now I need to bring the adapter and path online with cfgmgr. The lspath output displays an additional path to vscsi3.
# lspath Enabled hdisk0 vscsi0 Defined hdisk0 vscsi1
# cfgmgr Method error (/et 0514-082 The requested function could only be performed for some of the specified paths.
# lspath Enabled hdisk0 vscsi0 Defined hdisk0 vscsi1 Enabled hdisk0 vscsi3
Now I need to remove the old path to vscsi1. The path to vscsi3 is now Enabled. The adapter, vscsi3, is in an Available state. All is good.
# rmpath -l hdisk0 -p vscsi1 -d path Deleted
# lspath Enabled hdisk0 vscsi0 Enabled hdisk0 vscsi3
# lsdev -Cc adapter | grep vscsi vscsi0 Available Virtual SCSI Client Adapter vscsi3 Available Virtual SCSI Client Adapter
The same steps need to be repeated for the vscsi0 adapter. This is renamed to vscsi2.
# rmdev -Rl vscsi0 vscsi0 Defined # lsdev -Cc adapter | grep vscsi vscsi0 Defined Virtual SCSI Client Adapter vscsi3 Available Virtual SCSI Client Adapter
# rendev -l vscsi0 -n vscsi2
# lsdev -Cc adapter | grep vscsi vscsi2 Defined Virtual SCSI Client Adapter vscsi3 Available Virtual SCSI Client Adapter
# lspath Defined hdisk0 vscsi0 Enabled hdisk0 vscsi3
# cfgmgr Method error (/et 0514-082 The requested function could only be performed for some of the specified paths.
# lspath Defined hdisk0 vscsi0 Enabled hdisk0 vscsi2 Enabled hdisk0 vscsi3
# rmpath -l hdisk0 -p vscsi0 -d path Deleted
# cfgmgr # lspath Enabled hdisk0 vscsi2 Enabled hdisk0 vscsi3
That’s it. Both adapters have been renamed while the system was in use. No downtime required.
# lsdev -Cc adapter | grep vscsi vscsi2 Available Virtual SCSI Client Adapter vscsi3 Available Virtual SCSI Client Adapter
# lspath Enabled hdisk0 vscsi2 Enabled hdisk0 vscsi3
Please refer to the AIX 7.1 command reference for more information on this new command: http
And by the way, here’s a draft of what I’ve been working on for the last 5 weeks:
IBM AIX Version 7.1 Differences Guide: http
Follow me on Twitter:
|
Hi Anthony, I think your colleague is referring to renaming (a)tape devices specifically. This procedure was for renaming tape devices (with the atape device driver installed) ONLY.https://www-304.ibm.com/support/entdocview.wss?uid=isg3T1000748
Chris, a colleague advised me of an option on the chdev command to rename devices: chdev -l rmt0 -a new_name=rmt10 I've never noticed this command before and I can't find that attribute (-a new_name) in the chdev command documentation I've looked at. Do you have any thoughts on whether this command is possible, and whether there'd be any reason to change a device name using the chdev command rather than rendev?
OK I see you another technote: https://www.ibm.com/developerworks/community/blogs/cgaix/entry/in_a_perfect_world_rootvg_would_always_reside_on_hdisk0?lang=en and so I understand the mirrorvg is only way for change name of rootvg disk:)
Hi Chris, I am wonderin is there any way for change rootvg disk name without mirroring it?. I guess the rendev command desn't support for rootvg disk and we cannot use -P flag as you know. ----------------------------------------------------- bash-3.2# lspv hdisk2 00c3dbae78134537 rootvg active bash-3.2# rendev -l hdisk2 -n hdisk0 Method error (/etc/methods/ucfgdevice): 0514-062 Cannot perform the requested function because the specified device is busy. bash-3.2# rendev -l hdisk2 -n hdisk0 -P rendev: illegal option -- P Usage: rendev -l Name [-n NewName] [-u] ----------------------------------------------------------------- Thanks.
Any word on when the rendev command will be fixed in 7.1? Just checked all the way up to TL2 SP1 and I don't see any mention of it. Thanks.
"I would have preffered a command that can change a device that is currently in use..................So I have to hope a VIOS release in the Future deals with this "issue" Couldn't agree more. One way to request this enhancement would be to contact your IBM rep and suggest a Design Change Request (DCR). Cheers. Chris
I would have preffered a command that can change a device that is currently in use. Theoretically you can remove all devices from one VIO because in a dual VIO concept nothing should go wrong. Praktically its a whole differnt story. Oracle DBs for example are very sensiteve with the IO of their control-files. We had some default mpio path switches on Oracle DBs and in 90% of the time the DB coredumped. Besides this fact it's to complicated and work intensive to remove and reconfigure all devices of our VIO LPARS. So I have to hope a VIOS release in the Future deals with this "issue". Thanks, Sebastian
"Is there a "legal" way to rename vtscsi devices in a supported way?" Well I guess one, supported, method would be to remove the device mapping and then re-map the device with the new/desired vtscsi name.
Hi We have a lot of very old VIOS server and recently we thought it might be a good idea to rename the vtscsi device to somthing like lpar_hdisk# to get a better overview. On our newer Vios I manged to use rendev as root (there is sadly no chvdev command present) to rename the device. But it feels a bit risky as someone stated above viosbr can get troubles and so on. I don't feel relly save at the moment renaming all vtscsi devices on a VIO without long term testing. Then we realized that pre AIX 6.1 vios (1.4 &1.5) not even has the rendev command... Is there a "legal" way to rename vtscsi devices in a supported way. I mean even when I do it as root on more recent VIOS versions, its not really supported because it fells like circumventing the VIO ODMs. Any idea on this? Regards Sebastian
Just a further warning for anyone thinking of creative uses for rendev :). The command's purpose and limitations should be better documented IMO. I guess the reason I try not to care about hdisk names is that before making a change I need to verify what the pvid/path/lun/size/type is for each hdisk, and the only reliable way to do that is to query the os/san array for current info so I have scripts to do all that (otherwise not much work would get done :p) Trusting hdisk device names to match seems a bit sketchy to me. My preference would be to use mknod whenever possible for stuff like RAC that requires identical device names.