La respuesta más segura a este hilo de origen sin respuesta es: no hagas que el espejo Btrfs existente de OMV sea lo primero con lo que experimentes. Mantén OpenMediaVault en línea, instala ZimaOS en el sistema independiente que quieras evaluar, conecta los recursos compartidos de OMV como almacenamiento LAN y copia los datos por fases. Así conservarás el NAS antiguo tanto como servicio operativo como vía de reversión mientras pruebas las aplicaciones, los recursos compartidos y las copias de seguridad de ZimaOS.
La cuestión de la CPU también resulta más sencilla si se divide por capas. VT-x es la función clave de virtualización de hardware para las máquinas virtuales x86 normales. VT-d/IOMMU es principalmente relevante cuando quieres asignar dispositivos PCIe físicos directamente a una máquina virtual. Las aplicaciones Docker no requieren VT-d. Por lo tanto, un i5-2310 de 2011 todavía puede ejecutar contenedores y quizá también máquinas virtuales normales, pero la asignación directa de dispositivos y el rendimiento general de las máquinas virtuales tienen limitaciones independientes.
Las aplicaciones Docker no requieren VT-d
Las aplicaciones de la tienda de ZimaOS se ejecutan como contenedores Docker. Comparten el núcleo del sistema anfitrión y no necesitan asignación directa de dispositivos de hardware solo para iniciarse.
El i5 antiguo puede ser lento con aplicaciones más exigentes, pero la falta de VT-d no significa «no se pueden ejecutar aplicaciones». Para los contenedores normales, la memoria RAM, la velocidad del almacenamiento y la carga de CPU de las aplicaciones son más importantes.
VT-x puede admitir máquinas virtuales normales
Las directrices actuales de ZimaOS para planificar máquinas virtuales separan la virtualización básica con KVM/QEMU de la asignación directa de dispositivos PCIe/GPU. Los sistemas invitados Linux/Windows normales necesitan una ruta de virtualización funcional y suficiente CPU/RAM del anfitrión.
Consulta la guía actual de hardware para máquinas virtuales de ZimaOS.
VT-d es principalmente un límite para la asignación directa de dispositivos
Si un sistema invitado debe controlar directamente una GPU PCIe, una HBA, una NIC o un dispositivo similar, IOMMU/VT-d adquiere importancia. La asignación directa de dispositivos USB también puede depender de cómo el anfitrión exponga los controladores/dispositivos USB y de la interfaz ZVM utilizada.
No confundas «la máquina virtual arranca» con «todos los dispositivos físicos se pueden asignar a la máquina virtual».
No des por hecho que ZimaOS adoptará localmente un espejo Btrfs existente de OMV
El usuario original tenía un espejo Btrfs de dos discos creado y administrado por OMV. La documentación actual de almacenamiento de ZimaOS se centra en crear y administrar espacios de almacenamiento de ZimaOS mediante su propio flujo de almacenamiento. No ofrece una garantía general de que las configuraciones RAID Btrfs preexistentes y arbitrarias de OMV puedan importarse sin destruir los datos.
Si esas unidades de 16 TB contienen la única copia de datos importantes, déjalas bajo el control de OMV hasta que los datos tengan una copia de seguridad independiente o se hayan copiado.
La ruta oficial actual de migración es copiar por red
Las instrucciones actuales de IceWhale para migrar desde otro NAS consisten en mantener el NAS antiguo en línea, exponer sus recursos compartidos, añadirlo en Archivos de ZimaOS como almacenamiento LAN y copiar después los datos al almacenamiento nuevo de ZimaOS.
Usa la estrategia actual para migrar desde otro NAS. El mismo concepto de migración mediante SMB se aplica a los recursos compartidos de OMV.
Un equipo Ryzen más rápido con ZimaOS puede usar OMV como almacenamiento de red
La alternativa original —ejecutar las aplicaciones y las máquinas virtuales en el equipo con Ryzen 9 mientras OMV sigue sirviendo los discos de 16 TB— es una transición sensata y de bajo riesgo. ZimaOS puede montar almacenamiento de red mediante Archivos, mientras el NAS antiguo sigue siendo la autoridad sobre el almacenamiento.
El límite práctico será el enlace de 1GbE del equipo OMV: un rendimiento de red aproximado de clase gigabit, independientemente de la NIC de 2,5GbE del equipo Ryzen.
JBOD USB es una opción, pero cambia el modelo de fallos
ZimaOS admite actualmente unidades USB como almacenamiento independiente y en flujos de almacenamiento compatibles. Trasladar los discos duros a una carcasa USB permite que ZimaOS asuma su control directo, pero la carcasa y el puente USB pasan a formar parte de la ruta de almacenamiento.
Para un RAID crítico y siempre encendido, evalúa la compatibilidad con SMART, la enumeración estable de los dispositivos, el suministro eléctrico, la refrigeración y el comportamiento del puente antes de trasladar los discos de producción.
Un orden de migración más seguro
- haz una copia de seguridad de los datos de OMV;
- instala ZimaOS en hardware o almacenamiento independientes;
- prueba las aplicaciones y una máquina virtual representativa;
- monta OMV como almacenamiento LAN;
- copia un subconjunto y verifica los permisos y las sumas de comprobación;
- crea por separado el almacenamiento definitivo de ZimaOS;
- copia el resto de los datos;
- mantén OMV intacto hasta verificar las restauraciones y las copias de seguridad.
Preguntas frecuentes sobre OMV y ZimaOS
¿No tener VT-d significa que no puedo ejecutar aplicaciones Docker?
No. Las aplicaciones Docker no requieren VT-d.
¿No tener VT-d significa que no puedo ejecutar máquinas virtuales normales?
No necesariamente. VT-x puede admitir máquinas virtuales normales aceleradas por hardware; VT-d es principalmente un requisito avanzado para la asignación directa de dispositivos.
¿Debo dejar que ZimaOS vuelva a crear el RAID antiguo de OMV antes de copiar los datos?
No, si contiene la única copia. Mantén el NAS antiguo intacto y migra primero a través de la red.
