La réponse la plus sûre à cette question restée sans réponse est la suivante : ne faites pas du miroir Btrfs OMV existant la première chose sur laquelle vous expérimentez. Laissez OpenMediaVault en ligne, installez ZimaOS sur le système séparé que vous souhaitez évaluer, connectez les partages OMV en tant que stockage LAN, puis copiez les données par étapes. Vous conservez ainsi l’ancien NAS comme service fonctionnel et solution de retour en arrière pendant que vous testez les applications, les partages et les sauvegardes ZimaOS.
La question du processeur est également plus simple lorsqu’on la divise par couche. VT-x est la fonctionnalité clé de virtualisation matérielle pour les VM x86 classiques. VT-d/IOMMU concerne principalement le cas où vous souhaitez transmettre directement des périphériques PCIe physiques à une machine invitée. Les applications Docker n’ont pas besoin de VT-d. Un i5-2310 datant de 2011 peut donc toujours exécuter des conteneurs et éventuellement des VM classiques, mais le passthrough et les performances globales des VM constituent des limites distinctes.
Les applications Docker n’ont pas besoin de VT-d
Les applications de l’App Store de ZimaOS s’exécutent sous forme de conteneurs Docker. Elles partagent le noyau de l’hôte et n’ont pas besoin du passthrough de périphériques pour démarrer.
L’ancien i5 peut être lent avec les applications plus exigeantes, mais l’absence de VT-d ne signifie pas « aucune application ». Pour les conteneurs classiques, la mémoire vive, la vitesse du stockage et la charge processeur de l’application sont plus importantes.
VT-x peut prendre en charge les VM classiques
Les recommandations actuelles de ZimaOS pour la planification des VM distinguent la virtualisation KVM/QEMU de base du passthrough PCIe/GPU. Les systèmes invités Linux/Windows classiques ont besoin d’un mécanisme de virtualisation fonctionnel et de ressources CPU/RAM suffisantes sur l’hôte.
Consultez le guide matériel actuel des VM ZimaOS.
VT-d est principalement une limite pour le passthrough
Si une machine invitée doit contrôler directement un GPU PCIe, un HBA, une carte réseau ou un périphérique similaire, IOMMU/VT-d devient important. Le passthrough USB peut également dépendre de la manière dont l’hôte expose les contrôleurs et périphériques USB, ainsi que de l’interface ZVM utilisée.
Ne confondez pas « la VM démarre » avec « tous les périphériques physiques peuvent être attribués à la VM ».
Ne supposez pas que ZimaOS adoptera sur place un miroir Btrfs OMV existant
L’utilisateur initial disposait d’un miroir Btrfs à deux disques, créé et géré par OMV. La documentation actuelle du stockage ZimaOS se concentre sur la création et la gestion d’espaces de stockage ZimaOS via son propre workflow de stockage. Elle ne garantit pas de manière générale que des configurations RAID Btrfs OMV préexistantes puissent être importées sans destruction.
Si ces disques de 16 To contiennent l’unique copie de données importantes, laissez-les sous OMV jusqu’à ce que les données soient sauvegardées ou copiées indépendamment.
La méthode officielle actuelle de migration consiste à copier les données sur le réseau
Pour migrer depuis un autre NAS, les recommandations actuelles d’IceWhale consistent à laisser l’ancien NAS en ligne, à exposer ses partages, à l’ajouter dans Fichiers de ZimaOS en tant que stockage LAN, puis à copier les données vers le nouveau stockage ZimaOS.
Utilisez la stratégie actuelle de migration depuis un autre NAS. Le même concept de migration SMB s’applique aux partages OMV.
Un boîtier ZimaOS Ryzen plus rapide peut utiliser OMV comme stockage réseau
L’alternative proposée — exécuter les applications et les VM sur le boîtier Ryzen 9 tandis qu’OMV continue de servir les disques de 16 To — constitue une transition raisonnable et peu risquée. ZimaOS peut monter le stockage réseau via Fichiers, tandis que l’ancien NAS reste l’autorité de stockage.
La limite pratique sera la liaison 1 GbE du boîtier OMV : un débit réseau de l’ordre du gigabit, quel que soit le contrôleur réseau 2,5 GbE du boîtier Ryzen.
Le JBOD USB est une option, mais il modifie le modèle de panne
ZimaOS prend actuellement en charge les disques USB comme stockage autonome ainsi que dans certains workflows de stockage pris en charge. Le fait de déplacer les disques durs dans un boîtier USB donne à ZimaOS le contrôle direct, mais le boîtier et le pont USB deviennent partie intégrante du chemin de stockage.
Pour un RAID critique fonctionnant en permanence, évaluez le passthrough SMART, l’énumération stable des périphériques, l’alimentation, le refroidissement et le comportement du pont avant de déplacer les disques de production.
Un ordre de migration plus sûr
- sauvegardez les données OMV ;
- installez ZimaOS sur du matériel ou un stockage séparé ;
- testez les applications et une VM représentative ;
- montez OMV comme stockage LAN ;
- copiez un sous-ensemble et vérifiez les autorisations et les sommes de contrôle ;
- créez séparément le stockage ZimaOS final ;
- copiez les données restantes ;
- conservez OMV intact jusqu’à ce que les restaurations et les sauvegardes soient vérifiées.
FAQ sur la migration d’OMV vers ZimaOS
L’absence de VT-d signifie-t-elle qu’aucune application Docker ne peut fonctionner ?
Non. Les applications Docker n’ont pas besoin de VT-d.
L’absence de VT-d signifie-t-elle qu’aucune VM classique ne peut fonctionner ?
Pas nécessairement. VT-x peut prendre en charge des VM classiques avec accélération matérielle ; VT-d est principalement requis pour le passthrough avancé de périphériques.
Dois-je laisser ZimaOS recréer l’ancien RAID OMV avant de copier les données ?
Non, s’il contient l’unique copie. Conservez l’ancien NAS intact et effectuez d’abord la migration sur le réseau.
