Alle 4 Netzwerk-RJ45-Ports sind jetzt mit dem Switch verbunden zusätzlich zum (5. RJ45-) ILO Port!!

Die Startprozedur ist die Gleiche wie bisher. Der Proliant DL385 hat jetzt 6 x 142 GB SCSI Platten bekommen und weiterhin insgesamt 12 logische Laufwerke = entsprechen 12 "physikalischen" Drives für Linux.
-

Installiert werden soll Suse 12.1 nach wie vor über ILO vom Remote Desktop.

Der Treiber ist wieder mal entfleucht (hatten wir schon mal)eintragen. Sonst erkennt Suse den "cciss Teiber" wieder mal nicht. Der "cciss". Das ist nämlich der Profi RAID Controller Treiber für die sehr teueren Compaq/HP RAID5 Controller in 380/385 Proliant Servern.
-

Bei der Installation sollte man "Deutsch" und "Vesa" auswählen und auf der "Grünen Seite" muß man unbedingt in der Installations-Kommandozeile "noapic, acpi=off" eintippen !!!!!! Sonst started der Proliant mit cciss RAID Controller nicht mehr.
-

Bis zur Uhrzeit ist alles normal, auch dort einfach weiter klicken, bei der Arbeitsumgebung auf Andere klicken.

Dort "Minimales grafisches Sytem" anwählen, wir brauchen X11 für den VNC Server
-

Wenn "Minimales grafisches Sytem" und X11 und VNC Server ausgewählt wird, werden ca. 1,7 Gigabyte aus dem Netz geholt. Warum so viel, ist unklar. Wenn ich nur das nackte "Minimale grafische Sytem" ohne weitere Options auswähle, sind es nur ca. 550 MB. Den Rest werde ich später nachinstallieren und genau aufpassen.

Der Partitionierungsvorschlag ist wieder mal unglücklich, alle Einträge löschen und nur auf /dev/ciss/c0d0 anfangen
-

Für die XEN DOM"0" lege ich 1000MB Swap und 7GB  mit ext4 an. Wenn das Installsystem partout spinnt (bei unserem DL360-G4 Testserver) und es einfach nicht macht, dann (leider) nochmal mit gparted starten und dann damit die Partitions-Tabelle für die erste Partition anlegen und swap und root einrichten und gleich mit ext4 formatieren. Warum die Smartstart CD das nicht (mehr) macht , na ja.
-

Dann installiere ich das vorgeschlagene 12.1 System zuzüglich XEN und schalte ganz unten noch SSH ein. Die Firewall ist bereits eingeschaltet.

Das Installprogramm möchte 1.7 Gigabyte runter laden - wobei kein KDE und außer XEN keine Server gefragt sind  - so viel - das dauert gute 20 Minuten mit DSL 16.000.
-

Warum es bei zwei physikalisch fast gleichen Servern dennoch nicht 1:1 geht, kann mir niemand verraten.

Nach dem ersten Neustart stürtzt 12.1 sogleich total ab. Da hilft nur ein Server-Reset per ILO, ein Durchhangeln bis zum Server-Startbildschirm, dort XEN auswählen und sofort die CLI Befehle "noapci, apci=off" eintragen.
-

Auch muss jetzt, aus welchen Gründen auch immer, die ILO Remote-Konsole sofort geschlossen werden, sonst stürzt sie unwiederbringlich ab.

Nach einer gefühlten Wartezeit von ein paar Minuten kann man über die ILO Console wieder auf die Server-Console schaun und die Graifk-Seite mit "Hostname und Domänenname" ist wieder da.

Jetzt erst geht es weiter und geht wie gewohnt bis zum Ende durch.
-

Wenn alles geklappt hat, startet Suse mit der X11 Login Maske. Dort sofort als root einlogen und per yast2 im Bootloader auf den XEN Kernel gehen und die Bootkonfiguration prüfen bzw. ergänzen. "noacpi, acpi=off" muss da stehen !! Sonst startet die DOM0 nicht mehr.

Ich habe auch gleich den Boot-Modus auf 3 (also ohne X11) umgestellt und starte später nach dem einloggen mit "startx" von Hand.

Auf jeden Fall muß man am Ende eine völlig autarke "Bootsession" ohne eingelegte CD und ohne jeden Eingriff auf der Console durchspielen. Der Server muss von ganz alleine durchbooten.
-

Folgende Programme habe ich per Yast nachinstalliert:

mc, htop, iftop, vsftp, net-snmp, net-date, . . .  da war noch was
-

-

Die letzte physikalische Platte ist unser Lager für alles. Dort wohnt auch die Suse 12.1 DVD als Quelle für alle VMs und Gast-Systeme. Bei mir ist es ein Verzeichnis z-iso, das ist so "fremd", man findet es sofort. Das wird per Yast auf diese leere Partition gebunden.

Dazu richte ich mir einen Hilfs-User ein, der die Gruppenrechte (ftp) auf dieser Partition hat. Im vsftp.conf muss ich noch das Schreiben freigeben und den vsftp nochmal starten. Auch muss in der Firewall der vsftp Dienst freigegeben werden.

Jetzt kann ich von meinem NAS Server per midnight commander eine ftp Verbindung zu dem ftp Hilfsbenutzer auf diesem neuen XEN Server herstellen und die 4,5 GigaByte ISO Datei (openSUSE-12.1-DVD-x86_64.iso) dort rüber "schieben" (kopieren).
-

Eigentlich wollte ich erst mal die HP HPASM Tools zumlaufenbringen, doch das klappte noch nicht und ist sehr zeitaufwendig.

Der normale Start des VM Managers sollte mit einer Partitionierung in einem 2. Putty Fenster unter yast erfolgen. Der VM Manger kann die angelegten Partitionen dann zwar füllen, aber nicht mehr verändern. Also swap, root und data werden vorher extern angelegt.

Jetzt geht es weiter mit der 1. VM. Wichtig ist hierbei wegen des Suse 12.1 cciss Bugs Nummer 1, daß im Kernel Abschnit des Bootloader unbedingt in der Kernel Befehlszeile "noapci, apci=off" eingetragen wird. Sonst startet diese virtuelle Maschine (auch) nicht mehr. (keine Platte gefunden)

Beim Terminal habe ich noch "Zeichenmodus = 3" eingetragen, das könnte man später ändern, wenn diese VM überhaupt startet.

Also die "schmalste" Version von Suse 12.1 ausgewählt bedeutet : 500 MB aus dem ISO Image und 100 MB online vom Suse Server holen.
-
Erster Versuch gescheitert, die VM bootet nicht mehr.

also 2. Versuch
Bei dem Menüpunkt "Installation des Betriebssystems" in der Zeile "Weitere Angaben" diesen Text "noapci, apci=off," eintragen.

Dazu jetzt : Installation von virtueller Plattte, nicht vom http Server
Das Extrahieren aus dem ISO von dem eigenen RAID geht sehr schnell, deutlich schneller als von der CD oder DVD oder aus dem Netz.

Bei der Kontrolle der Einträge im Bootloader ist "noapci, apci=off" jetzt schon ethalten.
-
"Bootloader Einstellungen" testweise auf "Aus Root-Partition starten"

mal sehen

geht auch nicht

also 3. Versuch

mit der 12.1 NET ISO, mal sehen, es ist spät geworden, schon wieder

also x-te Versuch
Mit ext3 oder ext4 geht es auch nicht, mit dieversen boot-Optionen wie "start from MBR" oder "start from root Partition" geht es auch nicht.

Auch eine erneute Installaton direkt aus dem Netz geht auch nicht, überall der gleiche Fehler : kann kein Betriebssystem laden.

-

That means : I did'nt get it running with at least one VM. There mus be a secret how to start a VM after installation. Ok, with a lot of googling I heard about another trick (three days old !!!!), the boot partition must be a separate small one, about 500 megabyte in size !!!

Continue here.
-

-

Es ist noch ein zweiter Bug (vermutlich noch ein dritter) in der Suse 12.1 bei der Installation einer VM !!!
Aber erst einmal kommt das XEN Basis-System DOM 0 :

1.) Die allererste Platte bei unseren Servern ist "dev/cciss/c0d0" mit 500 MB bis 1GB "swap" und 6,0 bis 8 GB root mit ext4 formatiert.

Beim Start "noapci apci=off" in die Kommandozeile eintragen !!! das ist ganz wichtig für den cciss Treiber der HP-Proliants

2.) Installation von "minimalem grafiksystem mit X11"

3.) softwareauswahl ergänzt ohne rücksicht auf datenmenge
a) yast2 installationspakete
b) hostserver für virtual maschines
c) Runlevel 3 ausgewählt. Später wird der X11 Server mit startx gestartet
d) SSH aktiviert und in der Firewall freigegeben

4.) es werden 1,739 GB mit fast 13 Mbit/s (um 30 Min. nach Mitternacht) vom Suse-Server herunter geladen

5.) Netzwerk-Konfiguration
a) SSH Port öffnen
b) VNC aktivieren - hier ist es besser, es werden gleich am Anfang alle Module mit installiert
c) Firewall prüfen- alle Ports sind der externen Zone zugeordnet

6.) alle Updates bestätigen, nichts übergehen
(immer default = collectives Updatepackage ist markiert)

7.) und schon kommt beim Booten der Fehler:

Asparagus Kernel 3.1.0-1.2-xen(tty1)

unable to read sysrq code in control/sysrq

hier mit RETURN den Bootvorgang vollenden bis zum LOGIN

8.) nach dem Einloggen  mit "startx" die x-Console aufrufen
und mit der Maus das erste XTerm Fenster öffnen und YAST2 aufrufen

GESCHAFFT, sowohl die Nerven als auch der Server !
-

Nach einer (vor 2 Tagen) im Internet publizierten Erfahrung von vor 2 !!! Tagen muß das Boot Device einer "Virteullen Maschine" (und nur der "VM") eine eigene primäre (Boot-) Partition mit max. 499 MB sein und dorthin muß (ausschliesslich) "/boot" eingehängt sein. Die jeweils einzelne physikalische Platte für eine VM ist bei uns minimal 10 Giga groß, meist jedoch 40 Giga.

Die neue Workaround- Partitionierung mache ich jetzt unter YAST2 im grafischen Modus und lege also für diesen Versuch 3 Partitionen auf der Zielplatte an: "swap" mit 1 Giga, "/boot" mit 400MB und "/" mit 8,5 Giga.

Also mal sehen ..........

1.) Zuerst in der DOM0 (XEn Grundsystem) mit YAST2 unter "Languages" und dort "Details" bei "Local Setting for user root" ein "yes" anklicken und abspeichern. Alle Programme verlassen und das Terminal schliessen mit "CTRL D" und dann sogleich neu aufmachen - es muß jetzt fast alles auf Deutsch kommen.

2.) Auf unseren Servern lege ich zur VM Installtion im root-FS der "DOM 0" ein Verzeichnis z-iso an (dort wohnen alle ISO Dateien) --- (und linke das später mit den ganzen ISOs im Partionierer auf meine letzte Partition.

3.) Im Partitioner also auf die letzte Partition klicken und z-iso einhängen

4.) Auf der jetzt aufgerufenen "VM Install" Seite dann die 12.1 DVD ISO Datei !! als Quelle auswählen und als Zielplatte das "phy" Device hinzufügen. Vorher im Partitioner die entsprechende Bezeichnung genau ansehen (hier im Beispiel ist es : phy://dev/cciss/s0d1).

5.) Die Partionierung der Zielplatte genau konfigurieren - das Verzeichnis /boot muss auf die 500MB Partition zeigen (sagt der Tester in einem Forum)

6.) vorerst keine weitere Zusatzsoftware, für den Test - alles ziemlich spartanisch lassen,

7.) Bei den Bootloadereinstellungen "noapci apci=off" nicht vergessen

8.) für den SYSTEMSTART Boot aus /boot Paetition aktivieren
-

Endlich - Es hat funktioniert, die erst VM kam nach dem Reboot wieder hoch.

Jetzt werden wieder alle Updates kommentarlos durchgewunken, es funktioniert immer noch - bisher jedenfalls. Und ich bekomme den ersten Login-Promt einer VM unter 12.1. auf einem Proliant Server.

Das ist natürlich ein Schmarren, denn in der 10.1 hatten sie auch einen ähnlichen Bug eingebaut und uns damals tagelanges Suchen verordnet. Die 11.1 bis 11.3 hatte auch solch kleine Bugs, erst die 11.4 funktionierte problemlos.

Jetzt geht es eventuell weiter mit den virtuellen Applikations-Servern.
-

Mit den gleichen Workarounds bzw. Tricks funktuiniert es bei dern nächsten VM schon nicht mehr.

Und für eine VM auf einem XEN Server brauche ich das XEN nicht.
-

Beim Booten der DOM0 mit dem XEN Grundsystem kommt (noch vor dem Login-Promt) "Unable to read sysrq code in /control/sysrq" und der Bildschirm hängt.

Mit "RETURN" geht es zwar weiter, aber der Fehler nervt, zumal der Promt nicht erscheint.

Mal sehen, ob das hier hilft :

Magic SysRq muß eingeschaltet werden - vermutlich 3 Änderungen

1.) in /boot/ nach "config-3.1.0-1.2-xen" suchen
und dort den folgenden String überprüfen :

CONFIG_MAGIC_SYSRQ=y

2.) dann in /proc/sys/kernel in sysrq reinschaun:

cat /proc/sys/kernel/sysrq

This will have a value of 1 or 0

• 0 = off
• 1 = on

To turn it on then:

echo 1 > /proc/sys/kernel/sysrq

This will turn it on until the next reboot. If you need it set permanently you will need to edit files or use the SUSE YaST tool.

3.) From the YaST Local Security Tool you can turn on support for Magic SysRq. This actually writes to the file:

/etc/sysconfig/sysctl
ENABLE_SYSRQ=”yes”

This line should be yes as above to permanently turn on Sysrq. This will have effect after a server reboot but you can turn it on immediately as described on the previously. Using YaST will set the file and current running value.

www.novell.com/communities/node/6214/magic-sysrq-your-emergency-link-kernel
www.susegeek.com/general/linux-kernel-magic-sysrq-keys-in-opensuse-for-crash-recovery/

20. Dez. 2011 - Das hat aber bislang nichts geholfen.
Der Fehler bleibt

-

Ziel war, unter Suse 12.1 auf einem HP DL360-G4 einen Postfix (mit GUI) Mailserver sowie einen DNS und einen DHCP(Test) Server jeweils als eigene VM aufzusetzen. Dazu musste ich einige Workarounds durchführen.

Aber es hat funktioniert, die 2. VM läuft leidlich.


-