Virtual I/O Server VIOS

Integrate Virtualisation Manager IVM

Speichernutzung im VIOS / IVM

Speicherprobleme mit der IVM Java / Eclipse GUI

SEA Failover

Microcode Update bei SEA Failover Adapter

Zusätzliche Software auf VIOS / IVM

VIOS mksysb via crontab

VIOS

VIOS update

Die VIOS Fixpaks werden als ISO images im Web bereitgestellt. Allerdings wird niemand mit je nach Version 3 bis 5 CD an der HMC stehen und das update einspielen, zumal das wegen überkreuzter Abhängigkeiten zwischen den CD technisch gar nicht möglich ist. (Man sollte meinen, so etwas kann nicht sein und wie kommen solche ISOs durch die Qualitäts- oder Endkontrolle. Es ist aber leider Realität.) Es empfiehlt sich  deshalb alle Dateien aus den ISO Dateien in einem Verzeichnis zusammenzufassen und dann von dort aus das update durchzuführen.

Seit AIX 6.1 TL4 können die ISO Dateien direkt gemountet werden:

# loopmount -i VIOS1.ISO -o "-o ro -v cdrfs" -m /mnt

SEA Failover

Beim Anlegen von 2 SEA auf 2 VIOS hält man am besten eine bestimmte Reihenfolge ein, da abhängig vom genutzten Switch / dessen Firmware Probleme im Netzwerk auftreten können. Die hier genannte Reihenfolge verursacht die wenigsten Probleme.

Man beginnt auf VIOS 1 und erst wenn dort alle Schritte durchgeführt wurden macht man auf VIOS 2 weiter:

  1. Virtuellen Adapter anlegen, den der SEA nutzen soll. PVID definieren (i.d.R. 1) und Häkchen setzen bei "Access external network". Trunk priority setzen (i.d.R. auch 1).
  2. Virtuellen Adapter anlegen, der für den Control-Channel genutzt werden soll. PVID definieren (hoher Wert z.B. über 80 oder 90).
  3. shutdown -h VIOS 1. Activate VIOS 1.
  4. SEA anlegen: $ mkvdev -sea entX -vadapter entY -default entY -defaultid 1 -attr_mode=auto ctl_chan=entW
  5. Auf VIOS 2 wechseln
  6. Virtuellen Adapter anlegen, den der SEA nutzen soll. PVID definieren (i.d.R. 1) und Häkchen setzen bei "Access external network". Trunk priority setzen und zwar auf Priority von VIOS 1 + 1 (hier also "2").
  7. Falls der SEA eine IP Adresse bekommen soll, dann jetzt auf VIOS 1 mit: $ mktcpip -hostname <hostname> -interface enZ -inetaddr A.B.C.D -netmask 255.255.255.0 -gateway <gw> -nsrvaddr E.F.G.H -nsrvdomain meine.ganze.domain -start
  8. Virtuellen Adapter anlegen, der für den Control-Channel genutzt werden soll. PVID setzen wie auf VIOS 1).
  9. shutdown -h VIOS 2. Activate VIOS 2.
  10. SEA anlegen auf VIOS 2: $ mkvdev -sea entX -vadapter entY -default entY -defaultid 1 -attr_mode=auto ctl_chan=entW
  11. Falls der SEA eine IP Adresse bekommen soll, dann jetzt auf VIOS 2 mit: $ mktcpip -hostname <hostname> -interface enZ -inetaddr A.B.C.D -netmask 255.255.255.0 -gateway <gw> -nsrvaddr E.F.G.H -nsrvdomain meine.ganze.domain -start

Microcode Update bei SEA Failover Adapter

Durch die Redundanz bei SEA Failover Adaptern kann man die beteiligten physischen Adapter nacheinander aktualisieren ohne daß die Netzwerkverbindung zu den LPAR unterbrochen wird.

  1. Mit entstat -all [SEA] | grep -i state auf beiden VIOS den Status des SEA Adapters ergründen.
  2. Den ungenutzten phys. Adapter aus seinem Etherchannel rauskonfigurieren indem der main adapter aus dem Etherchannel entfernt wird.  Wer sich auf der Kommandozeile nicht wohl fühlt nimmt Z.B. smitty chgethch.
  3. Microcode update auf diesem Adapter durchführen. Es muß nur ein device aktualisiert werden, die anderen werden automatisch mit aktualisiert. (gilt für ent und fcoe devices).
  4. Den aktualisierten Adapter wieder als main adapter in den Etherchannel aufnehmen.
  5. Den dazugehörenden VIOS wieder zum Primary/Backup machen chdev -dev <sea> -attr_ha_mode=auto.
  6. Prüfen ob alle Adapter des Channels im Zustand "up" sind: entstat -all [SEA] Falls das erfolgreich ist, weiter mit dem nächsten Schritt.
  7. Für die Aktualisierung des anderen VIOS nun einen manuellen SEA Failover auslösen.: chdev -dev <sea> -attr_ha_mode=standby.
  8. Den ungenutzten phys. Adapter aus seinem Etherchannel rauskonfigurieren indem der main adapter aus dem Etherchannel entfernt wird. Z.B. smitty chgethch.
  9. Microcode update auf diesem Adapter durchführen. Es muß nur ein device aktualisiert werden, die anderen werden automatisch mit aktualisiert. (gilt für ent und fcoe).
  10. Den aktualisierten Adapter wieder als main adapter in den Etherchannel aufnehmen.
  11. Den dazugehörenden VIOS wieder zum Primary/Backup machen chdev -dev <sea> -attr_ha_mode=auto.
  12. Prüfen ob alle Adapter des Channels im Zustand "up" sind: entstat -all [SEA]

Integrated Virtualization Manager IVM

Der IVM ist eine Art lokale HMC, welche wie eine mksysb Installation als erste LPAR (ID 0) innerhalb einer P5 installiert wird. Mit ihm werden dann LPAR angelegt und verwaltet. IVM ist als Black Box konzipiert und für p5 Systeme von p505 bis p560 als Einstieg in VIO gedacht. Die Software ist identisch zum VIO, es gibt jedoch eine eigene GUI und in der shell ein paar abweichende Kommandos. Ab p570 soll nicht mehr IVM, sondern eine HMC verwendet werden (IVM auf p570 ist aber technisch möglich).

Eindeutiges Manko bei IVM Installation ist, daß virtuelle devices nicht redundant an VIO Clients durchgereicht werden können. Fällt der IVM aus, verlieren die Clients ihre durch den IVM zur Verfügung gestellten Resourcen.

Speichernutzung

Im Gegensatz zum VIO, der mit relativ wenig RAM auskommt (in der Anfangszeit bei VIO 1.1 mit 500MB), braucht der IVM mit dem Webserver und dem Java deutlich mehr Speicher. Jeder logische HEA Port benötigt nochmal 100MB RAM für sich. Daraus folgt, daß ein Startwert von 1 GB für IVM geboten ist, je nach Anzahl der gehosteten LPAR bzw. Adapter kann schnell 1,5GB oder gar 2 GB für einen reibungslosen Betrieb nötig sein.

Wenn der Speicher knapp wird, bemerkt man dies zuerst an der schlechten Antwortzeit in der GUI. Später erhält man dann Java 500 Fehler, Frames werden falsch oder gar nicht mehr angezeigt, Aktionen in der GUI schlagen mit merkwürdigen Meldungen fehl. In der padmin Konsole wird die Rückgabe der Kommandos ebenfalls langsamer, bis man bei "cannot fork" angelangt.

Für VIOS ab V.2 sollte man mit 2GB RAM starten.

nach oben

Fehler in der IVM Java/Eclipse GUI

Für eine Analyse der Probleme im Zshg. mit Java/Eclipse kann man einen java core erzeugen mit

# kill -3 <javapid>

Der daraufhin erzeugte Core liegt mit datum und Uhrzeit in

/usr/ios/lpm/gui/httpd/runtime/core/javacore233598.1228214838.txt

Man kann den IVM Webserver auch im laufenden Betrieb neu starten indem man einen kill auf die <javapid> absetzt. Der Javaprozess startet sich dann selbständig neu und taucht nach kurzer Zeit mit neuer PID und Startzeit in Prozessliste auf.

Welche Software ist auf VIO/IVM erlaubt?

Aus dem Blackbox Konzept für VIO/IVM ergibt sich, daß es nur eingeschränkt möglich ist zusätzliche Software zu installieren. Es existieren nur ein paar Ausnahmen, die ohne Verlust des Softwaresupport installiert werden dürfen. Die folgende Aufstellung entstammt einer whitelist vom August 2009. Wenn man eines dieser Produkte installieren möchte empfiehlt sich in jedem Fall bei IBM nachzufragen ob der Support erhalten bleibt. Für die Fremdanbieter Software gilt ansonsten, daß zwar die Installation nicht verboten ist, Support für die Software selbst wird jedoch nicht von IBM geleistet.
Beta Systems Software AG SAM Jupiter
BMC Performance Manager for Servers

Performance Assurance for Servers

Performance Analysis for Servers  

CA, Inc. CA Advanced Systems Management

CA Audit

CA Access Control

CA Network and Systems Management

EMC EMC Control Center (ECC) for IBM Virtual I/O Server

EMC PowerPath for IBM Virtual I/O Server

Fox Technologies, Inc. BoKS Access Control for Servers
Hitachi Hitachi Dynamic Link Manager
HP HP Performance Agent Software

HP Operations Agent Software 8.X

HP GlancePlus Software

Metron Technology Limited Athene
NetApp Host Utilities
PassGo Technologies Ltd UPM
SAP AG SAP Operating System monitoring agent for VIOS
Symantec Software Corp. Symantec Enterprise Security Manager
Sysload Software SP Analyst Agent
TeamQuest Corp TeamQuest Performance Software V9 for POWER and zSeries

TeamQuest Performance Software Release 10

IBM TotalStorage SDD

SDDPCM

IBM Tivoli IBM Tivoli Montoring (ITM)

IBM Tivoli Monitoring: UNIX Logs Agent

Tivoli Storage Manager (TSM)

IBM Tivoli Usage and Accounting Manager (ITUAM)

Tivoli Identity Manager (TIM)

Tivoli Application Dependency Discovery Manager (TADDM)

TotalStorage Productivity Center (TPC)

VIOS mksysb via crontab

Eine Möglichkeit regelmäßig eine mksysb Sicherung vom VIOS zu ziehen.

#!/bin/ksh93

# @(#) Zweck: Automatische Sicherung der VIOS mittels crontab

# @(#) auf den NIM.

# @(#) Problem: User padmin kann keine crontab nutzen, user root

# @(#) kann das backupios Kommando nicht ausfuehren. Deshalb

# @(#) verwenden der root crontab und backupios Aufruf

# @(#) als padmin.

# @(#) Datum: 26. Okt. 2010 0.1 Basisfunktionalitaet

# @(#)                      0.2 Lokale Logdatei

#

## Variables ################################################

DATE=`date +"%d%m%Y"`

HOST=`hostname`

## Main ###################################################

# Haenge /images Verzeichnis auf /mnt

/usr/ios/cli/ioscli mount nim1:/images /mnt

if [[ $? = 0 ]]

then

# Wenn NFS mount erfolgreich war, erstelle das Backup als padmin

/usr/ios/cli/ioscli backupios -file /mnt/$HOST.mksysb -mksysb | tee backupioserror.log

else

# Fehlermeldung, wenn NFS mount fehlschlaegt

print "Fehler beim Versuch nim1:/images zu mounten"

exit 99

fi

# Aufraeumen und mount wieder loesen.

umount /mnt

<TOP>

Switchredundanz behalten mit NPIV

http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS4089