A resposta mais segura para esta discussão de origem sem resposta é: não faça do espelho Btrfs existente do OMV a primeira coisa em que experimenta. Mantenha o OpenMediaVault online, instale o ZimaOS no sistema separado que pretende avaliar, ligue as partilhas do OMV como Armazenamento de rede e copie os dados por fases. Assim, preserva o NAS antigo como serviço funcional e como caminho de reversão enquanto testa as aplicações, partilhas e cópias de segurança do ZimaOS.
A questão do CPU também fica mais simples quando dividida por camadas. O VT-x é a principal funcionalidade de virtualização por hardware para VMs x86 comuns. O VT-d/IOMMU é sobretudo relevante quando pretende passar dispositivos PCIe físicos diretamente para um convidado. As aplicações Docker não requerem VT-d. Assim, um i5-2310 de 2011 ainda pode executar contentores e talvez VMs comuns, mas o passthrough e o desempenho geral das VMs são limitações distintas.
As aplicações Docker não requerem VT-d
As aplicações da App Store do ZimaOS são executadas como contentores Docker. Partilham o kernel do anfitrião e não precisam de passthrough de dispositivos de hardware apenas para arrancar.
O i5 antigo pode ser lento com aplicações mais exigentes, mas a ausência de VT-d não significa “sem aplicações”. Para contentores normais, a RAM, a velocidade do armazenamento e a carga de CPU da aplicação são mais importantes.
O VT-x pode suportar VMs comuns
As orientações atuais de planeamento de VMs do ZimaOS distinguem a virtualização básica KVM/QEMU do passthrough de PCIe/GPU. Os convidados Linux/Windows comuns precisam de um caminho de virtualização funcional e de CPU/RAM suficientes no anfitrião.
Consulte o guia atual de hardware para VMs do ZimaOS.
O VT-d é sobretudo uma fronteira para passthrough
Se um convidado tiver de controlar diretamente uma GPU PCIe, HBA, NIC ou dispositivo semelhante, o IOMMU/VT-d torna-se importante. O passthrough de USB também pode depender da forma como o anfitrião expõe os controladores/dispositivos USB e da interface ZVM utilizada.
Não confunda “a VM arranca” com “qualquer dispositivo físico pode ser atribuído à VM”.
Não assuma que o ZimaOS adotará diretamente um espelho Btrfs existente do OMV
O utilizador original tinha um espelho Btrfs de dois discos criado e gerido pelo OMV. A documentação atual de armazenamento do ZimaOS centra-se na criação e gestão de espaços de armazenamento do ZimaOS através do seu próprio fluxo de Armazenamento. Não oferece uma garantia geral de que esquemas RAID Btrfs preexistentes e arbitrários do OMV possam ser importados sem destruição.
Se essas unidades de 16 TB contiverem a única cópia de dados importantes, mantenha-as sob o controlo do OMV até os dados terem uma cópia de segurança independente ou terem sido copiados.
O método oficial atual de migração é a cópia através da rede
As orientações atuais da IceWhale para migrar de outro NAS consistem em manter o NAS antigo online, disponibilizar as respetivas partilhas, adicioná-lo em Ficheiros do ZimaOS como Armazenamento de rede e, em seguida, copiar os dados para o novo armazenamento do ZimaOS.
Utilize a estratégia atual de migração de outro NAS. O mesmo conceito de migração SMB aplica-se às partilhas do OMV.
Um equipamento ZimaOS Ryzen mais rápido pode utilizar o OMV como armazenamento de rede
A alternativa apresentada na origem — executar aplicações/VMs no equipamento com Ryzen 9 enquanto o OMV continua a disponibilizar os discos de 16 TB — é uma transição sensata e de baixo risco. O ZimaOS pode montar armazenamento de rede através de Ficheiros, enquanto o NAS antigo continua a ser a autoridade de armazenamento.
O limite prático será a ligação 1GbE do equipamento OMV: aproximadamente o débito de uma rede gigabit, independentemente da placa de rede 2,5GbE do equipamento Ryzen.
O JBOD USB é uma opção, mas altera o modelo de falha
O ZimaOS atual suporta unidades USB como armazenamento autónomo e em fluxos de armazenamento suportados. Transferir os HDDs para uma caixa USB dá ao ZimaOS controlo direto, mas a caixa/ponte USB passa a fazer parte do percurso de armazenamento.
Para RAID crítico sempre ligado, avalie o passthrough do SMART, a enumeração estável dos dispositivos, a alimentação, a refrigeração e o comportamento da ponte antes de transferir os discos de produção.
Uma ordem de migração mais segura
- faça uma cópia de segurança dos dados do OMV;
- instale o ZimaOS em hardware/armazenamento separado;
- teste as aplicações e uma VM representativa;
- monte o OMV como Armazenamento de rede;
- copie um subconjunto e verifique as permissões/somas de verificação;
- crie separadamente o armazenamento final do ZimaOS;
- copie os dados restantes;
- mantenha o OMV intacto até as reposições e cópias de segurança estarem verificadas.
Perguntas frequentes sobre OMV para ZimaOS
A ausência de VT-d significa que não posso utilizar aplicações Docker?
Não. As aplicações Docker não requerem VT-d.
A ausência de VT-d significa que não posso utilizar VMs comuns?
Não necessariamente. O VT-x pode suportar VMs comuns aceleradas por hardware; o VT-d é sobretudo um requisito avançado para o passthrough de dispositivos.
Devo deixar o ZimaOS recriar o RAID antigo do OMV antes de copiar os dados?
Não, se este contiver a única cópia. Mantenha o NAS antigo intacto e migre primeiro através da rede.
