Migracja z VMware na Proxmox Warszawa

Dlaczego w stołecznej spółce ta zmiana zaczyna się od papieru?

Nie z zamiłowania do procedur. W firmie, która obsługuje klientów korporacyjnych albo należy do większej grupy, infrastruktura jest przedmiotem zapisów w umowach i pytań w ankietach kontrahentów. Zmiana platformy wirtualizacyjnej dotyka wszystkich systemów naraz, więc jest dokładnie tą zmianą, o którą ktoś zapyta: audytor, dział ryzyka po stronie klienta albo ubezpieczyciel przy odnowieniu polisy.

Druga przyczyna jest bardziej przyziemna. Środowisko liczone w kilkunastu maszynach ma zwykle kilkunastu właścicieli po stronie biznesu, a każdy z nich ma inny pogląd na to, kiedy wolno wyłączyć „jego” system. Bez zapisanego harmonogramu z nazwiskami projekt utyka na etapie ustalania terminów i wraca po kwartale w tym samym miejscu.

Papier nie zastępuje tu pracy technicznej. Sprawia natomiast, że praca techniczna ma kiedy się odbyć.

Co musi być ustalone, zanim otworzymy pierwsze okno?

Sześć rzeczy, każda z nazwiskiem i datą. Dopóki którejś brakuje, nie ruszamy maszyny, choćby była gotowa od strony technicznej.

Etap	Dowód, który zostaje	Kto to podpisuje
Spis środowiska	wykaz maszyn z rolami, zasobami i zależnościami	osoba odpowiadająca za IT
Ocena wpływu	co przestaje działać i na jak długo	właściciel każdego systemu
Wniosek o zmianę	termin, zakres, warunek powrotu	osoba decyzyjna po Waszej stronie
Próba na maszynie testowej	zmierzone czasy i lista niespodzianek	inżynier prowadzący i Wasz zespół
Przełączenie maszyny	protokół testów po starcie	właściciel systemu
Odbiór projektu	raport, dokumentacja, wynik odtworzenia kopii	osoba decyzyjna po Waszej stronie

Najważniejszy jest wiersz trzeci, a w nim warunek powrotu. Zapisujemy go zawsze jako zdanie mówiące, co dokładnie musi się wydarzyć, żebyśmy przerwali prace i wrócili na starą platformę. Bez tego zdania decyzja o przerwaniu zapada w środku nocy, pod presją, przez osobę, która nie ma do niej mandatu.

Jak wygląda dzień przełączenia maszyny krytycznej?

Zaczyna się kilka dni wcześniej i to jest w nim najważniejsze. Dyski kopiujemy przy działającym systemie, sterowniki wgrywamy na jeszcze pracującej maszynie, konfigurację sieci po nowej stronie przygotowujemy i sprawdzamy na próbie. W samym oknie zostaje ostatnia synchronizacja, zatrzymanie starej maszyny i uruchomienie nowej.

Po starcie idzie lista, a nie wrażenie. Sprawdzamy, czy usługi wstały, czy aplikacja widzi bazę, czy stanowiska faktycznie się z nią łączą, czy integracje wychodzące na zewnątrz odpowiadają i czy wykonało się pierwsze zadanie kopii po nowej stronie. Dopiero komplet odpowiedzi zamyka maszynę, a właściciel systemu potwierdza to jednym zdaniem w protokole.

Stara maszyna zostaje wtedy wyłączona, ale nietknięta. Różnica między maszyną wyłączoną a skasowaną jest różnicą między minutą a kilkoma godzinami odtwarzania, i to o niej pamiętamy najbardziej w tygodniu po przełączeniu.

Kiedy przerywamy prace i wracamy na starą platformę?

Wtedy, gdy spełni się warunek zapisany we wniosku, i ani chwili później. Zwykle brzmi on prosto: maszyna nie wstaje w ciągu ustalonego czasu, kluczowa usługa nie odpowiada po dwóch próbach albo wydajność po migracji jest wyraźnie gorsza od pomiaru sprzed niej. Powrót polega wtedy na wyłączeniu maszyny w Proxmoksie i uruchomieniu starej, więc mieści się w tym samym oknie.

Nie naprawiamy w oknie. To najczęstszy błąd w takich projektach: godzina diagnozy zamienia się w trzy, okno się kończy, ludzie przychodzą do pracy, a środowisko jest w stanie pośrednim. Diagnoza odbywa się po powrocie, na spokojnie, i kończy się kolejnym terminem, a nie improwizacją.

Zasoby po stronie VMware zwalniamy dopiero po pisemnym odbiorze całości. Kilka tygodni miejsca na magazynie danych jest najtańszym ubezpieczeniem, jakie w takim projekcie da się kupić.

Co zostaje po projekcie i kto z tego korzysta później?

Środowisko na Proxmoksie, opis klastra, magazynu i sieci, wykaz maszyn z rolami i zasobami, procedura odtworzenia po awarii oraz raport zawierający zmierzone czasy przestojów. Do tego komplet dokumentów zmiany, czyli to, co pokażecie audytorowi i klientowi pytającemu o infrastrukturę.

Konta administracyjne zakładamy na Waszą spółkę, nie na siebie, więc dalsze prowadzenie środowiska możecie zostawić nam albo przejąć w całości bez odbudowywania czegokolwiek. Wybór między platformami opisuje porównanie Proxmoksa i VMware, budowę środowiska od podstaw wirtualizacja serwerów, a bieżący nadzór administracja serwerami. Termin przeglądu ustalimy przez kontakt.

Treść sprawdzona i zaktualizowana: 2 sierpnia 2026