Warum ist das mit den UUIDs so kompliziert ?
- hier ein kleines Beispiel von UUIDs
Ein(e) UUID, eine(e) "Universally Unique Identifier" ist eine sehr große Nummer - eine 128-Bit-Zahl, die vermutlich weltweit nur einmal vorkommt.
Und diese UUIDs kommen immer öfter vor und sind vom Verständnis und vor allem von der Handhabung recht komplex und erfordern immer mehr abstraktes logisches Denken.
.
Aus unserer (Server-) Sicht - wo kommen die UUIDs vor ?
Betrachten wir unsere mit XEN virtualisierten Produktions-Server (also die im Echtbetrieb draußen am Netz hängenden Server) in einem Rechnzentrum oder Hosting-Gebäude.
Und beginnen wir mit den Massenspeichern, den Festplatten oder den SSDs. Auf diesen Speichern lagert alles, das wir zum Betrieb des Servers brauchen, einfach alles. Und das darf nie verlustig gehen.
.
Die ersten 3 Host-Partitionen unseres XEN Servers :
Darum installieren wir heutzutage mindestens RAID1 Speicher, das sind jeweils 2 gleich große gegeneinander gespiegelte Platten. Auf jeder der beiden Platten erstellen wir "spiegelbildlich" gleich große sogenannte Platten-Partitions- Paare.
Ein solches gleich großes Partitions-Paar verbinden wir zu einer RAID1 Partition.
Bereits jetzt ganz am Anfang haben wir
- je eine UUID für die gesamte physikalische Platte (Beispiel sda und sdb)
- je eine UUID für jede physikalische Primary-Partition (Beispiel sda1, sda2, sda3 und sdb1, sdb2, sdb3) - und dann noch
- je eine UUID für jede dieser neuen logische RAID Partitionen (Beispiel md0, md1, md2)
Das bedeutet, bei zwei 1,8TB SATA Platten habe ich für den Host (mit 3 gespiegelten Primary-Partitionen) bereits 11 UUIDS .
.
Jetzt gehts aber erst richtig los mit den UUIDs
Unsere beiden 1,82 TB XEN Server-Platten sollen 6 oder 8 (oder mehr) virtuelle Gäste "bewirten". Der Host (der Gastgeber - das ist die Domaine 0) bekommt nach den ersten drei Primary-Partitionen auf dem gesamten Rest der beiden physikalischen Platten (sda und sdb) zwei neue riesengroße 1,78 TB (extended) Partitionen (sda4 und sdb4) eingerichtet.
.
Auf dem Host sehen die ersten vier Partitionen so aus:
- Die beiden extended Partitionen werden nicht gespiegelt
Wichtig : Diese beiden (extended) Partitionen werden in ihrer Gesamtheit NICHT gespiegelt. Die neuen Sub-Partitionen (für die VMs) in beiden extended Partitionen werden später einzeln gespiegelt, als wenn es völlig separate Festplatten wären.
.
Auf diesen beiden (extended) Partitionen werden (wie oben bereits gesagt) alle weiteren - aber dann wiederum gespiegelten Sub-Partitionen als sogenannte unformatierte RAW-Devices (für die neuen VMs, die späteren virtuellen Gäste) angelegt.
Jetzt habe ich bereits (und noch ohne einen einzigen VM-Gast) 10 UUIDS für die einzelnen physikalischen Partitionen (+3 UUIDS für die 3 logischen RAID1 Host-Partitionen md0, md1 und md2).
.
Neue logische Partitionen in den beiden exended Partitions
Für die erste virtuelle Maschine erstelle ich zwei neue (unformatierte) gleich große 100GB RAW Partitionen. Das sind dann in der Reihenfolge "sda5" und "sdb5". Die verbinde ich beide zu einer (unformatierten) 100GB RAID1- RAW Partition mit der vom System (nach "md2") vergebenen fortlaufenden Bezeichnung "md3".
Das bedeutet, der Host kennt "sda5" und "sdb5" - verbunden als RAID1 zu "md3". Das sind zu den alten 13 UUIDs jetzt 3 weitere UUIDs.
Und jetzt installiere ich vom Host aus mit dem Virt-Manager dort in die neue leere "md3" RAID1 Partition die erste VM (1) mit einem beliebigen nicht zu alten opensuse 13.2 oder 42.3 oder 15.1 boot-Kernel.
Dieser boot-Kernel erkennt den RAW Zustand von der als Ziel ausgewählten "md3" RAID1 Partition als ganz normale (physikalische/virtuelle) Platte und schlägt eine VM-interne Partitions-Aufteilung dieser 100GB Platte vor, die mir aber nicht gefällt. Ich möchte gerne 4GB als "swap", 15GB als "root" mit EXT4 und die restlichen 81GB als "data" mit XFS haben. Das sind erneut 3 neue Partitonen, mit denen das neue Gast-Betriebsystem in seiner eigenen Umgebung arbeitet.
Und das sieht dann innerhalb der VM (des Gasts) so aus :
- So sieht der Gast seine in der 100GB RAW-Partition angelegten drei Partitionen
Es werden deshalb weitere 4 UUIDs generiert, die aber nur den Gast interessieren, die der Host so nie zu Gesicht bekommt. Beim diesem Gast VM (1) sind jetzt die gesamte 100GB Platte als xvda und die 3 neuen Einzel-Partitionen mit xvda1, xvda2 und xvda3 angelegt. Der Gast weiß nicht, daß er auf einem RAID1-System aufgesetzt wurde.
Ist der Gast vollständig installiert und dann wieder herunter gefahren bzw. abgeschaltet, sieht der Host diese drei Partitionen zusätzlich zu der 100GB Platte "md4", nämlich "md4p1" mit 4GB, "md4p2" mit 15GB und "md4p3" mit 81GB.
So sieht der Host die Partitionen eines abgeschalteten Gastes, wenn er dort etwas reparieren muß :
- So sieht der Host die drei Partitionen (ist aus einem anderen Beispiel), die der Gast sich erzeugt hatte.
.
Pro Gast bekommen wir (in unserem Beispiel) 6 neue UUIDs
Das sind 3 UUIDs vom Host aus gesehen - die dort sichtbaren physikalischen Platten-Partitionen (md4p1 bis md4p3) und 3 UUIDs für die drei virtuellen Partitionen (xvda1 bis xvda3) eines jeden Gastes (die aber nur innerhalb des Gast-Betriebssystems eine Rolle spielen, zum Beispiel beim händischen Umzug von einer VM in eine andere VM.
.
Jetzt haben Sie eine Vorstellung von 8 VMs auf einem Host.
Doch das ist ja noch lange nicht alles. Jede Bridge und jede Netzwerkkarte auf dem Host und in jeder VM als solche bekommt eine UUID. Dazu bekommt die virtuelle Netzwerkkarte in einer jeden VM eine virtuelle MAC Adresse und weitere Kleinigkeiten.
Die stehen aber wiederum bei den händischen Umzugsplänen für die VMs unddie kommen noch.
.