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

Wybierz kontener Proxmox LXC jako hosta Dockera, gdy węzły urządzeń Linuksa można bezpiecznie udostępnić, host obsługuje wymagane sterowniki GPU lub USB, a znaczenie mają niski narzut albo współdzielenie GPU. Wybierz maszynę wirtualną, gdy system gościa musi zarządzać własnym stosem sterowników, urządzenie PCI powinno być izolowane za pomocą IOMMU albo Docker i jego dostęp do sprzętu muszą pozostać niezależne od hosta Proxmox. Szeregowe urządzenia USB często pasują do obu rozwiązań, natomiast wyłączne przekazanie GPU zazwyczaj przemawia za maszyną wirtualną.

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

LXC i KVM nie przekazują sprzętu obciążeniom w taki sam sposób. Kontener LXC współdzieli jądro Proxmox, więc zwykle otrzymuje uprawnienia dostępu do węzłów urządzeń utworzonych przez hosta, takich jak `/dev/dri`, `/dev/ttyUSB0` lub `/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, dołączyć wybrane urządzenie lub port USB albo przypisać urządzenie PCI za pomocą VFIO i IOMMU. System gościa ładuje wtedy własny sterownik i traktuje przypisany sprzęt bardziej jak urządzenie zainstalowane bezpośrednio.

Aktualny przewodnik konfiguracji serwera NAS Proxmox ZimaSpace przedstawia oba typy systemów gościa. Ten artykuł zawęża wybór do hosta Dockera, którego kontenery potrzebują kluczy USB, adapterów szeregowych, procesorów GPU do multimediów lub akceleratorów obliczeniowych.

Urządzenia USB przemawiają za LXC, gdy zachowują się jak stabilne węzły urządzeń Linuksa

Adaptery USB–szeregowe, koordynatory Zigbee, interfejsy UPS, akceleratory Coral USB i podobne urządzenia mogą dobrze działać w LXC, gdy Proxmox udostępni węzeł urządzenia i przypisze właściwego właściciela. Kontener Docker uruchomiony wewnątrz LXC otrzymuje następnie to urządzenie ze swojego linuksowego środowiska hosta.

Praktyczne wyjaśnienie dostępu USB wewnątrz Proxmox LXC pokazuje podstawowy schemat: zamontowanie urządzenia nie wystarczy, jeśli kontener nie otrzyma również uprawnień dostępu do niego.

Używaj stabilnych ścieżek, takich jak `/dev/serial/by-id`, jeśli aplikacja je obsługuje. Numery magistrali i przypisania `/dev/ttyUSB0` mogą zmienić się po ponownym uruchomieniu lub ponownym podłączeniu urządzenia. Podejście z LXC staje się podatne na problemy, gdy każda aktualizacja hosta wymaga ręcznej naprawy konfiguracji cgroup, UID, GID lub ścieżki urządzenia.

Maszyna wirtualna jest lepszym rozwiązaniem, gdy własność USB musi być w pełni samodzielna

Maszyna wirtualna może otrzymać urządzenie USB według identyfikatora producenta i produktu albo fizycznego portu, a następnie załadować sterownik urządzenia we własnym systemie operacyjnym. Jest to przydatne, 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 również wyraźniejszą granicę diagnostyczną. Jeśli gość utraci urządzenie USB, administrator może osobno sprawdzić podłączenie w hipernadzorcy, a następnie sterownik w gościu. W LXC w jednym łańcuchu uczestniczą sterownik hosta, węzeł urządzenia, uprawnienia, mapowanie kontenera, środowisko uruchomieniowe Docker i sama aplikacja.

Kompromisem jest sposób ponownego nawiązywania połączenia. Niektóre urządzenia USB resetują się, zmieniają tożsamość lub znikają podczas ponownego uruchamiania gościa. Przetestuj odłączenie urządzenia, ponowne uruchomienie hosta, ponowne uruchomienie gościa i odzyskiwanie aplikacji, zamiast zakładać, że pomyślne pierwsze podłączenie dowodzi stabilnego działania.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Współdzielony dostęp do GPU zazwyczaj przemawia na korzyść LXC

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

Niedawny przykład XDA dotyczący Proxmox wyjaśnia, jak LXC może współdzielić kartę GPU zarządzaną przez hosta, zamiast przydzielać ją na wyłączność za pośrednictwem przekazywania 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 tworzy zależności między wersjami. Sterownik jądra hosta, biblioteki przestrzeni użytkownika wewnątrz LXC, integracja środowiska uruchomieniowego Dockera i pakiety aplikacji muszą pozostać kompatybilne. Aktualizacja jądra lub sterownika Proxmox może więc jednocześnie wpłynąć na każdy kontener korzystający z GPU.

Wyłączne przekazywanie GPU zwykle przemawia za maszyną wirtualną

Maszyna wirtualna jest lepszym rozwiązaniem, gdy jedno obciążenie wymaga bezpośredniej własności dedykowanego układu GPU, zastrzeżonego sterownika gościa, obsługi systemu Windows, izolacji CUDA lub stosu jądra, którego nie należy instalować w Proxmox. Przypisanie VFIO odłącza urządzenie od hosta i udostępnia je systemowi gościa.

Model PCI w Proxmox jest zaprojektowany z myślą o przypisywaniu fizycznego urządzenia PCI gościowi KVM. Dyskusja na Level1Techs dotycząca Dockera oddaje praktyczne konsekwencje: maszyna wirtualna zwykle przejmuje przekazany układ GPU na wyłączność, podczas gdy LXC może współdzielić dostęp hosta do urządzenia między usługami.

Wybór ten może się zmienić, gdy procesor graficzny obsługuje urządzenia pośredniczone lub SR-IOV, ale konsumenckie układy GPU i platformy domowych serwerów nie zapewniają uniwersalnego mechanizmu współdzielenia. Przed zaprojektowaniem rozwiązania opartego na wyłącznym przekazaniu urządzenia sprawdź grupy IOMMU, zachowanie podczas resetu, oprogramowanie układowe, inicjalizację wyświetlania oraz to, czy host potrzebuje tego układu GPU.

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

LXC już zapewnia izolację na poziomie systemu operacyjnego, a Docker dodaje w nim kolejny mechanizm uruchamiania kontenerów. Może to być wydajne, ale wprowadza zagnieżdżone przestrzenie nazw, cgroups, sterowniki pamięci masowej, możliwości i sposób działania montowania. Niektóre funkcje Dockera wymagają w kontenerze Proxmox opcji zagnieżdżania lub dodatkowych uprawnień.

Maszyna wirtualna zapewnia Dockerowi konwencjonalnego hosta z Linuksem. Dokumentację Dockera, moduły jądra, działanie zapory sieciowej i sterowniki pamięci masowej łatwiej interpretować, ponieważ system gościa ma własną konfigurację jądra. Ceną jest kompletny system gościa, zarezerwowana pamięć, zarządzanie dyskiem wirtualnym i dodatkowa warstwa poprawek.

Nie wybieraj LXC wyłącznie po to, by zaoszczędzić kilkaset megabajtów, jeśli wymagana konfiguracja wymusza kontener uprzywilejowany, szerokie uprawnienia do urządzeń i nieudokumentowane modyfikacje hosta. Lekka opcja traci swoją wartość, gdy każda aktualizacja zależy od pamiętania o wyjątkach, które maszyna wirtualna zamknęłaby wewnątrz systemu gościa.

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

LXC współdzieli jądro hosta, więc nieprawidłowo skonfigurowany kontener uprzywilejowany lub zbyt szerokie mapowanie urządzeń może ujawnić większą część węzła Proxmox, niż zamierzano. Nieuprzywilejowane LXC, precyzyjne uprawnienia urządzeń, montowania tylko do odczytu i minimalny zestaw możliwości poprawiają tę granicę, ale architektura nadal jest bardziej zależna od hosta 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 oraz eksperymentalne oprogramowanie od bazowego systemu Proxmox. Taka separacja jest cenna, gdy host Dockera uruchamia obrazy innych firm, usługi publiczne, lokalne pakiety AI lub często eksperymentuje ze sterownikami.

Maszyna wirtualna nie jest automatycznie bezpieczna. Przekazywanie urządzeń PCI, montowania współdzielonego magazynu, dane uwierzytelniające do zarządzania oraz sieć mostkowana nadal tworzą ścieżki ataku i awarii. Wybierz ją, 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ą niewielkie i szybkie, ponieważ gość nie zawiera pełnego stosu wirtualnego sprzętu. Jednak przywrócenie dostępu do sprzętu na innym węźle Proxmox wymaga zgodnych węzłów urządzeń, grup, sterowników i uprawnień. System plików kontenera może zostać przeniesiony, ale umowa dotycząca 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. Podłączenia USB i adresy PCI nadal wymagają ponownego mapowania na urządzeniu docelowym, a przekazana karta GPU może uniemożliwiać migrację na żywo, ponieważ urządzenie fizyczne jest przypisane do jednego węzła.

Proces tworzenia kopii zapasowej Proxmox opisany przez ZimaSpace obejmuje ochronę gościa. W tym porównaniu odzyskiwanie jest ukończone dopiero wtedy, gdy Docker uruchomi się, a aplikacja zależna od USB lub GPU wykryje urządzenie zastępcze.

Przed wyborem typu gościa wykonaj test odzyskiwania urządzenia

1. Wymień wszystkie urządzenia USB i PCI wymagane przez aplikacje Dockera.
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 oraz uprawnienia Dockera dla LXC.
4. Przetestuj grupowanie IOMMU, instalację sterowników gościa oraz zachowanie mechanizmu resetowania maszyny wirtualnej.
5. Uruchom ponownie hosta Proxmox i potwierdź, że podłączone urządzenia są automatycznie ponownie dołączane.
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 migracja lub wymiana sprzętu ma znaczenie.

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

Który gość Proxmox najlepiej pasuje do hosta Dockera?

Wybierz LXC, gdy

Wybierz LXC, gdy wszystkie obciążenia są oparte na Linuksie, host może zarządzać sterownikami, urządzenia USB udostępniają stabilne węzły, a karta GPU powinna być współdzielona przez kilka usług. Jeśli to możliwe, pozostaw kontener nieuprzywilejowany i udokumentuj każde mapowanie urządzenia oraz grupy.

Wybierz maszynę wirtualną, gdy

Wybierz maszynę wirtualną, gdy host Dockera potrzebuje wyłącznego dostępu do karty GPU PCI, własnościowych lub eksperymentalnych sterowników, silniejszej izolacji jądra albo łatwiejszej przenośności całego stosu oprogramowania. Zarezerwuj dla gościa wystarczającą ilość pamięci RAM i przestrzeni dyskowej oraz przetestuj reset urządzenia po ponownym uruchomieniu.

Podziel obciążenia, gdy

Uruchamiaj lekkie usługi multimedialne i USB w LXC, a obliczenia GPU wymagające wyłącznego dostępu, narzędzia zależne od systemu Windows lub niezaufane stosy Dockera umieszczaj w maszynie wirtualnej. Platforma zgodna z Proxmox może obsługiwać oba rozwiązania, ale każdy fizyczny element sprzętu powinien mieć jeden udokumentowany model własności.

Najczęściej zadawane pytania

Czy Docker może niezawodnie działać wewnątrz nieuprzywilejowanego kontenera LXC?

Tak, w przypadku wielu zastosowań, ale zagnieżdżanie, sterowniki pamięci masowej, punkty montowania, sieć i dostęp do urządzeń mogą wymagać dodatkowej konfiguracji. Przetestuj dokładnie używane funkcje Dockera i nie przełączaj kontenera w tryb uprzywilejowany tylko po to, by ominąć niewyjaśniony problem z uprawnieniami.

Czy jedna karta GPU może być używana jednocześnie przez LXC i maszynę wirtualną?

Nie za pomocą zwykłego przekazywania całego urządzenia przez VFIO jednocześnie. LXC może współdzielić zarządzane przez hosta urządzenie renderujące, podczas gdy maszyna wirtualna zwykle wymaga odłączenia urządzenia od hosta. Obsługa SR-IOV lub urządzeń pośredniczonych może zmienić tę sytuację w przypadku konkretnego sprzętu.

Która opcja jest lepsza dla koordynatora Zigbee podłączanego przez USB?

Oba rozwiązania mogą się sprawdzić. LXC jest wydajne, gdy stabilna ścieżka serial-by-ID i uprawnienia działają niezawodnie. Maszyna wirtualna jest wygodniejsza, gdy stos oprogramowania koordynatora lub jego sterownik powinien pozostać niezależny 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. Użyj maszyny wirtualnej, gdy sprzęt powinien należeć do gościa, sterowniki muszą być odizolowane lub odzyskiwanie powinno 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.