Hyper-V Live Migration: Warum Ihr Netzwerk bei Wartungsarbeiten in die Knie geht

Willkommen bei IT for Business. Ich bin Mirko Peters.

Wir sind IT-Dienstleister für den Mittelstand, und hier geht es nicht um Produkte oder Hypes, sondern um echte IT-Entscheidungen: Infrastruktur, Cloud, Security und Architektur aus der Praxis.

Wenn Sie Verantwortung für IT tragen, Entscheidungen treffen oder Dienstleister bewerten, dann sind Sie hier richtig.

Und wenn Sie sich zu den Themen austauschen wollen, vernetzen Sie sich gerne mit mir auf LinkedIn, ich freue mich über den Austausch aus der Praxis.

Hier ist die Frage, die viele erst stellen, wenn es bereits ruckelt: Warum geht bei einer ganz normalen Wartung plötzlich das Netzwerk in die Knie, obwohl die virtuelle Maschine doch sauber per Live Migration verschoben werden sollte? Genau da liegt der Denkfehler. Viele schauen auf Hyper-V-Einstellungen und den Assistenten, aber das eigentliche Risiko liegt oft im Netzwerkpfad darunter.

Bleiben Sie kurz dran, das kann Ihnen einen teuren Fehler ersparen. Wir schauen uns an, warum Live Migration Lastspitzen erzeugt, warum Patchday und Host-Drain schnell zum Betriebsrisiko werden und wie Sie das sauber entschärfen. Dafür müssen wir erst nüchtern klären, was bei einer Live Migration technisch überhaupt durchs Netz läuft.

Was Live Migration tatsächlich über Ihr Netzwerk schiebt

Klartext: Bei einer Live Migration ist nicht zuerst die VM-Datei Ihr Hauptproblem. Das Problem ist der laufende Zustand der Maschine, genauer gesagt ihr Arbeitsspeicher und alles, was sich darin während der Migration weiter verändert.

Eine virtuelle Maschine läuft ja nicht als starre Datei vor sich hin. Sie arbeitet. Benutzer sind angemeldet, Dienste schreiben Daten, Prozesse ändern Speicherinhalte im Sekundentakt. Wenn Sie diese VM nun von Host A nach Host B verschieben, dann muss Hyper-V genau diesen Zustand übertragen, während die Maschine weiterläuft. Und das ist der Punkt, den viele im Betrieb unterschätzen.

Technisch läuft es vereinfacht so: Zuerst wird der aktuelle RAM-Inhalt der VM auf den Zielhost kopiert. Während diese Kopie läuft, arbeitet die VM aber weiter. Dadurch ändern sich Speicherbereiche erneut. Diese geänderten Bereiche werden nachverfolgt und später noch einmal übertragen. Man spricht dabei von sogenannten Dirty Pages, also Speicherseiten, die sich während des Kopiervorgangs wieder verändert haben.

Das ist kein exotisches Detail, sondern der Kern des Verfahrens. Solange die Änderungen schneller entstehen, als sie sauber nachgezogen werden können, bleibt die Migration unter Druck. Erst wenn der Rest klein genug ist, kann Hyper-V die VM ganz kurz umschalten und auf dem Zielhost weiterlaufen lassen. Für den Benutzer wirkt das oft unterbrechungsfrei. Für Ihr Netzwerk ist es trotzdem ein echter Lastfall.

Was bedeutet das konkret für Sie? Je aktiver eine VM ist, desto schwieriger wird die Migration. Eine ruhige Testmaschine mit wenig RAM wandert meist unspektakulär. Ein produktiver Applikationsserver mit viel Speicher und laufender Last verhält sich anders. Dann wächst das Migrationsfenster, der Datenstrom bleibt länger hoch und die Wahrscheinlichkeit steigt, dass andere Dienste denselben Pfad mitbenutzen müssen.

Genau deshalb ist Live Migration keine reine Komfortfunktion, sondern eine Belastungsprobe für die Infrastruktur. Sie testen dabei nicht nur Hyper-V. Sie testen Ihr Netzwerkdesign, Ihre Bandbreitenreserven und Ihre Fähigkeit, Betriebsverkehr von Wartungsverkehr sauber zu trennen.

An dieser Stelle lohnt sich die Abgrenzung zur Quick Migration. Bei der Quick Migration wird die VM nicht im laufenden Zustand über längere Zeit durchs Netz synchron gehalten. Stattdessen wird ihr Zustand gespeichert, die Maschine kurz angehalten und dann auf dem Zielhost wieder aufgenommen. Das heißt: kürzerer Übertragungsprozess im laufenden Betrieb, aber dafür ein merkbarer Ausfall. Das ist eine andere Risikoklasse. Live Migration vermeidet den sichtbaren Stillstand, erzeugt aber währenddessen deutlich mehr kontinuierliche Netzlast.

Jetzt kommt noch eine zweite Unterscheidung dazu, die in vielen Projekten untergeht: Läuft die Umgebung mit Shared Storage oder ohne? Wenn beide Hosts auf denselben Storage zugreifen, dann muss bei einer klassischen Cluster-Konstellation nicht zwangsläufig der komplette VM-Datenträger mitwandern. Dann geht es vor allem um Speicherinhalt und Zustand. Wenn Sie aber ohne gemeinsam genutzten Storage arbeiten oder Storage mitverschieben, dann reden wir schnell über deutlich mehr Daten auf demselben Weg. Das verändert die Last sofort.

Die typische Fehleinschätzung lautet dann: ohne Downtime heißt ohne Belastung. Genau das stimmt nicht. Ohne sichtbaren Ausfall heißt nur, dass die Anwendung weiterläuft. Es sagt nichts darüber aus, wie stark Hosts, CPU und Netzwerk währenddessen beansprucht werden.

Und genau an dieser Stelle kippen viele Umgebungen. Nicht weil Hyper-V die Funktion nicht beherrscht, sondern weil das Netz für normalen Tagesbetrieb gebaut wurde, nicht für gleichzeitige Wartung unter Last.

Warum Ihr Netzwerk bei Wartungsarbeiten einknickt

Seien wir ehrlich: In den meisten Umgebungen scheitert Live Migration nicht an Hyper-V selbst. Sie scheitert an historisch gewachsenen Konstruktionen, die im Alltag irgendwie funktionieren und unter Wartungslast plötzlich ihre Schwächen offenlegen. Alte Switches, ein irgendwann eingerichtetes Teaming, VLANs mit unklarer Dokumentation, ein zusätzlicher Pfad für Backup, daneben noch Cluster-Kommunikation, und niemand kann Ihnen auf Anhieb sagen, welcher Verkehr im Ernstfall wirklich wo entlangläuft. Genau so entstehen Frankenstein-Integrationen.

Im Normalbetrieb fällt das oft nicht auf, weil die Last sauber verteilt wirkt oder weil die Umgebung selten an ihre Grenzen kommt. Sobald Sie aber einen Host leerräumen, mehrere VMs verschieben oder nach einem Patchday Last neu verteilen, läuft plötzlich Wartungsverkehr über denselben Pfad wie Produktivverkehr. Technisch ist das bequem, betrieblich ist es riskant. Denn dann konkurrieren Benutzerzugriffe, Management, Cluster-Traffic und Live Migration um dieselben Leitungen, dieselben Queues und dieselben Reserven.

Das Problem beginnt oft schon bei der Grundannahme: Wenn es im Alltag stabil aussieht, wird es im Wartungsfenster schon auch reichen. Genau das stimmt häufig nicht. Ein Netz, das für den laufenden Betrieb dimensioniert wurde, ist nicht automatisch für planmäßige Lastspitzen ausgelegt. Wartung ist kein Randfall. Wartung ist ein eigener Betriebszustand, und dieser Zustand braucht ein eigenes Design.

Besonders sichtbar wird das bei 1-Gigabit-Umgebungen oder bei knapp bemessenen 10-Gigabit-Uplinks. Im Alltag tragen solche Verbindungen Management, etwas Storage, normalen VM-Verkehr und vielleicht noch Backup, ohne dass jemand sofort Alarm schlägt. Kommt dann Live Migration dazu, wird aus der Reserve ein Nadelöhr. Nicht dauerhaft, aber genau in dem Moment, in dem Sie Stabilität brauchen. Und das ist der unangenehme Teil: Die Umgebung wirkt gesund, bis Sie sie bewegen.

Nun denken viele an dieser Stelle: Dann aktivieren wir eben Komprimierung, dann geht weniger übers Netz. Das hilft oft auch, aber nur bis zu einem gewissen Punkt. Sie verschieben damit das Problem nicht ins Nichts, sondern auf die CPU der Hosts. Und die CPU arbeitet in diesem Moment ja nicht im Leerlauf. Sie betreibt produktive VMs, verarbeitet Storage-I/O, bedient Hintergrunddienste und soll dann zusätzlich Migrationsdaten komprimieren und wieder entpacken. Wenn die VM-Dichte hoch ist oder die Hosts ohnehin gut ausgelastet sind, wird daraus ein verdeckter Engpass.

Das merken Sie selten als klaren Fehler im Assistenten. Sie merken es im Betrieb. RDP-Sitzungen reagieren träge. Eine SQL-Anwendung fühlt sich zäh an, obwohl kein offensichtlicher Ausfall vorliegt. Backup-Fenster ziehen sich länger als geplant. Anwender melden kurze Hänger, die sich technisch schwer greifen lassen, weil nichts komplett abgestürzt ist. Genau das macht solche Probleme so teuer. Nicht der Totalausfall, sondern die Summe kleiner Störungen, die Vertrauen in die Plattform kosten.

SMB über Standard-TCP mit mehreren Netzwerkkarten kann Bandbreite bündeln, und für viele Umgebungen ist das ein vernünftiger Weg. Aber auch da lohnt sich Nüchternheit. Mehrere NICs allein lösen nicht automatisch Latenzprobleme, CPU-Last oder eine schlechte Pfadtrennung. Wenn die Zuweisung unsauber ist oder die Netzwerkkarten die Last nicht sauber über Kerne verteilen, steigt die Komplexität schneller als der Nutzen. Dann haben Sie auf dem Papier mehr Durchsatz und im Betrieb trotzdem Unruhe.

Der eigentliche Schaden zeigt sich operativ. Teams schieben Wartung auf, weil niemand sicher sagen will, wie sich der Cluster unter Last verhält. Host-Updates wandern in die Nacht, nicht weil das Geschäft nachts arbeitet, sondern weil man der eigenen Infrastruktur tagsüber nicht traut. Lastverteilung wird vermieden, obwohl sie technisch vorgesehen ist. Das ist ein Warnsignal. Wenn Sie Live Migration nur dann nutzen, wenn möglichst niemand arbeitet, dann fehlt nicht die Funktion, dann fehlt Vertrauen in das Design.

Lassen Sie uns das kurz auf den Punkt bringen: Die Lösung ist fast nie ein einzelner Haken in Hyper-V. Das Problem entsteht vorher, im Netzdesign, in der Rollenverteilung und in der Frage, welche Verkehrsarten sich Pfade teilen dürfen und welche nicht. Genau deshalb schauen wir als Nächstes auf die Basis, also auf saubere Netztrennung und die richtige Wahl der Migrationspfade.

Die Basis: saubere Netztrennung und richtige Pfadwahl

Wenn Sie das Thema sauber lösen wollen, fängt es nicht im Assistenten an, sondern bei der Netztrennung. Management, Cluster-Kommunikation, Live Migration, Storage und der eigentliche VM-Verkehr sollten nicht einfach irgendwie nebeneinander auf demselben Pfad liegen. Sie brauchen klare Rollen. Logisch per VLAN, physisch per eigener NIC oder als Mischform, das hängt von Ihrer Umgebung ab. Die Trennung selbst ist der Punkt.

Warum wirkt das so stark? Weil Sie damit verhindern, dass eine geplante Lastspitze aus der Wartung denselben Weg nimmt wie Benutzerzugriffe oder Applikationsverkehr. Wenn Live Migration auf dem gleichen Pfad läuft wie ein produktiver Datenbankserver oder ein Fileservice, dann konkurriert Wartung direkt mit Betrieb. Wenn Sie die Pfade sauber trennen, bleibt die Belastung dort, wo sie hingehört. Das klingt banal, spart Ihnen aber im Ernstfall sehr viel Ärger.

Hier ist die eigentliche Frage: Über welches Netz darf Live Migration überhaupt laufen? Viele Umgebungen stehen noch auf der bequemen Standardeinstellung, also sinngemäß: nimm irgendein verfügbares Netzwerk. In einem Labor mag das reichen. Im Mittelstand ist das fahrlässig, sobald mehrere NICs, VLANs oder Cluster-Rollen im Spiel sind. Sie sollten ein dediziertes Live-Migration-Netz festlegen und genau definieren, welche Subnetze oder Interfaces dafür zugelassen sind. Nicht ungefähr. Eindeutig.

Damit allein ist es noch nicht getan. In Multi-NIC-Umgebungen oder bei mehreren VLANs müssen Sie die Reihenfolge und Priorität sauber festlegen. Sonst nutzt Hyper-V im Zweifel einen technisch erreichbaren, aber betrieblich falschen Pfad. Dann läuft die Migration nicht über den vorgesehenen schnellen Weg, sondern über ein Management-Netz oder über ein Segment, das parallel bereits andere Last trägt. Genau solche Effekte führen später zu Diskussionen wie: Eigentlich war das doch so geplant. Ja, geplant vielleicht. Betrieben aber anders.

Wenn Sie nur wenige physische Ports zur Verfügung haben, heißt das nicht, dass sauberes Design unmöglich wird. Es heißt nur, dass Sie disziplinierter arbeiten müssen. Dann brauchen Sie klare VLAN-Zuschnitte, nachvollziehbare QoS-Regeln und eine eindeutige Dokumentation, welche Verkehrsart auf welchem Uplink priorisiert wird. Besser ein bewusst geplanter Mischpfad mit Grenzen als eine zufällige Überlagerung, bei der niemand mehr sagen kann, warum Last an einer bestimmten Stelle ankommt. Da versteckt sich das Risiko.

Im Betrieb gibt es ein paar Prüfpunkte, die oft übersehen werden und später erstaunlich viel Zeit kosten. Die vSwitch-Namen sollten auf allen Hosts konsistent sein. Sonst endet eine Migration nicht an der Netzwerkkarte, sondern an einer banalen Inkonsistenz. Die Berechtigungen für Live Migration und die Authentifizierung müssen zu Ihrem Betriebsmodell passen, gerade wenn Sie nicht interaktiv auf jedem Host arbeiten wollen. Und die Grundkonfiguration sollte hostübergreifend identisch sein: gleiche Netzrollen, gleiche Benennung, gleiche Erwartung an die Pfade. Wenn jeder Host ein wenig anders gebaut wurde, bekommen Sie keinen Cluster, sondern Einzelstücke mit gemeinsamem Namen.

Nun noch ein Punkt, bei dem viele Projekte unnötig kompliziert werden: NIC-Teaming, vNICs und VLAN-Konstrukte sind Werkzeuge, keine Architektur. Sie können damit saubere Lösungen bauen. Sie können damit aber auch Verantwortung verschleiern. Wenn niemand den gesamten Pfad vom Host über den virtuellen Switch bis zum physischen Uplink wirklich verantwortet, dann entsteht wieder genau das Durcheinander, das im Wartungsfenster Probleme macht. Architektur schlägt Tools. Immer.

Praktisch heißt das für Sie: Erst Rollen festlegen, dann Pfade zuweisen, dann testen, ob die Migration im Betrieb wirklich den vorgesehenen Weg nimmt. Nicht umgekehrt. Viele Teams konfigurieren zuerst Features und hoffen dann, dass das Netz schon irgendwie mitspielt. Das ist die falsche Reihenfolge.

Sobald diese Basis sauber steht, stellt sich die nächste Frage fast automatisch: Wie nutzen Sie die verfügbare Bandbreite so, dass Durchsatz, CPU-Last und Stabilität zusammenpassen? Genau da schauen wir jetzt hin.

SMB Multichannel, Komprimierung und RDMA: was wofür taugt

Wenn die Pfade sauber definiert sind, kommt die nächste Entscheidung: Wie soll Hyper-V die Migration technisch transportieren? Genau an dieser Stelle wird oft ungenau beraten. Dann fällt ein Schlagwort wie SMB, Komprimierung oder RDMA, und am Ende bleibt der Eindruck, das sei alles ungefähr dasselbe. Ist es nicht.

SMB Multichannel bedeutet zunächst etwas sehr Bodenständiges. SMB baut mehrere Verbindungen über mehrere geeignete Netzwerkkarten auf und kann so Bandbreite bündeln und gleichzeitig Redundanz schaffen. Fällt ein Pfad weg, bleibt die Sitzung im Idealfall über die anderen Pfade bestehen. Für Umgebungen mit mehreren schnellen NICs ist das oft ein vernünftiger Ansatz, gerade wenn Sie Live Migration oder SMB-basierten Storage nicht auf eine einzelne Leitung festnageln wollen.

Aber das ist nur die halbe Wahrheit. Multichannel ist keine Abkürzung für automatisch gute Performance. Wenn die beteiligten Netzwerkkarten nicht sauber zusammenarbeiten, wenn RSS oder VMQ nicht sinnvoll greifen oder wenn die SMB-Verbindungen am Ende über Pfade laufen, die eigentlich für andere Rollen gedacht waren, dann steigt vor allem die Komplexität. Sie haben dann mehr Sessions, mehr Verteilung, mehr mögliche Fehlerbilder, aber nicht zwingend mehr Ruhe im Betrieb.

Klartext: Mehrere NICs helfen nur dann, wenn das Gesamtdesign dazu passt. Sonst verteilen Sie Last lediglich auf eine Konstruktion, die schon vorher unsauber war. Das ist ein Unterschied, den man im Angebot selten so offen liest.

Darum ist Komprimierung in vielen Mittelstands-Umgebungen überhaupt erst einmal der pragmatische Standard. Der Gedanke dahinter ist einfach: Wenn weniger Daten übers Netz müssen, wird die Migration schneller, auch ohne besondere Netzwerkinfrastruktur. Moderne CPUs können das oft gut abfangen, und in Umgebungen ohne RDMA ist Komprimierung deshalb häufig die vernünftige Grundeinstellung. Vor allem dann, wenn 10GbE vorhanden ist, die Hosts noch Luft haben und die VM-Dichte überschaubar bleibt.

Der Haken daran liegt im Timing. Die CPU soll genau in dem Moment zusätzlich arbeiten, in dem bereits Last auf der Plattform liegt. Das kann gutgehen. Es kann aber auch kippen, wenn produktive VMs parallel Rechenleistung brauchen, etwa bei Datenbanken, Terminalservern oder Applikationsservern mit vielen gleichzeitigen Zugriffen. Dann tauschen Sie Netzengpässe gegen CPU-Druck. Auf dem Papier wirkt die Migration sauber, im Betrieb reagieren Anwendungen plötzlich zäher. Das Problem wandert also nur die Etage hoch.

Deshalb sollten Sie Komprimierung nicht als pauschale Empfehlung verstehen, sondern als Abwägung. Wenn CPU günstig ist und Netz knapp, passt sie oft gut. Wenn CPU bereits der enge Faktor ist, verschärft sie das Problem eher. Diese Unterscheidung ist wichtig, weil viele Admins nur auf die Migrationsdauer schauen und nicht auf die Nebenwirkungen im Host.

An einem anderen Punkt setzt RDMA an, also Remote Direct Memory Access, in der Hyper-V-Welt meist über SMB Direct. Dabei entlastet die Netzwerkkarte den Datenpfad deutlich stärker, sodass weniger CPU für den Transport selbst verbrannt wird. Das senkt die Latenz und hilft vor allem dort, wo viel und regelmäßig verschoben wird. Also nicht nur bei Live Migration, sondern auch bei Storage-nahen Lasten, Cluster-Verkehr und allgemein in Umgebungen, in denen viel Ost-West-Traffic zwischen Hosts läuft.

Gerade ab 25GbE spielt RDMA seine Stärken sehr deutlich aus. Nicht weil 25GbE magisch wäre, sondern weil ab dieser Größenordnung ein rein CPU-getriebener Transport schneller an Grenzen stößt. Wenn Sie hohe Bandbreite haben, wollen Sie sie auch nutzen können, ohne den Host dabei unnötig zu belasten. RDMA hilft genau dabei.

Nun wäre es falsch zu sagen, jede mittelständische Umgebung braucht sofort RDMA. Das wäre genauso ungenau wie die Behauptung, es sei nur etwas für Großkonzerne. Entscheidend ist die Betriebsrealität. Ein kleiner Cluster mit wenigen Hosts, moderater Last und seltenen Migrationen kommt oft ohne RDMA gut aus. Ein dichterer Cluster mit schnell angebundenem Storage, vielen parallelen VMs und regelmäßigen Wartungsfenstern profitiert häufig früher davon, als man zunächst annimmt. Nicht aus Technikliebe, sondern weil die Plattform berechenbarer wird.

Noch eine Nuance, die oft durcheinandergerät: SMB Multichannel und RDMA schließen sich nicht aus. Im Gegenteil. In einer gut geplanten Umgebung ergänzen sie sich. Multichannel sorgt dafür, dass mehrere geeignete Pfade genutzt werden können. RDMA beschleunigt und entlastet die einzelnen Datenpfade selbst. Das eine organisiert die Verteilung, das andere verbessert den Transport.

Wenn Ihnen also jemand eine dieser Optionen als alleinige Lösung verkauft, lohnt sich Nachfragen. Die eigentliche Frage lautet nicht: Welche Funktion ist besser? Die eigentliche Frage lautet: Welche Funktion passt zu Ihrer Host-Dichte, Ihrer CPU-Reserve, Ihrer Netzgeschwindigkeit und Ihrem Wartungsmodell?

Und genau damit kommen wir zu dem Teil, über den Anbieter ungern sprechen. Nicht zur Checkbox im Hyper-V-Manager, sondern zur Frage, welche Netzgröße wirtschaftlich überhaupt sinnvoll ist.

10GbE, 25GbE und die eigentliche Kostenfrage

Seien wir ehrlich: Die Diskussion über 10 oder 25 Gigabit wird oft geführt, als ginge es nur um den Preis der Netzwerkkarte. Genau dort beginnt die Fehlsteuerung. Die eigentlichen Kosten entstehen nicht im Warenkorb, sondern später im Betrieb. In längeren Wartungsfenstern. In verschobenen Updates. In Hosts, die tagsüber nicht angefasst werden, weil niemand sicher sagen kann, wie stark die Umgebung unter Migration reagiert.

10GbE kann für viele Mittelständler weiterhin vollkommen ausreichen. Wenn Sie einen kleinen Cluster betreiben, nur wenige Hosts haben, die VM-Anzahl überschaubar bleibt und Live Migration nicht laufend parallel mit Backup, Storage-Verkehr und Lastverschiebung stattfindet, dann ist 10GbE oft sachlich vertretbar. Man muss aus jeder Umgebung kein Hochleistungsdesign machen.

Interessant wird es dort, wo mehrere Dinge zusammenkommen. Viele VMs pro Host. Spürbarer Ost-West-Verkehr zwischen den Knoten. Schnelleres Storage, das nicht auf einen engen Netzpfad warten soll. Regelmäßige Wartung im laufenden Betrieb. Oder schlicht der Wunsch, einen Host tagsüber kontrolliert zu drainen, ohne dass das halbe Unternehmen kurze Aussetzer bemerkt. Dann reicht die reine Betrachtung des Anschaffungspreises nicht mehr.

25GbE verschafft Ihnen in solchen Umgebungen vor allem eines: mehr Luft an genau der Stelle, an der Hyper-V-Cluster unter Druck geraten. Migrationen laufen schneller durch, parallele Verkehrsarten stehen sich seltener im Weg, und der Betrieb wird berechenbarer. Das ist keine Luxusfrage. Das ist eine Frage, wie viel Reserve Sie im Netz einplanen, wenn der Cluster nicht nur funktionieren, sondern wartbar bleiben soll.

Was bedeutet das konkret für Sie? Kürzere Migrationsfenster senken die Zeit, in der Hosts, CPU und Netzwerk zusätzlich belastet werden. Lastspitzen flachen ab. Der Betrieb traut sich eher, Wartung auch tagsüber sauber durchzuführen. Und genau dieser Punkt wird gern unterschätzt: Eine schnellere Verbindung spart nicht nur Sekunden, sie verändert das Betriebsmodell. Wenn Ihr Team dem Cluster vertraut, treffen Sie andere Entscheidungen. Weniger Ausweichmanöver, weniger Nachtarbeit, weniger unnötige Vorsicht.

Trotzdem wäre es falsch, 25GbE als pauschale Pflicht auszugeben. Wenn Segmentierung, Pfadwahl und Verantwortlichkeiten unsauber bleiben, kaufen Sie mit mehr Bandbreite nur ein schnelleres Durcheinander. Dann wird das Symptom etwas später sichtbar, aber das Architekturproblem bleibt.

Für viele Mittelständler ist deshalb ein phasenweiser Weg vernünftig. Erst die Switches so wählen, dass 25GbE grundsätzlich möglich wird. Danach die kritischen Hosts modernisieren, also dort anfangen, wo VM-Dichte, Storage-Nähe oder Wartungsdruck am höchsten sind. Der Rest folgt im normalen Lebenszyklus. So verteilen Sie CAPEX sauber über mehrere Schritte, ohne die Zielarchitektur aus dem Blick zu verlieren.

Klartext: Es geht nicht darum, das schnellste Netz zu kaufen. Es geht darum, die wirtschaftlich passende Netzgröße für Ihr reales Betriebsmodell zu wählen. Wenn Ihr Dienstleister nur den Kartenpreis diskutiert, fehlt die halbe Rechnung.

Bevor Sie also investieren, lohnt sich ein nüchterner Blick auf die vorhandene Umgebung. Nicht auf Folien, sondern auf den tatsächlichen Betrieb.

Praxis-Check: so prüfen Sie Ihre Hyper-V-Live-Migration

Stellen Sie Ihrem Team oder Dienstleister fünf einfache Fragen.

Erstens: Über welches Netz läuft Live Migration heute wirklich, nicht laut Dokumentation, sondern im echten Betrieb unter Last?

Zweitens: Teilt sich dieser Verkehr den Pfad mit Storage, Backup oder produktiven Anwendungen, die gleichzeitig laufen?

Drittens: Nutzen Sie Komprimierung, SMB Multichannel oder RDMA bewusst, weil es zu Ihrer Umgebung passt, oder ist einfach der Standard aktiv geblieben?

Viertens: Wie viele gleichzeitige Migrationen verträgt das Design realistisch, bevor Benutzer etwas merken?

Fünftens: Wurde das unter einem echten Wartungsszenario geprüft oder nur in einer ruhigen Testsituation?

Wenn Sie darauf keine klaren Antworten bekommen, dann liegt das Risiko nicht in Hyper-V. Da versteckt sich das Risiko in der Architektur davor.

Outro: Entscheidung vor Technik

Das war IT for Business.

Wenn Sie aus dieser Folge etwas mitnehmen, dann vielleicht das: Gute IT entscheidet sich nicht im Tool, sondern in der Architektur und den Entscheidungen davor.

Für Hyper-V Live Migration heißt das sehr konkret: Die saubere Lösung beginnt nicht im Assistenten, sondern bei Netztrennung, Pfadwahl und einem Betriebsmodell, dem Ihr Team auch unter Wartung vertraut. Gehen Sie die fünf Prüffragen mit Ihrem IT-Leiter oder Dienstleister durch, bevor der nächste Patchday ansteht. Nicht nach dem ersten Hänger.

Wenn Ihnen die Folge gefallen hat, abonnieren Sie den Podcast, um keine weiteren Episoden zu IT-Entscheidungen aus der Praxis zu verpassen.

Und wenn Sie selbst vor einer IT-Modernisierung oder einem Projekt stehen: Stellen Sie die richtigen Fragen früh, nicht erst im Betrieb.

Bis zur nächsten Folge.

Wenn Ihr IT-Partner sagt, das läuft schon über das Standardnetz, dann prüfen Sie als Erstes genau dieses Netz.