O que faz um contentor LXC perder o acesso a dispositivos após reiniciar o anfitrião?
Um contentor LXC perde frequentemente o acesso aos dispositivos após o reinício do anfitrião porque este recria o dispositivo com um caminho, estado de permissões ou momento de arranque diferente.
Trate o reinício como um evento do ciclo de vida do dispositivo no anfitrião. Confirme que o hardware é detetado antes de o LXC arrancar, compare identificadores estáveis com nomes de dispositivos voláteis, verifique as permissões persistentes do udev e as regras de acesso do contentor e, em seguida, repita um arranque a frio. Um reinício do contentor que resolve temporariamente o problema é um indício de temporização, não uma reparação duradoura.
Confirme que o anfitrião recria o dispositivo após o reinício
Antes de iniciar o contentor, verifique se o anfitrião deteta o dispositivo USB, série, GPU ou outro dispositivo e registe o respetivo ID do fabricante, ID do produto, número de série, números major-minor e caminho atual.
As orientações para passthrough em ambientes domésticos recomendam o passthrough USB estável, em vez de presumir que um nome de dispositivo volátil irá referir-se sempre ao mesmo hardware após a enumeração.
Se o próprio anfitrião não vir o dispositivo, pare na camada do anfitrião. É necessário corrigir a deteção pelo firmware, controlador, alimentação, kernel ou a ligação antes de qualquer configuração LXC poder funcionar.
Substitua nomes de dispositivos voláteis por uma identidade estável
Compare os caminhos antes e depois do reinício. Os adaptadores série USB podem trocar os números ttyUSB e dispositivos semelhantes podem ser enumerados por uma ordem diferente após o arranque do anfitrião.
Um guia específico sobre passthrough USB para LXC mostra por que motivo passar um dispositivo para o LXC só funciona quando o objeto do lado do anfitrião referenciado pelo contentor continua a identificar o hardware pretendido.
Utilize um caminho estável por ID ou um symlink criado deliberadamente pelo udev quando a classe do dispositivo o permitir. Não amplie o acesso do contentor a todos os dispositivos USB apenas para ocultar alterações na ordem de enumeração.
Faça com que as permissões dos dispositivos sobrevivam à recriação
Verifique o proprietário, o grupo, o modo, a permissão do cgroup e o mapeamento do contentor após o reinício. Um chmod manual num nó de dispositivo não é persistente, porque o udev pode recriar esse nó.
Um exemplo de passthrough Z-Wave utiliza um mapeamento persistente do dispositivo para manter um dispositivo série acessível durante alterações no anfitrião, em vez de depender de uma alteração de permissões feita uma única vez.
Defina a propriedade ou a regra de grupo necessária na configuração persistente de gestão de dispositivos do anfitrião e conceda ao contentor apenas a classe de dispositivos de que necessita.
Verifique se o contentor arranca demasiado cedo
Reinicie o anfitrião e compare os registos temporais da criação do dispositivo e do arranque do LXC. Um contentor pode arrancar com êxito enquanto o hardware de que necessita ainda não terminou a enumeração.
As orientações mais abrangentes sobre mapeamento de dispositivos USB no Proxmox salientam que o passthrough USB depende de o anfitrião expor primeiro o dispositivo; essa ordem torna-se crítica durante arranques não assistidos de servidores domésticos.
Adicione uma dependência limitada ou uma verificação de prontidão, em vez de uma espera longa e arbitrária. O contentor deve falhar claramente ou aguardar brevemente quando o dispositivo necessário estiver ausente.
Execute uma verificação completa após o reinício
Depois de corrigir a identidade, as permissões ou a ordem de arranque, reinicie o anfitrião a frio duas vezes e teste o funcionamento real da aplicação que utiliza o dispositivo, não apenas a existência de um nó dentro do LXC.
O guia relacionado de configuração de servidor doméstico Proxmox da ZimaSpace mantém a reparação associada a uma configuração reproduzível de servidor doméstico Proxmox, em vez de uma solução temporária válida apenas durante a sessão.
A falha só fica resolvida quando o mesmo dispositivo físico aparece com o acesso pretendido após vários arranques. Se a identidade for estável, mas o acesso continuar a falhar, guarde os registos de negação do anfitrião e do contentor para a camada seguinte de diagnóstico.
Perguntas frequentes
Por que motivo reiniciar o contentor restaura por vezes o dispositivo?
O dispositivo pode ter aparecido depois de o contentor ter arrancado. Um reinício posterior encontra o nó de dispositivo do anfitrião já criado, mas isso apenas oculta a dependência da ordem de arranque.
Devo mapear um dispositivo USB através de /dev/ttyUSB0?
Prefira uma identidade estável quando a classe do dispositivo disponibilizar uma. Os nomes numéricos dos dispositivos podem mudar à medida que o hardware é enumerado após o reinício.
As permissões podem ser repostas mesmo quando o caminho do dispositivo permanece igual?
Sim. O udev pode recriar o nó com o proprietário, grupo e modo configurados, pelo que as alterações manuais feitas com chmod podem desaparecer na ligação seguinte ou após um reinício.
Produtos recomendados
Suporte e Dicas
Mais para Ler
O Plex pode partilhar uma GPU com outro contentor Docker?
O Plex e outro contentor conseguem frequentemente aceder à mesma GPU, mas é necessário testar o suporte dos controladores, o mapeamento de dispositivos, a...
Como saber se um erro do Plex vem do cliente ou do servidor
Reproduza o mesmo item noutro cliente, compare o percurso da sessão e, em seguida, recolha provas do servidor apenas depois de o âmbito lhe...
Como configurar a cache do Plex e o armazenamento temporário de transcodificação
Proteja o estado persistente do Plex enquanto coloca os ficheiros temporários de transcodificação num armazenamento local adequado e, em seguida, verifique a limpeza, o...
