Comment fonctionne une machine virtuelle ?
Un serveur physique partage ses ressources entre plusieurs systèmes invités indépendants grâce à un hyperviseur.
Définition simple
Une machine virtuelle, ou VM, est un ordinateur créé par logiciel. Elle possède son propre système d’exploitation, ses applications, ses disques et ses interfaces réseau, mais utilise en réalité les ressources d’un serveur ou d’un PC physique appelé hôte. Plusieurs VM peuvent fonctionner sur un même serveur tout en restant logiquement séparées : redémarrer une VM ne redémarre donc pas les autres.
Définition technique
L’hyperviseur expose à chaque VM des composants virtuels : processeurs (vCPU), mémoire, contrôleurs de stockage, disques, carte réseau et firmware BIOS ou UEFI virtuel. Le système d’exploitation invité, souvent Windows ou Linux, utilise ces équipements comme ceux d’un ordinateur physique. Des fonctionnalités matérielles telles qu’Intel VT-x ou AMD-V facilitent la virtualisation. Les performances restent limitées par les ressources et les capacités réelles de l’hôte.
- Hôte physique CPU, RAM, SSD et réseau
- Hyperviseur Gère l’allocation et l’isolation
- Ressources VM vCPU, vRAM, vDisk, vNIC
- Système invité Windows ou Linux
- Applications Services hébergés
La panne de l’hôte peut toucher plusieurs VM. Le schéma montre une VM, mais un même hyperviseur peut en héberger plusieurs.
À quoi cela sert ?
Consolider plusieurs serveurs sur une machine physique, isoler des applications, mettre en place des environnements de test et accélérer le déploiement de services. Les VM peuvent être utilisées pour Active Directory, les applications métier, les bases de données et la supervision. Les fonctions avancées de migration ou de haute disponibilité ne sont possibles que si l’infrastructure les prend en charge.
Exemple concret
Une PME dispose d’un hôte avec 16 cœurs de processeur, 128 Go de RAM et un stockage redondant. Elle y installe quatre VM : deux contrôleurs de domaine, une application de gestion et un serveur de fichiers. Chaque VM dispose de ses ressources attribuées, mais elles dépendent toutes du même hôte. Une panne matérielle peut donc rendre les quatre services indisponibles si aucun mécanisme de reprise n’est prévu.
Problèmes fréquents
- Surallocation des vCPU, contention processeur et hausse de la latence d’exécution.
- Pression mémoire ou échange sur disque lorsque la RAM physique devient insuffisante.
- Datastore plein, lenteurs d’entrées-sorties ou fichiers de snapshots delta qui grossissent.
- Mauvais rattachement au commutateur virtuel ou au VLAN, provoquant une perte réseau.
- Sauvegardes insuffisantes ou dépendance à un seul hôte et à un stockage unique.
Comment fonctionne une VM : hôte, hyperviseur, invité
L’hôte fournit les ressources matérielles : processeurs, mémoire, stockage et interfaces réseau. L’hyperviseur les répartit, crée les périphériques virtuels et contrôle l’exécution des machines. Chaque système invité garde ses propres comptes, services, applications et mises à jour. Cette séparation simplifie l’exploitation, mais ne supprime pas les risques liés à une panne de l’hôte ou à une mauvaise configuration.
Un hyperviseur de type 1 est utilisé dans les plateformes de virtualisation dédiées, comme VMware ESXi ou les technologies sur lesquelles repose Proxmox VE. D’autres solutions exécutent des VM depuis un système d’exploitation généraliste. Dans tous les cas, sécuriser la console d’administration et les réseaux virtuels reste essentiel.
CPU, RAM, disque et réseau : dimensionnement
- vCPU : une unité de calcul virtuelle présentée au système invité ; attribuer beaucoup de vCPU ne réserve pas automatiquement autant de cœurs physiques.
- RAM : surveiller la consommation réellement utilisée et les mécanismes de surallocation ; lorsque l’hôte manque de mémoire, les VM peuvent fortement ralentir.
- Stockage : les disques virtuels sont souvent des fichiers ou volumes. Le provisionnement dynamique économise de l’espace au départ mais nécessite de surveiller la capacité restante.
- Réseau : les cartes virtuelles rejoignent un vSwitch ou un bridge, puis un VLAN ou un réseau physique. Le filtrage et le routage restent nécessaires.
- Capacité : dimensionner aussi la croissance, les opérations de sauvegarde et les besoins de redémarrage après panne d’un hôte.
Snapshot, réplication, clone et sauvegarde : différences
Un snapshot conserve un état de référence pour certains retours arrière ; il peut s’appuyer sur des fichiers delta dépendant du disque d’origine. Un clone crée une autre machine ou copie de ses disques. La réplication maintient une seconde instance, parfois sur un autre site. Ces mécanismes ont des objectifs différents et ne remplacent pas automatiquement une sauvegarde indépendante et restaurable.
Une sauvegarde de VM doit permettre la restauration complète de la machine ou des données nécessaires, avec une cohérence adaptée aux applications. Il faut prévoir rétention, copie hors site ou isolée, contrôle des accès et tests de restauration. Un snapshot très ancien peut saturer le stockage ou compliquer la consolidation des disques.
Machine virtuelle ou conteneur ?
Une VM héberge en principe son propre noyau et son système d’exploitation invités sur du matériel virtualisé. Un conteneur isole des processus en partageant le noyau de l’hôte ; il est généralement plus léger et plus rapide à déployer pour une application. Une VM est adaptée à l’hébergement de systèmes complets, y compris avec des versions d’OS différentes.
Les approches sont complémentaires : il est courant de faire tourner des conteneurs Docker dans une VM Linux. Le choix dépend de la compatibilité, de l’isolation recherchée, de la gestion des mises à jour et de la disponibilité.
Termes associés
Concepts associés
À retenir : une VM est un système d’exploitation complet sur des ressources partagées. Elle facilite le déploiement et l’isolation, mais ne remplace ni une architecture de haute disponibilité, ni des sauvegardes indépendantes et testées.