Checkliste für die Migration von VMware zu STACKIT

1. Bestandsaufnahme

Was vorhanden ist, bevor jemand etwas entwirft.

• Jedes Blatt exportieren

  RVTools-Blätter vInfo, vDisk, vNetwork, vSnapshot und vMemory. Fehlt ein Blatt, warnt der Lauf und behandelt Snapshots oder Reservierungen als unbekannt, nicht als nicht vorhanden. Antwort: engineering/architect-report.md, Quellwarnungen.

• Blätter vollständig verknüpft

  Die Zeilen aus vDisk, vNetwork, vSnapshot und vMemory sollten sich VMs zuordnen lassen. Antwort: assessment.json, summary, inventory_join (Zeilen und Treffer je Blatt).

• Anwendungen benannt

  Gruppieren Sie VMs mit einer Anwendungsdatei und übergeben Sie sie mit --applications. Einheiten, die kein Selektor nennt, bleiben UNASSIGNED. Antwort: migration/applications.csv.

• Gast-Betriebssysteme geprüft

  Lesen Sie das Betriebssystem laut Konfigurationsdatei und das von VMware Tools gemeldete; die Warnung zum Support-Ende wertet nur das erste aus. Antwort: Hinweise in engineering/architect-report.md.

• Snapshots aufgeführt und konsolidiert

  Der Lauf sagt, dass nur der aktuelle Stand einer VM migriert wird. Konsolidieren Sie vor dem Export. Antwort: Snapshot-Hinweis je VM; die Broadcom-Seite beschreibt das Konsolidieren.

• Gemeinsam genutzte und Raw-Platten gefunden

  Suchen Sie in vDisk nach „Raw“ und „Sharing mode“. Solche VMs werden als MANUAL_REVIEW klassifiziert. Antwort: terraform/README.md, Abschnitt „Left for the architect“.

• Datenbank-VMs von den Verantwortlichen benannt

  Der Lauf erkennt keine Datenbanksoftware. Antwort: Ihre DBAs und die Spalte „Annotation“.

2. Design

Die Entscheidungen, die der Export nicht für Sie trifft.

• Region gewählt

  Beantworten Sie die Anfrage target.region. Antwort: review/inputs.yaml; der Lauf zählt sie bis zur Antwort als blockierend.

• Netzwerkpräfixe gesetzt

  Ein CIDR pro Portgruppe. Der Export hat Adressen, keine Masken. Antwort: review/target-values.tfvars, mit den gesehenen Adressen je Netzwerk.

• Netzwerknamen bestätigt

  VLAN-Nummern bleiben nur im Namen erhalten. Antwort: Arbeitspaket des Platform Architect in execution/manual/actions.md.

• Adressen behalten oder geändert

  Eine Schnittstelle behält ihre Adresse nach dem Anlegen. Antwort: offene Einstellung ip-address je VM in assurance/critical-semantics.json.

• Maschinentyp je VM

  Katalognamen; Windows braucht eine als kompatibel markierte Familie. Antwort: variables.tf, eine Maschinentyp-Variable je Server.

• Availability Zone gewählt

  Das Quell-Rechenzentrum wird nicht zugeordnet. Antwort: Arbeitspaket des Security Architect.

• Security Groups entworfen

  Eingehender Verkehr ist standardmäßig gesperrt, und von den Richtlinien der Portgruppen steht nichts in RVTools. Antwort: Ihr eigenes Design; der Entwurf setzt keine.

• Lizenzweg für Windows

  Standard-Image mit enthaltener Lizenz oder eigenes Image mit eigenen Lizenzen. Antwort: Windows-Hinweis je VM und der STACKIT-Lizenzleitfaden.

• Betriebszustand nach dem Cutover

  Der Entwurf setzt keinen Soll-Zustand; eine ausgeschaltete VM würde also starten. Antwort: offene Einstellung power-state je VM.

Zwei Checklisten, die der Lauf schon schreibt

Links der Abschnitt „Before wave 1“ aus migration/technical-sequencing.md. Rechts die ersten Zeilen von execution/verify/checks.md, die aufführt, was vor jedem Schritt gelten muss.

## Before wave 1

- [ ] Architect has reviewed every MANUAL_REVIEW, REDESIGN and BLOCKED unit in engineering/architect-report.md.
- [ ] STACKIT organisation, folders and projects are laid out (one project per environment is the usual start).
- [ ] Data-transfer method and cutover window agreed per data unit (databases, buckets, caches).

## Before each step

- [ ] `TF/stackit_network.network_PG_Shop_App` · `variable-supplied` `variable=network_PG_Shop_App_ipv4_nameservers` — The variable `network_PG_Shop_App_ipv4_nameservers` has a value.
- [ ] `TF/stackit_network.network_PG_Shop_App` · `variable-supplied` `variable=network_PG_Shop_App_ipv4_prefix` — The variable `network_PG_Shop_App_ipv4_prefix` has a value.
- [ ] `TF/stackit_network.network_PG_Shop_App` · `variable-supplied` `variable=project_id` — The variable `project_id` has a value.

• Pro Schritt, nicht pro Projekt

  Die Prüfdatei enthält eine Zeile je Variable und Schritt; ein fehlender Wert fällt also vor dem Anwenden auf, nicht erst währenddessen.

• Nichts wurde ausgeführt

  Beide Dateien sind Vorschläge. StackToIT liest und schreibt Dateien und ändert nichts in einer Cloud.

3. Aufbau

Vom Entwurf zu Servern in einem Testprojekt.

• Dienste im Projekt aktiviert

  Die README nennt die STACKIT-Dienste, die zuerst zu aktivieren sind; bei diesen Entwürfen IaaS. Antwort: terraform/README.md.

• Provider-Authentifizierung entschieden

  Die README empfiehlt Workload Identity Federation statt langlebiger Schlüssel. Antwort: Abschnitt „Target security checklist“ in terraform/README.md.

• State-Backend gewählt

  Der Entwurf deklariert keines. Die README warnt davor, sich bei einem S3-Backend auf Object Storage auf Locking zu verlassen. Antwort: dieselbe Checkliste.

• Alle Variablen haben Werte

  28 im Beispiellauf. Antwort: terraform/variables.tf und review/target-values.tfvars.

• Images vorbereitet

  STACKIT importiert raw, qcow2 und iso; die Seite zu eigenen Images nennt eine maximale Image-Größe von 70 GB. Laut der Begründung des Laufs für jede per Rehost umgesetzte VM werden VMware Tools sowie die Treiber vmxnet3 und PVSCSI durch die Treiber ersetzt, die das STACKIT-Image braucht. Antwort: engineering/architect-report.md und die Image-ID-Variable je Server.

• Templates behandelt

  Ein Template ist REPLATFORM und hat keinen Image-Block. Antwort: terraform/README.md, Abschnitt „Left for the architect“.

• Plan im Testprojekt fehlerfrei

  Führen Sie dort tofu init, validate und plan aus. StackToIT führt nie apply aus. Antwort: Ihre Plan-Ausgabe.

4. Daten

StackToIT überträgt nie Daten; diese Prüfungen liegen bei Ihnen.

• Volume-Liste geprüft

  Jede weitere Platte wird ein Volume; der Blockkommentar sagt, dass ihre Daten nach dem Anlegen kopiert werden. Antwort: terraform/compute.tf. Daten-Volumes reichen von 1 GB bis 16 TB.

• Kopierverfahren je Volume gewählt

  Plattenkopie, Dump und Restore, Backup-Import oder Replikation. Antwort: migration/data-movement.md hält fest, dass Daten auf VM-Platten nicht bewertet werden.

• Ausfalltoleranz festgehalten

  RTO, RPO und Ausfalltoleranz, wie der Verantwortliche sie nennt. Antwort: Anwendungsdatei und migration/applications.csv.

• Raw-Mappings kopiert

  Eine Raw-LUN ist nicht im Image. Antwort: die Begründung des Laufs an der Einheit; planen Sie eine Kopie auf Block- oder Anwendungsebene.

• Backup entworfen

  Der Export enthält keine Backup-Ressource. Antwort: assurance/operational-readiness.md, Zeile „Backup job“.

5. Cutover

Die Reihenfolge und der Rückweg.

• Wellenreihenfolge abgestimmt

  Erst Netzwerke, dann Server. Antwort: migration/technical-sequencing.md; die Datei nennt Wellen einen Ausgangspunkt.

• Cutover-Fakten gelesen

  Der Lauf führt die DNS-Einträge und Zertifikate auf, die er sehen konnte, und sagt offen, wenn er keine gesehen hat. Namen und Adressen außerhalb der Quelle liegen bei Ihnen. Antwort: Abschnitt „Cutover“ derselben Datei.

• Jede offene kritische Einstellung geschlossen oder akzeptiert

  136 im Beispiellauf. Antwort: decisions.json und review/decisions.yaml.

• Rollback je manuellem Schritt geschrieben

  Der Plan hält fest, dass er nicht weiß, wie ein manueller Schritt rückgängig gemacht wird. Antwort: „Rollback“-Zeilen in execution/manual/actions.md.

• Quell-VMs erhalten

  Herunterfahren, nicht löschen, bis der Verantwortliche freigibt. Das ist Praxis, keine Ausgabe des Laufs.

6. Nachbereitung

Sauber abschließen.

• Prüfungen nach jedem Schritt bestanden

  Antwort: execution/verify/checks.md.

• Entscheidungen festgehalten

  Akzeptierte Entscheidungen brauchen Begleitangaben und Belege. Antwort: review/decisions.yaml, danach erneut ausführen.

• Bewertung erneut ausgeführt

  Der nächste Lauf liest Ihre Antworten und erzeugt den Entwurf neu. Vergleichen Sie die Zahlen offener Punkte.

• Quelle stillgelegt

  Snapshots und VMs nach der Freigabe entfernen und das Inventar nachführen. Auch das ist Praxis, keine Ausgabe des Laufs.

Wie ein fehlendes Blatt aussieht

Aus dem Architektenbericht eines Laufs, in dessen Export zwei Blätter fehlten.

- **warning** RVTOOLS_SHEET_MISSING: the export has no vSnapshot sheet (SHEET_MISSING): the snapshot count and size of the 7 VMs are not known, so they are unknown (not none) for every VM
- **warning** RVTOOLS_SHEET_MISSING: the export has no vMemory sheet (SHEET_MISSING): the memory reservation of the 7 VMs are not known, so they are unknown (not none) for every VM

• Unbekannt heißt nicht: keine

  Die Warnung sagt, dass die Werte für jede VM unbekannt sind. Exportieren Sie die Blätter und starten Sie erneut.

• Früh entdeckt ist günstiger

  Lücken, die in Phase 1 auffallen, kosten einen Export; beim Cutover kosten sie ein Wartungsfenster.

Fragen zur Checkliste

Quellen

• STACKIT-Dokumentation: Eigene Images mit der IaaS-API nutzen
• STACKIT-Dokumentation: Maschinentypen
• STACKIT-Dokumentation: Konzepte von Block Storage
• STACKIT-Dokumentation: Netzwerkschnittstellen, Konzepte
• STACKIT-Dokumentation: Leitfaden zur Windows-Server-Lizenzierung
• Broadcom TechDocs: Snapshots konsolidieren