Migracja z VMware na Proxmox Toruń

Jak zmieścić migrację w oknie, które trwa dwie godziny?

Zakład spożywczy w Toruniu rzadko może zaoferować tydzień przerwy, ma za to coś, czego nie ma większość firm biurowych: okna krótkie, ale przewidywalne i wracające w stałym rytmie. Postój związany z myciem i przeglądem urządzeń pojawia się w planie z wyprzedzeniem i nie trzeba go nikomu wywalczać.

Cały projekt układamy więc pod ten rytm. Zamiast czekać na przerwę, która w takiej firmie po prostu nie nadchodzi, tniemy pracę na porcje wielkości jednego postoju. Zasada jest przy tym jedna i nienegocjowalna: żadna maszyna nie może przechodzić przez dwa okna. Przełączenie i sprawdzenie musi zamknąć się w jednym postoju, z zapasem na powrót do stanu poprzedniego.

Co mieści się w oknie, a co robimy wcześniej?

Znakomita większość pracy dzieje się poza postojem, przy działających maszynach. W oknie zostaje tylko to, czego nie da się zrobić inaczej.

Etap	Kiedy się dzieje	Ile zwykle trwa
Spis maszyn, zależności i licencji	w dowolnym dniu roboczym	kilka dni, bez wpływu na produkcję
Instalacja Proxmoksa i konfiguracja klastra	poza postojem, na nowym sprzęcie	zależnie od dostawy sprzętu
Migracja próbna maszyny nieprodukcyjnej	poza postojem, na żywym środowisku	jedno popołudnie
Wgranie sterowników VirtIO w systemach Windows	przy działającej maszynie, przed przełączeniem	kilkanaście minut na maszynę
Kopiowanie dysków na nową platformę	w tle, przy pracującej maszynie	od godziny do kilkunastu godzin
Ostatnia synchronizacja i uruchomienie po nowej stronie	wyłącznie w oknie serwisowym	od kilkunastu minut do godziny
Sprawdzenie maszyny i decyzja o powrocie	wyłącznie w oknie serwisowym	kilkanaście minut

Wiersz przedostatni jest jedynym, który naprawdę konkuruje o postój, i dlatego liczba potrzebnych okien wynika z liczby maszyn, a nie z wielkości środowiska.

Czego szukamy w spisie, zanim ustawimy pierwsze okno?

Rzeczy, które w zakładzie produkcyjnym potrafią zatrzymać całe przedsięwzięcie, a w biurze nie występują wcale. Spis robimy więc dokładniej, niż wynikałoby z liczby maszyn, i pytamy o cztery sprawy.

Klucze sprzętowe wpięte do portu USB, bez których program do etykiet albo system jakościowy nie uruchomi się w ogóle. Połączenia szeregowe do wag i sterowników, przepuszczane dziś z hosta do maszyny wirtualnej. Licencje przywiązane do adresu karty sieciowej, przez co przeniesiona maszyna budzi się bez uprawnień do działania. Wreszcie systemy stare na tyle, że ich zachowanie po zmianie warstwy sprzętowej trzeba po prostu sprawdzić, zamiast zakładać.

Każdą taką pozycję wypisujemy przy spisie i rozstrzygamy na migracji próbnej, a nie w oknie serwisowym. Kwadrans na sprawdzenie klucza sprzętowego tydzień wcześniej jest tańszy od decyzji podejmowanej o wpół do szóstej rano, gdy postój zaraz się kończy.

Dlaczego kalendarz sezonu wchodzi do harmonogramu przed pierwszym dniem prac?

Bo w zakładzie przyjmującym surowiec przez kilka tygodni w roku nie ma czegoś takiego jak drobna zmiana w szczycie. Wyłączamy więc te tygodnie z planu na starcie, wpisujemy je do harmonogramu jako czas niedostępny i nie wracamy do tej rozmowy w trakcie prac. Migracja rozciągnięta na dłużej, ale omijająca kampanię, jest tańsza od migracji, którą trzeba wstrzymać w połowie pod presją.

Ten sam kalendarz rozstrzyga kolejność. Maszyny obsługujące przyjęcie i etykietowanie przenosimy albo wyraźnie przed sezonem, albo wyraźnie po nim, nigdy w ostatnim wolnym oknie przed nim.

Co się dzieje, gdy okno przepadnie?

Przesuwa się jedna porcja pracy i nic poza tym. Kolejność układamy od maszyn najmniej krytycznych, każda porcja jest niezależna, a obie platformy pracują równolegle przez cały czas trwania projektu. Zakład, w którym postój wypadł, bo przyszła dostawa, wraca do planu w następnym tygodniu bez żadnych konsekwencji.

To jest właśnie powód, dla którego przy takim rytmie pracy nie planujemy migracji jako jednego wydarzenia. Plan, który rozsypuje się po pominięciu jednego terminu, jest planem źle ułożonym, a nie pechowym.

Kiedy i jak wracamy na VMware?

Decyzję podejmujemy w tym samym oknie, w którym przełączyliśmy maszynę, zaraz po sprawdzeniu, czy wstała poprawnie, czy widzi bazę i czy komunikuje się z urządzeniami. Powrót polega na wyłączeniu maszyny po nowej stronie i uruchomieniu starej, więc mieści się w minutach i nie wymaga odtwarzania danych.

Środowisko VMware zostaje kompletne do dnia odbioru całości. Zasoby zwalniamy dopiero po Waszej pisemnej akceptacji, i to nie jest formalność, tylko jedyny warunek, przy którym zdanie o możliwości wycofania się cokolwiek znaczy.

Co dostajecie po ostatnim oknie

Działające środowisko na Proxmoksie, opis klastra, magazynu i sieci, procedury odtwarzania maszyn oraz raport z migracji: co przeniesiono, w którym oknie, ile to zajęło i co zostało zmienione po drodze. Kopie i progi w monitoringu pracują po nowej stronie od pierwszej godziny, a nie od osobnego zlecenia.

Dostępy są Wasze, więc dalsze prowadzenie środowiska możecie zlecić nam w ramach administracji serwerami albo poprowadzić samodzielnie. Jeżeli decyzja o platformie jeszcze nie zapadła, warto zacząć od zestawienia na stronie Proxmox czy VMware, a budowę środowiska od zera opisuje wirtualizacja serwerów.

Treść sprawdzona i zaktualizowana: 14 sierpnia 2026