Teil 1 – Umfeld und Ablauf

1 Projektorganisation und Aufgabenstellung

1.1 Personen und Adressen

1.2 Mittel und Methoden

1x Dell-Server (PowerEdge R520)
1x Firewall (vorkonfiguriert)
1x Office Switch, unmanaged
1x Image-Datei der Xen-VM krokodil.syscon.ch auf einem USB-Stick
1x Arbeitsplatzrechner mit Windows 10 (vor der IPA eingerichtet)

Programmiersprache: Bash

1.3 Durchführungsblock

Startblock 8, KW14: 01.04.2019 – 05.04.2019
IPA-Durchführung: 01.04.2019 – 03.05.2019
Einreichung bis: 01.03.2019

1.4 Aufgabenstellung

In einer Testumgebung soll anhand der Migration einer ausgewählten Xen-VM ein Migrationskonzept entwickelt werden. Die Xen-VM steht dem Kandidaten als Image-Datei auf einem USB-Stick zur Verfügung. Sie soll auf den Ziel-Server (Proxmox-Server) migriert werden. Die zu migrierende VM ist krokodil.syscon.ch, es handelt sich dabei um einen der beiden DNS-Server der Firma Syscon. Die Gesamtmigration wird erst nach der IPA durchgeführt. Folgende Unteraufgaben sind zu lösen:

- Dokumentation des IST-Zustandes. Dem Kandidaten steht dafür ein Root-Zugang auf dem Xen-Server zur Verfügung:

• Xen-Server: Bezeichnung, Standort, OS, CPUs, Memory, Disks, RAID-Controller, RAID-Level, Partitionierung, Netzwerk-Interfaces, Netzwerk-Konfiguration (/etc/network/interfaces) & iptables-Konfiguration
• L3-Netzwerkdiagramm des Xen-Servers sowie aller virtueller Maschinen: Internet-Anbindung, Hostnames, Subnetze, Netzwerkadressen und Subnetzmasken, Ports und Dienste auf den VMs, Verwaltungszugänge auf den VMs, Ansprechpersonen
• Dokumentation der Erstellung der Image-Datei der Xen-VM krodokil.syscon.ch
  
  
  

1. Dokumentation des SOLL-Zustandes

• Proxmox-Server: Bezeichnung, OS, CPUs, Memory, Disks, RAID-Controller, RAID-Level, Partitionierung, Netzwerk-Interfaces, Netzwerk-Konfiguration
• L3-Netzwerkdiagramm der Testumgebung: Internet-Anbindung, Hostnames, Subnetze, Netzwerkadressen und Subnetzmasken, Ports und Dienste auf der VM, Verwaltungszugang auf der VM
  
  
  

1. Evaluation des geeigneten Proxmox-Storage

• Für die Proxmox-VMs bieten sich verschiedene Storage-Typen an, evaluieren Sie die geeignete
• Vergleichen Sie mindestens qcow2, raw, vmdk, Thin LVM, LVM
• Vergleichen Sie mindestens bezüglich folgender Kriterien: Performance, Thin Provisioning, Portability, Snapshots, Block-Storage, File-Storage, Stabilität
• Die Performance-Tests können vor der IPA durchgeführt werden, sollen aber dokumentiert sein

1. Aufbau der Testumgebung

• Firewall (bereits vor IPA konfiguriert): Adressierung soll dokumentiert werden
• Office Switch unmanaged
• Proxmox-Server:
  • OS: aktuelle Proxmox VE-Distribution, IP-Adresse fix, selbst bestimmt
  • Hostname: ozelot
  • FQDN: ozelot.syscon.ch
  • RAID-Level selbst gewählt, begründet
  • Partitionierung: Schema selbst gewählt
  • Proxmox-Storage: selbst gewählt, begründet
  • Zugänge alle verschlüsselt (SSH, HTTPS)
• Windows Test-PC: Um die Konfiguration zu prüfen steht ein Arbeitsplatzrechner mit Windows 10 zur Verfügung (vorgängig vorbereitet, soll dokumentiert werden)

1. Migration der VM von Hand

• Analyse der Image-Datei der Xen-VM krokodil.syscon.ch:
  • Art des Images
  • Filesystem
  • Kernel
  • OS
  • Bootloader
  • Xen-spezifische Anpassungen
    
    
    
• Aufbereiten des VM-Image:
  • Partitionierung
  • MBR
  • Bootloader
  • Xen-spezifische Anpassungen rückgängig machen
• Erzeugen einer Proxmox-VM mit Hilfe des aufbereiteten VM-Images
  
  
  

1. Automatische Migration

• Es soll ein Bash-Skript erstellt werden, mit welchem die unter 5. Realisierte Migration automatisiert werden kann
  
  
  

1. Migrationsplanung für die Gesamtmigration aller VMs. Es soll ein Grobkonzept für die Gesamtmigration aller VMs ausgearbeitet werden:

• Das aktuelle System wurde analysiert
• Die neuen Bedürfnisse sind abgeklärt
• Die zu migrierenden Daten sind vollständig erkannt
• Allfällige Datenkonversionen sind abgeklärt
• Der Migrationsprozess ist festgehalten
• Der «Point of no Return» ist zweckdienlich definiert
• Das Fallback-Szenario (oder «Plan B») ist festgelegt

1. Dokumentationen:

• Aufbereiten des VM-Image:
  • Partitionierung
  • MBR
  • Bootloader
  • Xen-spezifische Anpassungen rückgängig machen
• Erzeugen einer Proxmox-VM mit Hilfe des aufbereiteten VM-Images
• Dokumentation der Erstellung der Image-Datei der Xen-VM krokodil.syscon.ch
• L3-Netzwerkdiagramme IST- und SOLL-Zustand
• Erfassung Xen-Server (IST) und Proxmox-Server (SOLL)
• Evaluation des Proxmox-Storage
• Installationsanleitung Proxmox VE
• Beschreibung der manuellen Migration
• Kommentierter Code des Migrationsskripts
• Grobkonzept Gesamtmigration
  
  
  

1. Tests:

• Testumgebung ist aufgebaut, alle Geräte haben die vorgesehenen Hostnames und IP-Adressen
• Das migrierte System funktioniert einwandfrei, DNS-Ports sind freigeschaltet
• Verschlüsselung der Zugänge auf Proxmox

1.5 Vorkenntnisse

• Einführung in Xen-Server während des 3-monatigen Praktikums
• Arbeit mit Proxmox-Server

1.6 Vorarbeiten

• Firewall ist vorkonfiguriert
• Test-PC ist vor IPA bereitgestellt
• Xen-VM-Image von krokodil.syscon.ch liegt auf USB-Stick vor
• Performance-Tests der LVM-Storage durchgeführt zusammen mit dem Kandidaten Leon Tschudi
• Word-Vorlage für die IPA erstellt
• Projektmethode IPERKA zusammengefasst und als Vorlage an

2 Vorgehen

2.1 Projektmethode IPERKA

IPERKA ist eine Projektmethode, die bei Anwendung in einem Projekt eine strukturierte Vorgehensweise bevorzugt.

IPERKA steht für:

Informieren
Planen
Entscheiden
Realisieren
Kontrollieren
Auswerten

Diese Methode hat folgende Vorteile: 

• Die Projektphasen sind leicht zu merken, da der Name IPERKA aus den Anfangsbuchstaben der entsprechenden Phasen besteht: Informieren, Planen, Entscheiden, Realisieren, Kontrollieren und Auswerten.
• Diese Methode fördert den methodischen und strukturellen Ansatz, da die einzelnen Aktivitäten leicht den entsprechenden Projektphasen zugeordnet werden können.
• Oftmals wird zu wenig geplant und zu früh realisiert. IPERKA legt grossen Wert auf die Planung. Erst wenn ein solides Konzept erarbeitet und die Entscheidung darüber getroffen ist, welche Lösungsvariante umgesetzt wird, sollte mit der Realisierung begonnen werden.
• Oft wird davon ausgegangen, dass das notwendige Wissen im Projektteam bereits vorhanden ist. Die Phase «Informieren» beinhaltet beispielsweise auch, dass sich alle die notwendigen Kenntnisse über das Thema des Projekts aneignen.
• Eine Auswertung des Projekts ist ebenfalls Teil des strukturierten Ansatzes. Am Ende blickt man auf das Projekt zurück, wertet die Erfahrungen aus und zieht Lehren für zukünftige Projekte ähnlicher Art.

2.2 Dokumentation

2.2.1 Backup

Der Speicherort meiner Dokumentation befindet sich auf OneDrive. Dadurch kann ich nicht nur von überall auf die Doku zugreifen und sie bearbeiten, sondern es speichert mir alle Änderungen, die ich vornehme, automatisch in der Cloud ab. Zudem sind die Dokumente auf OneDrive meiner Fachkraft freigegeben.

Sollte OneDrive nicht verfügbar sein, sind die Dokumente auch auf meinem USB-Stick verfügbar.

2.2.2 Versionierung

Für jeden Arbeitstag habe ich einen Ordner erstellt, in dem sich eine neue Version des Dokuments befindet. Hierzu die Ordnerstruktur auf OneDrive…:

…und dieselbe Ordnerstruktur auf meinem USB-Stick:

3 Zeitplan

4 Arbeitsjournal

| TAG 3 ||

| TAG 4 ||

| TAG 5 ||

| TAG 6 ||

| TAG 7 ||

| TAG 8 ||

| TAG 9 ||

| TAG 10 ||

Teil 2 – Projekt

5 Kurzfassung IPA-Bericht

5.1 Ausgangssituation

Die Firma Syscon Systemberatungs AG verfügt über einen Server im Internet (ozelot.syscon.ch), auf welchem für eigene Dienste aber auch für externe Kunden virtuelle Maschinen (VMs) zur Verfügung gestellt werden. Die Basis für die VMs bildet die Community-Version der Virtualisierungsplattform Xen. Der X4100-Server von Sun ist inzwischen 10-jährig und sowohl von der Kapazität als auch von der Leistung her nicht mehr ausreichend. Es wurde deshalb beschlossen, auf eine neuere Hardware zu migrieren.
Neben der Migration auf eine neue Hardware soll auch die Virtualisierungsplattform auf das leichter zu verwaltende, KVM basierte Proxmox VE umgestellt werden. Dabei sind verschiedene Herausforderungen zu meistern. Bei den Xen-VMs handelt es sich ausnahmslos um Linux-Maschinen, die als LVM-Raw-Block-Devices mit einem Root- sowie einem Swap-Device aufgebaut sind. Das Root-Device verfügt weder über eine Partitionstabelle noch über einen MBR. Die VMs werden mit Hilfe des Xen-eigenen Bootloaders (PyGrub) gestartet. Damit sie in der Proxmox-Umgebung gebootet werden können, müssen die Raw-Block-Devices zunächst mit einer Partitionstabelle, einem MBR sowie einem eigenen Bootloader versehen werden. Zusätzlich müssen alle Xen-spezifischen Anpassungen in den VMs rückgängig gemacht werden.

5.2 Umsetzung

Für die Migration werden folgende Schritte durchgeführt:

• Erfassen und Definieren des IST- und SOLL-Zustandes
• Evaluation RAID-Level und Proxmox-Storage
• Aufsetzung des Proxmox-Servers
• Migration der Xen-VM von Hand
• Ein Bash-Skript für die automatisierte Migration erstellen
• Eine Migrationsplanung für die Gesamtmigration aller VMs erstellen
• Testszenario erstellen und durchführen

5.3 Ergebnis

Mit der neuen Hardware kann die Firma Syscon Systemberatungs AG von einer exponentiell höheren Systemleistung und einer einfacheren Benutzeroberfläche profitieren, während die Kundenzufriedenheit durch eine bessere VM-Performance erhöht wird.

6 Informieren

6.1 IST-Zustand

Die Firma Syscon Systemberatungs AG verfügt über einen produktiven Server mit verschiedenen VMs auf der Basis der Virtualisierungslösung Xen. Dieser Server soll auf eine neue Hardware migriert werden.

6.1.1 L3-Netzwerkplan

Der Layer 2-Switch ist im Netzwerkplan nicht angegeben.

6.1.2 Dokumentation Xen-Server

6.1.2.1 Systeminformationen

Die Systeminformationen habe ich durch Eingabe der folgenden Befehle abgerufen:

1. dmidecode system #Enthält eine Kurzbeschreibung des Systems, dessen Hardware und andere nützliche Informationen wie Seriennummern 
2.     
3. cat /proc/cpuinfo #Beschreibt die Eigenschaften des Prozessors im Detail
4.     
5. lspci #Listet alle PCI-Geräte auf  
6.   
7. fdisk -l #Listet alle Partitionstabellen auf  
8.     
9. parted -l #Listet alle Festplatten und deren Grössen in Bytes auf.  
10.       
11. mpt-status -i 2 #Ermittelt den RAID-Status  
12.   
13. xm info #Infos über Xen-Version  

| Bezeichnung | Sun Fire X4100 |

6.1.2.2 Konfiguration der Network-Interfaces

Inhalt von /etc/network/interfaces.

Die Interfaces mit einem Doppelpunkt sind sogenannte Aliases.
Mit Aliases kann man mehrere IP-Adressen einer einzigen Netzwerkkarte zuweisen.

1. # This file describes the network interfaces available on your system  
2. # and how to activate them. For more information, see interfaces(5).  
3.   
4. # The loopback network interface  
5. auto lo  
6. iface lo inet loopback  
7.   
8. # The primary network interface  
9. #allow-hotplug eth0  
10. #iface eth0 inet dhcp  
11. auto eth0  
12. iface eth0 inet static  
13.         address 62.12.167.102  
14.         netmask 255.255.255.240  
15.         network 62.12.167.96  
16.         broadcast 62.12.167.111  
17.         gateway 62.12.167.97  
18.   
19. auto eth0:0  
20. iface eth0:0 inet static  
21.         address 62.12.167.103  
22.         netmask 255.255.255.240  
23.         network 62.12.167.96  
24.         broadcast 62.12.167.111  
25.         gateway 62.12.167.97  
26.   
27. auto eth0:1  
28. iface eth0:1 inet static  
29.         address 62.12.167.104  
30.         netmask 255.255.255.240  
31.         network 62.12.167.96  
32.         broadcast 62.12.167.111  
33.         gateway 62.12.167.97  
34.   
35. auto eth0:2  
36. iface eth0:2 inet static  
37.         address 62.12.167.101  
38.         netmask 255.255.255.240  
39.         network 62.12.167.96  
40.         broadcast 62.12.167.111  
41.         gateway 62.12.167.97  
42.   
43. auto eth0:3  
44. iface eth0:3 inet static  
45.         address 62.12.167.106  
46.         netmask 255.255.255.240  
47.         network 62.12.167.96  
48.         broadcast 62.12.167.111  
49.         gateway 62.12.167.97  

6.1.2.3 Hosts-File des Xen-Servers

Mit /etc/hosts kann man Rechnernamen in IP-Adressen auflösen, wenn kein Nameserver im lokalen Netzwerk vorhanden ist.

1. 127.0.0.1       localhost  
2. 127.0.1.1       ozelot.syscon.ch        ozelot  
3.   
4. # The following lines are desirable for IPv6 capable hosts  
5. ::1     ip6-localhost ip6-loopback  
6. fe00::0 ip6-localnet  
7. ff00::0 ip6-mcastprefix  
8. ff02::1 ip6-allnodes  
9. ff02::2 ip6-allrouters  
10. 10.0.0.13       pfau.syscon.ch pfau  
11. 10.0.0.16       viper.syscon.ch viper  
12. 10.0.0.18       kolab.syscon.ch         kolab  
13. 10.0.0.20       krokodil.syscon.ch      krokodil  
14. 10.0.0.80       verkehr2.kalkbreite.net verkehr2  
15. 10.0.0.90       sbs.syscon.ch  
16. 10.0.0.91       psol.syscon.ch          psol  
17. 10.0.0.100      biber01.syscon.ch       biber01         biber           biber.syscon.ch  

6.1.2.4IP-Tables des Xen-Servers

Die Datei /etc/network/if-up.d/iptables verwendet Skripts, um die Firewall unter Linux zu konfigurieren. Es wird auch für Portforwarding verwendet. Über die Ports habe ich die Dienste herausgefunden und als Kommentar dokumentiert.

1. #!/bin/sh  
2.   
3. # kolab.syscon.ch (Groupware Server)  
4. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 –dport 25 -j DNAT –to 10.0.0.18:25 #SMTP
5. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 –dport 80 -j DNAT –to 10.0.0.18:80 #HTTP
6. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 –dport 110 -j DNAT –to 10.0.0.18:110 #POP3
7. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 –dport 143 -j DNAT –to 10.0.0.18:143 #IMAP
8. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 –dport 443 -j DNAT –to 10.0.0.18:443 #HTTPS
9. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 –dport 465 -j DNAT –to 10.0.0.18:465 #SMTPS 
10. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 –dport 587 -j DNAT –to 10.0.0.18:587 #MSA 
11. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 –dport 993 -j DNAT –to 10.0.0.18:993 #IMAPS 
12. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 –dport 995 -j DNAT –to 10.0.0.18:995 #POP3S 
13.   
14. #krokodil.syscon.ch (DNS-Server)  
15. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 –dport 53 -j DNAT –to 10.0.0.20:53 #DNS
16. iptables -A PREROUTING -t nat -p udp -d 62.12.167.104 –dport 53 -j DNAT –to 10.0.0.20:53 #DNS
17.   
18. #sbs.syscon.ch (Demo SBS)  
19. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 –dport 443 -j DNAT –to 10.0.0.90:443 #HTTPS
20. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 –dport 80 -j DNAT –to 10.0.0.90:80 #HTTP
21. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.102 –dport 2222 -j DNAT –to 10.0.0.90:22 #SSH
22.   
23. #pfau.syscon.ch (Webserver Plone)  
24. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.102 –dport 22 -j DNAT –to 10.0.0.13:22 #SSH
25. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.102 –dport 443 -j DNAT –to 10.0.0.13:443 #HTTPS
26. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.102 –dport 80 -j DNAT –to 10.0.0.13:80 #HTTP
27.   
28. #ozelot.syscon.ch (Xen-Dom0)  
29. iptables -A INPUT -d 62.12.167.102 -p tcp –dport 223 -j ACCEPT  
30.   
31. #verkehr2.kalkbreite.net (Webserver Kalkbreite)  
32. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 –dport 25 –src 62.12.167.96/28 -j DNAT –to 10.0.0.80:25 #SMTP
33. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 –dport 223 -j DNAT –to 10.0.0.80:22 #SSH
34. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 –dport 8223 -j DNAT –to 10.0.0.80:80 #HTTP
35.   
36. #biber.syscon.ch (Mailserver + Webserver)  
37. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 –dport 21 -j DNAT –to 10.0.0.100:21 #FTP
38. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 –dport 25 -j DNAT –to 10.0.0.100:25 #SMTP
39. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 –dport 80 -j DNAT –to 10.0.0.100:80 #HTTP
40. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 –dport 110 -j DNAT –to 10.0.0.100:110 #POP3
41. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 –dport 143 -j DNAT –to 10.0.0.100:143 #IMAP
42. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 –dport 443 -j DNAT –to 10.0.0.100:443 #HTTPS
43. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 –dport 465 -j DNAT –to 10.0.0.100:465 #SMTPS
44. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 –dport 587 -j DNAT –to 10.0.0.100:587 #MSA
45. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 –dport 993 -j DNAT –to 10.0.0.100:993 #IMAPS
46. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 –dport 995 -j DNAT –to 10.0.0.100:995 #POP3S
47. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 –dport 8080 -j DNAT –to 10.0.0.100:8080 #HTTPS (Verwaltungsinterface des Mail-Servers)
48.   
49. #viper.syscon.ch (Webshop Magento)  
50. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.106 –dport 80 -j DNAT –to 10.0.0.16:80 #HTTP
51. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.106 –dport 22 -j DNAT –to 10.0.0.16:22 #SSH
52.   
53. #psol.syscon.ch (Syscon SBS fuer Kunden)  
54. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.106 –dport 2222 -j DNAT –to 10.0.0.91:22 #SSH
55. iptables -A PREROUTING -t nat -p tcp -d 62.12.167.106 –dport 443 -j DNAT –to 10.0.0.91:443 #HTTPS
56.   
57. ### Port Forwarding SNAT ###  
58. iptables -t nat -I POSTROUTING -s 10.0.0.100 -j SNAT –to 62.12.167.103  
59. iptables -t nat -I POSTROUTING -s 10.0.0.20 -j SNAT –to 62.12.167.104  
60. iptables -t nat -I POSTROUTING -s 10.0.0.18 -j SNAT –to 62.12.167.101  
61. iptables -t nat -I POSTROUTING -s 10.0.0.16 -j SNAT –to 62.12.167.106  

6.1.2.5 Verwaltungszugang auf der VM

Nach dem Starten der VM mit «xl create /etc/xen/krokodil.syscon.ch.cfg» wird der Verwaltungszugriff auf die VM durch den folgenden Befehl gewährt:

1. xm console <ID>  

Jetzt müssen wir nur noch die ID unserer VM herausfinden. Dies machen wir mit dem Befehl «xm list»:

1. root@ozelot:/etc/xen# xm list
2. Name                                        ID   Mem VCPUs      State   Time(s)
3. Domain-0                                     0  2920     4     r—– 385241.5  
4. biber01.syscon.ch                           45  1024     2     -b—-  27914.7  
5. demo.syscon.ch                              42   512     2     -b—-   9646.6  
6. kolab.syscon.ch                             46  1024     2     -b—-  11971.0  
7. krokodil.syscon.ch                           4   512     1     -b—-   7556.2  
8. pfau.syscon.ch                              49  2048     2     -b—-   2659.3  
9. psol.syscon.ch                              35  1024     1     -b—-  48735.7  
10. verkehr2.kalkbreite.net                     47  1024     2     -b—-   1959.8  
11. viper.syscon.ch                             36   512     2     -b—- 169966.5  

Mit der erlangten ID können wir nun Zugriff auf die entsprechende VM erhalten:

1. xm console 4

Die Konsole kann durch Drücken von Ctrl + ] verlassen werden, oder Ctrl + 5, wenn wir Putty verwenden.

Dieses Vorgehen gilt für alle VMs.

6.1.2.6 Konfigurations-File der DomU ‘krokodil.syscon.ch’

Wenn wir unserer VM eine andere IP-Adresse, eine andere MAC-Adresse, mehr Arbeitsspeicher usw. zuweisen wollen, können wir die Datei /etc/xen/<DomU>.cfg, oder in diesem Fall /etc/xen/krokodil.syscon.ch.cfg verwenden, um eventuelle Änderungen vorzunehmen:

1. #  
2. # Configuration file for the Xen instance krokodil.syscon.ch, created  
3. # by Xen-tools 4.2 on Thu Mar 31 17:25:48 2011.  
4. #  
5.   
6. #  
7. #  Kernel + memory size  
8. #  
9.   
10.   
11. bootloader = '/usr/lib/Xen-default/bin/PyGrub'  
12.   
13. vcpus       = '1'  
14. memory      = '512'  
15.   
16. #  
17. #  Disk device(s).  
18. #  
19. root        = '/dev/xvda2 ro'  
20. disk        = [  
21.                   'phy:/dev/vg0/krokodil.syscon.ch-root,xvda2,w',  
22.                   'phy:/dev/vg0/krokodil.syscon.ch-swap,xvda1,w',  
23.               ]  
24.   
25.   
26. #  
27. #  Physical volumes  
28. #  
29.   
30.   
31. #  
32. #  Hostname  
33. #  
34. name        = 'krokodil.syscon.ch'  
35.   
36. #  
37. #  Networking  
38. #  
39. vif         = [ 'ip=10.0.0.20,mac=00:16:3E:1D:86:58' ]  
40.   
41. #  
42. #  Behaviour  
43. #  
44. on_poweroff = 'destroy'  
45. on_reboot   = 'restart'  
46. on_crash    = 'restart'  

6.1.3 Erstellen des VM-Images auf dem Originalserver

Auf dem Originalserver wurde ein Raw-Image der VM krokodil.syscon.ch erstellt. Dazu wurde zunächst ein verschlüsselter Zugriff auf dem Server via SSH eingerichtet. 

Mit dem Befehl «lvscan» können wir den Standort der zu migrierenden VM finden:

1. ACTIVE            '/dev/vg0/krokodil.syscon.ch-root' [8.00 GiB] inherit  

Für dieses Logical Volume erzeugen wir einen Snapshot:

1. lvcreate -L5G -sn snap-krokodil.syscon.ch-root /dev/vg0/krokodil.syscon.ch-root
3. #-L[Grösse] = Grösse des Snapshots  
4. #-s = Snapshot erstellen  
5. #-n = Name des Snapshots  

Mit dem Befehl «dd» können wir nun ein Image aus dem Snapshot erstellen:

1. dd if=/dev/vg0/snap-krokodil.syscon.ch-root of=/Xenbkp/krokodil.syscon.ch-root.img  

Wie in der Aufgabenstellung vermerkt, wurde mir dieses Image auf einem USB-Stick zur Verfügung gestellt.

6.1.4 Analyse des VM-Images

1. Der USB-Stick mit dem Raw-Image wird an einem USB 2.0 Port mit «mount /dev/sdb1 /mnt» eingebunden.
2. Das Raw-Image «krokodil.syscon.ch-root.img» wird ins Verzeichnis /home/lukas kopiert und danach der Stick mit dem Befehl «umount /dev/sdb1» ausgehängt.
3. Der Befehl «file krokodil.syscon.ch-root.img» zeigt:

Es handelt sich um ein ext3-formatiertes Raw-Image. Dieses Image sollte sich direkt mit dem mount-Befehl einbinden lassen.

1. Das Raw-Image wird gemountet mit «mount /home/lukas/krokodil.syscon.ch-root.img /mnt».
2. Um eine VM in Proxmox starten zu können, braucht es einen MBR, eine Partitionstabelle und einen Bootloader.

6.1.5 Xen-spezifische Anpassungen

Von der Beschäftigung mit Xen ist bekannt, dass Xen die Partitionen anders benennt als Proxmox. Die Benennung der Partitionen, die während des Systemstarts eingebunden werden, befinden sich in «etc/fstab». Der Befehl «cat /mnt/etc/fstab» zeigt folgenden Inhalt:

In Zeile 7 wird die Root-Partition eingebunden, in Zeile 5 die Swap-Partition. Die Partitionsbezeichnungen «xvda1» und «xvda2» müssen für Proxmox angepasst werden, da dieser anstatt «xvdx» die Bezeichnung «sdx» verwendet.

Die nächste und letzte Datei, an der wir Änderungen vornehmen müssen, ist inittab.

Diese Datei bestimmt, was passiert, wenn ein System neu gestartet wird oder gezwungen wird, den Runlevel (Zustand des Systems) zu wechseln.

Untenstehend ist der Ausschnitt, an dem Änderungen vorgenommen werden müssen:

1. 1:2345:respawn:/sbin/getty 38400 hvc0  
2. #2:23:respawn:/sbin/getty 38400 tty2  
3. #3:23:respawn:/sbin/getty 38400 tty3  
4. #4:23:respawn:/sbin/getty 38400 tty4  
5. #5:23:respawn:/sbin/getty 38400 tty5  
6. #6:23:respawn:/sbin/getty 38400 tty6  

In Xen wird die merkwürdige Abkürzung «tty» (=Terminal) durch «hvc» ersetzt. Diese muss wieder auf «tty1» geändert werden.

Der Serververantwortliche bestätigte mir, dass jede VM dieselben Xen-spezifischen Änderungen aufweist.

6.1.6 Windows Test-PC

Folgend sind die Spezifikationen des PCs, der mir zur Verfügung gestellt wurde:

7 Planen

7.1 SOLL-Zustand

7.1.1 L3-Netzwerkplan Testumgebung

7.1.2 Dokumentation Proxmox-Server

7.1.2.1 Systeminformationen 

7.1.2.2 Konfiguration der Network-Interfaces des Proxmox-Servers

Inhalt von /etc/network/interfaces.

1. auto lo  
2. iface lo inet loopback  
3.   
4. iface eno1 inet manual  
5.   
6. auto vmbr0  
7. iface vmbr0 inet static  
8.         address 192.168.20.20  
9.         netmask 255.255.255.0  
10.         gateway 192.168.20.1  
11.         bridge_ports eno1  
12.         bridge_stp off  
13.         bridge_fd 0  
14.   
15. iface eno2 inet manual  

7.1.2.3 Konfiguration der Network-Interfaces von krokodil.syscon.ch

1. auto lo  
2. iface lo inet loopback  
3.   
4. #Siehe SOLL-Netzwerkplan
5. auto eth0  
6. iface eth0 inet static  
7.  address 192.168.20.21  
8.  gateway 192.168.20.1  
9.  netmask 255.255.255.0  

7.1.2.4 Ports und Dienste auf der VM

Ports: 20 (SSH), 53 (DNS)

Dienste: DNS

7.1.2.5 Verwaltungszugang auf der VM

Der Verwaltungszugang erfolgt über das Webinterface. Nach dem Starten der VM greift man auf das Terminal mit der Schaltfläche «Console» zu:

7.2 Projektumfeld

Da drei Personen im gleichen Raum arbeiten, muss das Netzwerk im Projektumfeld so eingerichtet sein, dass sich unsere Geräte nicht gegenseitig beeinträchtigen. Mit anderen Worten, der Umbau des Netzwerks wird verhindern, dass eines unserer Geräte eine IP-Adresse zugewiesen bekommt, die bereits vergeben ist.

Um dies zu realisieren, wird jedem von uns eine eigene DMZ (Demilitarized Zone) in jeweils einem anderen Subnetz zugewiesen. Um das Umfeld übersichtlich zu gestalten, werden auch jedes Gerät und jedes Netzwerkkabel entsprechend etikettiert.

7.3 Benötigte Ressourcen (Hardware und Software)

Hardware:

• Server
• Firewall
• Switch
• PC

Software:

• Microsoft Office
• Putty

7.4 Meilensteine

Gemäss Zeitplan:

7.5 Kontrolle Erreichung SOLL-Zustand

Zur Erfolgskontrolle werden folgende Schritte durchgeführt:

1. IST-Zustand im Zeitplan eintragen
2. IST-IST Vergleich: ein Vergleich der Ausgangssituation mit der aktuellen Situation ermitteln. Sind die Arbeitspakete realistisch verteilt?
3. SOLL-IST Vergleich: ein Vergleich der aktuellen Situation mit der gewünschten Situation ermitteln. Bin ich im Zeitplan richtig?

8 Entscheiden

In diesem Kapitel werden die folgenden Schwerpunkte evaluiert, um die Anforderungen des SOLL-Zustandes zu erfüllen:

• RAID-Level
• Proxmox-Storage

8.1 Evaluation RAID-Level für Proxmox Server

Ein RAID (Redundant Array of Independent Disks) dient dazu, die Zuverlässigkeit und Leistung der Daten zu erhöhen. Wenn Festplatten zusammen in einem RAID-Array laufen (abhängig vom RAID-Level), können die Laufwerke redundante Kopien der Daten speichern und/oder die Lesegeschwindigkeit erhöhen, indem sie kleinere Blöcke von Daten auf mehrere Laufwerke verteilen.

Ein paar der wichtigsten RAID-Levels sind:

RAID 0:
Die Daten werden über eine Reihe von Laufwerken verteilt, um die Leistung zu erhöhen. Dies geschieht dadurch, dass zwei Platten mithilfe von RAID 0 im Prinzip kombiniert werden, was die Anzahl der IOPS (Input/Output Operations Per Second) in der Regel* verdoppelt.

RAID 0 sichert die Daten wie andere Arrays nicht, also wenn ein einzelnes Laufwerk ausfällt, gehen alle Daten auf dem Array verloren.

*Das Schlüsselwort hier ist „up to“: Aufgrund der Art des Stripings und der Datenausrichtung, wenn sich die zufällig aufgerufenen Sektoren überwiegend auf einer einzigen Festplatte befinden, endet man mit viel niedrigeren IOPS.

RAID 1
Alle Daten auf einem Laufwerk werden parallel auf jedes andere Laufwerk im Array kopiert. RAID 1 bietet die doppelte Leserate, aber die Schreibgeschwindigkeit eines einzelnen Laufwerks.

RAID 01 (ist nicht dasselbe wie RAID 10)
Es werden zwei oder mehr RAID 0-Arrays erstellt, die jeweils über ein übergeordnetes RAID 1-Array gespiegelt werden (bei RAID 10 wäre es umgekehrt). Gemäss Definition erfordert diese Konfiguration mindestens 4 Laufwerke.

RAID 5
Bietet sowohl Sicherung als auch erhöhte Leistung. Zusätzlich kann ein RAID 5-Array weiterhin normal arbeiten, wenn eines seiner Laufwerke ausfällt. Die Leistungsgeschwindigkeit des Arrays wird reduziert, bis das ausgefallene Laufwerk ausgetauscht wird, aber es würde kein Datenverlust auftreten. Dieses Array benötigt mindestens 3 Laufwerke.

RAID 6
Ähnlich wie RAID 5 bietet RAID 6 sowohl Sicherung als auch erhöhte Leistung. Zudem kann ein RAID 6-Array bei Ausfall von bis zu zwei seiner Laufwerke weiterarbeiten. Hierfür sind mindestens 4 Laufwerke notwendig.

Bilder: https://www.aja.com/pdf/support/RAID_Cheat_Sheet.pdf

8.1.1 KO-Kriterien

8.1.2 Präferenzmatrix für RAID 5 und RAID 6

Die Gewichtungen wurden vorgängig vom Kunden festgelegt.

Skala: 0-10

Obwohl RAID 5 und RAID 6 sehr ähnlich sind, erwies sich RAID 5 letztendlich als die bessere Option, da es im Gegensatz zu RAID 6 nur ein Laufwerk als Redundanz verwendet anstelle von zwei.

Wenn es bspw. mindestens zehn Laufwerke im RAID gegeben hätte, dann hätte ich RAID 6 als die bessere Option angesehen, da ein Ausfall mehrerer Festplatten im Gegensatz zu RAID 5 kein so grosses Problem dargestellt hätte.

8.2 Evaluation Proxmox-Storage

Die folgenden Schwerpunkte werden bei jedem Speicherformat ausgewertet:

• Unterstützt das Format Snapshots?
• Funktioniert das Format bei einem RAID?
• Unterstützt das Format Thin Provisioning?

Ähnlich wie bei der RAID-Evaluation scheiden zuerst die Formate aus, die unsere KO-Kriterien nicht erfüllen. Diesmal jedoch treten die restlichen Konkurrenten in einem Geschwindigkeitstest an, da die Geschwindigkeit der Hauptfaktor in der Bewertung sein wird. Bevor wir aber die Speicherformate evaluieren, hier noch ein kurzer Überblick über die wichtigsten Eigenschaften der jeweiligen Formate:

QEMU Image Format (qcow):
qcow ist ein Dateiformat für Disk-Image-Dateien, das von QEMU, einem gehosteten Monitor für virtuelle Maschinen, verwendet wird. Es steht für «QEMU Copy On Write» und verwendet eine Strategie zur Optimierung des Festplattenspeichers, die die Zuweisung von Speicherplatz verzögert, bis er tatsächlich benötigt wird. Es gibt zwei Versionen des Formats: qcow und qcow2.

Raw Disk Image:
Ein Raw Disk Image enthält eine exakte, sektorweise Kopie einer einzelnen Partition oder Festplatte.

VMware Image (vmdk):
vmdk (kurz für Virtual Machine Disk) ist ein Dateiformat, das Container für virtuelle Festplattenlaufwerke beschreibt, die in virtuellen Maschinen wie VMware Workstation oder VirtualBox verwendet werden.

LVM:
Unter Linux ist der Logical Volume Manager (LVM) ein Gerätezuordnungsziel, das die logische Datenträgerverwaltung für den Linux-Kernel bereitstellt.

LVM-Thin:
LVM weist normalerweise Blöcke zu, wenn ein Volume erstellt wird. LVM-Thin weist stattdessen Blöcke zu, wenn sie geschrieben werden. (Ähnlich wie bei QEMU.) Dieses Verhalten wird Thin Provisioning genannt.

ZFS:
ZFS ist ein kombinierter Dateisystem- und logischer Volume-Manager, entwickelt von Sun Microsystems. ZFS ist skalierbar und bietet umfassenden Schutz vor Datenkorruption, Unterstützung hoher Speicherkapazitäten, effiziente Datenkompression, Snapshots und Copy-on-Write-Klone, kontinuierliche Integritätsprüfung, automatische Reparatur und kann sehr präzise konfiguriert werden.

Quelle: https://pve.proxmox.com/wiki/Storage

*Die Gewichtung richtet sich nach den Bedürfnissen der Migration.

Die Leistung der beiden prominentesten Speicherformate habe ich bereits vor der IPA (siehe Vorarbeiten) mit einem Programm namens Fio (Flexible I/O Tester) getestet. Mit Fio können Geräte wie Festplatten oder SSDs bezüglich ihrer Geschwindigkeit getestet werden, indem ein vom User definierter Workload ausgeführt und Performance-Daten gesammelt werden.

Für die Performance-Messung wurde auf einem Proxmox-Host-System je eine 20 GB grosse virtuelle Platte im qcow2-Format bzw. als LVM-Thin-Image angelegt und mit folgendem Befehl getestet:

1. fio –randrepeat=1 –ioengine=libaio –direct=1 –gtod_reduce=1 –name=test –filename=random_read_write.fio –bs=4k –iodepth=64 –size=1G –readwrite=randrw –rwmixread=75

Hier sind die Resultate des Tests:

QEMU Image Format:

1. READ: io=785812KB, aggrb=3302KB/s, minb=3302KB/s, maxb=3302KB/s, mint=237971msec, maxt=237971msec    
2. WRITE: io=262764KB, aggrb=1104KB/s, minb=1104KB/s, maxb=1104KB/s, mint=237971msec, maxt=237971msec  

LVM-Thin:

1. READ: io=785812KB, aggrb=11757KB/s, minb=11757KB/s, maxb=11757KB/s, mint=66836msec, maxt=66836msec    
2. WRITE: io=262764KB, aggrb=3931KB/s, minb=3931KB/s, maxb=3931KB/s, mint=66836msec, maxt=66836msec    

Dem aggregierten Wert aggrb= kann man entnehmen, dass LVM-Thin sowohl beim Lesen als auch beim Schreiben viermal so schnell ist wie QEMU. Da wäre LVM-Thin ja ein durchaus fleissiger Schriftsteller! Was für einen Einfluss diese Leistung auf unsere Evaluation haben wird, sehen wir in der folgenden Präferenzmatrix.

8.2.1 Präferenzmatrix der beiden Storage-Formate QEMU und LVM-Thin

Wiederum hier wurden die Gewichtungen vorgängig mit dem Kunden zusammen festgelegt:

Skala: 0-10

Die Entscheidung fällt klar auf LVM-Thin.

8.3 Erstellen der Arbeitspakete

9 Realisieren

9.1 Aufbau der Testumgebung

Um während der IPA in meinem eigenen Subnetz arbeiten zu können, wurden ich und meine Kollegen beauftragt, unsere Testumgebung folgendermassen anzupassen:

Der Server ganz oben ist derjenige, mit dem ich arbeite. Dieser ist mit einem unmanaged Switch verbunden, der wiederum mit der Firewall verkabelt ist und so eine DMZ bildet.

Folgend sind die IP-Adressen aller Nodes aufgeführt:

9.1.1 Proxmox-Server

Mit den evaluierten RAID-Levels und Proxmox Storages haben wir festgestellt, dass die Verwendung von LVM-Thin als primäre Option und die Einrichtung unserer Laufwerke mit RAID 5 unsere beste Wahl ist (siehe Kapitel 8). Die Begründung lautet wie folgt:

Mit LVM-Thin (Thin Provisioning) profitieren wir zunächst einmal davon, dass wenn wir bei der Erstellung unserer VMs davon ausgehen, dass wir 5 GB einer VM zuweisen und das System nur 2 GB verwendet, stehen die verbleibenden 3 GB im sogenannten Thin Pool frei zur Verfügung. Das bedeutet zum Beispiel, wenn ich 15 GB Speicherplatz zur Verfügung habe und jeweils 5 GB für 3 Clients reserviere, hätte ich mit ziemlicher Sicherheit immer noch Platz für einen vierten Client, da der von den anderen 3 Clients ungenutzte Speicher für die Erstellung eines vierten Clients verwendet werden kann und somit nicht als verschwendeter Speicher gilt.

Zudem ist LVM-Thin, wie die Performance-Tests bei der Evaluierung gezeigt haben, recht schnell. Zwar schlägt Raw die anderen immer noch um ein Mehrfaches, aber auch LVM-Thin ist keineswegs langsam.

Was das RAID betrifft, legte ich den Fokus sowohl auf Kapazität als auch auf Zuverlässigkeit, weshalb ich RAID 5 den anderen RAID-Levels vorzog. RAID 6 war ziemlich nah dran, da es sich nur geringfügig von RAID 5 unterscheidet, aber da RAID 5 nur ein Laufwerk für die Redundanz anstelle von zwei verwendet - was bei vier Laufwerken meiner Meinung nach nicht wirklich vonnöten ist - gibt es uns mehr Speicherplatz zur Verfügung.

9.2 RAID konfigurieren auf dem Proxmox Server

Durch Drücken von Ctrl + R während des Bootvorgangs gelangen wir zum RAID-Controller.

Untenstehend sehen wir unsere Laufwerke als unkonfiguriert, was darauf hindeutet, dass unsere Festplatten von unserem Server korrekt erkannt werden und somit bereit sind, für ein RAID konfiguriert zu werden.

Dies geschieht durch Auswahl des RAID-Controllers und der Option «Create New VD (Virtual Disk)»:

Hierdurch wird das folgende Menü geöffnet. Hier wählen wir RAID 5 als unseren RAID-Level, wählen jede unserer Festplatten aus und schliessen die Konfiguration mit «OK» ab:

Nun, noch nicht ganz. Wie das System uns mitteilt, wird empfohlen, zuerst die logischen Laufwerke zu initialisieren:

Diese Option finden wir unter «Advanced Settings»:

Und wie folgt, ist unsere RAID-Konfiguration somit abgeschlossen:

9.3 Proxmox Grundinstallation

Für die Installation von Proxmox verwenden wir ein bootfähiges USB-Laufwerk, auf dem sich die neueste Version des Installations-Images befindet.

Folgend ist die Netzwerkkonfiguration des Systems. Den Rest der Installation belassen wir bei den Standardeinstellungen.

Nach Drücken von «Install» soll es nur ein paar wenige Minuten dauern…:

Et voila. Schon ist unser Server einsatzbereit:

9.4 Migration der VM von Hand

Zunächst habe ich auf Google verschiedene Anleitungen gefunden. Zusätzlich habe ich noch den Link zu einer Anleitung von meiner Fachkraft bekommen:
https://blog.filippo.io/converting-a-partition-image-to-a-bootable-disk-image/

Da das von meiner Fachkraft gefundene Tutorial am hilfreichsten erschien, habe ich es für die Migration verwendet.

Folgende Schritte sind enthalten:

1. Anlegen von Partitionstabelle und MBR (Master Boot Record)
2. Anlegen des Bootloaders
3. Xen-spezifische Anpassungen rückgängig machen

Nach sorgfältiger Durchführung des Tutorials stellte sich heraus, dass die Anleitung an die Migration angepasst werden musste, damit die VM in Proxmox funktionieren kann (siehe Kapitel 9.4.2). Ich bin eigentlich froh darüber, denn wenn die VM auf Anhieb funktioniert hätte, wäre die IPA ja zu einfach gewesen.

9.4.1 Anlegen von Partitionstabelle und MBR

Zunächst brauchen wir vor der ersten Partition einen Bereich von 1 MB zur Aufnahme von einem MBR und einem Bootloader. Mit dem folgenden Befehl erzeugen wir zu diesem Zweck ein kleines Image, das nur aus Nullen besteht:

1. dd if=/dev/zero of=/home/lukas/new-krokodil.syscon.ch-root.img count=1 bs=1MiB  

Dieses hängen wir hinter dem Original-Image mit einem Programm namens «pv» an:

1. apt install -y pv
3. pv krokodil.syscon.ch-root.img » new-krokodil.syscon.ch-root.img

Mit «fdisk» erstellen wir nun eine Partitionstabelle…:

1. fdisk new-krokodil.syscon.ch-root.img  

…und geben nacheinander folgende Parameter ein:

1. n #neue Partition  
2. p #primäre Partition  
3. 1 #Partitionsnummer  
4.   
5. #Die Sektorgrössen lassen wir bei den Standardwerten, die ext-Signatur wird nicht gelöscht.  
6.   
7. a #Partition bootbar machen  
8. w #Änderungen übernehmen  

Daraus ergibt sich ein Image mit der zu migrierenden Xen-VM und einer leeren, bootfähigen Partition, in der wir gleich anschliessend einen Bootloader installieren werden.

9.4.2 Anlegen des Bootloaders

Theoretisch könnten wir den Bootloader bereits jetzt installieren, aber nach gründlichen Tests stellte sich heraus, dass wir zusätzlich noch ein paar Schritte durchführen müssen, damit die VM einwandfrei funktionieren kann.

Zunächst einmal, anstatt das Image mit der Xen-VM zu migrieren und daraus eine Proxmox-VM zu erzeugen, machen wir es umgekehrt und erstellen zuerst die Proxmox-VM im Webinterface gemäss den Angaben in Kapitel 6.1.2.6 und ersetzen deren Inhalt später durch das Image:

Da wir den Inhalt der Proxmox-VM über das Terminal ersetzen, anstatt ein Installationsimage zu verwenden, wählen wir «Do not use any media»:

Die Xen-VM ist ca. 8 GB gross, also runden wir die Grösse der Proxmox-VM auf 10 GB:

Der Xen-VM wurde bisher ein Kern zugeordnet, also weisen wir ihr auch hier einen Kern zu:

Das Gleiche gilt auch für den Arbeitsspeicher:

Die neue VM wird an die interne Bridge vmbr0 angeschlossen. Die restlichen Netzwerkeinstellungen lassen wir so, wie sie sind:

Abschliessend bestätigen wir die Erstellung mit «Finish»:

Zusätzlich wollen wir der VM noch eine Swap-Disk anlegen, welche wie bei einer Auslagerungsdatei in Windows als Reserve für den Arbeitsspeicher dient. Für dies erstellen wir eine neue virtuelle Hard Disk mit der Grösse von 2 GB:

Da ich keine Möglichkeit gefunden habe, eine Swap-Disk mithilfe des Webinterfaces zu erstellen, machen wir dies stattdessen mit dem Terminal. Zunächst müssen wir herausfinden, wo Proxmox die virtuellen Hard Disks anlegt. Nach einer einfachen Google-Suche stellte sich heraus, dass sich die Disks in /dev/pve befinden:

1. root@ozelot:/home/lukas# ls /dev/pve  
2. root  swap  vm-100-disk-0  vm-100-disk-1  

Mit «mkswap» verwandeln wir die 2 GB grossen Disk in eine Swap-Disk:

1. root@ozelot:/home/lukas# mkswap /dev/pve/vm-100-disk-1  
2. Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)  
3. no label, UUID=9a38f80c-a083-47be-8b30-4fe026985f0a  

Nach der Erstellung der Proxmox-VM können wir jetzt dieses durch unser Image ersetzen. Dies machen wir wiederum mit dem Kopierbefehl «dd»:

1. dd if=/home/lukas/new-krokodil.syscon.ch-root.img of=/dev/pve/vm-100-disk-0  

Jetzt kommen wir endlich zum Teil, wo wir den Bootloader installieren können. Hierfür müssen wir die VM zunächst in die Partition zerlegen, die wir im vorherigen Kapitel mit «fdisk» erstellt haben, um sie mountbar zu machen. Dies machen wir mit einem Programm namens «kpartx»:

1. apt install -y kpartx  
2.     
3. kpartx -a /dev/pve/vm-100-disk-0
4. #-a = Legt die Partition in /dev/mapper. Partitionen, die mit kpartx zerlegt wurden, nennt man auch «device maps» oder «device mappings»

Nun mounten wir die zerlegte Partition in den Mount-Punkt /mnt…:

1. mount /dev/mapper/pve-vm–100–disk—0p1 /mnt

…und installieren abschliessend den Bootloader mit dem folgenden Befehl:

1. grub-install –target=i386-pc –recheck –debug –boot-directory=/mnt/boot /dev/mapper/pve-vm–100–disk–0  

9.4.3 Xen-spezifische Anpassungen rückgängig machen

Anders als bei anderen Virtualisierungsplattformen verfügt Xen über eine eigene Methode um VMs zu betreiben. Damit unsere VM also auf Proxmox laufen kann, müssen wir Änderungen in den folgenden Konfigurationsdateien vornehmen:

• /etc/fstab
• /etc/inittab
• /etc/resolv.conf
• /boot/grub/grub.cfg

Ausgenommen von /boot/grub/grub.cfg erfolgt eine Änderung, indem wir mit «nano» die jeweiligen Werte anpassen:

1. nano /mnt/<Pfad>/<Konfigurationsdatei>

Für /boot/grub/grub.cfg verwenden wir den Befehl «grub-mkconfig», da es sich hier um eine komplette Neukonfiguration des Bootloaders handelt.

1. /etc/fstab

Die fstab-Datei listet alle verfügbaren Festplattenpartitionen und andere Arten von Dateisystemen auf und gibt an, wie sie während des Bootvorgangs gemountet werden sollen.

Geändert wird das in Rot:

1. # /etc/fstab: static file system information.  
2. #  
3. # <file system> <mount point>   <type>  <options>       <dump>  <pass>  
4. proc            /proc           proc    defaults        0       0  
5. devpts          /dev/pts        devpts  rw,noexec,nosuid,gid=5,mode=620 0  0  
6. /dev/xvda1 none swap sw 0 0  
7. #/dev/xvda2 / ext3 sync,errors=remount-ro 0 1  
8. /dev/xvda2 / ext3 errors=remount-ro 0

Ersetzt wird «xvda1» durch «sdb» und «xvda2» durch «sda1»:

1. # /etc/fstab: static file system information.  
2. #  
3. # <file system> <mount point>   <type>  <options>       <dump>  <pass>  
4. proc            /proc           proc    defaults        0       0  
5. devpts          /dev/pts        devpts  rw,noexec,nosuid,gid=5,mode=620 0  0  
6. /dev/sdb none swap sw 0 0  
7. #/dev/xvda2 / ext3 sync,errors=remount-ro 0 1  
8. /dev/sda1 / ext3 errors=remount-ro 0 1

Um die Änderungen zu übernehmen, drücken wir Ctrl + O und Ctrl + X.

9.4.3.2 /etc/inittab

Diese Datei definiert drei Elemente für den init-Prozess:

• Das Standard-Runlevel
• Welche Prozesse gestartet, überwacht und neu gestartet werden sollen, wenn sie beendet werden
• Welche Massnahmen zu ergreifen sind, wenn das System in ein neues Runlevel eintritt.

Sobald alle Einträge in /etc/inittab für das Runlevel ausgeführt wurden, ist der Bootvorgang abgeschlossen und man kann sich anmelden.

Folgend ist nur der Teil dargestellt, der geändert werden muss. Diese Änderung muss vorgenommen werden, da Xen und Proxmox zwei unterschiedliche Terminals/Serial Consoles verwenden:

1. 1:2345:respawn:/sbin/getty 38400 hvc0  
2. #2:23:respawn:/sbin/getty 38400 tty2  
3. #3:23:respawn:/sbin/getty 38400 tty3  
4. #4:23:respawn:/sbin/getty 38400 tty4  
5. #5:23:respawn:/sbin/getty 38400 tty5  
6. #6:23:respawn:/sbin/getty 38400 tty6  

Ersetzt wird «hvc0» zu «tty1»:

1. 1:2345:respawn:/sbin/getty 38400 tty1 
2. #2:23:respawn:/sbin/getty 38400 tty2  
3. #3:23:respawn:/sbin/getty 38400 tty3  
4. #4:23:respawn:/sbin/getty 38400 tty4  
5. #5:23:respawn:/sbin/getty 38400 tty5  
6. #6:23:respawn:/sbin/getty 38400 tty6  

1. /etc/resolv.conf

resolv.conf wird verwendet, um den DNS des Systems zu konfigurieren.

1. domain syscon.ch  
2. search syscon.ch  
3. nameserver 127.0.0.1  

Da der DNS-Dienst der VM während der Migration nicht funktionsfähig ist und wir im nächsten Schritt einen Zugang zum Internet benötigen, ersetzen wir «127.0.0.1» (localhost) vorübergehend durch «8.8.8.8» (DNS-Server von Google):

1. domain syscon.ch  
2. search syscon.ch  
3. nameserver 8.8.8.8  

Nach der Migration stellen wir den Wert zurück auf localhost, damit der DNS-Dienst wie üblich funktionieren kann.

- /boot/grub/grub.cfg

Xen verwendet einen speziellen Bootloader namens «PyGrub», den Proxmox nicht unterstützt. Änderungen am Bootloader werden mit dem Befehl «grub-mkconfig» übernommen, aber da grub-mkconfig auf Konfigurationsdateien angewiesen ist, die auf dem laufenden System vorhanden sind, müssen wir sie ebenfalls mounten:

1. mount -t proc proc /mnt/proc   
2.   
3. mount -t sysfs sys /mnt/sys   
4.   
5. mount -o bind /dev /mnt/dev  

Danach machen wir einen chroot in unseren Mount-Punkt, um uns die Konfiguration des Bootloaders zu ermöglichen:

1. chroot /mnt

Als nächstes müssen die Paketlisten aktualisiert werden, damit wir die neueste Version des Bootloaders installieren können. Hierzu ist beim Ausführen des Befehls «apt-get update» folgende Fehlermeldung aufgetreten:

1. root@ozelot:/# apt-get update    
2. Ign http://ftp.ch.debian.org wheezy Release.gpg    
3. Ign http://ftp.ch.debian.org wheezy Release    
4. Err http://ftp.ch.debian.org wheezy/main Sources    
5.   404  Not Found [IP: 129.132.53.171 80]    
6. Err http://ftp.ch.debian.org wheezy/contrib Sources    
7.   404  Not Found [IP: 129.132.53.171 80]    
8. Err http://ftp.ch.debian.org wheezy/non-free Sources    
9.   404  Not Found [IP: 129.132.53.171 80]    
10. Err http://ftp.ch.debian.org wheezy/main amd64 Packages    
11.   404  Not Found [IP: 129.132.53.171 80]    
12. Err http://ftp.ch.debian.org wheezy/contrib amd64 Packages    
13.   404  Not Found [IP: 129.132.53.171 80]    
14. Err http://ftp.ch.debian.org wheezy/non-free amd64 Packages    
15.   404  Not Found [IP: 129.132.53.171 80]  

Dazu konnte ich nur die Stirn runzeln. Mit dem Internet verbinden kann ich ja, wieso funktioniert jetzt «apt-get update» nicht?

Folglich hat mir meine Fachkraft darauf hingewiesen, dass der Support von Debian Wheezy, auf was sich die VM basiert, ausgerechnet während der IPA eingestellt wurde. Und tatsächlich, wie https://wiki.debian.org/DebianWheezy bekanntgibt, wurde Wheezy vor kurzem ins Archiv verschoben.

Für uns heisst das also, dass wir die archivierte Repository in /etc/apt/sources.list kopieren und die anderen Repositories auskommentieren müssen, damit wir wieder Zugriff auf die Pakete bekommen:

1. root@ozelot:/# nano /etc/apt/sources.list  
2.   
3.   GNU nano 2.2.6         File: /etc/apt/sources.list  
4.   
5. deb http://archive.debian.org/debian wheezy main  
6.   
7. #deb http://httpredir.debian.org/debian/ wheezy main contrib non-free  
8. #deb-src http://httpredir.debian.org/debian/ wheezy main contrib non-free  
9.   
10. #deb http://security.debian.org/ wheezy/updates main contrib non-free  
11. #deb-src http://security.debian.org/ wheezy/updates main contrib non-free  

Nun können wir die Konfiguration des Bootloaders durchführen:

1. apt-get update   
2.   
3. apt-get -y install grub2-common   
4.   
5. grub-mkconfig -o boot/grub/grub.cfg  

Mir ist gerade aufgefallen, dass uns der Kernel noch fehlt, also installieren wir ihn gleich auch:

1. apt-get -y install linux-image-amd64  
2.   
3. exit #Beendet chroot  

Zuletzt umounten wir alles, was wir für die Konfiguration brauchten, setzen die Zerlegung der VM zurück, und schon sind wir fertig:

1. umount /mnt/proc     
2.     
3. umount /mnt/sys     
4.     
5. umount /mnt/dev     
6.     
7. umount /mnt     
8.     
9. kpartx -d /dev/pve/vm-100-disk-0    

Um den erfolgreichen Start der VM zu demonstrieren, hier ein paar Screenshots dazu:

Zu guter Letzt müssen wir die Netzwerkeinstellungen entsprechend unserem Netzwerkplan anpassen. Dazu logge ich mich mit den von meiner Fachkraft übermittelten Login-Daten ein:

Mit «nano /etc/network/interfaces» gelangen wir zur Konfigurationsdatei für die Netzwerkeinstellungen. Die Zeilen, die wir ändern müssen, sind rot markiert:

Basierend auf dem Netzwerkplan ersetzen wir die aktuelle IP-Adresse durch «192.168.20.21», den Gateway durch «192.168.20.1» und die Netzwerkmaske durch «255.255.255.0»:

Dann übernehmen wir die Änderungen durch Drücken von Ctrl + O und Ctrl + X und schon ist die Migration vollbracht.

9.5 Automatisierte Migration

Da die Ausfallzeit des Servers während der Gesamtmigration aller VMs so gering wie möglich sein sollte, wäre es sinnvoll, ein Skript zu erstellen, das die zeitaufwendige Arbeit für uns um einiges leichter macht.

Die meisten Befehle während der manuellen Migration können direkt in das Skript kopiert werden, aber es gibt einige Dinge, die einen Workaround erfordern, damit sie in einem Skript funktionieren:

• Die Erstellung einer VM in Proxmox (statt auf dem Webinterface)
• Die Bedienung von interaktiven Programmen (fdisk, chroot, etc.)
• Das Ersetzen von bestimmtem Text in Konfigurationsdateien (anstatt mit nano)

Die Lösungen dieser Probleme sind wie folgt:

Zeile 32: Dies ist der Befehl, mit dem Proxmox eine VM erstellt. «qm help» gibt eine Liste von Parametern an, die je nach Bedarf angepasst werden können. Basierend auf den Werten, die ich der VM während der manuellen Migration gegeben habe, habe ich die Werte im Skript in gleicher Weise angepasst.

Zeile 21/77: Um ein interaktives Programm innerhalb eines Shellskripts ohne Benutzerinteraktion auszuführen, wird ein sogenanntes Heredoc (oder Here document) verwendet. Die allgemeine Form für ein Heredoc ist «EOF (End-of-File), wobei die Shell den « Operator als Anweisung zum Lesen von Inputs interpretiert, bis sie eine Zeile mit dem angegebenen Trenner findet. (In diesem Fall EOF, das durch alles Mögliche ersetzt werden kann. Bspw. «Tomate oder «Salatsauce.)

Zeilen 59-66/85: Üblicherweise hätte ich den Befehl «echo» verwendet, um die Zeilen in den Konfigurationsdateien anzupassen, allerdings ist das Problem, dass «echo» nur entweder Text hinzufügt oder den gesamten Inhalt der Konfigurationsdatei durch den angegebenen Text ersetzt, anstatt nur die Zeilen zu ersetzen, die angepasst werden müssen. Hier kommt «sed» (stream editor) zur Rettung. Ein 45-jähriges Unix-Programm, das Text zeilenbasiert transformiert und dabei eine einfache, kompakte Programmiersprache verwendet.

9.5.1 Aufbau des Skripts

1. #!/bin/bash      
2.       
3. #Beendet das Skript mit einem Error, wenn eine Variabel undefiniert ist      
4. set -u      
5.     
6. #Die folgenden Variablen dienen zur Prävention von Tippfehler im Skript    
7. IMGPATH=/home/lukas #Pfad der Images    
8. MOUNTPOINT=/mnt #Mount-Punkt für die Konfiguration der VM    
9. IMG=„krokodil.syscon.ch-root.img“ #Name des alten Images    
10. IMGNEW=„new-krokodil.syscon.ch-root.img“ #Name des neuen Images    
11. VM=„krokodil.syscon.ch“ #Name der migrierten VM    
12. VMID=100 #ID der VM in Proxmox    
13.       
14. #Erstellt ein Image mit der Grösse von 1MB. Dieses verwenden wir für den Bootloader  
15. dd if=/dev/zero of=$IMGPATH/$IMGNEW count=1 bs=1MiB      
16.       
17. #Fügt den Inhalt des ursprünglichen Images hinter das neue      
18. pv $RAWIMGPATH/$IMG » $IMGPATH/$IMGNEW      
19.       
20. #Erstellt eine Partitionstabelle. EOF (End-of-File) gibt an, ab welcher Stelle keine Inputs im interaktiven Programm mehr gelesen werden sollen      
21. fdisk $IMGPATH/$IMGNEW «EOF      
22. n #neue Partition      
23. p #primäre Partition      
24. 1 #Partitionsnummer      
25.       
26.      
27. a #Macht die Partition bootbar      
28. w #Übernimmt die Änderungen      
29. EOF    
30.       
31. #Erstellt eine VM in Proxmox      
32. qm create $VMID –scsi0 local-lvm:10 –bootdisk scsi0 –sockets 1 –cores 1 –memory 512 –name $VM —ostype=l26 –kvm yes –acpi yes –net0 ‘virtio,bridge=vmbr0’    
33.       
34. #Erstellt eine 2 GB grosse Disk für die Swap-Disk      
35. qm set $VMID –scsi1 local-lvm:2  
36.   
37. #Macht aus der Disk eine Swap-Disk      
38. mkswap /dev/pve/vm-$VMID-disk-1      
39.       
40. #Ersetzt die neulich erstellte VM durch das krokodil-Image      
41. dd if=$IMGPATH/$IMGNEW | pv | dd of=/dev/pve/vm-$VMID-disk-0      
42.       
43. #Zerlegt die VM in ihre Partitionen. -a = macht die Partition in /dev/mapper sichtbar, -v = gibt den Output des Befehls an (zum Sicherstellen, dass sich die Partition am richtigen Ort befindet)  
44. kpartx -av /dev/pve/vm-$VMID-disk-0      
45.     
46. #Wartet, bis die VM zerlegt ist     
47. while [ ! -h /dev/mapper/pve-vm–$VMID–disk–0p1 ]      
48. do      
49.   sleep 2      
50. done      
51.       
52. #Mountet die Partition, welche vorhin mit fdisk erstellt wurde      
53. mount /dev/mapper/pve-vm–$VMID–disk–0p1 $MOUNTPOINT      
54.       
55. #Installiert den Bootloader in die gemountete Partition      
56. grub-install –target=i386-pc –recheck –debug –boot-directory=$MOUNTPOINT/boot /dev/mapper/pve-vm–$VMID–disk–0      
57.       
58. #Adaptiert fstab für Proxmox      
59. sed 's/xvda2/sda1/' -i $MOUNTPOINT/etc/fstab #Ersetzt „xvda2“ durch „sda1“      
60. sed 's/xvda1/sdb/' -i $MOUNTPOINT/etc/fstab #Ersetzt „xvda1“ durch „sdb“      
61.       
62. #Adaptiert inittab für Proxmox      
63. sed 's/hvc0/tty1/' -i $MOUNTPOINT/etc/inittab      
64.       
65. #Ersetzt vorübergehend „127.0.0.1“ durch „8.8.8.8“, da bei den folgenden Schritten der Zugang zum Internet gebraucht wird      
66. sed 's/127.0.0.1/8.8.8.8/' $MOUNTPOINT/etc/resolv.conf    
67.     
68. #Ersetzt die obsoleten Repositories durch die archivierte    
69. echo „deb http://archive.debian.org/debian wheezy main“ > $MOUNTPOINT/etc/apt/sources.list    
70.     
71. #Übernimmt /proc, /sys und /dev von Proxmox      
72. mount -t proc proc $MOUNTPOINT/proc      
73. mount -t sysfs sys $MOUNTPOINT/sys      
74. mount -o bind /dev $MOUNTPOINT/dev      
75.       
76. #Setzt die gemountete Partition als Root-Verzeichnis, installiert darin den Kernel und konfiguriert den Bootloader      
77. cat «EOF | chroot $MOUNTPOINT/      
78. apt-get update      
79. apt-get -y install linux-image-amd64      
80. apt-get -y install grub2-common      
81. grub-mkconfig -o boot/grub/grub.cfg      
82. EOF      
83.     
84. #Setzt den DNS zurück so wie es war    
85. sed 's/8.8.8.8/127.0.0.1/' -i $MOUNTPOINT/etc/resolv.conf    
86.   
87. #Setzt die Netzwerkeinstellungen gemäss dem Netzwerkplan  
88. sed 's/10.0.0.20/192.168.20.21/' -i $MOUNTPOINT/etc/network/interfaces  
89. sed 's/10.0.0.254/192.168.20.1/' -i $MOUNTPOINT/etc/network/interfaces  
90. sed 's/255.0.0.0/255.255.255.0/' -i $MOUNTPOINT/etc/network/interfaces  
91.   
92. umount $MOUNTPOINT/proc      
93. umount $MOUNTPOINT/sys      
94. umount $MOUNTPOINT/dev      
95.       
96. umount $MOUNTPOINT      
97.       
98. #Setzt die Zerlegung der VM zurück      
99. kpartx -d /dev/pve/vm-$VMID-disk-0

9.5.1.1 Skript starten

Nun ist die Frage, wie starten wir das Skript überhaupt? Bevor wir dies tun können, müssen wir zuerst die Rechte zum Ausführen des Skripts zuweisen:

1. chmod +x auto-migration.sh #x = Execute  

Zum Ausführen des Skripts geben wir diesen einfachen Befehl ein:

1. ./auto-migration.sh  

9.5.2 Start der VM

Um zu zeigen, dass die VM lauffähig ist und der User sich einloggen kann, hier noch einmal ein Screenshot dazu:

10.1.2 Planung

Vier Testfälle werden von 13:00 bis 15:30 nacheinander in jeweils 30 Minuten ausgeführt; 15 Minuten für die Durchführung des jeweiligen Tests und 15 Minuten für das Dokumentieren der Ergebnisse:

|
| Test durchführen |

10.2 Durchführung der Tests

10.2.1 Testfall Nr. 1

10.2.2 Testfall Nr. 2

10.2.3 Testfall Nr. 3

10.2.4 Testfall Nr. 4

10.2.5 Testfall Nr. 5

10.3 Ist der Zeitplan eingehalten?

Abgesehen von den wenigen Malen, in denen ich zu voreilig war und Dinge im Voraus erledigt habe, die erst später fällig gewesen wären, ist alles völlig reibungslos verlaufen. Es gab nie eine Teilaufgabe, für die ich entweder zu viel oder zu wenig Zeit für die Durchführung geschätzt habe, sodass ich jeweils am Ende vom Tag mindestens eine Stunde für die Reflexion der Arbeit einplanen konnte. Die Ungeduld bei der frühzeitigen Installation des Servers nehme ich jedoch als Lektion, um bei zukünftigen Projekten nicht vorschnell zu werden und mich immer am Zeitplan zu halten.

10.4 Ist das Ziel erreicht?

Ich kann mit Sicherheit sagen, dass alle zu Beginn gesetzten Ziele und Meilensteine mühelos erreicht wurden. Zudem konnte ich auch persönliche Ziele wie die Steigerung meiner Effizienz verfolgen, indem ich mich stets nur auf die Aufgaben konzentrierte, die am jeweiligen Tag fällig waren. Zu diesem Zweck habe ich eine persönliche Eisenhower-Matrix verwendet, in der ich jeden Morgen vor Arbeitsbeginn notierte, was ich tagsüber genau tun muss, welche Dinge zu einem späteren Zeitpunkt eingeplant werden können und welche Dinge ich an meine Fachkraft delegieren kann.

Das Einzige, womit ich nicht zufrieden bin, ist dass ich den Zugriff auf Proxmox gemäss der Aufgabenstellung nicht verschlüsseln konnte. Ich habe alles ausprobiert, von der Verwendung von Let's Encrypt bis hin zur Erstellung von Skripts, aber da es Dutzende von Firewalls im Netzwerk gibt, durch die das Zertifikat geleitet werden muss, gab es so oder so keine Möglichkeit, dass es hätte funktionieren können.

Ansonsten bin ich sehr davon überzeugt, dass ich jedes andere Kriterium erfüllen könnte.

11 Auswerten

11.1 Auswertung der Erfahrungen

Da ich viele Themen der PA bereits während meines 3-monatigen Praktikums erlernt habe, lernte ich während der eigentlichen IPA kaum etwas Neues, aber konnte stattdessen auf der persönlichen Ebene vieles gewinnen. Darunter:

• Lernen, bei der Sache zu bleiben und die Versuchung zu vermeiden, sich von der Arbeit abzulenken.
• Arbeitsschritte sinnvoll zu gestalten, so dass kein Tag unter- oder überarbeitet ist.
• Die Aufgaben des Tages vor Arbeitsbeginn realistisch planen

11.2 Gedanken über das Folgeprojekt

Was ich aus der Praxisarbeit in Bezug auf die Ausübung von Effizienz, Konzentration usw. gewinnen konnte, kann meiner Meinung nach nur weiter und weiter verbessert werden. Mit der Zeit bemerkte ich zudem immer mehr die Bedeutung der Projektmethode IPERKA, die wirklich nützlich sein kann, um genau die Dinge im Auge zu behalten, die direkt vor einem liegen. Mit anderen Worten, man verbringt die Zeit nicht damit, über die Vergangenheit nachzudenken oder sich um die Zukunft zu sorgen, sondern konzentriert sich stattdessen nur auf das Jetzt, sodass man in kürzerer Zeit mehr erreichen kann. Aber natürlich kann dies nicht nur in einem Projekt, sondern auch in allen Aktivitäten des täglichen Lebens angewendet werden.

11.3 Fazit und Reflexion

Abgesehen von dem, was ich bereits während des Praktikums gelernt habe, konnte ich viel darüber lernen, wie man seine Fähigkeiten optimal einsetzt, um so effizient und produktiv wie möglich zu arbeiten. Dank dessen hatte ich keinerlei Probleme, die Ziele der PA zu erfüllen, den Zeitplan einzuhalten und hatte zudem genügend Reservezeit pro Tag, um auf Rechtschreibfehler zu prüfen, die Grafiken und Tabellen visuell zu gestalten und so weiter. Natürlich gab es ein paar unerwartete Probleme während der PA, aber es gab nichts, das mich aus dem Gewicht halten liess.

Zusammenfassend bin ich sehr zufrieden, wie die IPA herauskam.

12 Schlusswort und Danksagung

An dieser Stelle möchte ich mich bei allen bedanken, die die IPA so zusammengestellt haben, dass sie mir eine gute Einführung in die wichtigsten Aspekte der Virtualisierung ermöglicht hat, was mir bisher schon immer an meinen IT-Kenntnissen gefehlt hat. Darüber hinaus, da es mir auch einen tiefen Einblick in Linux gab und ich im Grunde genommen ein gutes Erlebnis mit dem Betriebssystem hatte, fange ich langsam an zu verstehen, warum viele Linux gegenüber Windows bevorzugen.

13 Quellenverzeichnis

Disk Performance mit Fio messen:
https://www.unixmen.com/how-to-measure-disk-performance-with-fio-and-ioping/, Zugriff am 01.04.2019 um 10:00 Uhr.

Fio Outputs:
https://tobert.github.io/post/2014-04-17-fio-output-explained.html, Zugriff am 01.04.2019 um 10:12 Uhr.

IPERKA:
http://c-jacob.ch/iperka/iperka.pdf, Zugriff am 01.04.2019 um 11:16 Uhr.

Ethernet Aliases in Linux einrichten:
https://www.techrepublic.com/article/set-up-ethernet-aliases-in-linux/, Zugriff am 03.04.2019 um 10:33 Uhr.

Liste von Well-Known Ports:
https://www.webopedia.com/quick_ref/portnumbers.asp, Zugriff am 03.04.2019 um 13:12 Uhr.

SSL Mailserver Ports:
https://www.fastmail.com/help/technical/ssltlsstarttls.html, Zugriff am 03.04.2018 um 15:42 Uhr.

RAID Cheat Sheet:
https://www.aja.com/pdf/support/RAID_Cheat_Sheet.pdf,Zugriff am 04.04.2019 um 11:17 Uhr.

Dokumentation Proxmox-Storage:
https://pve.proxmox.com/wiki/Storage, Zugriff am 04.04.2019 um 12:58 Uhr.

Mehr über qcow2-Storage:
https://en.wikibooks.org/wiki/QEMU/Images, Zugriff am 04.04.2019 um 14:22 Uhr

Anleitung Migration Xen-VM zu Proxmox: 
https://blog.filippo.io/converting-a-partition-image-to-a-bootable-disk-image/, Zugriff am 10.04.2019 um 09:02 Uhr

Was macht EOF in einem Skript:
https://superuser.com/questions/1003760/what-does-eof-do, Zugriff am 15.04.2019 um 10:49 Uhr.

Link Aggregation Grundlagen:
https://www.thomas-krenn.com/de/wiki/Link_Aggregation_und_LACP_Grundlagen, Zugriff am 16.04.2019 um 15:03 Uhr.

Was ist ein Runlevel:
http://www.linfo.org/runlevel_def.html, Zugriff am 16.04.2019 um 15:59 Uhr.

14 Glossar