Proxmox LXC versus VM als Docker-host met USB- of GPU-passthrough: wat is eenvoudiger in beheer?

Kies een Proxmox LXC-container voor de Docker-host wanneer Linux-apparaatknooppunten veilig beschikbaar kunnen worden gesteld, de host de vereiste GPU- of USB-stuurprogramma's beheert en een lage overhead of GPU-deling belangrijk is. Kies een VM wanneer de gast de stuurprogrammastack moet beheren, een PCI-apparaat via IOMMU moet worden geïsoleerd of Docker en de hardwaretoegang daarvan onafhankelijk van de Proxmox-host moeten blijven. USB-seriële apparaten passen vaak bij beide routes; exclusieve GPU-passthrough valt meestal in het voordeel van een VM uit.

Definieer ‘passthrough’ voordat je LXC en een VM vergelijkt

LXC en KVM geven hardware niet op dezelfde manier door aan workloads. Een LXC-container deelt de Proxmox-kernel en krijgt daarom doorgaans toestemming om toegang te krijgen tot door de host aangemaakte apparaatknooppunten, zoals `/dev/dri`, `/dev/ttyUSB0` of `/dev/bus/usb`. De host detecteert de hardware nog steeds en laadt het kernelstuurprogramma.

Een VM draait zijn eigen kernel. Proxmox kan een USB-apparaat emuleren, een geselecteerd USB-apparaat of een geselecteerde poort koppelen, of via VFIO en IOMMU een PCI-apparaat toewijzen. De gast laadt vervolgens zijn eigen stuurprogramma en behandelt de toegewezen hardware meer als een rechtstreeks geïnstalleerd apparaat.

De huidige Proxmox NAS-installatiehandleiding van ZimaSpace introduceert beide gasttypen. Dit artikel beperkt de keuze tot een Docker-host waarvan de containers USB-dongles, seriële adapters, media-GPU's of rekenaccelerators nodig hebben.

USB-apparaten zijn geschikt voor LXC wanneer ze zich gedragen als stabiele Linux-apparaatknooppunten

USB-seriële adapters, Zigbee-coördinatoren, UPS-interfaces, Coral USB-versnellers en vergelijkbare apparaten kunnen goed werken in LXC wanneer Proxmox het apparaatknooppunt beschikbaar maakt en het juiste eigenaarschap toewijst. De Docker-container binnen LXC ontvangt dat apparaat vervolgens vanuit zijn Linux-hostomgeving.

Een praktische uitleg van USB-toegang binnen Proxmox LXC laat het onderliggende patroon zien: het koppelen van het apparaat is niet voldoende als de container er niet ook toegang toe heeft.

Gebruik stabiele paden zoals `/dev/serial/by-id` wanneer de applicatie dit ondersteunt. Busnummers en toewijzingen van `/dev/ttyUSB0` kunnen na een herstart of opnieuw verbinden veranderen. De LXC-route wordt kwetsbaar wanneer voor elke hostupdate handmatig cgroup-, UID-, GID- of apparaatherstel nodig is.

Een VM is netter wanneer USB-eigenaarschap volledig zelfstandig moet zijn

Een VM kan een USB-apparaat ontvangen op basis van leverancier- en product-ID of via een fysieke poort, en vervolgens het apparaatstuurprogramma in het eigen besturingssysteem laden. Dit is nuttig wanneer het apparaat een leverancierspakket, een andere kernelversie of een applicatiestack nodig heeft die niet afhankelijk mag zijn van Proxmox-hostbibliotheken.

De VM creëert ook een duidelijkere diagnostische grens. Als de gast het USB-apparaat verliest, kan de beheerder eerst de koppeling in de hypervisor controleren en daarna afzonderlijk het stuurprogramma in de gast. Bij LXC maken het hoststuurprogramma, het apparaatknooppunt, de rechten, de containertoewijzing, de Docker-runtime en de applicatie allemaal deel uit van één keten.

De afweging betreft het gedrag bij opnieuw verbinden. Sommige USB-apparaten worden gereset, veranderen van identiteit of verdwijnen tijdens het opnieuw opstarten van de gast. Test het loskoppelen, het opnieuw opstarten van de host, het opnieuw opstarten van de gast en het herstel van de applicatie, in plaats van ervan uit te gaan dat een succesvolle eerste koppeling stabiele werking bewijst.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Gedeelde GPU-toegang heeft meestal de voorkeur bij LXC

Voor Intel- of AMD-renderapparaten en ondersteunde NVIDIA-workloads kan LXC de apparaatknooppunten van de host-GPU beschikbaar maken voor meerdere Linux-services. De GPU blijft beheerd worden door het Proxmox-hoststuurprogramma, waardoor meerdere containers hardwarematige transcoding of berekeningen kunnen gebruiken zonder het volledige PCI-apparaat aan één gast toe te wijzen.

Het recente Proxmox-voorbeeld van XDA legt uit hoe LXC de door de host beheerde GPU kan delen in plaats van deze via VM-passthrough exclusief toe te wijzen. Ditzelfde operationele model kan geschikt zijn voor Jellyfin, Plex, Frigate of meerdere Docker-services wanneer de vereisten voor stuurprogramma's en rechten overeenkomen.

Delen zorgt voor versieafhankelijkheid. De host-kerneldriver, gebruikersbibliotheken binnen LXC, de integratie met de Docker-runtime en toepassingspakketten moeten compatibel blijven. Een upgrade van de Proxmox-kernel of -driver kan daardoor alle containers die de GPU gebruiken tegelijk beïnvloeden.

Exclusieve GPU-passthrough pleit doorgaans voor een VM

Een VM is de sterkere optie wanneer één workload rechtstreeks eigenaar moet zijn van een discrete GPU, een propriëtaire gastdriver nodig heeft, Windows-ondersteuning vereist, CUDA-isolatie vraagt of een kernelstack nodig heeft die niet op Proxmox geïnstalleerd zou moeten worden. VFIO koppelt het apparaat los van de host en stelt het beschikbaar aan de gast.

Het PCI-model van Proxmox is ontworpen om een fysiek PCI-apparaat toe te wijzen aan een KVM-gast. Een Docker-discussie op Level1Techs vat het praktische gevolg goed samen: een VM gebruikt de toegewezen GPU normaal gesproken exclusief, terwijl LXC de hosttoegang tot het apparaat met meerdere services kan delen.

Deze keuze kan anders uitvallen wanneer de GPU mediated devices of SR-IOV ondersteunt, maar consumentengpu's en thuisserverplatforms bieden geen universele manier om resources te delen. Controleer IOMMU-groepen, resetgedrag, firmware, display-initialisatie en of de host die GPU nodig heeft voordat je een ontwerp baseert op exclusieve passthrough.

Docker in LXC voegt een geneste beheerlaag toe

LXC biedt al isolatie op besturingssysteemniveau, en Docker voegt daarbinnen nog een container-runtimesysteem aan toe. Dat kan efficiënt zijn, maar introduceert geneste namespaces, cgroups, opslagstuurprogramma's, mogelijkheden en mountgedrag. Voor sommige Docker-functies zijn nestingopties of extra machtigingen in de Proxmox-container nodig.

Een VM biedt Docker een conventionele Linux-host. Docker-documentatie, kernelmodules, firewallgedrag en opslagstuurprogramma's zijn gemakkelijker te interpreteren omdat de gast zijn kernelconfiguratie zelf beheert. Daar staat tegenover dat je een volledig gastbesturingssysteem, gereserveerd geheugen, beheer van virtuele schijven en een extra patchlaag nodig hebt.

Kies niet voor LXC alleen om een paar honderd megabytes te besparen als de vereiste configuratie een geprivilegieerde container, ruime apparaatmachtigingen en niet-gedocumenteerde wijzigingen aan de host vereist. De lichtgewicht optie verliest haar voordeel wanneer elke upgrade afhankelijk is van het onthouden van uitzonderingen die de VM binnen de gast zou afhandelen.

Isolatie en beveiliging kunnen de prestatiewinnaar omkeren

LXC deelt de kernel van de host, waardoor een verkeerd geconfigureerde geprivilegieerde container of een te ruime apparaattoewijzing meer van de Proxmox-node kan blootleggen dan bedoeld. Niet-geprivilegieerde LXC, beperkte apparaatmachtigingen, alleen-lezenkoppelingen en minimale mogelijkheden verbeteren de grens, maar de architectuur blijft sterker gekoppeld dan die van een volledige VM.

Een VM heeft een afzonderlijke kernel en kan propriëtaire GPU-stacks, Docker-netwerken, firewallmodules en experimentele software isoleren van de Proxmox-basis. Die scheiding is waardevol wanneer de Docker-host images van derden, openbare diensten, lokale AI-pakketten of regelmatig geteste stuurprogramma's uitvoert.

De VM is niet automatisch veilig. PCI-passthrough, gedeelde opslagkoppelingen, beheerdersreferenties en overbrugd netwerkverkeer creëren nog steeds aanvalsmogelijkheden en storingspunten. Kies hiervoor wanneer de onafhankelijke kernel- en stuurprogrammagrenzen het beveiligings- en onderhoudsmodel daadwerkelijk vereenvoudigen.

Back-ups en migratie vragen elk om een ander soort eenvoud

LXC-back-ups zijn compact en snel omdat de gast geen volledige virtuele hardwarestack bevat. Het herstellen van hardwaretoegang op een andere Proxmox-node vereist echter overeenkomende apparaatnodes, groepen, stuurprogramma's en machtigingen. Het containerbestandssysteem kan worden gemigreerd, maar de koppeling met het fysieke apparaat niet.

Een VM-back-up bevat het gastbesturingssysteem en de configuratie van de stuurprogramma's, waardoor applicatieherstel meer op zichzelf staat. USB-aansluitingen en PCI-adressen moeten op de doelhost nog steeds opnieuw worden toegewezen, en een doorgegeven GPU kan live migratie verhinderen omdat het fysieke apparaat aan één node is gekoppeld.

De Proxmox-back-upworkflow van ZimaSpace behandelt de bescherming van gasten. Voor deze vergelijking is herstel pas voltooid wanneer Docker start en de USB- of GPU-afhankelijke applicatie het vervangende apparaat kan zien.

Voer een apparaathersteltest uit voordat u het gasttype kiest

1. Maak een lijst van alle USB- en PCI-apparaten die de Docker-applicaties nodig hebben.
2. Bepaal of elk apparaat met de host moet worden gedeeld of aan één gast moet worden toegewezen.
3. Test het hoststuurprogramma, de apparaatnode, de UID/GID-toewijzing en de Docker-machtigingen voor LXC.
4. Test de IOMMU-groepering, de installatie van gaststuurprogramma's en het herstelgedrag voor een VM.
5. Start de Proxmox-host opnieuw op en bevestig dat de apparaattoewijzing automatisch wordt hersteld.
6. Herstel de gast vanuit een back-up en maak de hardwarekoppeling opnieuw aan de hand van de documentatie.
7. Herhaal dit op een andere compatibele node als migratie of hardwarevervanging belangrijk is.

Meet het gedrag van de applicatie in plaats van alleen de overhead van de gast. Stabiliteit van hardwaretranscodering, USB-herverbindingen, driverupdates, hostonderhoud en hersteltijd zijn meestal belangrijker dan een klein CPU-verschil tussen LXC en KVM.

Welke Proxmox-gast past bij de Docker-host?

Kies LXC wanneer

Kies LXC wanneer alle workloads Linux-gebaseerd zijn, de host de drivers kan beheren, USB-apparaten stabiele nodes aanbieden en een GPU door meerdere services moet worden gedeeld. Houd de container waar mogelijk onbevoorrecht en documenteer elke apparaat- en groepskoppeling.

Kies een VM wanneer

Kies een VM wanneer de Docker-host exclusief eigendom van een PCI-GPU nodig heeft, propriëtaire of experimentele drivers gebruikt, sterkere kernelisolatie vereist of eenvoudigere overdraagbaarheid van de volledige softwarestack belangrijk is. Reserveer voldoende RAM en opslag voor de gast en test of het apparaat na een herstart correct kan worden gereset.

Splits de workloads wanneer

Draai lichte media- en USB-services in LXC en plaats exclusieve GPU-compute, Windows-afhankelijke tools of niet-vertrouwde Docker-stacks in een VM. Een Proxmox-compatibel platform kan beide ondersteunen, maar elk fysiek apparaat moet één gedocumenteerd eigendomsmodel hebben.

Veelgestelde vragen

Kan Docker betrouwbaar binnen een onbevoorrechte LXC draaien?

Ja, voor veel workloads, maar nesting, opslagdrivers, mounts, netwerken en apparaattoegang kunnen extra configuratie vereisen. Test de exacte Docker-functies en schakel niet over naar een geprivilegieerde container alleen om een onverklaard rechtenprobleem te omzeilen.

Kan één GPU door zowel een LXC als een VM worden gebruikt?

Niet tegelijkertijd via gewone VFIO-passthrough van het volledige apparaat. LXC kan een door de host beheerd renderapparaat delen, terwijl een VM het apparaat normaal gesproken van de host moet loskoppelen. Ondersteuning voor SR-IOV of gemedieerde apparaten kan dit op specifieke hardware veranderen.

Welke optie is beter voor een USB-Zigbee-coördinator?

Beide kunnen werken. LXC is efficiënt wanneer een stabiel serial-by-ID-pad en betrouwbare rechten beschikbaar zijn. Een VM is overzichtelijker wanneer de softwarestack of driver van de coördinator onafhankelijk van de Proxmox-host moet blijven.

Eindoordeel

Gebruik LXC voor een Docker-host wanneer USB- en GPU-resources kunnen worden gedeeld via de Linux-driverstack van de Proxmox-host en een lage overhead belangrijk is. Gebruik een VM wanneer de hardware aan de gast moet toebehoren, drivers geïsoleerd moeten zijn of herstel een zelfstandig besturingssysteem moet behouden. Kies op basis van apparaateigendom en herstelgedrag, niet vanuit de aanname dat containers altijd eenvoudiger zijn.