# Die VLAN-Änderung am Verwaltungsuplink
Typ: Checkliste
Herkunft: virtualization-private-cloud / virtual-networking / virt-network-change-safety
Version: virt-network-change-safety-2026-09-13
Geprüft: 2026-09-13

ACHTUNG: Dieses Dokument ist ein Lernartefakt aus einer Schulungssequenz. Es ist kein produktives Runbook. Vor jeder Anwendung in einer realen Umgebung müssen die Schritte gegen lokale Dokumentation, Runbooks und Freigabestatus geprüft werden.

## Szenario
Die Verwaltungsschnittstelle eines Hypervisor-Hosts soll in ein eigenes VLAN wandern. Der Host trägt produktive VMs, und die Verwaltungsverbindung läuft aktuell über denselben Uplink, der geändert wird.

## Schritte
1. Feststellen, über welchen Uplink und welche Portgruppe die Verwaltungsverbindung tatsächlich läuft — nicht, über welche sie laufen sollte.
2. Einen zweiten Zugang sichern, der nicht über diesen Pfad führt: Fernwartungskarte oder Serverkonsole.
3. Die bestehende Konfiguration und den Rückweg schriftlich festhalten, bevor etwas geändert wird.
4. Die Änderung an genau einem Host durchführen und die Erreichbarkeit über den neuen Pfad prüfen.
5. Gegenprobe über den zweiten Zugang, dass auch die produktiven VMs des Hosts unverändert erreichbar sind.
6. Erst nach bestandener Prüfung auf die übrigen Hosts ausrollen.

## Begründung
Warum: Netzänderungen am Hypervisor sind die seltene Klasse von Eingriffen, bei denen das Werkzeug und der Gegenstand derselbe sind. Deshalb geht der Nachweis eines unabhängigen Zugangs jeder Änderung voraus, nicht erst der Fehlersuche danach.
Folgen: **+** Ein Fehlschlag bleibt auf einen Host begrenzt und ist über den zweiten Zugang korrigierbar. **−** Der Ablauf kostet spürbar mehr Zeit als die Änderung selbst und wirkt übervorsichtig, solange nichts schiefgeht.

## Quellen
1. https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/8-0/vsphere-networking/setting-up-networking-with-vnetwork-standard-switches.html
2. https://pve.proxmox.com/pve-docs/pve-admin-guide.html