Zuerst mal der "Standard"-Spruch der klugen EDV- Leute
"Wenn man weiß, wie es geht, ist alles trivial." ......... Darum hier eine Zusammenfassung bis zur ersten funktionierenden V(irtuellen) M(aschine).
April 2020 - Ein Grundkonzept aus 20 Jahren Erfahrung
Gute, schlechte und bittere Erfahrung mit Suse und opensuse. Nicht jedes Release funktioniert. Viel zu oft wurde verschlimmbessert und erst die nachgebesserten (Folge-) Versionen 2 oder 3 eines Releases, zum Beispiel 9.2, 10.3, 11.1, 12.3, 13.2 und 42.3 funktionier(t)en endlich - wieder - wie gewohnt. Die Version 15.0 ging für uns fast gar nicht, die 15.1 läuft leidlich als VM, die 15.2 geht noch nicht (startet mit scharzem Bildschirm).
Das "schlagende" Argument für opensuse ist nach wie vor noch yast, yast2 und zypper. Alles andere können "die anderen" (nach 20 Jahren) auch. Es gibt bei Webtropia (als auch bei Hetzner) ein Web-Interface für die dedicated Root-Server und dazu Wissensdatenbanken, die sich aber weit unterscheiden. Damit muß man sich auf jeden Fall beschäftigen. Weil ein paar wichtige aber eigentlich triviale Dinge dort nicht stehen, gibt es diese Seiten hier.
.
Die Linux-Installationen auf unseren Root-Servern
Jede einzelne Linux Installation - ob auf einem RAID5 oder einem RAID1 Plattensystem - hat bei uns immer 3 aufgeteilte Partitionen
.
- eine (1) swap Partition,
- eine (2) root-Partition (immer ext4) und
- eine (3) Programm- und Daten- Partition (immer xfs).
.
Unsere ganzen HP-Proliant 380 G1 Server (2 CPUs/4GB) wurden ab 2009 zu nur noch zwei Proliant G5 (8 CPUs/32GB) migriert und sind seit 2011 alle mit opensuse XEN virtualisiert.
.
Das XEN Grundsystem, der Host bzw. die "DOM 0"
Das XEN Grundsystem, der Host bzw. die "DOM 0", bekommt auch immer 3 (aber spezielle andere) Partitionen, nämlich die spätere
- (md0) swap-, die
- (md1) "/boot" (mit ext4)- und die
- (md2) "/" (root mit ext4)-Partition.
.
Übrigens wird das opensuse Ur-Install-System von Webtropia auch so konfigurriert - mit einer extra /boot Partition wegen der extrem großen sata-Platten.
.
Eine Programm oder Daten-Partition gibt es dort auf der "DOM 0" NICHT. Auf der "DOM 0" laufen bei uns prinzipiell KEINE Anwendungs-Programme wie DHCP oder DNS oder Apache oder ftp oder sonstwas.
Für die einzelnen Aufgaben gibt es später jeweils eine eigene V(irtuelle M(aschine) - Gast oder "DOM U" genannt, auch wenn das immer einer (monatlich) kostenpflichtigen IPV4 Adresse bedarf. Mit 32GB oder gar 64GB RAM geht das ganz locker. Dies verteilte Konzept ist (für uns) ein wichtiger Sicherheitsaspekt. Die extrem wichtige "DOM 0" ist dann nämlich "dicht".
.
Das Webtropia (default) Installations-Grundsystem 42.3
Die von Webtropia au deren Repository eingerichtete opensuse 42.3 Grund-Installation (man braucht das n ur anzuklicken bzw. bei der Beauftragung mit zu bestellen) kann die beiden 1,8 TB Platten nicht zu einem RAID 1 kombinieren. Das muß man daher vorher etwas vorbereiten. Und dafür gibt es das sogenannte Rescue System. Es ist von der Reihenfolge der Installationen etwas verzwackt (und hier ausführlich beschrieben).
Die "DOM 0" besteht also aus 2 bis 4 GB "swap", max 1 GB "/boot/" und 20 bis 30 GB für das "root"-Filesystem - siehe weiter oben. Das reicht in der Regel vollkommen aus.
.
Mit allen Tricks kämpfen .... die RAIDs einrichten
Zu allererst installiere ich das im ZKM zur Verfügung gestellte (das vorbereitete automatische) webtropia opensuse 42.3 image - volle Pulle - auf die erste Platte, in der (aller-) kleinsten oder schmalbrüstigsten Textversion. Da die 1,2GB Daten vom webtropia Repository kommen, ist die Menge unerheblich. Wir brauchen davon (später) eigentlich nur die physikalische Netzwerk-Konfiguration der in dieser Hardware physikalisch verbauten Netzwerkkarte, die wir unbedingt sichern müssen. Der gesamte Rest interessiert nicht.
Danach starte ich den webtropia Server im Rescue Modus ---- und in der dort hochgefahreren virtuellen Maschine (wie das geht, steht hier vorher heruntergeladenes) starte ich ein opensuse Net-Image aus dem entsprechenden opensuse Repository (steht auch alles hier) und installiere nochmal neu die opensuse textbasierte Server-Version - aber ohne jede Software-Ergänzung, und auch (absichtlich) noch kein XEN dabei.
Jetzt kann yast-install die angelegten 6 Einzel-Partitionen auf den beiden 1TB Platten "sda" und "sdb" Partition für Partition zu drei RAID1 Partitionen "spannen" und somit definiere ich im yast die ersten drei Partitionen md0, md1 und md2 - wie weiter oben bereits beschrieben.
Lediglich die "firewall" sowie der "ssh-Dienst" werden jetzt gleich bei der Installation im Bereich Software aktiviert. Einen "Hilfs-Benutzer" sowie der Benutzer "root" bekommen hier getrennte Passwörter für den ssh-Dienst.
In dieser gestarteten Rescue/Debian VM wird natürlich eine "virtuelle" Netzwerkkarte auf das Rescue System "drauf" gesetzt, die aber später nicht mehr da ist. Darum noch kein XEN (mit einer Bridge) installieren. Wir müssen nach dieser Installation erst noch die vorab gesicherte Netzwerk Konfiguration überschreiben bzw. rücksichern, bevor wir das Betriebssystem von der Platte starten können. Auch das geht verhältnismäßig leicht, wenn nach der Installation die Rescue-VM wieder abgebaut ist. Dann kann man die Partition "md3" mounen und dort ganz normal die (gesichterte) Netzwerk Konfig rein kopieren.
.
Der erste echte Start von den zwei gespiegelten Platten
Im Webinterface ZKM wird der Rescue Modus per Click beendet und mit "reboot" wird die Rescue (putty) Console verlassen. Der Server müsste jetzt von Platte starten.
Wie gesagt, erkennt opensuse bereits beim Start, daß es gespiegelte Platten sind, auf denen diese ersten drei Partitionen der "DOM 0" wohnen. Wenn wir alles richtig gemacht haben, kommt das Linux Betriebssystem sauber hoch. Da wir nicht vor dem Server Bildschirm sitzen und zusehen können, müssen wir einfach nur warten, bis unser DOS-Fenster mit den Dauer-Pings (ping 213.202.xxx.yyy -n 10000) auf die Haupt-IP des Servers antwortet und den Erfolg anzeigt.
Die opensuse Version 42.3 ist nicht mehr aktuell, dafür funktioneirt sie aber erstaunlich gut, (die opensuse 15.0 sowie die 15.1 hatten schon wieder nur Probleme gemacht ????), darum müssen wir in yast die Links auf die Quellen der Updates anpassen. Die Repositories wurden in andere Verzeichnisse verlagert.
Benötigt werden auf der "DOM 0" nur noch (ergänzend) die ganzen XEN Virtualisierungsmodule sowie die kleinstmögliche grafische Oberfläche X11 mit dem iceWM für den XEN "virt-manager" und auch für yast2. (Was ich sonst noch installiert hatte, steht hier.)
.
Die neue XEN Netzwerk Konfiguration der "DOM 0"
Bei der Erstinstallation hatte diese Installation nur die (eine) Netzwerkkarte (eth0) und dort war ursprünglich DHCP und dann von mir händisch die Haupt-IP Nummer samt Netzmaske und dem Routing auf die Gateway IP nach draußen eingetragen, also nur 2 IP-Nummern. Die Nameserver sind vorläufig optional.
Nach der Installation von XEN hatte das virt-Install-Programm die IP-Nummer der Netzwerkkarte (eth0) samt Netzmaske wieder ausgetragen und in die jetzt neu angelegte Bridge (br0) übernommen. Die Bridge 0 ist fest an die Netzwerkkarte gekoppelt.
Die "DOM0" Netzkonfiguration kennt also nur 2 IP-Nummern (Haupt-IP und die Route nach Draußen), evtl. eine oder zwei DNS-Sever IP-Nummern, die aktivierte IPV4 Weiterleitung und "ein paar" Host-Namen. Alles andere bleibt so, wie es opensuse vorgeschlagen hatte und instaliert hatte. Sie brauchen da nichts zu ändern.
.
Doch zuerst die Grundsatzfragen beantworten ...
Selbstverständlich kann man die große gespiegelte 1TB Platte behalten und die einzelnen Gäste in sogenannte virtuelle Gast-Partitinen packen. Das sind dann aber einzelne riesen große 40GB oder 100GB Container-Dateien, in denen sich wiederum die virtuellen Gast-Dateisysteme des jeweiligen Gastes befinden. Das geht, hat aber den folgenschweren Nachteil : Stürzt - aus was für einem Grund auch immer - das DOM0- / Host- Dateisystem ab, ist alles im Eimer. Ich präferiere daher auf den Festplatten lieber viele einzelne 40 und 80GB RAID1- RAW-Partitionen jeweils für jeden Gast, in denen er sich seine Dateisyteme (siehe unten) anlegt. Stürzt dann doch einmal der Host ab, sind die Gast-Partionen davon (in der Regel) unberührt und lassen sich mit der Rescue- Version bequem und vollständig (und im letzten aktuellen Zustand unversehrt) sichern.
.
Die große Platte für die Gäste vorbereiten.
Mit dem Partitionierer von yast oder yast2 werden jetzt zu den vorhandenen drei Raid-Partitionen md0, md1 und md2 weitere angelegt. Dazu "müssen" Sie immer auf der einen Platte eine Partition erzeugen, dann die exakt gleiche Größe auf der anderen Platte. Gespannt - also zusammengefügt zu einer RAID1- Partition wird später.
Bei uns ist jetzt die erste Gast-Partition md3 mit 20 GB (z.B. für den Nameserver) und md4 mit 80 oder 100 GB (z.B. erster Webserver) und md5 und md6 usw. - Die jeweils neue RAID1-Partition ist erstmal eine RAW-Partition - unformatiert !!!! - Das alles ist zwar etwas mühsam, aber das macht man nur einmal für die Lebenszeit des jeweiligen Servers.
.
Eine VM (einen Gast) anlegen
Vorbemerkung : Meine bisherigen virtuellen Server laufen alle auf HP-Proliant DL380 G5 und haben 2 oder 4 einzelne 1GB Netzwerkkarten, von denen nur eine aktiviert ist. Dazu kommen 560 GB Raid5 Platten und 32GB RAM und das läuft alles seit 2010 erstaunlich stabil.
Die Einrichtung neuer VMs ist also eingeübt und mit dem grafischen "virt-manager" eigentlich ein Kinderspiel. Selbst wenn andere dort nicht vorgeschlagene Betriebssysteme zum Einsatz kommen sollen, wenn man das bereits geübt hatte, geht es schnell.
Das Konzept ist einleuchtend. Das virtuelle Interface schickt die Ethernet Pakete zur Bridge und von dort über die physikalische Netzwerkkarte zum Gateway nach draußen.
Kommen vom Gateway geroutete Ethernet Pakete mit einer IP-Adresse eines Gastes an oder zurück zur Netzwerkkarte, schickt die gekoppelte Bridge diese Pakete an das (hochgefahrene virtuelle) Gastsystem.
Das funktioniert bei mir seit Jahren völlig problemlos.
Bei webtropia (und insbesondere bei Hetzner) ist es anders
Dort werden die zusätzlichen "festen" IPv4-Nummern der Gäste (egal, wieviele Gäste) auf die Haupt IPv4-Nummer geroutet (oder geklemmt). Das wiederum bedeutet, daß die für diesen Server bestimmten Pakete von draußen alle auf der Haupt-IPv4 in der Bridge landen (also die Pakete kommen sowieso nur auf dieser Schnittstelle an) und die weiß mit diesen "fremden" IPs erstmal nichts anzufangen.
Der Bridge in der "DOM 0" muß darum mitgeteilt werden, wer (welcher Gast) diese Pakete bekommen soll. Dieses sogannte "point to point" Routing ist erst dann logisch, wenn man die Logik dahinter verstanden hat.
.
Die Logik der IP Verteilung der Bridge (mit point to point)
(diese spezeille Zeile heißt aber "pointopoint")
- hier sind 3 VM Gäste mehrfach gestartet, darum "vif25" bis "vif37"
Die Bridge der DOM-0 kennt erstmal nur die eigene (Haupt-) IPv4 sowie das Gateway nach draußen und weiß von den anderen virtuellen Gästen so lange nichts, "bis diese sich ihr mitteilen". Und ganz wichtig : Das tun sie aber erst, wenn die einzelnen VM gestartet worden sind.
Jede VM erhält beim Installieren (erstmaligem Starten) in der DOM-0 eine fortlaufende temporäre Bezeichnung (quasi die eigene virtuelle Ziel-Adresse) für ihr virtuelles Interface. Das hat aber mit der IP-Nummer der VM vorerst nichts zu tun. Die VM-IP-NUmmer steht ja nur in der VM-Konfiguration.
Von da an - also wenn die VM (nach dem Ausschalten) neu gestartet ist - ist diese Gast-IP-Nummer von draußen erreichbar, weil die Bridge jetzt weiß, wohin solche Pakete geschickt werden sollen. Wird die VM runter gefahren, ist diese Zieladresse wieder weg und die VM-IP-Nummer ist im Netz nicht mehr erreichbar.
.
Mein grosser Irrtum
Werden die einzelnen VM-IP-Sub-Nummern im Netzwerk-Router aber bereits vorher auf die Webtropia Haupt-IP-Nummer geroutet (was auf meinen eigenen HP-Proliants nie der Fall war), muß jede VM der "DOM 0"-Bridge das mitteilen, wenn die VM kalt gestartet wird bzw. hoch fährt. Die DOM-0 bleibt dabei passiv und muß überhaupt nicht angefasst werden.
Dafür muß jetzt bei der neuen VM die zusätzliche "pointopoint" IP-Nummer - Achtung : nur 1 "t" in der Ethernet- Konfiguration des "vif" (virtuellen interfaces) von Hand neu eingetragen werden und somit beim (Kalt-)Starten der VM von der VM an die DOM-0 publiziert werden.
Bislang war ich der irrigen Meinung, die VM-IPV4- Nummern müssten im Host in derDOM-0 Host-Bridge "br1" zu der jeweiligen VM geroutet werden, weil die Pakete ja vom Host an die VM durchgereicht werden, - jedoch wohin ?
Das hätte (mir) auffallen müssen, tat es aber nicht. Daß der Host zwar die internen VM-Gast-Adressen kennt, aber von der wirklichen Routing-IP-Adresse des "vif" erst erfährt, wenn die VM gestartet und online ist, das hatten die webtropia und die Hetzner KVM/XEN-Experten einfach mal vorausgesetzt. Ja, wenn man alles vorher weiß .....
.
Hier die Konfigurations-Muster in "DOM 0" und "DOM U"
Das bedeutet : In der DOM 0 wird opensuse XEN ganz normal als Standard konfiguriert. Die DOM 0 weiß von dem speziellen (webtropia/Hetzner-) Routing der Sub-IPs auf die Haupt-IP gar nichts. Die Bridge-Konfig des yast xen-installers kann also genau so belassen werden, wie sie ist. Mit den diversen logischen Namen der Interfaces kann man variieren oder spielen.
.
Alleine im VM-Gast ist ein besonderer "pointopoint" Eintrag wichtig.
.
Bei unserem Musterserver haben wir diese IP-Adressen:
.
- Route zum Gateway nach Draussen - 213.202.254.1
- Hauptadresse für die DOM 0 - 213.202.254.184
- Subadresse für die VM1 - 213.202.211.168
.
in der "DOM 0"- in den drei Konfig-Files steht :
in der "DOM 0"- "ifcfg-eth0" steht :
BOOTPROTO='none'
IPADDR=''
PREFIXLEN=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
NETMASK=''
BROADCAST=''
ETHTOOL_OPTIONS=''
MTU=''
NAME=''
NETWORK=''
LINK_REQUIRED='no'
.
in der "DOM 0"- "ifcfg-br0" steht :
BOOTPROTO='static'
BRIDGE='yes'
BRIDGE_FORWARDDELAY='0'
BRIDGE_PORTS='eth0'
BRIDGE_STP='off'
IPADDR='213.202.254.184/24'
PREFIXLEN='24'
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
BROADCAST=''
ETHTOOL_OPTIONS=''
MTU=''
NAME=''
NETWORK=''
in der "DOM 0"- "routes" steht :
default 213.202.254.1 - -
und wie gesagt, das ist alles opensuse XEN Standard !!!
.
in der "DOM U" (im Gast) - ifcfg-eth0 steht :
.
BOOTPROTO='static'
STARTMODE='auto'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='213.202.211.168/32'
MTU=''
NAME=''
NETWORK=''
PREFIXLEN='24'
REMOTE_IPADDR='213.202.254.1'
pointopoint='213.202.254.1'
Man sieht an den zusätzlichen beiden letzten Einträgen der letzten beiden Zeilen ganz deutlich, daß die VM dem Host mitteilt, wer sie ist und daß somit alle Datenpakete - von Draußen über die Haupt-IPv4 Nummer geroutet - hierher abzuliefern sind.
.
Nochmal im Klartext (es ist vielfach verwirrend beschrieben):
Am XEN Host - der DOM 0 - muß nichts geändert werden.
Jede VM bekommt in der Ethernet Konfiguration ihres virtuellen Interfaces diese eine Zeile eingetragen
pointopoint='213.202.254.1' (es ist unsere Beispiel IP)
und evtl diese hier auch noch :
REMOTE_IPADDR='213.202.254.1'
(also das Gateway des ersten Routers im Netzwerkschrank des Rechenzentrums)
NACHTRAG in 2021
Ist die VM Installation nur halbfertig, dann ist weder der "joe" noch der "mc" verfügbar und man kann diese beiden Zeilen nicht einfügen.
Dann geht nur der Trick über die DOM0, in der man sich das boot-Laufwerk mounten muß, sofern die VM runter gefahren ist.
bei uns war das als Beispiel einer beliebigen VM :
mkdir /md7p2
mount /dev/md7p2 /md7p2
editiere die eth0 Config dieser neuen VM und speichere die ab.
umount /md7p2
und starte die VM neu. DIE VM hat sich an der DOM 0 angemeldet. Jetzt müsste ein "ping" von draußen funktionieren.
Natürlich wollen wir für die Anwendungsprogramme wie DNS-Server, Mail-Server, ftp-Server und Web-Server ein aktuelles Betriebssystem haben.
Darum haben die VMs, die Gäste andere Prioritäten.
.