Need to update the running attributes of a virtual SCSI adapter on
an AIX system? Try these steps.

I want to change value for the vscsi_err_recov attribute
to fast_fail.
I can’t do this if the adapter is busy i.e. has open/available paths to a disk device.

#
lsattr -El vscsi2

vscsi_err_recov
delayed_fail
N/A
True

vscsi_path_to
0 Virtual
SCSI Path Timeout True

#
chdev -l vscsi2 -a vscsi_err_recov=fast_fail

Method
error (/usr/lib/methods/chggen):

0514-029 Cannot perform the requested function because a

child device of the specified device is not in a correct state.

I have two paths to my disk devices. This will allow me to take
one path offline while I change the attributes of the adapter.

#
lspath | grep vscsi2

Enabled
hdisk4 vscsi2

Enabled
hdisk5 vscsi2

#
rmpath -l hdisk4 -p vscsi2

path
Defined

#
rmpath -l hdisk5 -p vscsi2

path
Defined

#
lspath | grep vscsi2

Defined
hdisk4 vscsi2

Defined
hdisk5 vscsi2

With the path offline, I can now change the attributes of the
device and then bring the path online again.

#
chdev -l vscsi2 -a vscsi_err_recov=fast_fail

vscsi2
changed

#
lsattr -El vscsi2 -a vscsi_err_recov

vscsi_err_recov
fast_fail N/A True

#
cfgmgr<
Bring the path online.

#
lspath | grep vscsi2

Enabled
hdisk4 vscsi2

Enabled
hdisk5 vscsi2

Now I can do the same for the other VSCSI adapter.

#
lsattr -El vscsi3 -a vscsi_err_recov

vscsi_err_recov
delayed_fail N/A True

#
chdev -l vscsi3 -a vscsi_err_recov=fast_fail

Method
error (/usr/lib/methods/chggen):

0514-029 Cannot perform the requested function because a

child device of the specified device is not in a correct state.

#
lspath | grep vscsi3

Enabled
hdisk4 vscsi3

Enabled
hdisk5 vscsi3

#
rmpath -l hdisk4 -p vscsi3

path
Defined

#
rmpath -l hdisk5 -p vscsi3

path
Defined

#
lspath | grep vscsi3

Defined
hdisk4 vscsi3

Defined
hdisk5 vscsi3

#
chdev -l vscsi3 -a vscsi_err_recov=fast_fail

vscsi3
changed

#
lsattr -El vscsi3 -a vscsi_err_recov

vscsi_err_recov
fast_fail N/A True

#
cfgmgr

# lspath
| grep vscsi3

Enabled
hdisk4 vscsi3

Enabled
hdisk5 vscsi3

All paths are available again and the adapters have been updated.
All of this was done without taking an outage.

#
lspath

Enabled
hdisk4 vscsi2

Enabled
hdisk4 vscsi3

Enabled
hdisk5 vscsi2

Enabled
hdisk5 vscsi3

#
lsattr -El vscsi2 -a vscsi_err_recov

vscsi_err_recov
fast_fail N/A True

# lsattr
-El vscsi3 -a vscsi_err_recov

vscsi_err_recov
fast_fail N/A True

If I’d chosen not to take the paths offline, one at a time, I
would have needed to change the adapters attributes by specifying the –P flag
with the chdev command. Then I would need to reboot the system.

-P

Changes
the device's characteristics permanently in the Customized Devices object class
without actually changing the device. This is useful for devices that cannot
be made unavailable and cannot be changed while in the available state. The
change is made to the database, and the changes are applied to the device when
the system is rebooted. This flag cannot be used with the -T flag. Not all
devices support the -P flag.

OK, so I had
a NIM master with two network interfaces, en0 and en1. The en0 interface was connected
to the 192.168.10.0 network and the en1 interface was connected to the 10.1.1.0 network. When the
master was initially configured, we chose en0 as the primary install interface.
The master could now install NIM clients on the 192.168.10.0 network, without
any additional NIM network configuration.

There was
a single NIM network definition for the 192.168.10.0 network (net_192_168_10) in the NIM database.

root@nim1 /
# lsnim -c networks

net_192_168_10 networksent

Sure
enough, the time came when we needed to install NIM clients on the 10.1.1.0
network. Rather than adding NIM routes, we chose to configure the NIM master
with an additional install interface on the 10.1.1.0 network. Fortunately, the
NIM master was already “directly” connected to the 10.1.1.0 network on its en1
interface. So all we had to do was update the NIM configuration.

First we
added a new entry in the /etc/hosts file for the NIM master’s 10.1.1.0 network
address. The hostname for this interface was nim1i.

root@nim1 /
# grep nim1 /etc/hosts

192.168.10.10nim1

10.1.1.10 nim1i

root@nim1 / #
host nim1i

nim1i is 10.1.1.10

Next we
defined a new network install interface for the NIM master via the smit
fastpath, ‘smit nim_mac_if’.

We entered
the hostname of the NIM master on the 10.1.1.0 network i.e. nim1i.

Define a Network Install Interface

Type or
select a value for the entry field.

Press Enter
AFTER making all desired changes.

[Entry Fields]

* Host Name
of Network Install Interface[nim1i]

We named
the new NIM network, net_10_1_1 and entered the appropriate subnet mask for
this network. We did not enter a default gateway for the client or the NIM
master (it is unnecessary, as the master is “directly” connected to this
network).

Define a Network Install Interface

Type or
select values in entry fields.

Press Enter
AFTER making all desired changes.

[Entry Fields]

* Machine
Namemaster

Network Install Interface

*Cable TypeN/A+

Network Speed Setting[]+

Network Duplex Setting[]+

*NIM Network[net_10_1_1]

*Network Typeent

*Ethernet TypeStandard+

*Subnetmask[255.255.255.0]

Default Gateway Used by Machine[]

Default Gateway Used by Master[]

*Host Namenim1i

Network Adapter Hardware Address[0]

Network Adapter Logical Device Name[]

There were
now two network definitions in our NIM database. The Nstate attribute was set to ‘ready
for use’, so our definition was OK to use.

root@nim1 /
# lsnim -c networks

net_192_!68_10networksent

net_10_1_1networksent

root@nim1 /
# lsnim -l net_10_1_1

net_10_1_1:

class= networks

type= ent

comments= Generated during definition of nim1i

Nstate= ready for use

prev_state = information is missing from
this object's definition

net_addr= 10.1.1.0

snm= 255.255.255.0

The NIM
master has two network interfaces defined.

root@nim1 /
# lsnim -l master | grep if

if_defined= chrp.64.ent

if1= net_192_168_10 nim1 0

if2= net_10_1_1
nim1i 0

Now we
could install new NIM clients using this network. We verified this by adding a
new NIM client to the NIM database.

# smit
nim_mkmac

Define a Machine

Type or
select a value for the entry field.

Press Enter
AFTER making all desired changes.

[Entry Fields]

* Host Name
of Machine[lpar22i]

(Primary Network Install Interface)

After
pressing enter on the previous smit panel, we were immediately presented with a
panel to modify the attributes of the NIM client and (more importantly) the
correct network and hostname were automatically selected as part of the clients
definition.

Define a Machine

Type or
select values in entry fields.

Press Enter
AFTER making all desired changes.

[Entry Fields]

* NIM
Machine Name[lpar22]

* Machine
Type[standalone]+

* Hardware
Platform Type[chrp]+

Kernel to use for Network Boot[64]+

Communication Protocol used by client[nimsh]+

Primary Network Install Interface

*Cable TypeN/A+

Network Speed Setting[]+

Network Duplex Setting[]+

*NIM Networknet_10_1_1

*Host Namelpar22i

Network Adapter Hardware Address[0]

Network Adapter Logical Device Name[]

IPL ROM Emulation Device[]+/

CPU Id[]

Machine Group[]+

Managing System Information

WPAR Options

Managing System[]

-OR-

LPAR Options

Identity[]

Management Source[]+

Comments[]

If we had
configured NIM incorrectly i.e. it was not aware of the 10.1.1.0 network, then
we would have been prompted for network information before we could configure
the NIM client (as shown below).

I don’t know if there are any plans to fix this but I wanted to
share this information in case anyone else encounters this issue. iSCSI is not
all that popular on AIX systems (perhaps this is a good thing?), so it may not
impact enough people to warrant a quick fix.

You are receiving that mail because we have been either in touch in regards
of LPA2RRD tool about year ago or you are on LPAR2RRD mailing list.

I’ve decided to make professional paid support of LPAR2RRD.
Here are my reasons which led me to that thought:
- I have not touched the source code for nearly 1.5 year (looks like the
last version is quite stable :) ). No time at all and lack of motivation...
- Only what I trying to keep is support of the tool, but my response times
are not what I am proud of
- the tool itself would need big time investment to implement new
functionalities, rewrite the web face (would need to hire a web designer
for that) etc.

Only the solution what I see how to keep continuity and do not let project
slowly died is paid support.
Basically I feel that as the last chance for any further development or
support from my side.
I simply cannot manage to do everything I actually do around and still work
on LPAR2RRD.
If I would get some money from the project then I will be able to
prioritize my other activities in favour of LPAR2RRD development and
support.

From that reason I’ve created new LPAR2RRD home here:http://www.lpar2rrd.com
I am about to found a company which would be responsible for support. Based
on your feedback I will decide go or no-go.
I could even imagine working on LPAR2RRD full time in case of enough
support subscribers.

I do not intend to force you ordering support. If you are happy with the
actual version, you have no issues etc ... that this makes me also happy.
Make people happy was the main reason why I spent my free time by
developing of the tool since 2006. I do not regret that at all! It was fun.