Instalacja Proxmoxa na Lenovo M710q: od pustego dysku do pierwszej maszyny

W poprzednim wpisie opisałem, dlaczego do homelaba wybrałem poleasingowego Lenovo ThinkCentre M710q. Sam sprzęt był jednak tylko początkiem. Żeby stał się użytecznym środowiskiem, potrzebował warstwy, na której mogłem bezpiecznie uruchamiać kolejne usługi.

Instalacja Proxmoxa nie była szczególnie długa, ale po drodze trafiłem na kilka decyzji i jeden problem, które miały większe znaczenie niż samo przechodzenie przez instalator.

Ten wpis opisuje drogę od pustego dysku do pierwszej maszyny z Ubuntu Server. To trzeci etap serii: po decyzji o budowie homelaba i wyborze sprzętu przyszedł czas na fundament pod właściwe środowisko developerskie.

Dlaczego w ogóle potrzebowałem hypervisora?

Moim celem nie było nauczenie się Proxmoxa dla samego Proxmoxa. Chciałem zbudować środowisko developerskie, które działa niezależnie od laptopa i jest dostępne wtedy, kiedy go potrzebuję.

Codex CLI, repozytoria GitHub, integracje MCP i przyszły NAS miały działać na jednej małej maszynie, ale bez mieszania wszystkich odpowiedzialności w jednym systemie operacyjnym.

Proxmox nie był więc celem samym w sobie. Był sposobem na zbudowanie fundamentu pod kolejne elementy homelaba: development, backupy, monitoring i eksperymenty, które mogę rozwijać krok po kroku.

Dlaczego nie Ubuntu bezpośrednio na sprzęcie?

Najprostsza opcja wyglądała rozsądnie: zainstalować Ubuntu Server na Lenovo i uruchomić na nim wszystko. Dla jednej usługi byłoby to wystarczające. Problem pojawia się wtedy, gdy maszyna zaczyna pełnić kilka ról.

Nie chciałem, żeby aktualizacja środowiska developerskiego wpływała na przyszły NAS albo monitoring. Nie chciałem też odtwarzać całej konfiguracji po nieudanym eksperymencie.

Hypervisor daje mi prosty podział odpowiedzialności. Każda maszyna może mieć własne zasoby, cykl życia i backup. Snapshot przed ryzykowną zmianą kosztuje mniej czasu niż ręczne naprawianie systemu po fakcie.

Plan przed instalacją

Zanim uruchomiłem instalator, ustaliłem prosty stan docelowy:

Proxmox VE działa bezpośrednio na Lenovo M710q,
panel administracyjny jest dostępny tylko w prywatnej sieci,
pierwsza maszyna wirtualna działa na Ubuntu Server,
VM ma stałe, przewidywalne miejsce w sieci i można połączyć się z nią przez SSH,
repozytoria, Codex CLI i integracje MCP trafiają do VM, a nie na hosta Proxmoxa.

Ta ostatnia decyzja jest ważna. Host powinien pozostać możliwie prosty. Proxmox zarządza maszynami; nie jest miejscem na codzienną pracę developerską.

Przygotowanie Lenovo M710q

Przed instalacją podłączyłem Lenovo przewodowo do routera, klawiatury i monitora. Wi-Fi jest wygodne dla laptopa, ale host wirtualizacji powinien mieć stabilne, przewidywalne połączenie sieciowe.

W BIOS-ie sprawdziłem kolejność bootowania i obsługę wirtualizacji. To drugi punkt okazał się istotny później: sam procesor wspiera VT-x, ale używany komputer nie musi mieć tej funkcji włączonej.

Instalacyjny pendrive przygotowałem z oficjalnego obrazu ISO Proxmox VE. Ponieważ instalacja miała wykorzystać cały dysk, wcześniej upewniłem się, że nie ma na nim danych, których potrzebuję.

Instalacja Proxmox VE

Sam instalator wymaga kilku konkretnych decyzji: wyboru dysku, ustawień regionalnych, hasła administratora i konfiguracji sieci. Najwięcej uwagi poświęciłem właśnie sieci.

Proxmox potrzebuje adresu, pod którym panel administracyjny pozostanie dostępny po restarcie. Ustawiłem więc adres w prywatnej sieci domowej, poprawną bramę i serwer DNS. Następnie zarezerwowałem ten adres po stronie routera, żeby uniknąć późniejszego konfliktu.

Po instalacji wyjąłem pendrive i uruchomiłem komputer ponownie. Panel Proxmoxa był dostępny z przeglądarki na innym urządzeniu w tej samej sieci. Nie wystawiałem go do publicznego internetu i nadal nie mam takiej potrzeby.

Pierwszy błąd: brak sprzętowej akceleracji KVM

Pierwsza próba utworzenia maszyny wirtualnej szybko ujawniła problem:

No support for hardware accelerated KVM virtualization detected

Komunikat sugerował, że host nie może użyć sprzętowej wirtualizacji. Na początku wyglądało to jak ograniczenie Lenovo albo procesora, ale specyfikacja i5-7400T mówiła co innego.

Przyczyna była prostsza: Intel Virtualization Technology była wyłączona w BIOS-ie. Po jej włączeniu i ponownym uruchomieniu hosta KVM zaczął działać poprawnie.

To był najbardziej praktyczny wniosek z całej instalacji: przy używanym sprzęcie nie należy zakładać, że ustawienia BIOS-u odpowiadają możliwościom urządzenia. Warto sprawdzić je przed diagnozowaniem systemu operacyjnego.

Sieć: bridge zamiast ręcznego kombinowania

Proxmox podczas instalacji tworzy bridge sieciowy, zwykle nazwany vmbr0. Dla maszyn wirtualnych działa on jak wirtualny switch połączony z fizycznym interfejsem Lenovo.

Dzięki temu pierwsza VM mogła dostać własny adres w tej samej prywatnej sieci co pozostałe urządzenia. Nie potrzebowałem dodatkowego NAT-u ani nietypowych reguł routingu. Z punktu widzenia routera Ubuntu Server jest osobną maszyną.

Na tym etapie prostota była ważniejsza niż rozbudowana segmentacja. Osobne VLAN-y i bardziej restrykcyjne reguły mają sens później, kiedy w homelabie pojawi się więcej usług o różnych poziomach zaufania.

Pierwsza maszyna: dev-ubuntu

Pierwszą maszynę nazwałem dev-ubuntu. Jej zadanie jest jednoznaczne: ma być prywatnym, zawsze dostępnym środowiskiem pracy.

Na start przydzieliłem jej tylko część zasobów Lenovo. Nie ma sensu oddawać jednej VM całego CPU, RAM-u i dysku, zanim pojawią się rzeczywiste pomiary. Zasoby w Proxmoxie można zwiększyć później, a wolna pamięć zostawia miejsce na kolejne usługi.

Podczas instalacji Ubuntu Server włączyłem SSH. Po pierwszym uruchomieniu zaktualizowałem system, skonfigurowałem logowanie kluczem i sprawdziłem, czy połączenie działa z mojego głównego komputera.

Co trafiło do VM, a co zostało na hoście?

Podział jest celowo prosty:

Lenovo ThinkCentre M710q
│
└── Proxmox VE
    │
    └── VM: dev-ubuntu
        │
        ├── Workspace
        │   └── GitHub repositories
        │
        ├── Codex CLI
        │
        └── MCP Integrations
            ├── GitHub MCP
            └── Linear MCP

Host Proxmoxa odpowiada za wirtualizację, sieć maszyn i ich cykl życia. Narzędzia developerskie działają wewnątrz dev-ubuntu. Jeśli zepsuję konfigurację środowiska, nie naruszam fundamentu całego homelaba.

Backup przed optymalizacją

Po skonfigurowaniu czystej VM wykonałem pierwszy backup. To dobry moment, bo system jest już dostępny przez SSH, ale nie zawiera jeszcze wielu zależności i ręcznych zmian.

Snapshot jest wygodny przed krótkim eksperymentem, ale nie zastępuje backupu przechowywanego niezależnie od działającej maszyny. Docelowo kopie trafią do osobnego storage'u; na tym etapie najważniejsze było wyrobienie nawyku odtwarzania, zanim środowisko stanie się istotne.

Czego nauczyła mnie ta instalacja?

Najwięcej czasu nie zajęła instalacja Proxmoxa, tylko podjęcie kilku prostych decyzji we właściwej kolejności.

Najpierw trzeba określić role hosta i maszyn, zamiast instalować wszystko w jednym systemie.
Przewidywalna sieć i dostęp przez SSH są ważniejsze niż rozbudowany panel administracyjny.
Przy sprzęcie poleasingowym warto od razu sprawdzić BIOS, zwłaszcza ustawienia wirtualizacji.
Host hypervisora powinien pozostać nudny i stabilny. Eksperymenty należą do VM.
Backup warto przygotować przed momentem, w którym zacznie być naprawdę potrzebny.

Co dalej?

Po tym etapie miałem działający fundament: Proxmox na Lenovo M710q i pierwszą maszynę Ubuntu dostępną przez SSH. Dopiero teraz homelab zaczął realizować właściwy cel.

W kolejnym kroku opiszę konfigurację środowiska developerskiego wewnątrz dev-ubuntu: repozytoria GitHub, Codex CLI, integracje MCP oraz bezpieczny zdalny dostęp. Proxmox pozostanie w tle, dokładnie tam, gdzie powinien być.