Project Oxygen & Ideo-LabIDEO LAB Dashboard 2026

💿 Storage Systems — Chapitre 16 : Images disque et formats virtuels

Les images disque sont la matière première des plateformes virtualisées : VMDK pour VMware, VHD/VHDX pour Hyper-V, QCOW2 et RAW pour KVM/QEMU, snapshots, thin provisioning, conversions, templates et backups. Cette page densifie les formats, leurs avantages, risques, performances, chaînes de snapshots, cohérence applicative, migration V2V/P2V, sécurité et runbooks de réparation.

VMDKVHD / VHDXQCOW2RAWThin provisioningSnapshots VM
16.1

VMDK

Format VMware : flat, sparse, delta, descriptor, thin/thick, snapshots, CBT, consolidation et migration.

VMwareVMDKSnapshots
16.2

VHD / VHDX

Formats Hyper-V : VHD historique, VHDX moderne, fixed/dynamic/differencing, checkpoints, ReFS et VSS.

Hyper-VVHDXCheckpoints
16.3

QCOW2

Format KVM/QEMU : snapshots, compression, backing files, thin provisioning, metadata, cluster size et chaînes.

KVMQEMUqcow2
16.4

RAW

Performance et simplicité : disque brut, prévisibilité, conversions, limites snapshots et compatibilité universelle.

RAWPerformanceSimple
16.5

Thin provisioning

Avantages et pièges : overcommit, datastore full, UNMAP/discard, monitoring, reclaim, fragmentation et alertes.

ThinOvercommitUNMAP
16.6

Snapshots VM

Usage, risques, consolidation : delta disks, differencing disks, quiescing, application consistency et rollback.

SnapshotsDeltaConsolidation
16.7

Matrice des formats

Comparer VMDK, VHDX, QCOW2, RAW, VDI : plateformes, fonctions, performance, conversion et risques.

MatrixFormatsDecision
16.8

Thick provisioning

Eager zeroed, lazy zeroed, fixed disks, allocation complète, garanties de capacité et impact performance.

ThickFixedCapacity
16.9

Sparse & differencing

Disques différentiels, backing chains, overlay, copy-on-write, risques de dépendance et profondeur de chaîne.

SparseCOWBacking
16.10

Cohérence applicative

Crash-consistent vs application-consistent : VSS, fsfreeze, guest agents, DB logs, AD, Exchange, SQL Server.

VSSfsfreezeDB
16.11

Conversion & migration

qemu-img, vmkfstools, StarWind V2V, Disk2VHD, V2V/P2V, virt-v2v, drivers et boot repair.

V2VP2Vqemu-img
16.12

Performance des images

Cache modes, bus virtio/SCSI/NVMe, block size, alignment, preallocation, fragmentation et queue depth.

CacheVirtIOQueue
16.13

Resize & expansion

Agrandir un disque VM : image, partition, filesystem, LVM, Windows Disk Management, risques et rollback.

ResizeLVMFilesystem
16.14

Backup des images

CBT, dirty bitmap, incremental backup, immutable repo, snapshot temporary, export OVA/OVF et validation restore.

CBTIncrementalRestore
16.15

Sécurité des images

Chiffrement, secure delete, secrets dans images, golden images, template hardening, scan malware et access control.

EncryptionSecretsTemplates
16.16

Templates & golden images

Images maîtres, cloud-init, sysprep, Packer, versioning, patching, baseline CIS et dérive de configuration.

TemplatesPackercloud-init
16.17

Runbooks incidents

Snapshot bloqué, chain corrompue, datastore full, conversion ratée, VM ne boote plus, extension disque ratée.

IncidentRepairRollback
16.18

Checklist production

Préprod : format choisi, thin/thick, snapshots courts, backup testé, conversion documentée, monitoring capacité.

Prod-readyAuditChecklist
16.1 VMDK : format VMware
VMDK en pratique

VMDK est le format de disque virtuel VMware. Il peut représenter un disque plat préalloué, un disque thin, un delta snapshot, ou un ensemble descriptor + extent. Le VMDK est au cœur de VMFS, NFS datastores, templates, clones, snapshots et mécanismes de backup VMware.

Point clé : un VMDK n'est pas toujours un seul fichier. Selon le datastore et le type de disque, il peut être composé d'un descriptor, d'un flat file, de delta files et de fichiers metadata.
Chaîne logique
Guest OS→Virtual SCSI/NVMe→VMDK→Datastore→SAN/NFS/vSAN
TypeDescriptionUsageRisque
ThinAllocation à la demande.Économie capacité.Datastore full si surcommit.
Thick lazy zeroedCapacité réservée, blocks zéro au fil de l'eau.Standard général.Première écriture plus coûteuse.
Thick eager zeroedCapacité réservée et initialisée.Workloads sensibles, clustering legacy.Provisioning plus long.
DeltaFichier de snapshot.Backup/maintenance courte.Chaînes longues dangereuses.

Lors d'un snapshot VMware, les nouvelles écritures vont dans des delta files. Plus le snapshot dure, plus la chaîne grandit et plus la consolidation peut devenir longue et risquée.

Un snapshot VMware n'est pas une sauvegarde. Il doit rester temporaire, surveillé et consolidé.
# ESXi shell examples
ls -lh /vmfs/volumes/datastore1/VM01/
vmkfstools -P /vmfs/volumes/datastore1
vmkfstools -i source.vmdk target.vmdk -d thin
vim-cmd vmsvc/snapshot.get
  • Surveiller snapshots orphelins et consolidation needed.
  • Limiter durée des snapshots.
  • Conserver headroom datastore.
  • Utiliser CBT pour backup incrémental.
  • Tester restore VMDK complet, pas seulement backup successful.
16.2 VHD / VHDX : formats Hyper-V

VHDX est le format moderne Hyper-V, remplaçant VHD pour la plupart des usages. Il supporte de grandes tailles, meilleure résilience metadata, alignement moderne et intégration avec checkpoints, ReFS et VSS.

Guest OS→Virtual Disk→VHDX→CSV / SMB3 / S2D
TypeDescriptionUsage
FixedAllocation complète.Performance/prévisibilité.
Dynamically expandingAllocation progressive.Économie capacité.
DifferencingDisque enfant dépendant d'un parent.Lab, templates, checkpoints.
AVHDXCheckpoint delta.Sauvegarde/rollback temporaire.

Les checkpoints Hyper-V utilisent des disques différentiels. Ils sont utiles avant maintenance courte ou pour backup, mais dangereux en rétention longue.

Des AVHDX accumulés peuvent consommer beaucoup d'espace et dégrader les performances.
Get-VHD -Path "D:\VMs\VM01\disk.vhdx"
Resize-VHD -Path "D:\VMs\VM01\disk.vhdx" -SizeBytes 200GB
Optimize-VHD -Path "D:\VMs\VM01\disk.vhdx" -Mode Full
Get-VMCheckpoint -VMName VM01

ReFS accélère certaines opérations Hyper-V, notamment block cloning et checkpoints/merges selon version et configuration. Il est particulièrement pertinent avec S2D/CSV modernes.

16.3 QCOW2 : KVM, snapshots, compression

QCOW2 est le format QEMU Copy On Write. Il supporte thin provisioning, snapshots internes, backing files, compression optionnelle et encryption historique. Il est fréquent avec KVM, libvirt, OpenStack et Proxmox selon backend.

FonctionIntérêtRisque
Thin allocationÉconomise capacité.Volume plein si surcommit.
Backing fileClones rapides depuis base image.Dépendance parent.
Internal snapshotsRollback local.Gestion complexe en production.
CompressionRéduit taille image froide.CPU, usage limité.
base.qcow2→overlay-1.qcow2→overlay-2.qcow2→running VM
Une chaîne profonde augmente complexité, risques de perte parent et coûts de lecture.
qemu-img info disk.qcow2
qemu-img check disk.qcow2
qemu-img create -f qcow2 -b base.qcow2 overlay.qcow2
qemu-img commit overlay.qcow2
qemu-img rebase -b newbase.qcow2 overlay.qcow2
qemu-img convert -p -O qcow2 source.raw target.qcow2
  • Utiliser raw pour performance maximale simple.
  • Utiliser qcow2 pour flexibilité, templates, lab, cloud images.
  • Documenter backing files.
  • Éviter chaînes longues en production.
  • Tester boot après conversion.
16.4 RAW : performance, simplicité

RAW est le format le plus simple : une image disque brute sans couche metadata complexe. Elle se comporte comme une suite de blocs. Cela offre prévisibilité, compatibilité et souvent de très bonnes performances.

RAW est souvent le choix privilégié quand le backend fournit déjà snapshots, thin provisioning, réplication ou compression : LVM, ZFS zvol, Ceph RBD, SAN, storage array.
  • Structure simple.
  • Performance prévisible.
  • Conversions faciles.
  • Moins de risques de chaîne snapshot interne.
  • Compatible avec beaucoup d'outils bas niveau.
LimiteConséquence
Pas de metadata richeFonctions à déléguer au backend.
Snapshots internes absentsUtiliser snapshots hyperviseur/backend.
Peut consommer taille complèteDépend sparse filesystem ou backend.
Pas auto-descriptifBien documenter taille, OS, partitions.
qemu-img info disk.raw
qemu-img convert -p -O raw disk.qcow2 disk.raw
qemu-img convert -p -O qcow2 disk.raw disk.qcow2
file disk.raw
fdisk -l disk.raw
  • VM haute performance.
  • Backend Ceph RBD ou LVM.
  • Images intermédiaires de migration.
  • Disques simples à analyser hors hyperviseur.
16.5 Thin provisioning : avantages et pièges

Le thin provisioning présente à la VM une capacité logique supérieure à la capacité réellement consommée au départ. Les blocs sont alloués au fil des écritures. C'est très utile, mais dangereux sans monitoring.

Provisioned capacity peut être > physical capacity
Le risque majeur = datastore/pool full
Capacitysave

Moins d'espace initial.

Speedfast

Provisioning rapide.

Flexagile

Déploiements VM rapides.

Labideal

Dev/test efficace.

PiègeImpactMitigation
Overcommit excessifPool full.Alertes, quotas, headroom.
Snapshots oubliésExplosion capacité.Rétention courte.
UNMAP absentEspace non récupéré.discard/fstrim/Storage reclaim.
Croissance non suivieIncident brutal.Capacity planning.
# Linux guest examples
fstrim -av
lsblk --discard

# KVM/libvirt concepts
virtio-scsi + discard=unmap
qemu-img map disk.qcow2
Thin provisioning sans alerting capacité est une bombe à retardement. Un datastore full peut suspendre ou corrompre des VMs.
16.6 Snapshots VM : usage, risques, consolidation

Un snapshot VM capture un point dans le temps, souvent en créant un delta disque pour les nouvelles écritures. Il permet rollback temporaire, backup agentless ou maintenance courte.

Base disk→Delta 1→Delta 2→Current state
RisqueCauseImpact
PerformanceChaîne delta longue.Latence accrue.
CapacitéDelta grossit.Datastore full.
ConsolidationMerge long.VM stun, fenêtre longue.
CohérenceSnapshot crash-only.DB à récupérer.
  • Crash-consistent : état comme coupure courant.
  • File-system consistent : buffers filesystem flushés.
  • Application-consistent : DB/app quiesced via VSS/agent/scripts.

La consolidation fusionne les deltas dans le disque parent. Elle peut être longue et consommer beaucoup d'I/O si le snapshot a vécu trop longtemps ou si la VM écrit beaucoup.

Toujours vérifier capacité libre avant consolidation d'une grosse chaîne.
  • Snapshot court, avec owner et date d'expiration.
  • Pas de snapshot long pour remplacer backup.
  • Surveillance automatique des snapshots oubliés.
  • Application-aware pour workloads critiques.
16.7 Matrice des formats : VMDK, VHDX, QCOW2, RAW, VDI
FormatPlateformeForcesLimites
VMDKVMwareÉcosystème vSphere, CBT, templates.Chaînes snapshots, dépendance VMware.
VHDXHyper-VRésilience, ReFS, checkpoints.Écosystème Microsoft.
QCOW2KVM/QEMUCOW, backing files, flexible.Overhead et chaînes.
RAWUniverselSimple, performant.Peu de fonctions intégrées.
VDIVirtualBox/Xen selon contexteOutils spécifiques.Moins standard enterprise.
  • VMware : VMDK natif.
  • Hyper-V : VHDX natif.
  • KVM flexible : qcow2.
  • KVM performance/backend avancé : raw ou RBD.
  • Migration : convertir vers format natif cible.
Format optimal = plateforme cible + besoin snapshots + performance + backup + migration + support outillage
16.8 Thick provisioning : eager zeroed, lazy zeroed, fixed disks

Le thick provisioning réserve la capacité complète dès la création. Il réduit le risque de pool full lié à la croissance imprévue, mais consomme plus d'espace dès le départ.

TypeDescriptionUsage
Lazy zeroedRéservé, zéro à la première écriture.Usage général.
Eager zeroedRéservé et initialisé immédiatement.Workloads exigeants/legacy clustering.
Fixed VHDXTaille complète allouée.Performance/prévisibilité Hyper-V.
  • Capacité garantie.
  • Moins de risque overcommit.
  • Prévisibilité pour production critique.
  • Peut réduire certaines latences de première écriture.
  • Provisioning plus long.
  • Moins efficace en capacité.
  • Peut encourager surallocation côté VM.
  • Ne remplace pas monitoring capacité.
16.9 Sparse & differencing : backing chains, overlay, COW

Les formats sparse/differencing stockent seulement les blocs modifiés par rapport à un état initial ou parent. C'est la base des clones rapides, snapshots, templates et labs.

Golden image→Child 1Child 2Child 3
  • Déploiement très rapide.
  • Économie capacité.
  • Templates et golden images.
  • Rollback/lab/dev-test.
RisqueImpact
Parent manquantChild inutilisable.
Chaîne longuePerformance et complexité.
Consolidation ratéeVM bloquée ou données à risque.
Documentation absenteMigration dangereuse.
16.10 Cohérence applicative : crash-consistent vs application-consistent
NiveauDescriptionRisque
Crash-consistentComme coupure électrique.Recovery applicatif nécessaire.
Filesystem-consistentBuffers FS flushés.DB pas forcément propre.
Application-consistentApp/DB quiesced.Plus complexe mais meilleur RPO.

VSS coordonne les writers Windows : SQL Server, Exchange, AD, filesystem. Un backup application-aware doit vérifier que les writers sont stables.

vssadmin list writers
vssadmin list shadows
  • Guest agent QEMU/VMware tools.
  • fsfreeze pour filesystem.
  • Scripts pre/post backup pour DB.
  • Dump logique ou backup natif DB si nécessaire.
Pour une base critique, un snapshot VM seul n'est pas toujours suffisant. Prévoir WAL/binlog/redo archiving, backup natif, test restore et cohérence transactionnelle.
16.11 Conversion & migration : qemu-img, vmkfstools, V2V/P2V
OutilUsage
qemu-imgConvertir raw/qcow2/vmdk/vhdx selon support.
vmkfstoolsCloner/convertir VMDK sur ESXi.
StarWind V2VConversions Windows friendly.
Disk2VHDP2V Windows vers VHD/VHDX.
virt-v2vConversions vers KVM/libvirt.
qemu-img info source.vmdk
qemu-img convert -p -O qcow2 source.vmdk target.qcow2
qemu-img convert -p -O raw source.vhdx target.raw
qemu-img convert -p -O vmdk source.qcow2 target.vmdk
  • Installer drivers virtio/VMware/Hyper-V avant migration si possible.
  • Vérifier boot mode BIOS/UEFI.
  • Corriger fstab, initramfs, bootloader.
  • Vérifier adresses MAC, licences, agents backup.
  • Tester application, pas seulement boot OS.
Toute conversion production doit prévoir rollback : image source intacte, fenêtre, validation checksum, test boot isolé et plan DNS/IP.
16.12 Performance des images : cache, bus, block size, alignment
Busvirtio

SCSI/NVMe optimisés.

Cachemode

Impact sécurité/perf.

Align4K

Éviter write amplification.

Queuedepth

Concurrence I/O.

writebackRapide mais exige protection power-loss.
writethroughPlus sûr, moins performant.
none/directÉvite double cache, souvent bon pour DB.
unsafeLab uniquement, risque perte données.
  • virtio-scsi ou virtio-blk pour KVM.
  • Paravirtual SCSI ou NVMe VMware selon workload/support.
  • Hyper-V synthetic storage controller.
  • Drivers invités à jour.
fio --name=imgtest --filename=/data/testfile --size=20G --rw=randrw --rwmixread=70 --bs=4k --iodepth=32 --numjobs=4 --direct=1 --time_based --runtime=120 --group_reporting
16.13 Resize & expansion : image, partition, filesystem
  1. Backup ou snapshot court avant opération.
  2. Agrandir l'image côté hyperviseur.
  3. Rescan disque dans le guest.
  4. Agrandir partition ou PV LVM.
  5. Agrandir filesystem.
  6. Valider application et monitoring.
# Example for LVM
lsblk
parted /dev/sda print
pvresize /dev/sda3
lvextend -r -L +50G /dev/vg0/root

# Filesystem only examples
resize2fs /dev/vg0/root
xfs_growfs /mountpoint
# PowerShell / DiskPart concepts
Get-Disk
Get-Partition
Resize-Partition -DriveLetter C -Size 200GB

# Or Disk Management GUI
Réduire un disque est beaucoup plus risqué qu'agrandir. Toujours sauvegarder, réduire filesystem avant image, et tester hors production.
16.14 Backup des images : CBT, dirty bitmap, incremental, restore

Les solutions modernes utilisent CBT, dirty bitmaps ou mécanismes équivalents pour sauvegarder uniquement les blocs modifiés depuis le dernier point. Cela réduit fortement la fenêtre backup.

PatternUsage
Full syntheticChaîne logique complète sans tout relire.
Incremental foreverOptimise fenêtres courtes.
Immutable repoProtection ransomware.
Instant restoreRTO faible.
  • Vérifier checksum et boot automatique.
  • Test restore isolé.
  • Application-aware pour DB/AD.
  • Documenter RPO/RTO mesurés.

OVA/OVF ou export image peuvent servir à migration ou archivage, mais ne remplacent pas une stratégie backup incrémentale et testée.

16.15 Sécurité des images : chiffrement, secrets, golden images
Secrets dans imageClés SSH, tokens, mots de passe oubliés.
Template vulnérableToutes les VMs héritent de la faille.
Image non chiffréeExfiltration datastore.
Suppression non sécuriséeDonnées récupérables.
  • Chiffrement VM ou datastore.
  • Nettoyer cloud-init, machine-id, SSH host keys avant template.
  • Scanner malware et vulnérabilités.
  • RBAC sur templates et exports.
  • Secure delete ou crypto erase selon backend.

Une golden image doit être versionnée, patchée, scannée et reconstruite régulièrement. Elle ne doit contenir aucun secret spécifique environnement.

16.16 Templates & golden images : cloud-init, sysprep, Packer

Les templates standardisent les déploiements VM. Ils réduisent le temps de provisionnement et les écarts de configuration, mais deviennent dangereux s'ils ne sont pas maintenus.

PackerConstruction automatisée d'images.
cloud-initPersonnalisation Linux au premier boot.
SysprepGénéralisation Windows.
AnsiblePost-provisioning/configuration.
Base ISO→Packer build→Patch→Scan→Publish template
  • Versionner templates.
  • Retirer images obsolètes.
  • Documenter drivers et agents.
  • Tester boot après update.
  • Ne pas modifier template manuellement en production.
16.17 Runbooks incidents images disque
  1. Identifier VM, snapshot, delta files.
  2. Vérifier capacité datastore.
  3. Vérifier backup récent.
  4. Lancer consolidation contrôlée.
  5. Surveiller latence et stun.
  6. Ne pas supprimer delta à la main sans procédure.
  1. Arrêter écritures si possible.
  2. Copier tous les fichiers image/metadata.
  3. Analyser chaîne avec outil natif.
  4. Tenter repair sur copie.
  5. Restaurer backup si intégrité douteuse.
Priorité : stabiliser avant de supprimer. Une suppression précipitée de fichiers VM peut rendre les données irrécupérables.
  1. Stopper nouveaux snapshots/backups.
  2. Identifier gros deltas/ISOs/temp.
  3. Ajouter capacité si possible.
  4. Consolider après headroom.
  5. Valider VMs critiques.
  1. Vérifier ordre boot BIOS/UEFI.
  2. Vérifier contrôleur disque virtuel.
  3. Monter image offline si nécessaire.
  4. Réparer bootloader/initramfs/BCD.
  5. Rollback ou restore si conversion récente.
16.18 Checklist production images disque
ContrôleOK ?Note
Format natif plateforme choisi☐VMDK/VHDX/qcow2/raw.
Thin/thick décidé☐Avec monitoring capacité.
Snapshots gouvernés☐TTL, owner, alertes.
Backup restore testé☐VM complète + application.
Templates versionnés☐Patch, scan, secrets nettoyés.
  • Alertes datastore/pool full.
  • Rapport snapshots > seuil.
  • Procédure conversion V2V.
  • Runbook consolidation.
  • Documentation chemins images.
  • Chiffrement si données sensibles.
  • RBAC sur exports/templates.
  • Secrets retirés des golden images.
  • Secure erase/crypto erase sortie de parc.
NO-GO si : snapshots sans limite, thin sans monitoring, pas de restore testé, templates contenant secrets, conversion sans rollback, datastore déjà proche de saturation.