Une VM peut-elle utiliser un partage NAS comme disque de données secondaire ?

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Can a VM Use a NAS Share as a Secondary Data Disk? - Zima Store Online

Oui. Une VM peut monter un partage NFS ou SMB dans le système invité et l'utiliser comme stockage de fichiers secondaire. Un hyperviseur peut également placer un disque virtuel sur un stockage adossé à un NAS, mais cela présente un stockage en mode bloc au système invité et entraîne un comportement différent en cas de panne.

Choisissez le modèle avant de le configurer. Les partages de fichiers conviennent aux documents, aux médias, aux sauvegardes et aux données de projet partagées ; les bases de données et les applications qui nécessitent un verrouillage sur disque local, une faible latence ou une disponibilité au démarrage peuvent plutôt avoir besoin d'un disque virtuel ou d'un stockage local. Cette distinction détermine la configuration sûre, la méthode de validation et le point de restauration.

Choisissez la sémantique fichier ou la sémantique bloc

Un partage NFS ou SMB monté par le système invité reste clairement un stockage réseau. Il est facile à partager avec d'autres clients, mais le système invité doit gérer les identifiants, les pannes réseau et la récupération du montage.

Un disque virtuel stocké sur un datastore NFS ou iSCSI ressemble à un périphérique bloc local pour le système invité. L'hyperviseur prend en charge la dépendance réseau, et plusieurs systèmes invités ne doivent pas monter simultanément le même système de fichiers standard, sauf s'il est compatible avec les clusters.

N'appelez pas un partage mappé un disque dans la documentation de la conception. Les étapes de récupération, les instantanés, les autorisations et les risques de corruption dépendent du modèle réellement déployé.

Interprétez les signaux de panne avant d'engager les données

Montez d'abord le partage manuellement et testez la création, le renommage, le verrouillage, l'écriture de fichiers volumineux et l'héritage des autorisations. Mesurez le débit et la latence sous la charge d'un autre client au lieu de vous fier aux performances d'un NAS vide.

Redémarrez le NAS tout en laissant la VM active. L'application doit se mettre en pause ou échouer clairement, puis récupérer sans écrire dans un point de montage local vide qui ressemble seulement au chemin du partage.

Utilisez le tableau ci-dessous pour déterminer si le chemin sélectionné est prêt pour la production.

État observé	Verdict	Action suivante
Fichiers/médias partagés	NFS ou SMB monté par le système invité	Bonne adéquation
Système de fichiers d'un seul invité nécessitant une sémantique bloc	Disque virtuel adossé à un NAS	Tester le comportement en cas de panne de l'hyperviseur
Base de données sensible à la latence sur un Wi-Fi instable	Aucun des deux	Utiliser un stockage bloc local ou filaire fiable

Rendez explicites les dépendances réseau et d'identité

Pour un système invité Linux, utilisez un montage automatique systemd ou un montage prenant en charge `_netdev`, et faites dépendre l'application de l'unité de montage. Pour SMB, stockez les identifiants dans un fichier lisible par root au lieu de les intégrer à l'historique du shell ou à une configuration largement accessible.

Alignez le mappage UID/GID pour NFS ou utilisez un compte de service SMB dédié avec le principe du moindre privilège. Confirmez que les instantanés et les sauvegardes couvrent la copie faisant autorité ; un instantané de VM peut ne pas inclure les données d'un partage monté par le système invité.

Le guide de configuration d'un NAS Proxmox de ZimaSpace fournit le contexte plus large du stockage sur l'hôte.

Un guide pratique du stockage centralisé pour un homelab compare le montage de NFS et de SMB dans les VM et les conteneurs.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

Retestez la charge de travail initiale et une panne du NAS

Copiez des données représentatives, exécutez l'application réelle, redémarrez la VM et vérifiez que le partage est présent avant que le service n'écrive. Testez à la fois une maintenance planifiée du NAS et une interruption réseau brutale.

Restaurez la VM séparément et confirmez que les opérateurs savent que les données du NAS sont restaurées par le plan de sauvegarde du NAS, et non par la seule image de l'invité. Évitez que deux processus de restauration indépendants n'écrasent le même jeu de données.

Poursuivez lorsque le protocole correspond à la charge de travail, que les dépendances au démarrage sont imposées et que le comportement en cas de panne est sûr. Arrêtez-vous si une application bascule silencieusement vers le stockage local, si le verrouillage échoue ou si le fournisseur de la base de données ne prend pas en charge le système de fichiers réseau choisi.