From HMC, change password expiration
# viosvrcmd -m <Managed System Name> --id <VIOS lpar id> -c "chuser -attr maxage=0 padmin" # viosvrcmd -m <Managed System Name> --id <VIOS lpar id> -c "chuser -attr maxexpired=-1 padmin"
Common Causes of VIOS Update Failures Using Updateios Command
http://www-01.ibm.com/support/docview.wss?uid=isg3T1022699
Cisco ethernet port config
interface Ethernet2/3 description VIOS1 switchport switchport mode trunk switchport trunk allowed vlan 22,23,200 spanning-tree port type edge trunk mtu 9216 # if MTU 9000 allowed on one VLAN no shutdown
Timeout when I fallback to primary VIOS:
However, I found that, when I reconnect the 10G network after a failover test, the VIO servers can response to the change (from entstat command) within 1 or 2 seconds, but the client LPAR which using the failover VLAN will be disconnected (by ping test) and need 20 – 30 seconds to resume the connection. I also see that, even the VLAN which do not require to fallback, will also experience a short outage for about 5 – 6 seconds.
This behavior is not normal, here is what I’m doing to resolve this problem, it works in my case, let me know if it solve yours :
– First read the page 240 from this redbook : http://www.redbooks.ibm.com/redbooks/pdfs/sg247940.pdf – On the default route setup the dead gateway detection : # route change default -active_dgd – Add this line to /etc/rc.tcpip to make the change permanent. – Set interval of dgd to 2 seconds instead of five (reboot your server after this change) : # no -p -o dgd_ping_time=2 – On network switch : – Disable spanning tree protocol (STP), OR – Enable PortFast trunk # switchport mode trunk eth1/1 # spanning-tree portfast eth1/1 – If your are using LACP 802.3ad set this one to ACTIVE on the switch side. – Restest a failover and let me know if this it ok for you.
Before starting a VIOS upgrade, I always open a second windows with oem_setup_env. So in case of trouble, I create a new user that has an id 0 like root and I test a ssh connection to prevent any problem after reboot.
If you have a Failed status on your upgrade, for example on the package “ios.cli.rte”:
ios.cli.rte 6.1.7.15 USR APPLY SUCCESS ios.cli.rte 6.1.7.15 ROOT APPLY FAILED
The use the following command as root, after a reboot, this will retry only the root part of the installation package:
[proot@vios-520]/home/padmin/soft/tmp# installp -Or -agX ios.cli.rte +-----------------------------------------------------------------------------+ Installing Software... +-----------------------------------------------------------------------------+ installp: APPLYING software for: ios.cli.rte 6.1.7.15 ....Success
8284-22A connected over 10G with two Nexus 5596UP using vPC.
nexus5k-2# sh run int Po17 !Command: show running-config interface port-channel18 !Time: Thu Jan 8 11:26:38 2015 version 5.2(1)N1(7) interface port-channel17 description CHEPRE - et1/17 switchport mode trunk switchport trunk allowed vlan 401,403 spanning-tree port type edge trunk speed 10000 flowcontrol receive on flowcontrol send on vpc 17 nexus5k-2# sh run int Po18 !Command: show running-config interface port-channel18 !Time: Thu Jan 8 11:26:38 2015 version 5.2(1)N1(7) interface port-channel18 description CHEPRE - et1/18 switchport mode trunk switchport trunk allowed vlan 401,403 spanning-tree port type edge trunk speed 10000 flowcontrol receive on flowcontrol send on vpc 18 interface Ethernet1/17 description CHEPRE LAN3 10G P2 switchport mode trunk switchport trunk allowed vlan 401,403 flowcontrol receive on flowcontrol send on channel-group 17 mode active nexus5k-2# sh run int et1/18 !Command: show running-config interface Ethernet1/18 !Time: Thu Jan 8 11:27:00 2015 version 5.2(1)N1(7) interface Ethernet1/18 description CHEPRE LAN6 10G P2 switchport mode trunk switchport trunk allowed vlan 401,403 flowcontrol receive on flowcontrol send on channel-group 18 mode active
VIOS SEA Adapter Setting: adapter_reset and LACP (8023ad Link Aggregation) posted on Jan 15, 2016 by steve in VIO Server Tips
After upgrading to VIOS 2.2.3.4 I noticed that there is a new SEA adapter attribute: adapter_reset
This adapter setting is set to 'yes' by default, so a SEA adapter going in to Backup state will cause the Physical Link to be reset. If this link is running LACP (802.3ad) Link Aggregation, it can take up to 30 seconds for the LACP bundle to reset.
If you are running SEA Load Sharing, then Load Sharing is inititated by the 2nd VIO Servers adapter going in to Backup_sh mode. This can cause the physical link to be reset and network communications may be interupted for this time.
It is advisable to change this adapter setting to 'no' for SEA adapters running Load Sharing where the underlying link is LACP.
1 - Login to the VIO Server
2 - Check the current setting.
# lsdev -dev ent9 -attr adapter_reset value yes
3 - Change the setting from 'yes' to 'no' - This is a Dynamic Change.
# chdev -dev ent9 -attr adapter_reset=no
4 - Confirm the adapter has changed.
# lsdev -dev ent9 -attr adapter_reset value no