Proxmox LXC czy maszyna wirtualna jako host Dockera z przekazywaniem USB lub GPU: co łatwiej obsługiwać?

Wybierz kontener LXC w Proxmox jako hosta Docker, gdy można bezpiecznie udostępnić węzły urządzeń Linuksa, host obsługuje wymagane sterowniki GPU lub USB, a ważne są niskie narzuty albo współdzielenie GPU. Wybierz maszynę wirtualną, gdy system gościa musi samodzielnie obsługiwać stos sterowników, urządzenie PCI ma być odizolowane przez IOMMU albo Docker i jego dostęp do sprzętu muszą być niezależne od hosta Proxmox. Szeregowe urządzenia USB często nadają się do obu rozwiązań; przekazanie GPU na wyłączność zwykle przemawia za maszyną wirtualną.

Zdefiniuj „przekazywanie” przed porównaniem LXC i maszyny wirtualnej

LXC i KVM nie przekazują sprzętu zadaniom w ten sam sposób. Kontener LXC współdzieli jądro Proxmox, więc zwykle otrzymuje uprawnienia dostępu do utworzonych przez hosta węzłów urządzeń, takich jak `/dev/dri`, `/dev/ttyUSB0` czy `/dev/bus/usb`. Host nadal wykrywa sprzęt i ładuje sterownik jądra.

Maszyna wirtualna uruchamia własne jądro. Proxmox może emulować urządzenie USB, podłączyć wybrane urządzenie lub port USB albo przypisać urządzenie PCI przez VFIO i IOMMU. System gościa ładuje wtedy własny sterownik i korzysta z przypisanego sprzętu bardziej tak, jakby był on zainstalowany bezpośrednio w maszynie.

Aktualny przewodnik po konfiguracji NAS-a Proxmox w ZimaSpace przedstawia oba typy systemów gościa. W tym artykule zawężamy wybór do hosta Docker, którego kontenery potrzebują kluczy USB, adapterów szeregowych, kart GPU do multimediów lub akceleratorów obliczeniowych.

Urządzenia USB lepiej działają w LXC, gdy są stabilnymi węzłami urządzeń Linuksa

Adaptery USB-szeregowe, koordynatory Zigbee, interfejsy UPS, akceleratory Coral USB i podobne urządzenia mogą dobrze działać w LXC, jeśli Proxmox udostępnia węzeł urządzenia i mapuje właściwego właściciela. Kontener Docker działający wewnątrz LXC otrzymuje wtedy urządzenie ze środowiska systemu Linux, na którym działa.

Praktyczne wyjaśnienie dostępu do USB w Proxmox LXC pokazuje podstawową zasadę: samo zamontowanie urządzenia nie wystarczy, jeśli kontener nie ma również uprawnień dostępu do niego.

Jeśli aplikacja to obsługuje, używaj stabilnych ścieżek, takich jak `/dev/serial/by-id`. Numery magistral i przypisania `/dev/ttyUSB0` mogą się zmieniać po restarcie lub ponownym podłączeniu. Rozwiązanie z LXC staje się zawodne, gdy każda aktualizacja hosta wymaga ręcznego poprawiania cgroup, UID, GID lub ścieżki urządzenia.

Maszyna wirtualna jest lepszym rozwiązaniem, gdy własność USB ma być całkowicie niezależna

Urządzenie USB można przypisać do maszyny wirtualnej według identyfikatora producenta i produktu lub fizycznego portu, a następnie załadować jego sterownik w osobnym systemie operacyjnym. Przydaje się to, gdy urządzenie wymaga pakietu producenta, innej wersji jądra lub stosu aplikacji, który nie powinien zależeć od bibliotek hosta Proxmox.

Maszyna wirtualna zapewnia też wyraźniejszą granicę diagnostyczną. Jeśli system gościa utraci urządzenie USB, administrator może osobno sprawdzić podłączenie w hiperwizorze, a następnie sterownik w systemie gościa. W LXC w jednym łańcuchu uczestniczą sterownik hosta, węzeł urządzenia, uprawnienia, mapowanie kontenera, środowisko Docker i aplikacja.

Kompromisem jest sposób ponownego nawiązywania połączenia. Niektóre urządzenia USB resetują się, zmieniają tożsamość lub znikają po ponownym uruchomieniu systemu gościa. Przetestuj odłączenie i ponowne podłączenie, restart hosta, restart systemu gościa oraz odzyskiwanie działania aplikacji, zamiast zakładać, że udane pierwsze podłączenie gwarantuje stabilne działanie.

Featured

ZimaBoard 2 - Miniaturowy serwer domowy dla wielkich pomysłów

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Współdzielony dostęp do GPU zwykle przemawia za LXC

W przypadku urządzeń renderujących Intel lub AMD oraz obsługiwanych zastosowań NVIDIA LXC może udostępniać węzły urządzeń GPU hosta kilku usługom linuksowym. Sterownik hosta Proxmox nadal zarządza kartą graficzną, dzięki czemu wiele kontenerów może korzystać ze sprzętowego transkodowania lub obliczeń bez przypisywania całego urządzenia PCI jednemu systemowi gościa.

Najnowszy przykład Proxmoxa w XDA wyjaśnia, jak LXC może współdzielić kartę graficzną zarządzaną przez hosta, zamiast przypisywać ją na wyłączność przez przekazywanie urządzenia do maszyny wirtualnej. Ten sam model operacyjny może sprawdzić się w przypadku Jellyfin, Plex, Frigate lub wielu usług Docker, gdy wymagania dotyczące sterowników i uprawnień są zgodne.

Współdzielenie powoduje zależność od wersji. Sterownik hosta, biblioteki przestrzeni użytkownika w LXC, integracja środowiska uruchomieniowego Dockera i pakiety aplikacji muszą pozostać zgodne. Aktualizacja jądra Proxmox lub sterownika może więc jednocześnie wpłynąć na każdy kontener korzystający z GPU.

Przekazywanie GPU na wyłączność zwykle przemawia za maszyną wirtualną

Maszyna wirtualna jest lepszym wyborem, gdy jedno obciążenie wymaga bezpośredniego dostępu do osobnego GPU, zastrzeżonego sterownika w systemie gościa, obsługi Windows, izolacji CUDA lub stosu jądra, którego nie należy instalować w Proxmox. Przypisanie przez VFIO odłącza urządzenie od hosta i udostępnia je systemowi gościa.

Model PCI w Proxmox został zaprojektowany z myślą o przypisywaniu fizycznych urządzeń PCI do maszyn wirtualnych KVM. Dyskusja o Dockerze na Level1Techs pokazuje praktyczną konsekwencję: maszyna wirtualna zazwyczaj korzysta z przekazanego GPU na wyłączność, natomiast LXC może współdzielić dostęp hosta do urządzenia między usługami.

Wybór może się odwrócić, gdy GPU obsługuje urządzenia mediowane lub SR-IOV, ale konsumenckie karty graficzne i platformy serwerów domowych nie zapewniają uniwersalnej metody współdzielenia. Zanim oprzesz na tym konfigurację, sprawdź grupy IOMMU, zachowanie po resecie, firmware, inicjalizację wyświetlania oraz to, czy host potrzebuje danego GPU.

Docker w LXC dodaje zagnieżdżoną warstwę zarządzania

LXC zapewnia już izolację na poziomie systemu operacyjnego, a Docker dodaje w nim kolejne środowisko uruchomieniowe kontenerów. Może to być wydajne, ale wprowadza zagnieżdżone przestrzenie nazw, cgroups, sterowniki pamięci masowej, uprawnienia i sposób obsługi punktów montowania. Niektóre funkcje Dockera wymagają włączenia zagnieżdżania lub dodatkowych uprawnień w kontenerze Proxmox.

Dla Dockera maszyna wirtualna stanowi standardowy host linuksowy. Dokumentację Dockera, moduły jądra, działanie zapory i sterowniki pamięci masowej łatwiej zrozumieć, ponieważ konfiguracja jądra gościa jest niezależna. Ceną jest pełny system operacyjny gościa, zarezerwowana pamięć, zarządzanie dyskiem wirtualnym i kolejna warstwa aktualizacji.

Nie wybieraj LXC wyłącznie po to, by zaoszczędzić kilkaset megabajtów, jeśli wymagana konfiguracja wymusza użycie uprzywilejowanego kontenera, szerokich uprawnień do urządzeń i nieudokumentowanych zmian na hoście. Lekkie rozwiązanie traci na wartości, gdy każda aktualizacja wymaga pamiętania o wyjątkach, które w przypadku maszyny wirtualnej byłyby zamknięte w systemie gościa.

Izolacja i bezpieczeństwo mogą odwrócić wynik porównania wydajności

LXC współdzieli jądro hosta, więc błędnie skonfigurowany kontener uprzywilejowany lub zbyt szerokie mapowanie urządzeń może dać większy dostęp do węzła Proxmox, niż zamierzano. LXC bez uprawnień, wąsko określone uprawnienia urządzeń, montowania tylko do odczytu i minimalny zakres uprawnień zwiększają izolację, ale architektura nadal jest bardziej powiązana niż w przypadku pełnej maszyny wirtualnej.

Maszyna wirtualna zapewnia oddzielne jądro i może izolować zastrzeżone stosy GPU, sieć Dockera, moduły zapory sieciowej i oprogramowanie eksperymentalne od podstawowego systemu Proxmox. Taka separacja jest cenna, gdy host Dockera uruchamia obrazy innych firm, usługi publiczne, lokalne pakiety AI lub często testowane sterowniki.

Maszyna wirtualna nie jest automatycznie bezpieczna. Przekazywanie PCI, współdzielone montowania pamięci masowej, dane logowania do zarządzania i sieć mostkowana nadal tworzą wektory ataku i awarii. Wybierz ją wtedy, gdy niezależne jądro i granica sterowników rzeczywiście upraszczają model zagrożeń i utrzymania.

Kopie zapasowe i migracja sprzyjają różnym rodzajom prostoty

Kopie zapasowe LXC są kompaktowe i szybkie, ponieważ gość nie zawiera pełnego stosu sprzętu wirtualnego. Jednak odtworzenie dostępu do sprzętu na innym węźle Proxmox wymaga zgodności węzłów urządzeń, grup, sterowników i uprawnień. System plików kontenera można przenieść, ale warunków dostępu do urządzenia fizycznego już nie.

Kopia zapasowa maszyny wirtualnej zawiera system operacyjny gościa i konfigurację sterowników, dzięki czemu odzyskiwanie aplikacji jest bardziej samodzielne. Urządzenia USB i adresy PCI nadal trzeba ponownie zmapować na hoście docelowym, a przekazanie GPU może uniemożliwić migrację na żywo, ponieważ urządzenie fizyczne jest przypisane do jednego węzła.

Przepływ pracy tworzenia kopii zapasowych Proxmox w ZimaSpace obejmuje ochronę gościa. Na potrzeby tego porównania odzyskiwanie jest zakończone dopiero wtedy, gdy Docker się uruchomi, a aplikacja zależna od USB lub GPU wykryje urządzenie zastępcze.

Przetestuj odzyskiwanie urządzenia przed wyborem typu gościa

1. Wymień wszystkie urządzenia USB i PCI wymagane przez aplikacje Docker.
2. Zdecyduj, czy każde urządzenie ma być współdzielone z hostem, czy przypisane do jednego gościa.
3. Przetestuj sterownik hosta, węzeł urządzenia, mapowanie UID/GID i uprawnienia Dockera dla LXC.
4. Przetestuj grupowanie IOMMU, instalację sterownika gościa i zachowanie podczas resetowania maszyny wirtualnej.
5. Uruchom ponownie hosta Proxmox i potwierdź, że urządzenie zostanie ponownie automatycznie podłączone.
6. Przywróć gościa z kopii zapasowej i odtwórz mapowanie sprzętu na podstawie dokumentacji.
7. Powtórz test na innym kompatybilnym węźle, jeśli znaczenie ma migracja lub wymiana sprzętu.

Oceniaj działanie aplikacji, a nie tylko narzut gościa. Stabilność transkodowania sprzętowego, ponowne łączenie urządzeń USB, aktualizacje sterowników, konserwacja hosta i czas odzyskiwania zwykle mają większe znaczenie niż niewielka różnica w obciążeniu procesora między LXC a KVM.

Który gość Proxmox sprawdzi się jako host Dockera?

Wybierz LXC, gdy

Wybierz LXC, gdy wszystkie obciążenia działają w systemie Linux, sterownikami może zarządzać host, urządzenia USB mają stabilne ścieżki, a procesor graficzny ma być współdzielony przez kilka usług. W miarę możliwości pozostaw kontener nieuprzywilejowany i udokumentuj każde mapowanie urządzeń i grup.

Wybierz maszynę wirtualną, gdy

Wybierz maszynę wirtualną, gdy host Dockera wymaga wyłącznego dostępu do GPU przez PCI, zastrzeżonych lub eksperymentalnych sterowników, silniejszej izolacji jądra albo łatwiejszej przenośności całego stosu oprogramowania. Przydziel systemowi gościa wystarczającą ilość pamięci RAM i przestrzeni dyskowej, a po ponownym uruchomieniu przetestuj reset urządzenia.

Podziel obciążenia, gdy

Uruchamiaj lekkie usługi multimedialne i usługi USB w LXC, a obliczenia wymagające wyłącznego dostępu do GPU, narzędzia zależne od Windowsa lub niezaufane stosy Dockera umieszczaj w maszynie wirtualnej. Platforma obsługująca Proxmox może obsłużyć oba rozwiązania, ale każdy fizyczny sprzęt powinien mieć udokumentowany model własności.

Często zadawane pytania

Czy Docker może niezawodnie działać w nieuprzywilejowanym LXC?

Tak, w wielu zastosowaniach, ale zagnieżdżanie, sterowniki pamięci masowej, punkty montowania, sieć i dostęp do urządzeń mogą wymagać dodatkowej konfiguracji. Przetestuj konkretne funkcje Dockera i nie przełączaj się na kontener uprzywilejowany tylko po to, by obejść niewyjaśniony problem z uprawnieniami.

Czy jeden procesor graficzny może być używany jednocześnie przez LXC i maszynę wirtualną?

Nie w przypadku zwykłego przekazywania całego urządzenia przez VFIO w tym samym czasie. LXC może współdzielić zarządzane przez hosta urządzenie renderujące, natomiast w przypadku maszyny wirtualnej urządzenie zwykle trzeba odłączyć od hosta. Obsługa SR-IOV lub urządzeń wirtualnych może to zmienić w przypadku konkretnego sprzętu.

Które rozwiązanie jest lepsze dla koordynatora Zigbee USB?

Oba rozwiązania mogą się sprawdzić. LXC jest wydajny, gdy stabilna ścieżka urządzenia szeregowego oparta na identyfikatorze oraz uprawnienia działają niezawodnie. Maszyna wirtualna jest lepszym wyborem, gdy oprogramowanie koordynatora lub jego sterownik powinny pozostać niezależne od hosta Proxmox.

Ostateczny werdykt

Użyj LXC jako hosta Dockera, gdy zasoby USB i GPU mogą być współdzielone za pośrednictwem stosu sterowników Linuksa hosta Proxmox, a niski narzut ma znaczenie. Wybierz maszynę wirtualną, gdy sprzęt ma należeć do systemu gościa, sterowniki muszą być odizolowane lub odzyskiwanie ma zachować samodzielny system operacyjny. Wybieraj na podstawie własności urządzeń i sposobu przywracania, a nie założenia, że kontenery zawsze są prostsze.