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

Kies een Proxmox LXC-container als Docker-host wanneer Linux-apparaatknooppunten veilig toegankelijk kunnen worden gemaakt, de host de benodigde GPU- of USB-drivers beheert en lage overhead of het delen van een GPU belangrijk is. Kies een VM wanneer de gast zijn eigen driverstack moet beheren, een PCI-apparaat via IOMMU moet worden geïsoleerd of Docker en de hardwaretoegang onafhankelijk moeten blijven van de Proxmox-host. Seriële USB-apparaten zijn vaak geschikt voor beide opties; exclusieve GPU-passthrough is doorgaans beter geschikt voor een VM.

Bepaal eerst wat ‘passthrough’ betekent 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 apparaatknooppunten die door de host zijn aangemaakt, zoals `/dev/dri`, `/dev/ttyUSB0` of `/dev/bus/usb`. De host blijft de hardware detecteren en de kerneldriver laden.

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

De huidige handleiding voor het instellen van Proxmox NAS met ZimaSpace introduceert beide gasttypen. Dit artikel zoomt in op de keuze voor een Docker-host waarvan de containers USB-dongles, seriële adapters, mediakaarten of accelerators voor rekenwerk nodig hebben.

USB-apparaten zijn geschikter 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 werken goed met LXC wanneer Proxmox het apparaatknooppunt beschikbaar maakt en de juiste eigenaar toewijst. De Docker-container binnen LXC krijgt dat apparaat vervolgens vanuit de Linux-hostomgeving.

Een praktische uitleg van USB-toegang binnen Proxmox LXC laat het onderliggende principe zien: alleen het apparaat koppelen is niet genoeg; de container moet ook toestemming hebben om het te gebruiken.

Gebruik stabiele paden zoals `/dev/serial/by-id` als de applicatie die ondersteunt. Busnummers en toewijzingen zoals `/dev/ttyUSB0` kunnen veranderen na een herstart of opnieuw verbinden. De LXC-route wordt kwetsbaar wanneer elke hostupdate handmatige aanpassingen aan cgroup, UID, GID of apparaatpaden vereist.

Een VM is overzichtelijker wanneer het USB-apparaat volledig zelfstandig beheerd moet worden

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

De VM biedt ook een duidelijkere grens voor diagnoses. Als de gast het USB-apparaat kwijtraakt, kan de beheerder de koppeling van de hypervisor en vervolgens afzonderlijk het stuurprogramma van de gast controleren. Bij LXC zijn het hoststuurprogramma, het apparaatknooppunt, de machtigingen, de containerkoppeling, de Docker-runtime en de applicatie allemaal onderdeel van dezelfde keten.

De keerzijde is het gedrag bij opnieuw verbinden. Sommige USB-apparaten worden gereset, veranderen van identiteit of verdwijnen wanneer de gast opnieuw wordt gestart. Test het loskoppelen, het opnieuw opstarten van de host, het opnieuw opstarten van de gast en het herstel van de applicatie, in plaats van aan te nemen dat een succesvolle eerste verbinding een stabiele werking garandeert.

Featured

ZimaBoard 2 - Mini-homeserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Gedeelde GPU-toegang werkt doorgaans het best met LXC

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

Het recente Proxmox-voorbeeld van XDA laat zien hoe LXC de door de host beheerde GPU kan delen, in plaats van deze via passthrough aan een VM toe te wijzen. Hetzelfde operationele model kan geschikt zijn voor Jellyfin, Plex, Frigate of meerdere Docker-services, wanneer de vereisten voor stuurprogramma’s en machtigingen overeenkomen.

Delen leidt tot versieafhankelijkheden. Het kernelstuurprogramma van de host, gebruikersbibliotheken in LXC, Docker-runtime-integratie en applicatiepakketten moeten compatibel blijven. Een upgrade van de Proxmox-kernel of het stuurprogramma kan daardoor alle containers die de GPU gebruiken tegelijk beïnvloeden.

Exclusieve GPU-passthrough is doorgaans gunstiger voor een VM

Een VM is de betere optie wanneer één workload direct eigenaarschap over een discrete GPU nodig heeft, een propriëtaire gastdriver, ondersteuning voor Windows, CUDA-isolatie of een kernelstack die niet op Proxmox geïnstalleerd moet worden. VFIO-toewijzing koppelt het apparaat los van de host en biedt het aan de gast aan.

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 samen: een VM gebruikt de doorgegeven GPU doorgaans exclusief, terwijl LXC toegang tot apparaten op de host kan delen met verschillende services.

Deze keuze kan anders uitvallen wanneer de GPU mediated devices of SR-IOV ondersteunt, maar consumenten-GPU's en thuisserverplatforms bieden geen universele manier om de GPU te delen. Controleer IOMMU-groepen, resetgedrag, firmware, initialisatie van het beeldscherm en of de host die GPU nodig heeft voordat je uitgaat van exclusieve passthrough.

Docker in LXC voegt een geneste beheerlaag toe

LXC biedt al isolatie op besturingssysteemniveau, en Docker voegt daarbinnen nog een container-runtime toe. Dit 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 compleet gastbesturingssysteem, gereserveerd geheugen, beheer van virtuele schijven en een extra patchlaag nodig hebt.

Kies niet voor LXC alleen om een paar honderd megabyte te besparen als de vereiste configuratie een geprivilegieerde container, ruime apparaatmachtigingen en niet-gedocumenteerde wijzigingen aan de host vereist. De lichte optie verliest aan waarde wanneer je bij elke upgrade uitzonderingen moet onthouden die de VM binnen de gast zou afvangen.

Isolatie en beveiliging kunnen de prestatiewinnaar veranderen

LXC deelt de hostkernel, waardoor een verkeerd geconfigureerde bevoorrechte container of een te ruime apparaattoewijzing meer van de Proxmox-node kan blootleggen dan bedoeld. Onbevoorrechte LXC, beperkte apparaatmachtigingen, alleen-lezen koppelingen en minimale mogelijkheden verbeteren de beveiliging, maar de architectuur blijft sterker gekoppeld dan bij 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 services, lokale AI-pakketten of frequente driverexperimenten uitvoert.

De VM is niet automatisch veilig. PCI-passthrough, gedeelde opslagkoppelingen, beheerdersgegevens en overbruggde netwerken vormen nog steeds aanvals- en faalrisico's. Kies hiervoor wanneer de afzonderlijke kernel- en drivergrens het dreigings- en onderhoudsmodel daadwerkelijk vereenvoudigt.

Back-ups en migratie vragen om verschillende vormen van eenvoud

LXC-back-ups zijn compact en snel, omdat de guest geen volledige virtuele hardwarestack bevat. Voor herstel van hardwaretoegang op een andere Proxmox-node zijn echter overeenkomende apparaatknooppunten, groepen, drivers en machtigingen nodig. Het bestandssysteem van de container kan worden gemigreerd, maar de koppeling met het fysieke apparaat niet.

Een VM-back-up bevat het besturingssysteem van de guest en de driverconfiguratie, waardoor herstel van applicaties zelfstandiger is. USB-koppelingen en PCI-adressen moeten nog steeds opnieuw worden toegewezen op de bestemming, en een GPU die via passthrough is toegewezen kan live migratie verhinderen omdat het fysieke apparaat aan één node is gekoppeld.

De Proxmox-back-upworkflow van ZimaSpace biedt bescherming voor guests. Voor deze vergelijking is herstel pas voltooid wanneer Docker start en de applicatie die afhankelijk is van USB of een GPU het vervangende apparaat kan zien.

Voer een apparaathersteltest uit voordat je het type guest kiest

1. Vermeld alle USB- en PCI-apparaten die de Docker-applicaties nodig hebben.
2. Bepaal of elk apparaat met de host moet worden gedeeld of door één guest moet worden gebruikt.
3. Test de hostdriver, het apparaatknooppunt, de UID/GID-toewijzing en Docker-rechten voor LXC.
4. Test de IOMMU-groepering, de installatie van de guestdriver en het resetgedrag voor een VM.
5. Start de Proxmox-host opnieuw op en controleer of de apparaten automatisch weer worden gekoppeld.
6. Herstel de guest vanaf een back-up en stel de hardwaretoewijzing opnieuw in aan de hand van de documentatie.
7. Herhaal dit op een andere compatibele node als migratie of vervanging van hardware belangrijk is.

Meet het gedrag van toepassingen en kijk niet alleen naar de overhead van de gast. Stabiliteit van hardwaretranscodering, opnieuw verbinden van USB-apparaten, driverupdates, onderhoud van de host en hersteltijd zijn meestal belangrijker dan een klein CPU-verschil tussen LXC en KVM.

Welke Proxmox-gast is geschikt voor de Docker-host?

Kies LXC wanneer

Kies LXC wanneer alle workloads op Linux draaien, de host de drivers kan beheren, USB-apparaten stabiele apparaatknooppunten hebben en een GPU door meerdere services moet worden gedeeld. Houd de container waar mogelijk niet-geprivilegieerd en documenteer elke apparaattoewijzing en groepskoppeling.

Kies een VM wanneer

Kies een VM wanneer de Docker-host exclusief eigenaar moet zijn van een PCI-GPU, eigen of experimentele drivers nodig heeft, sterkere kernelisolatie vereist is of de volledige softwarestack eenvoudiger overdraagbaar moet zijn. Reserveer voldoende RAM en opslagruimte voor de gast en test of het apparaat na een herstart kan worden gereset.

Verdeel de workloads wanneer

Draai lichte media- en USB-services in LXC en plaats GPU-computing die exclusief gebruik vereist, Windows-afhankelijke tools of niet-vertrouwde Docker-stacks in een VM. Een platform dat geschikt is voor Proxmox kan beide ondersteunen, maar leg voor elk fysiek apparaat één eigendomsmodel vast.

Veelgestelde vragen

Kan Docker betrouwbaar draaien binnen een niet-geprivilegieerde LXC?

Ja, voor veel workloads, maar voor nesting, opslagdrivers, mounts, netwerken en apparaattoegang kan extra configuratie nodig zijn. Test de exacte Docker-functies en schakel niet over op een geprivilegieerde container alleen om een onverklaarbaar machtigingsprobleem te omzeilen.

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

Niet tegelijkertijd via gewone VFIO-passthrough van het volledige apparaat. LXC kan een renderapparaat delen dat door de host wordt beheerd, terwijl het apparaat bij een VM normaal gesproken van de host moet worden losgekoppeld. SR-IOV- of mediated-device-ondersteuning 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 pad op basis van serienummer en betrouwbare machtigingen beschikbaar zijn. Een VM is netter wanneer de softwarestack of driver van de coördinator onafhankelijk moet blijven van de Proxmox-host.

Eindoordeel

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