Update README.md

diff --git a/README.md b/README.md
index 65360dc1e4bb44d750e4345d35501c5aec55e10d..fec42b9003ad7268ef8575addf97eeedf1096a55 100644 (file)
--- a/README.md
+++ b/README.md
@@ -350,72 +350,110 @@ Boolscher Wert. Wenn wahr, ist das identisch damit, als ob *'create-terraform'*
 Schalter *'--simulate'* aufgerufen wird. Es wird also nur so getan, als ob, und die Terraform-Projekt-Verzeichnisse
 und -Dateien werden nicht angelegt.
 
-* **simulate**: Boolscher Wert. Wenn wahr, ist das identisch damit, als ob *'create-terraform'* immer mit dem
-  Schalter *'--simulate'* aufgerufen wird. Es wird also nur so getan, als ob, und die Terraform-Projekt-Verzeichnisse
-  und -Dateien werden nicht angelegt.
-* **defaults**: Wie bereits erwähnt, werden hier die globalen Vorgabewerte für alle VMs definiert.
-* **vms**: Liste der nicht gruppierten VMs. Das heißt, sie beziehen ihre Vorgaben ausschließlich aus den
-  Vorgabewerten der obersten Ebene.
-  In dieser Liste werden alle VMs, die provisioniert werden sollen, als Hashes aufgelistet, wobei minimal
-  der Name und eine IPv4-Adresse pro VM definiert werden müssen.
-* **groups**: Liste von Gruppen von VMs, die wiederum gemeinsame, von den globalen abweichende Vorgabewerte
-  haben. Jede Gruppe ist ein Hash mit drei notwendigen Schlüsseln: *'name'*, *'defaults'* und *'vms'*, sowie
-  dem optionalen Schlüssel *'groups'*.
-  Mit **name** wird jeder Gruppe ein eindeutiger Gruppenname zugewiesen. Dieser wird zwar in Terraform
-  nicht verwendet, aber dient zum einfacheren Auffinden von Fehlern in der Konfiguration.
-  Die Schlüssel **defaults**, **vms** und **groups** haben exakt die selbe Bedeutung wie auf der obersten
-  Ebene. In den *defaults* in einer Gruppe können Vorgabewerte der nächsthöheren Ebene überschrieben werde.
+##### defaults
+
+Wie bereits erwähnt, werden hier die globalen Vorgabewerte für alle VMs definiert.
+
+##### vms
+
+Liste der nicht gruppierten VMs. Das heißt, sie beziehen ihre Vorgaben ausschließlich aus den
+Vorgabewerten der obersten Ebene.
+
+In dieser Liste werden alle VMs, die provisioniert werden sollen, als Hashes aufgelistet, wobei minimal
+der Name und eine IPv4-Adresse pro VM definiert werden müssen.
+
+##### groups
+
+Liste von Gruppen von VMs, die wiederum gemeinsame, von den globalen abweichende Vorgabewerte
+haben. Jede Gruppe ist ein Hash mit drei notwendigen Schlüsseln: `name`, `defaults` und `vms`, sowie
+dem optionalen Schlüssel `groups`.
+
+Mit **name** wird jeder Gruppe ein eindeutiger Gruppenname zugewiesen. Dieser wird zwar in Terraform
+nicht verwendet, aber dient zum einfacheren Auffinden von Fehlern in der Konfiguration.
+
+Die Schlüssel **defaults**, **vms** und **groups** haben exakt die selbe Bedeutung wie auf der obersten
+Ebene. In den **defaults** in einer Gruppe können Vorgabewerte der nächsthöheren Ebene überschrieben werde.
 
 #### 2.1.2. Konfigurations-Parameter für eine VM
 
 Die nachfolgenden Parameter können pro defaults-Abschnitt und pro VM vergeben werden.
 
-* **vsphere**: Name der der VSPhere-Umgebung aus der Konfiguration dieser Anwendung, also im Falle von Pixelpark
-  entweder _test_ oder _live_. **Achtung**: Durch die Limitierung von Terraform darf es in einem Terraform-Projekt
-  nur ein VSphere geben, damit macht es Sinn, diesen Parameter nur ein einziges Mal anzugeben, nämlich im
-  obersten Template.
-
-* **vm_folder**: Der Name des Ordners innerhalb des Baums der 'VMs und Vorlagen'-Ansicht in VSPhere. Dabei achtet
-  VSPhere auf Groß- und Kleinschreibung, also sind _'Pixelpark'_ und _'pixelpark'_ zwei unterschiedliche Ordner.
-  Empfohlen wird auf oberster Ebene der Kunde als Ordnername, und darunter bei kleineren Kunden das Tier (z.Bsp.
-  'live', 'test' und 'dev') als zweite Ebene, bei größeren Kunden sollte noch das Projekt als zweite Ebene
-  dazwischen geschoben werden. Damit ergeben sich bei kleineren Kunden Ordnernamen wie _'Mubea/live'_, und bei
-  größeren Kunden zum Beispiel _'Pixelpark/DNS/test'_. Wenn der Ordner in VSphere nicht existieren sollte, wird
-  er vom Create-Script angelegt. Die Ordner werden nicht als Terraform-Resourcen behandelt, das heißt, wenn nach
-  dem Wegwerfen von VMs mittels Terraform der Ordner leer ist, wird er von Terraform nicht weggeräumt. Das
-  obliegt dann dem Admin, der die VMs weggeräumt hat, manuell.
-
-* **num_cpus**: Die Anzahl der CPUs der VM als Integer-Zahl. Der Einfachheit halber ist damit grundsätzlich die
-  Anzahl der CPUs mit jeweils einem Core gemeint. Wer Spielereien wie 'X CPUs mit Y Cores' unbedingt und dringend
-  benötigt, richtet die VM erst mal nach obigem Schema ein und konfiguriert diese anschließend manuell in VSPhere.
-  Bislang hat sich mir derlei Notwendigkeit aber noch nicht dargestellt.
-
-* **memory**: Die Größe des Haupspeichers der VM. Wenn keine Einheit angegeben wurde, werden MiByte (also 2^20 Bytes)
-  angenommen. Man kann aber auch eine Float- oder Integerzahl zusammen mit einer Maßeinheit wie GiB oder TiB
-  angeben. Zu beachten ist, dass der resultierende Haupspeicher mindestens 256 MiB groß sein sowie ein Vielfaches
-  von 256 MiB sein muss. SI-konforme Einheiten werden hier nicht beachtet, das heißt beispielsweise, dass
-  1 GB identisch mit 1 GiB ist, also 2^30 Bytes, und nicht 10^9 entspricht. Im Normalfall verwendet man aber
-  ein Vielfaches von 1 GiB als Hauptspeicher.
-
-* **boot_delay**: Die Verweildauer im POST nach dem Einschalten als Float-Zahl in Sekunden. In diesem Zeitraum kann
-  in der VM-Konsole in VSPhere zum Beispiel das Boot-Menü aufgerufen werden, um die VM beispiesweise vom Netz oder
-  einer verbundenen Live-CD zu booten, oder um die BIOS-Einstellungen zu gelangen. Wenn man unbedingt das
-  VSPhere-Standard-Verhalten haben möchte (sofortiger Boot ohne Warten), stellt man den Wert auf '**0**'. In diesem
-  Fall kann man aber auch keine Tasten für BIOS usw. drücken. Der Standardwert, wenn er nicht gesetzt wird,
-  beträgt 5 Sekunden.
-
-* **datastore_cluster**: Welcher Datenstore-Cluster soll für alle Disks der VM verwendet werden? Ene Angabe an dieser
-  Stelle hat Vorrang vor *datastore_type*. Man muss allerdings beachten, dass zum Zeitpunkt des Schreibens dieser
-  Dokumentation (2020-01-07) im live-VSPhere noch keine Datenstore-Cluster verfügbar sind und es demzufolge keinen
-  Sinn macht, bei Provisionierung in das live-Cluster hier etwas anzugeben. Bei Provisionierungen in das test-Cluster
-  hingegen macht das wiederum viel Sinn, da es dort Datenstore-Cluster gibt.
-
-* **datastore_type**: Auf welchem Typ Storage sollen die Disks der VM angelegt werden, wenn kein Datenstore-Cluster
-  angegeben wurde. Mögliche Angaben sind **ssd**, **sas** und **sata**, wobei letzteres die Vorgabe ist, wenn hier
-  nichts angegeben wird. Kriterium für die Auswahl eines Datastores ist es, ob der angegebene String im Namen des
-  Datastores auftaucht und genügend Platz für alle Disks aufweist. Lokale Datastores und solche auf NFS werden nicht
-  berücksichtigt. Wenn bei einem Typ kein Datastore gefunden wird, wird die Suche auf andere Typen ausgedehnt, wobei
-  ausgehend von der Angabe in folgender Reihenfolge gesucht wird:
+##### vsphere
+
+Name der der VSPhere-Umgebung aus der Konfiguration dieser Anwendung, also im Falle von Pixelpark
+entweder `test` oder `live`.
+
+**Achtung**: Durch die Limitierung von Terraform darf es in einem Terraform-Projekt nur ein VSphere geben,
+damit macht es Sinn, diesen Parameter nur ein einziges Mal anzugeben, nämlich im obersten Template.
+
+##### vm\_folder
+
+Der Name des Ordners innerhalb des Baums der 'VMs und Vorlagen'-Ansicht in VSPhere. Dabei achtet
+VSPhere auf Groß- und Kleinschreibung, also sind `Pixelpark` und `pixelpark` zwei unterschiedliche Ordner.
+
+Empfohlen wird auf oberster Ebene der Kunde als Ordnername, und darunter bei kleineren Kunden das Tier (z.Bsp.
+`live`, `test` und `dev`) als zweite Ebene, bei größeren Kunden sollte noch das Projekt als zweite Ebene
+dazwischen geschoben werden. Damit ergeben sich bei kleineren Kunden Ordnernamen wie `Mubea/live`, und bei
+größeren Kunden zum Beispiel `Pixelpark/DNS/test`.
+
+Wenn der Ordner in VSphere nicht existieren sollte, wird er vom Create-Script angelegt. Die Ordner werden
+nicht als Terraform-Resourcen behandelt, das heißt, wenn nach dem Wegwerfen von VMs mittels Terraform der
+Ordner leer ist, wird er von Terraform nicht weggeräumt.
+Das obliegt dann dem Admin, der die VMs weggeräumt hat, manuell.
+
+##### num\_cpus
+
+Die Anzahl der CPUs der VM als Integer-Zahl. Der Einfachheit halber ist damit grundsätzlich die
+Anzahl der CPUs mit jeweils einem Core gemeint.
+
+Wer Spielereien wie 'X CPUs mit Y Cores' unbedingt und dringend benötigt, richtet die VM erst mal nach
+obigem Schema ein und konfiguriert diese anschließend manuell in VSPhere.
+
+Bislang hat sich mir derlei Notwendigkeit aber noch nicht dargestellt.
+
+##### memory
+
+Die Größe des Haupspeichers der VM. Wenn keine Einheit angegeben wurde, werden MiByte (also 2^20 Bytes)
+angenommen. Man kann aber auch eine Float- oder Integerzahl zusammen mit einer Maßeinheit wie GiB oder TiB
+angeben.
+
+Zu beachten ist, dass der resultierende Haupspeicher mindestens 256 MiB groß sein sowie ein Vielfaches
+von 256 MiB sein muss. SI-konforme Einheiten werden hier nicht beachtet, das heißt beispielsweise, dass
+1 GB identisch mit 1 GiB ist, also 2^30 Bytes, und nicht 10^9 entspricht. Im Normalfall verwendet man aber
+ein Vielfaches von 1 GiB als Hauptspeicher.
+
+##### boot\_delay
+
+Die Verweildauer im POST nach dem Einschalten als Float-Zahl in Sekunden. In diesem Zeitraum kann
+in der VM-Konsole in VSPhere zum Beispiel das Boot-Menü aufgerufen werden, um die VM beispiesweise vom Netz oder
+einer verbundenen Live-CD zu booten, oder um die BIOS-Einstellungen zu gelangen.
+
+Wenn man unbedingt das VSPhere-Standard-Verhalten haben möchte (sofortiger Boot ohne Warten), stellt man den
+Wert auf '**0**'. In diesem Fall kann man aber auch keine Tasten für BIOS usw. drücken.
+
+Der Standardwert, wenn er nicht gesetzt wird, beträgt 5 Sekunden.
+
+##### datastore\_cluster
+
+Welcher Datenstore-Cluster soll für alle Disks der VM verwendet werden? Ene Angabe an dieser
+Stelle hat Vorrang vor *datastore_type*.
+
+Man muss allerdings beachten, dass zum Zeitpunkt des Schreibens dieser Dokumentation (2021-09-15) im live-VSPhere
+nur Datenstore-Cluster mit SATA-Platten verfügbar waren. Es macht demzufolge keinen Sinn, hier etwas anzugeben,
+wenn man SSD-Storage benötigt.
+
+Der Standard-Wert für diesen Eintrag ist **'~'** - also nicht angegeben.
+
+##### datastore\_type
+
+Auf welchem Typ Storage sollen die Disks der VM angelegt werden, wenn kein Datenstore-Cluster
+angegeben wurde. Mögliche Angaben sind **ssd**, **sas** und **sata**, wobei letzteres die Vorgabe ist, wenn hier
+nichts angegeben wird.
+
+Kriterium für die Auswahl eines Datastores ist es, ob der angegebene String im Namen des Datastores auftaucht
+und genügend Platz für alle Disks aufweist. Lokale Datastores und solche auf NFS werden nicht berücksichtigt.
+Wenn bei einem Typ kein Datastore gefunden wird, wird die Suche auf andere Typen ausgedehnt, wobei
+ausgehend von der Angabe in folgender Reihenfolge gesucht wird:
 
     **\*** *sata* -> *sas* -> *ssd*
 
@@ -423,7 +461,9 @@ Die nachfolgenden Parameter können pro defaults-Abschnitt und pro VM vergeben w
 
     **\*** *ssd* -> *sas* -> *sata*
 
-  
+Vorgesehen ist, vorher eine ähnliche Suche über alle Datenstore-Cluster zu machen, wenn keiner angegeben
+wurde, und erst danach, wenn kein entsprechender Datenstore-Cluster gefunden wurde, die Suche auf
+Datastores auszudehnen.
 
 ## 3. FeatureRequests