Proxmox LXC vs VM para um host Docker com passagem direta de USB ou GPU: qual é mais fácil de gerir?

Escolha um contentor LXC do Proxmox para o anfitrião Docker quando for possível expor nós de dispositivo Linux em segurança, o anfitrião tiver os controladores de GPU ou USB necessários e forem importantes os baixos requisitos de recursos ou a partilha da GPU. Escolha uma VM quando o sistema convidado tiver de gerir a sua própria pilha de controladores, quando for necessário isolar um dispositivo PCI através de IOMMU ou quando o Docker e o respetivo acesso ao hardware tiverem de ser independentes do anfitrião Proxmox. Os dispositivos USB série são muitas vezes adequados a qualquer uma das opções; a passagem direta de uma GPU exclusiva costuma favorecer uma VM.

Definir a «passagem direta» antes de comparar o LXC e uma VM

O LXC e o KVM não disponibilizam o hardware às cargas de trabalho da mesma forma. Um contentor LXC partilha o kernel do Proxmox, pelo que normalmente recebe permissão para aceder a nós de dispositivo criados pelo anfitrião, como `/dev/dri`, `/dev/ttyUSB0` ou `/dev/bus/usb`. O anfitrião continua a detetar o hardware e a carregar o controlador do kernel.

Uma VM executa o seu próprio kernel. O Proxmox pode emular um dispositivo USB, ligar um dispositivo ou uma porta USB específicos, ou atribuir um dispositivo PCI através de VFIO e IOMMU. O sistema convidado carrega então o seu próprio controlador e trata o hardware atribuído de forma semelhante a um dispositivo instalado diretamente.

O atual guia de configuração de um NAS Proxmox da ZimaSpace apresenta os dois tipos de sistemas convidados. Este artigo centra-se na escolha de um anfitrião Docker cujos contentores necessitam de dongles USB, adaptadores de série, GPUs para multimédia ou aceleradores de computação.

Os dispositivos USB preferem o LXC quando funcionam como nós de dispositivo Linux estáveis

Os adaptadores série USB, coordenadores Zigbee, interfaces de UPS, aceleradores Coral USB e dispositivos semelhantes podem funcionar bem em LXC quando o Proxmox disponibiliza o nó de dispositivo e mapeia a propriedade correta. O contentor Docker dentro do LXC recebe então esse dispositivo do seu ambiente anfitrião Linux.

Uma explicação prática do acesso USB num LXC Proxmox mostra o padrão subjacente: montar o dispositivo não é suficiente, a menos que o contentor também tenha autorização para lhe aceder.

Utilize caminhos estáveis, como `/dev/serial/by-id`, quando a aplicação os suportar. Os números de barramento e as atribuições de `/dev/ttyUSB0` podem mudar após um reinício ou ao restabelecer a ligação. A abordagem com LXC torna-se frágil quando cada atualização do anfitrião exige a reparação manual de cgroup, UID, GID ou caminhos de dispositivos.

Uma VM é mais adequada quando a gestão do USB deve ser autónoma

Uma VM pode receber um dispositivo USB através do ID do fabricante e do produto ou de uma porta física e, depois, carregar o controlador do dispositivo no seu próprio sistema operativo. Isto é útil quando o dispositivo precisa de um pacote do fabricante, de uma versão diferente do kernel ou de uma pilha de aplicações que não deve depender das bibliotecas do anfitrião Proxmox.

A VM também cria um limite de diagnóstico mais claro. Se o convidado perder o dispositivo USB, o administrador pode inspecionar a ligação ao hipervisor e, em seguida, o controlador do convidado separadamente. No LXC, o controlador do anfitrião, o nó de dispositivo, as permissões, o mapeamento do contentor, o ambiente de execução do Docker e a aplicação fazem todos parte da mesma cadeia.

A desvantagem está no comportamento ao restabelecer a ligação. Alguns dispositivos USB reiniciam, mudam de identidade ou desaparecem durante o reinício do convidado. Teste desligar e voltar a ligar o dispositivo, reiniciar o anfitrião, reiniciar o convidado e recuperar a aplicação, em vez de presumir que uma primeira ligação bem-sucedida comprova um funcionamento estável.

Featured

ZimaBoard 2 - Mini servidor doméstico para a sua grande ideia

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

O acesso partilhado à GPU favorece normalmente o LXC

Para dispositivos de renderização Intel ou AMD e cargas de trabalho NVIDIA compatíveis, o LXC pode disponibilizar os nós de dispositivo da GPU do anfitrião a vários serviços Linux. A GPU continua a ser gerida pelo controlador do anfitrião Proxmox, permitindo que vários contentores utilizem a transcodificação por hardware ou a computação, sem atribuir todo o dispositivo PCI a um único convidado.

O exemplo recente da XDA com Proxmox explica como o LXC pode partilhar a GPU gerida pelo anfitrião, em vez de a dedicar através do passthrough para uma VM. O mesmo modelo operacional pode ser adequado para Jellyfin, Plex, Frigate ou vários serviços Docker, quando os requisitos de controladores e permissões são compatíveis.

A partilha cria dependências entre versões. O controlador do kernel do anfitrião, as bibliotecas de espaço do utilizador no LXC, a integração do ambiente de execução do Docker e os pacotes da aplicação têm de permanecer compatíveis. Por isso, uma atualização do kernel ou do controlador do Proxmox pode afetar, de uma só vez, todos os contentores que utilizam a GPU.

A atribuição exclusiva da GPU favorece geralmente uma máquina virtual

Uma máquina virtual é a opção mais robusta quando uma carga de trabalho precisa de controlo direto sobre uma GPU dedicada, de um controlador proprietário para o sistema convidado, de suporte para Windows, de isolamento do CUDA ou de uma pilha de kernel que não deva ser instalada no Proxmox. A atribuição por VFIO separa o dispositivo do anfitrião e apresenta-o ao sistema convidado.

O modelo PCI do Proxmox foi concebido para atribuir um dispositivo PCI físico a um convidado KVM. Uma discussão sobre Docker no Level1Techs resume a consequência prática: uma máquina virtual utiliza normalmente a GPU atribuída em exclusivo, enquanto o LXC pode partilhar o acesso ao dispositivo do anfitrião entre serviços.

Esta escolha pode inverter-se quando a GPU suporta dispositivos mediados ou SR-IOV, mas as GPUs para consumidores e as plataformas de servidores domésticos não oferecem uma solução universal de partilha. Verifique os grupos IOMMU, o comportamento de reposição, o firmware, a inicialização do ecrã e se o anfitrião precisa dessa GPU antes de conceber uma solução baseada na atribuição exclusiva.

O Docker dentro do LXC acrescenta uma camada de gestão aninhada

O LXC já fornece isolamento ao nível do sistema operativo, e o Docker acrescenta outro ambiente de execução de contentores no seu interior. Isto pode ser eficiente, mas introduz namespaces aninhados, cgroups, controladores de armazenamento, capacidades e comportamento de montagem. Algumas funcionalidades do Docker requerem opções de aninhamento ou permissões adicionais no contentor Proxmox.

Uma máquina virtual apresenta ao Docker um anfitrião Linux convencional. A documentação do Docker, os módulos do kernel, o comportamento da firewall e os controladores de armazenamento são mais fáceis de interpretar porque o sistema convidado controla a configuração do seu kernel. O custo é um sistema operativo convidado completo, memória reservada, gestão de discos virtuais e mais uma camada de atualizações.

Não escolha LXC apenas para poupar algumas centenas de megabytes se a configuração necessária obrigar a usar um contentor privilegiado, permissões amplas para dispositivos e alterações não documentadas no anfitrião. A opção mais leve perde valor quando cada atualização depende de se lembrar das exceções que a máquina virtual manteria dentro do sistema convidado.

O isolamento e a segurança podem inverter o vencedor em desempenho

O LXC partilha o kernel do anfitrião, pelo que um contentor privilegiado mal configurado ou um mapeamento de dispositivos demasiado abrangente pode expor mais do nó Proxmox do que o pretendido. O LXC não privilegiado, as permissões restritas dos dispositivos, as montagens só de leitura e o mínimo de capacidades melhoram o isolamento, mas a arquitetura continua a ser mais interdependente do que uma VM completa.

Uma VM disponibiliza um kernel separado e pode isolar pilhas proprietárias de GPU, a rede Docker, módulos de firewall e software experimental da instalação base do Proxmox. Este isolamento é valioso quando o anfitrião Docker executa imagens de terceiros, serviços públicos, pacotes de IA local ou experiências frequentes com controladores.

A VM não é segura por definição. O passthrough PCI, os pontos de montagem de armazenamento partilhado, as credenciais de gestão e a rede em bridge continuam a criar vias de ataque e de falha. Escolha-a quando o kernel e os controladores independentes simplificarem efetivamente o modelo de segurança e manutenção.

As cópias de segurança e a migração favorecem diferentes tipos de simplicidade

As cópias de segurança de LXC são compactas e rápidas, porque o guest não contém uma pilha completa de hardware virtual. No entanto, restaurar o acesso ao hardware noutro nó Proxmox exige que os nós de dispositivo, os grupos, os controladores e as permissões sejam compatíveis. O sistema de ficheiros do contentor pode ser migrado sem que o acesso ao dispositivo físico o acompanhe.

Uma cópia de segurança de uma VM inclui o sistema operativo do guest e a configuração dos controladores, tornando a recuperação da aplicação mais autónoma. As ligações USB e os endereços PCI continuam a ter de ser remapeados no destino, e uma GPU passada à VM pode impedir a migração em direto, uma vez que o dispositivo físico está associado a um único nó.

O fluxo de trabalho de cópias de segurança do Proxmox da ZimaSpace protege os guests. Nesta comparação, a recuperação só está concluída quando o Docker arranca e a aplicação dependente de USB ou GPU consegue detetar o dispositivo de substituição.

Faça um teste de recuperação de dispositivos antes de escolher o tipo de guest

1. Liste todos os dispositivos USB e PCI de que as aplicações Docker necessitam.
2. Decida se cada dispositivo deve ser partilhado com o anfitrião ou atribuído a um único guest.
3. Teste o controlador do anfitrião, o nó do dispositivo, o mapeamento de UID/GID e as permissões do Docker para LXC.
4. Teste o agrupamento IOMMU, a instalação de controladores no guest e o comportamento de reinicialização de uma VM.
5. Reinicie o anfitrião Proxmox e confirme que a ligação do dispositivo é restabelecida automaticamente.
6. Restaure o guest a partir da cópia de segurança e recrie o mapeamento de hardware com base na documentação.
7. Repita os testes noutro nó compatível se a migração ou a substituição de hardware forem importantes.

Avalie o comportamento das aplicações, não apenas a sobrecarga do sistema convidado. A estabilidade da transcodificação por hardware, a reconexão USB, as atualizações dos controladores, a manutenção do anfitrião e o tempo de recuperação costumam ser mais importantes do que uma pequena diferença de CPU entre LXC e KVM.

Que tipo de sistema convidado do Proxmox é mais adequado para o anfitrião Docker?

Escolha LXC quando

Escolha LXC quando todas as cargas de trabalho forem baseadas em Linux, o anfitrião puder gerir os controladores, os dispositivos USB expuserem nós estáveis e a GPU tiver de ser partilhada entre vários serviços. Mantenha o contentor não privilegiado sempre que possível e documente todos os dispositivos e mapeamentos de grupos.

Escolha uma VM quando

Escolha uma VM quando o anfitrião Docker precisar de propriedade exclusiva da GPU PCI, de controladores proprietários ou experimentais, de um isolamento mais forte do kernel ou de maior facilidade na portabilidade da pilha de software completa. Reserve RAM e armazenamento suficientes para o sistema convidado e teste a reposição do dispositivo após o reinício.

Divida as cargas de trabalho quando

Execute serviços de multimédia e USB leves em LXC e aloje num VM as tarefas de computação GPU exclusivas, as ferramentas que dependem do Windows ou as pilhas Docker não fidedignas. Uma plataforma compatível com o Proxmox pode suportar ambos, mas cada dispositivo físico deve ter um modelo de propriedade documentado.

Perguntas frequentes

O Docker pode funcionar de forma fiável num LXC não privilegiado?

Sim, para muitas cargas de trabalho, mas o aninhamento, os controladores de armazenamento, as montagens, a rede e o acesso aos dispositivos podem exigir configuração adicional. Teste as funcionalidades específicas do Docker e evite mudar para um contentor privilegiado apenas para contornar um problema de permissões cuja causa não foi esclarecida.

É possível usar uma GPU tanto num LXC como numa VM?

Não através da passagem VFIO convencional do dispositivo completo em simultâneo. O LXC pode partilhar um dispositivo de renderização gerido pelo anfitrião, enquanto uma VM normalmente exige que o dispositivo seja desligado do anfitrião. O suporte para SR-IOV ou dispositivos mediados pode alterar esta situação em hardware específico.

Qual é a melhor opção para um coordenador Zigbee USB?

Ambas as opções podem funcionar. O LXC é eficiente quando o caminho serial-by-ID e as permissões são fiáveis. Uma VM é mais adequada quando a pilha de software ou o controlador do coordenador devem permanecer independentes do anfitrião Proxmox.

Veredito final

Use LXC como anfitrião Docker quando os recursos USB e GPU puderem ser partilhados através da pilha de controladores Linux do anfitrião Proxmox e forem importantes os baixos requisitos de recursos. Use uma VM quando o hardware tiver de pertencer ao sistema convidado, os controladores tiverem de estar isolados ou a recuperação tiver de preservar um sistema operativo autónomo. Escolha com base na propriedade dos dispositivos e no comportamento do restauro, não partindo do princípio de que os contentores são sempre mais simples.