Migracja z VMware na Proxmox Białystok

Czy taką migrację da się przeprowadzić bez naszego inżyniera w Waszej serwerowni?

W większości przypadków tak i robimy to regularnie, tylko odpowiedź „tak” ma tu warunki, które trzeba sprawdzić przed podpisaniem, a nie w pierwszym oknie. Sama praca jest wdzięczna do prowadzenia przez łącze: kopiowanie dysków idzie między hostami stojącymi w tej samej szafie, po Waszej sieci lokalnej, a przez internet przechodzą wyłącznie nasze polecenia i podgląd konsoli. Odległość nie spowalnia więc kopiowania ani o minutę.

Ryzyko leży gdzie indziej. Migracja polega na ponownej instalacji systemu na gołym sprzęcie i na uruchamianiu maszyn w nowym miejscu, czyli na czynnościach, w których coś potrafi zatrzymać się przed startem sieci. Bez drogi wejścia niezależnej od systemu operacyjnego taki moment kończy się czekaniem na czyjś przyjazd, a okno serwisowe zamyka się bez efektu.

Dlatego etap drugi naszego projektu nie dotyczy maszyn, tylko dostępów. Jeżeli wypada źle, mówimy o tym przed wyceną i proponujemy albo naprawę warunków, albo zaplanowanie wizyty na dni instalacji.

Co musi być gotowe, zanim ustawimy pierwsze okno?

Sześć rzeczy. Każdą sprawdzamy sami, nie na podstawie zapewnień, i każdą zapisujemy w protokole przed harmonogramem.

Warunek	Po co jest potrzebny	Co robimy, gdy go brakuje
Karta zarządzania w obu hostach	obraz konsoli i sterowanie zasilaniem przy maszynie bez systemu	wizyta na dni instalacji albo dokupienie kart, gdy sprzęt to dopuszcza
Nośnik wirtualny na karcie	wgranie obrazu instalacyjnego bez wkładania pamięci przenośnej	instalacja z nośnika przygotowanego wcześniej przez Waszego pracownika
Wyjście zapasowe do sieci zarządzania	dostęp w czasie awarii łącza podstawowego	modem LTE uruchamiany na czas projektu
Osoba osiągalna pod telefonem	wypięcie przewodu, odczyt diod, wyłączenie zasilania	przesunięcie okna na termin, w którym ktoś taki będzie
Zapas mocy na jednym węźle	przetrwanie kilku dni pracy na pojedynczym hoście	wypożyczenie hosta na czas migracji albo etapowanie po kilka maszyn
Sprawdzona kopia całego środowiska	ostatnia droga powrotu, gdy zawiodą pozostałe	wykonanie i przetestowanie kopii przed rozpoczęciem prac

Wiersz piąty jest tym, który najczęściej zmienia harmonogram. Firma z dwoma hostami wypełnionymi po brzegi nie zmieści maszyn na jednym z nich, więc migracja idzie mniejszymi porcjami albo z dostawionym sprzętem.

Jak instalujemy nowy hypervisor na sprzęcie, którego nikt nie dotyka?

Kolejność nazywamy wahadłową i wygląda tak samo w każdym środowisku o dwóch hostach. Najpierw zwalniamy pierwszy host, przenosząc jego maszyny na drugi i sprawdzając, czy ten drugi faktycznie udźwignął całość. Potem, przez nośnik wirtualny karty zarządzania, wgrywamy na zwolniony sprzęt obraz instalacyjny i stawiamy na nim nową platformę razem z siecią i magazynem.

Maszyny przechodzą pojedynczo, od najmniej krytycznych. Po każdej sprawdzamy usługi, wydajność i to, czy widzą się nawzajem, bo błąd wychwycony przy trzeciej maszynie jest tańszy niż ten sam błąd znaleziony przy piętnastej. Gdy pierwsza połowa środowiska pracuje po nowej stronie, to samo robimy z drugim hostem.

W systemach Windows sterowniki VirtIO instalujemy jeszcze przed przełączeniem, na działającym systemie, bo maszyna przeniesiona bez nich potrafi nie wstać. Aktywację sprawdzamy na migracji próbnej, a nie na maszynie, od której zależy wydanie towaru.

Co robimy, gdy w środku okna zniknie zdalny dostęp?

Ten scenariusz ma spisany plan, bo przy pracy z odległości dwustu kilometrów prędzej czy później się wydarzy. Zaczynamy od rozpoznania, co dokładnie zniknęło: łącze operatora, sieć zarządzania czy sama maszyna.

Utrata łącza podstawowego przenosi nas na modem LTE, uruchamiany na czas projektu właśnie po to. Utrata dostępu do maszyny, przy działającej karcie zarządzania, kończy się wyłączeniem jej i uruchomieniem starej wersji po stronie VMware, co zajmuje minuty. Utrata obu dróg naraz uruchamia telefon do Waszej osoby na miejscu, z prośbą o wyłączenie i włączenie zasilania konkretnej maszyny, a nie o cokolwiek więcej.

Jeżeli w wyznaczonym czasie nie odzyskamy panowania nad maszyną, okno zamykamy powrotem do stanu sprzed jego rozpoczęcia. Granicę czasu ustalamy z Wami przed pracami i trzymamy się jej, bo najgorszy scenariusz w takim projekcie to nie przerwane okno, tylko okno przeciągnięte w nadziei, że jeszcze się uda.

Czego nie przenosimy i co przy okazji gaśnie?

Spis środowiska prawie zawsze wyławia maszyny, których nikt nie używa: serwer testowy sprzed trzech lat, kopia systemu wymienionego w międzyczasie, maszyna postawiona pod projekt, który się nie odbył. Przenoszenie ich kosztowałoby czas w oknach i miejsce na nowym magazynie.

Zasada jest prosta i nie podejmujemy tej decyzji sami. Do każdej takiej maszyny szukamy właściciela po Waszej stronie, a jeżeli się nie znajdzie, wyłączamy ją na uzgodniony czas przed migracją i patrzymy, czy ktokolwiek się odezwie. Kopię zachowujemy niezależnie od wyniku.

Nie przenosimy też maszyn, które powinny przestać istnieć w tej formie: systemów bez wsparcia producenta, wystawionych do internetu bez powodu, albo takich, których zadanie da się zrealizować w usłudze, którą już płacicie. Mówimy o tym przy spisie, bo migracja jest najtańszym momentem na taki porządek.

Kiedy odradzamy tę migrację firmie spod Białegostoku?

Gdy Wasze oprogramowanie ma wsparcie producenta wyłącznie na VMware i to wsparcie realnie wykorzystujecie. Gdy hosty nie mają kart zarządzania i nie da się ich dokupić, a w firmie nie ma nikogo, kto podejdzie do maszyny w środku okna. Gdy jeden węzeł nie udźwignie środowiska nawet przez kilka dni, a na dostawienie sprzętu nie ma budżetu.

W każdej z tych sytuacji mówimy to przed wyceną i kończymy rozmowę na porównaniu kosztów obu platform, które opisuje Proxmox czy VMware. Bieżące prowadzenie środowiska, na jednej i na drugiej platformie, stoi przy wirtualizacji serwerów, a podział pracy na sesję zdalną i wyjazd rozpisuje administracja serwerami Białystok.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026