Blogi dla programistów Java zwykle omawiają Springa, JVM i testy. Rzadziej — co się dzieje, gdy firma przenosi serwery aplikacyjne z VMware na Proxmox. A dzieje się dużo: inne dyski wirtualne, inna sieć, inny czas rozruchu. Ten tekst łączy świat wdrożeń z światem hiperwizora, żebyście wiedzieli, czego wymagać od zespołu infrastruktury.
Jeśli Wasza aplikacja działa na Tomcacie w VM na ESXi, migracja hiperwizora to Wasz problem tak samo jak problem admina. Pipeline CI/CD nie przeżyje, jeśli adresy środowiska testowego się zmienią bez powiadomienia. Testy integracyjne padną, jeśli baza po konwersji ma inny zegar systemowy. Developer, który rozumie podstawy migracji VM (V2V) i przełączenia, szybciej pomaga domknąć projekt — i rzadziej słyszy „u nas działa na laptopie”. Przy projekcie migracja maszyn vmware do proxmox ten sam wkład (testy odbiorcze, pipeline, wycofanie aplikacji) jest warunkiem odbioru fali, nie „opcją na koniec”.
Co się zmienia pod spodem JVM
Sama maszyna wirtualna z Linuxem i JDK często startuje na KVM bez zmian w kodzie. Zmienia się warstwa pod JVM: sterowniki dysku (VirtIO zamiast VMware paravirtual), karta sieciowa, czasem UUID maszyny widoczny dla licencji narzędzi. Heap i GC tego nie widzą — widzi to skrypt startowy, jeśli zakładał ścieżki montowania po starych nazwach urządzeń.
Po migracji sprawdźcie: /etc/fstab, montowania NFS dla artefaktów, hostname w TLS certyfikatach, połączenia JDBC (czasem inna latencja przez bridge). Jedna godzina testu odbiorczego po fali oszczędza tydzień debugowania „losowych” timeoutów.
Środowiska dev, test i prod w jednym klastrze
Zespoły Java często mają kilka VM: dev, test, preprod, prod. Na Proxmox można je trzymać w jednym klastrze z tagami VLAN i limitami zasobów — podobnie jak na vSphere, ale bez licencji od socketów. Ważne, by przed migracją spisać mapę: która VM odpowiada któremu branchowi, jakie porty są wystawione, gdzie Jenkins lub GitLab Runner ma swój agent.
Jeśli runner był na ESXi z snapshotem sprzed miesiąca, migracja to dobry moment na czysty obraz i powtarzalny cloud-init — mniej wyjątkowych, ręcznie doglądanych serwerów, więcej infrastruktury jako kodu.
Narzędzia konwersji z perspektywy wdrożeń
Administrator użyje narzędzi w stylu eksportu dysku, virt-v2v lub importu obrazu. Developer powinien wiedzieć, że:
- konwersja trwa dłużej niż kopiowanie pliku JAR — planujcie okna;
- Windowsowe build agenty wymagają VirtIO przed przełączeniem;
- Linuxowe serwisy z Dockerem potrzebują sprawdzenia cgroupów i storage driverów po przeniesieniu;
- bazy danych (PostgreSQL, Oracle) często idą w osobnej fali z repliką lub kopią punkt-w-czasie.
Nie musicie obsługiwać tych narzędzi — musicie dostarczyć listę kontrolną aplikacji: porty, zależności, minimalne RAM/CPU, czas startu po reboot.
CI/CD a migracja falami
Gdy prod jedzie na Proxmox, a staging jeszcze na ESXi, macie dwa światy. Ustalcie zamrożenie zmian infrastruktury w tygodniu przełączenia albo flagę funkcji na środowisku. Pipeline, który wdraża co godzinę, koliduje z migracją bazy w tej samej nocy.
Dobry partner migracji proxmox pyta o okna wdrożeń — jeśli nie pyta, przypomnijcie. Wasz harmonogram wydań to dane wejściowe do scenariusza operacyjnego, nie „szczegół na później”.
Java na KVM: wydajność i tuning
KVM w Proxmox daje tryb CPU z bezpośrednim przekazaniem hosta albo emulację — zależnie od polityki klastra. Dla JVM z dużym heapem liczy się stabilność częstotliwości i NUMA — przy migracji z innego typu CPU sprawdźcie flagi -XX:+UseNUMA i benchmark po przełączeniu. Nie chodzi o mikro-optymalizacje, lecz o to, by opóźnienie pod obciążeniem nie skoczyło po weekendzie.
Kontenery LXC na tym samym hoście mogą obsłużyć lekkie usługi pomocnicze (Redis, broker), ale stateful Java zwykle zostaje w pełnej VM — to decyzja architektury, nie religia.
Bezpieczeństwo: sekrety i sieć
Po migracji przejrzyjcie magazyn sekretów z danymi dostępowymi: czy IP bazy się zmieniło, czy firewall widzi nową podsieć. Spring Cloud Config i zmienne środowiskowe w Kubernetesie (jeśli macie hybrydę) muszą wskazywać właściwe hosty. 2FA na panelu Proxmox to temat admina, ale segregacja sieci prod/dev — temat wspólny.
Kiedy developer powinien eskalować
Eskalujcie, gdy: test odbiorczy po migracji pada na SSL, JDBC łączy się z timeoutem mimo zielonego pinga, pliki na współdzielonym magazynie mają złe uprawnienia, lub czas JVM startu przekracza SLA orchestracji. To nie są „bugi aplikacji” — to symptomy warstwy VM.
Pełna migracja vmware na proxmox z udziałem zespołu aplikacyjnego kończy się protokołem: lista VM, wersje JDK, wyniki testów, znane odchylenia. Bez tego utrzymanie żyje na pamięci jednego seniora.
Testy automatyczne po migracji VM
Po każdej fali odpalcie pakiet testów, który naprawdę dotyka produkcji: kontraktowe testy API, testy dymne Selenium na krytycznych ścieżkach, test połączenia do brokera wiadomości. Nie polegajcie wyłącznie na „ping działa”. JVM potrafi wstać, a aplikacja paść na braku montowania NFS z logami.
W pipeline dodajcie tymczasowy job „post-migration-health” z alertem na Slack — jeden klik dla dyżurnego po przełączeniu. To godzina pracy devopsu, która oszczędza noc eskalacji.
Wersjonowanie środowisk a niezmienna infrastruktura
Jeśli po migracji budujecie VM z szablonu cloud-init zamiast klonować „świętą” maszynę sprzed pięciu lat, zyskujecie powtarzalność. Obraz bazowy z JDK, agentem monitoringu i utwardzeniem OS to infrastruktura jak kod — łatwiejsza do odtworzenia po awarii niż ręcznie patchowany serwer.
Spring Boot z externalized configuration przez zmienne środowiskowe ułatwia przełączanie między starym a nowym hostem — pod warunkiem, że config server zna nowe adresy przed falą.
Mikroserwisy i monolit na jednym klastrze
Zespół z monolitem na jednej dużej VM i mikroserwisami na mniejszych gościach musi ustalić kolejność fal: najpierw usługi bez stanu, potem bazy, na końcu monolit — albo odwrotnie, jeśli monolit jest hubem integracji. Kolejność to decyzja architekta aplikacji, nie losowa lista z vCenter.
Logi i obserwowalność po przełączeniu
Upewnijcie się, że agent APM i przekaźnik logów (ELK, Loki, Splunk) startują po ponownym starcie VM na nowym hiperwizorze. Częsty błąd: aplikacja działa, ale metryki zniknęły, bo ścieżka do socketa lub uprawnienia systemd się zmieniły. Dodajcie do listy kontrolnej fali jeden punkt: „pulpit zielony przez 24 h” — bez tego dyżurny dowiaduje się o problemie od użytkownika, nie od alertu.
Podsumowanie dla programisty
Migracja hiperwizora to projekt infrastruktury z interfejsem w Waszym kodzie i pipeline. Dostarczcie mapę zależności, respektujcie okna fal, testujcie po przełączeniu jak po większym release. Zrozumienie KVM i Proxmox nie zastępuje admina — ale skraca drogę od commita do działającej produkcji, gdy serwerownia przestaje być czarną skrzynką z logo VMware.
Gradle, Maven i ścieżki artefaktów po zmianie VM
Jeśli buildy trzymają artefakty na dysku współdzielonym montowanym z VM, sprawdźcie mount point po migracji — często zmienia się identyfikator urządzenia w Linuxie. Pipeline, który wcześniej publikował JAR na /mnt/artifacts, może cicho pisać w pusty katalog. Dodajcie do pull requesta listę kontrolną infrastrukturalną obok zmian w kodzie.
Przy wielu mikroserwisach rozważcie tymczasowe flagi funkcji na środowisku staging po przełączeniu — pozwala włączać ruch stopniowo, zamiast przełączać całą siatkę usług jednym wieczorem.
