Disques virtuels - Format brut - Création - Restauration - Partitionnement

Mise à jour : Debian Buster 11.1

• Les disques virtuels sont des fichiers, aussi appelés images disque, utilisables comme des disques réels, par des émulateurs / virtualisateurs tels que qemu
  

• Les formats courants des fichiers image disque sont le format brut et le format qcow2. Ce document traite
  
• de la création
• de la restauration (création de disques réels à partir de disques virtuels)
• et du partitionnement des disques virtuels au format brut

• Le format compressé qcow2 est traité dans Disques virtuels - Format qcow2
• La création de boucles de périphérique permettant de formater, monter, explorer .... les partitions d'une image disque est décrite dans Disques virtuels - Périphériques boucle
• L'utilisation des disques virtuels en tant que périphérique de l'émulateur qemu est décrite dans Émulateur Qemu - Kvm - Périphériques de stockage

Sommaire

1 - Principe

• Les fichiers image au format brut ont la propriété
• de pouvoir être crées (et restaurés) simplement à partir de (et vers) une disque physique par recopie "bit à bit"
• d'utiliser les mêmes outils de partitionnement (parted, fdisk, ...) que les disques réels

2 - Création d'un disque vierge

• On prend l'exemple de la création d'un disque virtuel de taille 1GiB. Trois méthodes sont comparées
• qemu-img
• fallocate
• dd
  

2.1 - Création avec qemu-img

• Création de l'image disque vdisk1.img
  

$ qemu-img create vdisk1.img 1G
Formatting 'vdisk1.img', fmt=raw size=8589934592

• La taille (apparente) du fichier est conforme à ce qui est attendu : 1GiB
  

$ ls -lnh vdisk1.img
-rw-r--r-- 1 1000 1000 1,0G 30 nov.  23:24 vdisk1.img

• L'occupation disque est minimum, en effet les blocs "vides" sont remplacés par des "trous". Cet avantage disparaîtra néanmoins au fur et à mesure des écritures sur le disque).

$ du -h vdisk1.img 
4,0K  vdisk1.img

• qemu-img info fournit un affichage rapide des caractéristiques du fichier image, en particulier
• taille apparente (virtual size)
• occupation disque (disk size)
  

$ qemu-img info vdisk1.img 
image: vdisk3.img
file format: raw
virtual size: 1 GiB (1073741824 bytes)
disk size: 4 KiB

• On peut vérifier que

• dd interprète bien le fichier comme une suite de 1GiB de zéros

$ dd if=vdisk1.img  bs=1MiB |hexdump -C
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
1024+0enregistrements lus
1024+0 enregistrements écrits
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 1,6309 s, 658 MB/s
40000000

• le fichier image est partitionnable comme un disque réel, par exemple avec parted

$ sudo parted vdisk1.img -s mktable msdos mkpart primary fat32 2MiB 500MiB mkpart primary ext2 500MiB 100% unit MiB print
Model:  (file)
Disk /home/philippe/soft/qemu/test/vdisk1.img: 1024MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start    End      Size    Type     File system  Flags
 1      2,00MiB  500MiB   498MiB  primary  fat32        lba
 2      500MiB   1024MiB  524MiB  primary  ext2         lba

• les partitions peuvent être affichées avec partx
  

$ sudo partx vdisk1.img 
NR   START     END SECTORS SIZE NAME UUID
 1    4096 1023999 1019904 498M      562efcec-01
 2 1024000 2097151 1073152 524M      562efcec-02

• Le partitionnement a augmenté l'occupation du fichier sur le disque

$ qemu-img info vdisk1.img 
image: vdisk1.img
file format: raw
virtual size: 1 GiB (1073741824 bytes)
disk size: 24 KiB

2.2 - Création avec fallocate

• Création de l'image disque vdisk2.img
  

$ fallocate -l 1G vdisk2.img

• La taille (apparente) du fichier est conforme à ce qui est attendu : 1GiB
  

$ ls -lnh vdisk2.img
-rw-r--r-- 1 1000 1000 1,0G  4 déc.  21:03 vdisk2.img

• L'occupation disque est un peu supérieure à la taille (apparente) du fichier (4K)
  

$ du -k --apparent-size vdisk2.img
1048576        vdisk2.img

$ du -k vdisk2.img
1048580 vdisk2.img

• Les informations fournies par qemu-img ne confirment pas cette augmentation, car elles sont arrondies.
  

$ qemu-img info vdisk2.img
image: vdisk2.img
file format: raw
virtual size: 1 GiB (1073741824 bytes)
disk size: 1 GiB

• On peut vérifier, comme pour qemu-img, que
  

• dd interprète bien le fichier comme une suite de 1GiB de zéros

$ dd if=vdisk1.img  bs=1MiB |hexdump -C
....

• le fichier image est partitionnable comme un disque réel, par exemple avec parted

$ sudo parted vdisk1.img -s mktable msdos mkpart primary fat32 2MiB 500MiB mkpart primary ext2 500MiB 100% unit MiB print
....

• les partitions peuvent être affichées avec partx
  

$ sudo partx vdisk2.img 
...

• Le partitionnement n'a pas augmenté l'occupation du fichier sur le disque

$ du -k vdisk2.img
1048580        vdisk2.img

• Il est possible de réduire l'occupation disque du fichier créé par fallocate, en remplaçant les zéros par des "trous", tout en conservant la taille apparente initiale, cette réduction disparaissant peu à peu au fur et à mesure des écritures dans le fichier

$ fallocate -d vdisk2.img

$ ls -lnh vdisk2.img
-rw-r--r-- 1 1000 1000 1,0G  4 déc.  21:48 vdisk2.img

$ du -k vdisk2.img
8        vdisk2.img

2.3 - Création avec dd

• Création de l'image (la commande écrit des zéros dans tout le fichier, ce qui a un impact sur le temps de la commande)

$ dd if=/dev/zero of=vdisk3.img bs=1M count=1024
1024+0 enregistrements lus
1024+0 enregistrements écrits
1073741824 octets (1,1 GB, 1,0 GiB) copiés, 0,578335 s, 1,9 GB/s

• La taille (apparente) du fichier est conforme à ce qui est attendu : 1GiB
  

$ ls -lnh vdisk2.img
-rw-r--r-- 1 1000 1000 1,0G  4 déc.  21:38 vdisk3.img

• L'occupation disque est un peu supérieure à la taille (apparente) du fichier (4K), comme pour fallocate
  

$ du -k --apparent-size vdisk2.img
1048576        vdisk3.img

$ du -k vdisk3.img
1048580 vdisk3.img

• Il est possible de réduire l'occupation disque du fichier créé par dd, en remplaçant les zéros par des "trous", tout en conservant la taille apparente initiale, cette réduction disparaissant peu à peu au fur et à mesure des écritures dans le fichier
  

$ fallocate -d vdisk3.img

$ ls -lnh vdisk3.img 
-rw-r--r-- 1 1000 1000 1,0G  4 déc.  21:41 vdisk3.img

$ du -k vdisk3.img
0       vdisk3.img

• On peut vérifier, comme pour qemu-img, que
  

• dd interprète bien le fichier comme une suite de 1GiB de zéros

$ dd if=vdisk1.img  bs=1MiB |hexdump -C
....

• le fichier image est partitionnable comme un disque réel, par exemple avec parted

$ sudo parted vdisk1.img -s mktable msdos mkpart primary fat32 2MiB 500MiB mkpart primary ext2 500MiB 100% unit MiB print
....

• les partitions peuvent être affichées avec partx
  

$ sudo partx vdisk2.img 
...

• Le partitionnement a légèrement augmenté l'occupation sur le disque
  

$ du -k vdisk3.img
24     vdisk3.img

2.4 - Bilan

• En ce qui concerne la fonctionnalité de création d'un disque virtuel vierge, les trois solutions (qemu-img, fallocate, dd) ne sont pas tout à fait équivalentes

$ qemu-img create vdisk1.img

$ fallocate -l 1G vdisk2.img

$ dd if=/dev/zero of=vdisk3.img bs=1M count=1024

• Les temps de création avec qemu-img et fallocate sont "quasi" nuls, la création avec dd beaucoup plus longue car elle effectue une écriture de la totalité du fichier
  
• A la création du fichier, l'occupation disque est minimum avec qemu-img. Elle augmente ensuite au fur et à mesure que les blocs de zéro sont consommés par les écritures dans le fichier.
  
• Il est possible de réduire de manière équivalente l'occupation disque des fichiers créés par fallocate ou dd, en remplaçant les blocs de zéro par des "trous"
  

$ fallocate -d vdisk.img

• Les utilitaires disques partx, parted, fdisk, .... sont directement utilisables sur les fichiers images au format brut, quelque soit la méthode de création (qemu-img, fallocate, dd)
  

3 - Création par recopie d'un disque réel

Il est possible de créer un disque virtuel au format brut par recopie "bit à bit" d'un disque réel. Le disque virtuel ainsi créé possède le même partitionnement, le même contenu que le disque réel

3.1 - Recopie standard

• La commande ci-dessous recopie le disque en créant une image, de même taille que le disque réel (y compris l'espace vide éventuel en fin de disque)
  

$ sudo dd if=/dev/sdb bs=4MiB of=disk.img conv=fsync iflag=fullblock status=progress
2000683008octets (2,0 GB, 1,9 GiB) copiés, 203 s, 9,8 MB/s 
477+1 enregistrements lus
477+1 enregistrements écrits
2003828736 octets (2,0 GB, 1,9 GiB) copiés, 203,963 s, 9,8 MB/s

• conv=fsync : la commande ne s'achève qu'une fois la recopie physique des données sur le périphérique effectuée, évite de retirer un périphérique avant que le transfert ne soit achevé
• status=progress : affiche l'avancement de la recopie
• iflag=fullblock : avec les grandes valeurs de bloc ou lorsque dd est utilisé en filtre assure que le nombre de données transférées soit exactement bs*count
• optionnellement : oflag=direct ; le cache d'E/S ne sera pas utilisé, en association avec iflag=flullblock assure que les données sont transférées bloc par bloc. Si la commande est interrompue, on est ainsi assuré de récupérer la main dès que le transfert du bloc en cours est terminé

• On peut vérifier que
  
• la taille du disque virtuel est égale à celle du disque réel
  

$ sudo fdisk -l sdb.img |grep Disque
Disque sdb.img : 1,87 GiB, 2003828736 octets, 3913728 secteurs

$ du -b --apparent-size sdb.img
2003828736    sdb.img

$ ls -ln sdb.img
-rw-r--r-- 1 0 0 2003828736  4 déc.  22:55 sdb.img

• le partitionnement du disque d'origine et de l'image disque sont identiques
  

$ sudo parted /dev/sdb unit b print free
Model: General USB Flash Disk (scsi)
Disk /dev/sdb: 2003828736B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start        End          Size         File system  Name  Flags
        17408B       2097151B     2079744B     Free Space
 1      2097152B     524287999B   522190848B                gpt1  msftdata
 2      524288000B   2002780159B  1478492160B               gpt2
        2002780160B  2003811839B  1031680B     Free Space

$ sudo parted disk.img unit b print free
Model:  (file)
Disk /home/philippe/soft/qemu/test/disk.img: 2003828736B
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start        End          Size         File system  Name  Flags
        17408B       2097151B     2079744B     Free Space
 1      2097152B     524287999B   522190848B                gpt1  msftdata
 2      524288000B   2002780159B  1478492160B               gpt2
        2002780160B  2003811839B  1031680B     Free Space

3.2 - Recopie avec réduction de l'espace libre en fin de disque

• L'objectif ici est de créer une copie du disque réel en supprimant l'espace libre à la fin du disque de façon à minimiser le temps de création de l'image et à réduire la taille de l'image. Dans le cas d'un partitionnement gpt, il est nécessaire de prendre en compte la présence de la table de partition secondaire
  
• Afficher le partitionnement et l'espace libre du disque réel, avec pour unité le secteur
  

$ sudo parted /dev/sdb unit s print free
Model: General USB Flash Disk (scsi)
Disk /dev/sdb: 3913728s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start     End       Size      File system  Name  Flags
        34s       4095s     4062s     Free Space
 1      4096s     976895s   972800s                gpt1  msftdata
 2      976896s   1953791s  976896s                gpt2
        1953792s  3913694s  1959903s  Free Space

• Calculer la taille minimum (en secteurs) du fichier virtuel en ajoutant
  
• au premier secteur libre, ici 1953792s
  
• soit 0 cas d'un partitionnement MBR/Bios
• soit 33s pour la table de partition GPT secondaire dans le cas d'un partitionnement GPT
  

$ calc 1953792+33
   1953825 

• En déduire le nombre de blocs à prévoir, pour la taille de bloc retenue, ici 4MiB, en arrondissant à l'unité supérieure
  

$ calc 1953825/2/1024/4
  238.5040283203125

Le nombre de blocs minimum sera donc 239

• Lancer la recopie
  

$ sudo dd if=/dev/sdb bs=4MiB count=239 of=disk.img conv=fsync iflag=fullblock status=progress
998244352octets (998 MB, 952 MiB) copiés, 99 s, 10,1 MB/s
239+0 enregistrements lus
239+0 enregistrements écrits
1002438656 octets (1,0 GB, 956 MiB) copiés, 99,91 s, 10,0 MB/s

• Dans le cas d'un partitionnement msdos, le fichier est directement utilisable
• Dans le cas d'un partitionnement gpt, deux problèmes restent à régler
  
• la taille du disque a changé et la modification n'a pas été prise en compte dans la gpt primaire
  
• il manque la gpt secondaire en fin de disque
  

$ sudo gdisk shortdisk.img 
....
Warning! Disk size is smaller than the main header indicates! Loading
secondary header from the last sector of the disk! You should use 'v' to
verify disk integrity, and perhaps options on the experts' menu to repair
the disk.
Caution: invalid backup GPT header, but valid main header; regenerating
backup header from main header.

Warning! Error 25 reading partition table for CRC check!
Warning! One or more CRCs don't match. You should repair the disk!

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: damaged

****************************************************************************
Caution: Found protective or hybrid MBR and corrupt GPT. Using GPT, but disk
verification and recovery are STRONGLY recommended.
****************************************************************************

• Pour réparer les tables de partitionnement GPT (et MBR protective), dans le menu gdisk
  

• Sélectionnez les choix :
  

(gdisk) > r (recovery/transformation)

• puis

(gdisk) > e (rebuild secondary GPT)

• confirmez les choix et terminer en écrivant les modifications

(gdisk) > w (write)

• Informer le noyau des changements (nécessaire?)
  

$ sudo partx -a disk.img

• Afficher la table de partitionnement de l'image, vérifier l'absence de message d'erreur
  

$ sudo parted disk.img unit s print free
Model:  (file)
Disk /home/philippe/soft/qemu/test/disk.img: 1957888s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start     End       Size     File system  Name  Flags
        34s       4095s     4062s    Free Space
 1      4096s     976895s   972800s               gpt1  msftdata
 2      976896s   1953791s  976896s               gpt2
        1953792s  1957854s  4063s    Free Space

4 - Restauration

• On s’intéresse ici à la restauration (création de disques réels à partir de disques virtuels) d'un disque virtuel

4.1 - Vérification de la taille des disques

• Le périphérique cible doit impérativement être de taille supérieure ou égale à celle du disque virtue. La première étape consiste à comparer la taille du disque réel et la taille du disque virtuel :
• Dans ce qui suit, le disque réel est attaché en /dev/sdb, sa taille est de 223,57 GiB GiB
  

$ sudo fdisk -l /dev/sdb |grep Disque
Disque /dev/sdb: 223,57 GiB, 240057409536 octets, 468862128 secteurs

• Le disque virtuel à restaurer a pour nom disk.img. Sa taille (virtuelle) est de 956 MiB
  

$ sudo fdisk -l disk.img |grep Disque
Disque disk.img: 956 MiB, 1002438656 octets, 1957888 secteurs

• La taille du disque réel est donc supérieure à celle du disque virtuel, la recopie pourra donc s'effectuer
  

4.2 - Restauration

• Attention : Toutes les données présentes sur le périphérique sur lequel s'effectuera la restauration seront perdues
  

• Lancer la recopie

$ dd if=debiangpt.img iflag=fullblock |pv -s 10G |sudo dd of=/dev/sdb conv=fsync oflag=direct

• Dans le cas d'une image disque avec partitionnement msdos, le disque réel est directement utilisable
• Dans le cas d'une image disque avec partitionnement gpt, la gpt recopiée sur le disque présente un problème : le disque physique est plus grand qu'indiqué dans la gpt et la gpt secondaire n'est pas en fin de disque. Pour la réparer, lancer parted et sélectionner l'option de réparation: "Fix"
  

$ sudo parted /dev/sdb print
Warning: Not all of the space available to /dev/sdb appears to be used, you can fix
the GPT to use all of the space (an extra 466904240 blocks) or continue with the
current setting? 
Fix/Ignore? Fix                                                         

• On peut alors vérifier que
  
• la table de partition primaire en début de disque ( secteurs 1 à 34)

$ sudo head -c $((34*512)) /dev/sdb|tail -c $((33*512)) |hexdump -C
00000000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00000010  b0 3f 28 a1 00 00 00 00  01 00 00 00 00 00 00 00  |.?(.............|
00000020  af 44 f2 1b 00 00 00 00  22 00 00 00 00 00 00 00  |.D......".......|
00000030  8e 44 f2 1b 00 00 00 00  7a a7 6d 23 17 a5 55 46  |.D......z.m#..UF|
00000040  9c 6f 92 bf 76 d3 41 f9  02 00 00 00 00 00 00 00  |.o..v.A.........|
00000050  80 00 00 00 80 00 00 00  a2 9d 2c 46 00 00 00 00  |..........,F....|
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
00000210  ad eb 97 1f e4 6e ab 4b  8d 8b 4f 50 18 10 c2 8f  |.....n.K..OP....|
00000220  00 10 00 00 00 00 00 00  ff e7 0e 00 00 00 00 00  |................|
00000230  00 00 00 00 00 00 00 00  67 00 70 00 74 00 31 00  |........g.p.t.1.|
00000240  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000280  af 3d c6 0f 83 84 72 47  8e 79 3d 69 d8 47 7d e4  |.=....rG.y=i.G}.|
00000290  c3 fa 38 be 5c 5a 4f 42  8a 28 75 52 9b 67 7f 6e  |..8.\ZOB.(uR.g.n|
000002a0  00 e8 0e 00 00 00 00 00  ff cf 1d 00 00 00 00 00  |................|
000002b0  00 00 00 00 00 00 00 00  67 00 70 00 74 00 32 00  |........g.p.t.2.|
000002c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00004200

• correspond à la table de partition secondaire en fin de disque (les 33 derniers secteurs)

$ sudo tail -c $((33*512)) disk.img |hexdump -C
00000000  a2 a0 d0 eb e5 b9 33 44  87 c0 68 b6 b7 26 99 c7  |......3D..h..&..|
00000010  ad eb 97 1f e4 6e ab 4b  8d 8b 4f 50 18 10 c2 8f  |.....n.K..OP....|
00000020  00 10 00 00 00 00 00 00  ff e7 0e 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  67 00 70 00 74 00 31 00  |........g.p.t.1.|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  af 3d c6 0f 83 84 72 47  8e 79 3d 69 d8 47 7d e4  |.=....rG.y=i.G}.|
00000090  c3 fa 38 be 5c 5a 4f 42  8a 28 75 52 9b 67 7f 6e  |..8.\ZOB.(uR.g.n|
000000a0  00 e8 0e 00 00 00 00 00  ff cf 1d 00 00 00 00 00  |................|
000000b0  00 00 00 00 00 00 00 00  67 00 70 00 74 00 32 00  |........g.p.t.2.|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00004000  45 46 49 20 50 41 52 54  00 00 01 00 5c 00 00 00  |EFI PART....\...|
00004010  ee 03 60 fa 00 00 00 00  ff df 1d 00 00 00 00 00  |..`.............|
00004020  01 00 00 00 00 00 00 00  22 00 00 00 00 00 00 00  |........".......|
00004030  de df 1d 00 00 00 00 00  7a a7 6d 23 17 a5 55 46  |........z.m#..UF|
00004040  9c 6f 92 bf 76 d3 41 f9  df df 1d 00 00 00 00 00  |.o..v.A.........|
00004050  80 00 00 00 80 00 00 00  a2 9d 2c 46 00 00 00 00  |..........,F....|
00004060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00004200