# Création d'images Qcow2 à la mauvaise taille dans la VM

**URL:** <https://www.debian-fr.org/t/creation-dimages-qcow2-a-la-mauvaise-taille-dans-la-vm/79987>\
**Category:** Support Debian\
**Created:** [Août 26, 2019, 5:30 UTC](https://www.debian-fr.org/t/creation-dimages-qcow2-a-la-mauvaise-taille-dans-la-vm/79987 "2019-08-26T17:30:25Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![jhfra](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/j/eb9ed0/32.png) [@jhfra](https://www.debian-fr.org/u/jhfra)\
**Post date:** [Août 26, 2019, 5:30 UTC](https://www.debian-fr.org/t/creation-dimages-qcow2-a-la-mauvaise-taille-dans-la-vm/79987/1 "2019-08-26T17:30:25Z")

</div>

Hello,

Dans un environnement KVM, lorsque je souhaite ajouter un disque au format Qcow2 à une VM, peu importe la taille que je lui donne, dans la VM, la taille reste de 192k (correspondant aux metadatas ?).

Pour les images au format RAW, je n’ai pas ce problème.

Exemple concret :

`qemu-img create -f qcow2 /stockage/disques_additionnels/test.domaine.org_disk2 50M`

> Formatting ‹&nbsp;/stockage/disques\_additionnels/test.domaine.org\_disk2&nbsp;›, fmt=qcow2 size=52428800 cluster\_size=65536 lazy\_refcounts=off refcount\_bits=16

` qemu-img info /stockage/disques_additionnels/test.domaine.org_disk2`

> image: /stockage/disques\_additionnels/test.domaine.org\_disk2  
> file format: qcow2  
> virtual size: 50M (52428800 bytes)  
> disk size: 196K  
> cluster\_size: 65536  
> Format specific information:  
> compat: 1.1  
> lazy refcounts: false  
> refcount bits: 16  
> corrupt: false

`virsh attach-disk test.domaine.org /stockage/disques_additionnels/test.domaine.org_disk2 vdc`

> Disk attached successfully

Jusqu’ici, tout va bien, on voit bien que la taille est bonne. Maintenant, passons dans la VM. L’objectif est simple, créer une partition de ~50Mo

Déjà au dmesg, on voit une différence entre vdb (image raw) et vdc (image qcow2) dont la taille pour cette dernière n’est pas bonne :

> [306.664094] virtio-pci 0000:00:08.0: enabling device (0000 → 0003)  
> [306.678459] virtio\_blk virtio3: [vdb] 102400 512-byte logical blocks (52.4 MB/50.0 MiB)  
> […]  
> [9337.218394] virtio-pci 0000:00:09.0: enabling device (0000 → 0003)  
> [9337.232575] virtio\_blk virtio4: [vdc] 385 512-byte logical blocks (197 kB/193 KiB)

Puis, évidemment au niveau de fdisk, pas de miracle :

```
fdisk /dev/vdc

Bienvenue dans fdisk (util-linux 2.33.1).
Les modifications resteront en mémoire jusqu'à écriture.
Soyez prudent avant d'utiliser la commande d'écriture.

Le périphérique ne contient pas de table de partitions reconnue.
Création d'une nouvelle étiquette pour disque de type DOS avec identifiant de disque 0xa42d033f.

Commande (m pour l'aide) : p
Disque /dev/vdc : 192,5 KiB, 197120 octets, 385 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xa42d033f

Commande (m pour l'aide) : n
Type de partition
   p primaire (0 primaire, 0 étendue, 4 libre)
   e étendue (conteneur pour partitions logiques)
Sélectionnez (p par défaut) : p
Numéro de partition (1-4, 1 par défaut) :
Premier secteur (1-384, 1 par défaut) :
Dernier secteur, +/-secteurs ou +/-taille{K,M,G,T,P} (1-384, 384 par défaut) :

Une nouvelle partition 1 de type « Linux » et de taille 192 KiB a été créée.

Commande (m pour l'aide) : p
Disque /dev/vdc : 192,5 KiB, 197120 octets, 385 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0xa42d033f

Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/vdc1 1 384 384 192K 83 Linux

Commande (m pour l'aide) : w
La table de partitions a été altérée.
Appel d'ioctl() pour relire la table de partitions.
Synchronisation des disques.

```

Pourquoi diable je ne peux rien faire cette image au format Qcow2 ?

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Août 26, 2019, 6:19 UTC](https://www.debian-fr.org/t/creation-dimages-qcow2-a-la-mauvaise-taille-dans-la-vm/79987/2 "2019-08-26T18:19:53Z")

</div>

“Disclaimer” : je n’y connais rien, mais comme dit le poète, “c’est pas parce qu’on a rien à dire qu’il faut fermer sa gueule”.

Un fichier image qcow2 grossit au fur et a mesure qu’on écrit dans le disque virtuel, donc est-ce que 192 ko ne serait pas sa taille physique initiale ?  
L’hyperviseur ne le considèrerait-il pas comme une image au format raw et ne faudrait-il pas spécifier explicitement le format qcow2 lors de l’attachement ?

---

<div class="post-metadata">

**Author:** ![jhfra](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/j/eb9ed0/32.png) [@jhfra](https://www.debian-fr.org/u/jhfra)\
**Post date:** [Août 26, 2019, 6:55 UTC](https://www.debian-fr.org/t/creation-dimages-qcow2-a-la-mauvaise-taille-dans-la-vm/79987/3 "2019-08-26T18:55:54Z")

</div>

Eh bien c’est ce que je fais au qemu-img create, je précise que c’est du Qcow2 (RAW étant le mode par défaut) et à la fin, je lui précise bien qu’il s’agit de 50M.

J’emploie exactement la même syntaxe pour des images RAW (en virant le -f du coup) et la taille est bonne côté VM. Côté HV ça retourne ça :

> image: /stockage/disques\_additionnels/test.domaine.org\_disk1  
> file format: raw  
> virtual size: 50M (52428800 bytes)  
> disk size: 6.0M

Et côté VM, cette image est bien vue comme un blockdevice de ~50Mo :

> virtio\_blk virtio3: [vdb] 102400 512-byte logical blocks (52.4 MB/50.0 MiB)

Du coup, il y a un loup quelque-part..

---

<div class="post-metadata">

**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\
**Post date:** [Août 26, 2019, 7:29 UTC](https://www.debian-fr.org/t/creation-dimages-qcow2-a-la-mauvaise-taille-dans-la-vm/79987/4 "2019-08-26T19:29:31Z")

</div>

Je parlais de la commande qui attache l’image à la VM, pas de celle qui la crée.

---

<div class="post-metadata">

**Author:** ![jhfra](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/j/eb9ed0/32.png) [@jhfra](https://www.debian-fr.org/u/jhfra)\
**Post date:** [Août 26, 2019, 7:42 UTC](https://www.debian-fr.org/t/creation-dimages-qcow2-a-la-mauvaise-taille-dans-la-vm/79987/5 "2019-08-26T19:42:57Z")

</div>

Ah ok, je regarde la doc à ce sujet [ici](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/virtualization_administration_guide/sect-virtualization-virtualized_block_devices-adding_storage_devices_to_guests), et je vous suis, mais visiblement le disk-attach ne prévoit pas ce type de paramètre.

Il y a un truc que je ne comprends pas. Certains utilisent aussi la méthode du fichier préalloué à coup de _dd if=/dev/zero of=ubuntu-box1-vm-disk1-5G bs=1M count=5120 status=progress_ , du coup ça marche comme ça, mais l’image prend quoi comme format, si ce n’est ni du Qcow2 ni du RAW ? On perd en plus l’intérêt de l’un ou de l’autre.

Je viens d’essayer le disk-attach en y mettant --type disk, mais idem.

Je ne vois pas comment font les gens sur les tutos, pourtant les commandes sont les mêmes…

---

<div class="post-metadata">

**Author:** ![Albert](https://www.debian-fr.org/user_avatar/www.debian-fr.org/albert/32/8474_2.png) [@Albert](https://www.debian-fr.org/u/Albert)\
**Post date:** [Août 26, 2019, 7:50 UTC](https://www.debian-fr.org/t/creation-dimages-qcow2-a-la-mauvaise-taille-dans-la-vm/79987/6 "2019-08-26T19:50:58Z")

</div>

Bonjour,  
Je n’y connais rien non plus 🙂  
On dirait que tu choisis le format de l’image.  
Voir ce [tutoriel](https://www.cyberciti.biz/faq/how-to-add-disk-image-to-kvm-virtual-machine-with-virsh-command/amp/)  
’ sudo qemu-img create -f raw ubuntu-box1-vm-disk1-5G 5G’  
Si ça peut t’aider !

---

<div class="post-metadata">

**Author:** ![jhfra](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/j/eb9ed0/32.png) [@jhfra](https://www.debian-fr.org/u/jhfra)\
**Post date:** [Août 26, 2019, 7:56 UTC](https://www.debian-fr.org/t/creation-dimages-qcow2-a-la-mauvaise-taille-dans-la-vm/79987/7 "2019-08-26T19:56:15Z")

</div>

Hello, merci, mais ee tuto est le copier/coller d’un autre que j’avais déjà vu (les mecs ne s’embêtent pas quand même).

J’en viens à me demander si les gens qui ont rédigé les tutos (en dehors de la doc officielle) ont réellement testé et si les sorties qu’ils affichent sont réelles… Car je ne vois pas comment c’est possible de faire un disk-attach avec un blockdevice qui aura pour nom vda, celui-ci correspondant précisément au disque système… alors pour ajouter ça en live, bonne chance 😉

En résumer, sont fonctionnels :

- Une image à base de dd, en préalloc, mais on perd l’intérêt soit du RAW, soit du QCOW2
- Une image RAW, mais ça rend le snapshot de la VM impossible (à moins de faire, comme je l’avais mentionné dans un autre poste, un retrait à chaud du disque =\> le snapshot =\> l’opération de maintenance =\> puis la réintégration.

Je me demande si ce que j’essaye de faire est seulement possible car sur la doc officielle je ne vois nulle part la séquence qui est jouée avec le format qcow2 jusqu’à l’intégration dans la VM.

---

<div class="post-metadata">

**Author:** ![sk4hrr](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/s/7bcc69/32.png) [@sk4hrr](https://www.debian-fr.org/u/sk4hrr)\
**Post date:** [Août 27, 2019, 6:57 UTC](https://www.debian-fr.org/t/creation-dimages-qcow2-a-la-mauvaise-taille-dans-la-vm/79987/8 "2019-08-27T06:57:12Z")

</div>

Bonjour,

@PascalHambourg t’a donné la réponse et Wikipédia est très clair !

> [Qcow2 — Wikipédia](https://fr.wikipedia.org/wiki/Qcow2)  
> […] retarde l’allocation de stockage jusqu’à ce que cela soit réellement nécessaire.

C’est de [l’allocation fine ou thin provisioning](https://fr.wikipedia.org/wiki/Dynamic_Provisioning). En gros la taille que tu précises à la création de ton qcow2 est une sorte de quota : ton qcow2 peut aller jusqu’a 50Mo. Si tu veux vraiment avoir un qcow2 de la sa taille maximale, faut que tu le bourre de 1 avec dd, mais je ne vois pas du tout l’utilité de la chose.

Concernant ton problème lors de l’attachement à la VM, je pense qu’encore une fois, @PascalHambourg a mis le doigt sur quelque chose. Dans ce que j’ai pu lire en quelques minutes avec les mots clefs «&nbsp;virsh attach-disk qcow&nbsp;» sur Qwant :

```
virsh attach-disk --domain vmname /var/lib/libvirt/images/vmname-vdb.qcow2 --target vdb --persistent --config --live

```

\_source : [https://bgstack15.wordpress.com/2017/09/22/create-attach-detach-disk-to-vm-in-kvm-on-command-line/\_](https://bgstack15.wordpress.com/2017/09/22/create-attach-detach-disk-to-vm-in-kvm-on-command-line/_)

```
virsh attach-disk {vm-name} /var/lib/libvirt/images/{img-name-here} vdb --cache none

```

source : [https://www.cyberciti.biz/faq/how-to-add-disk-image-to-kvm-virtual-machine-with-virsh-command/](https://www.cyberciti.biz/faq/how-to-add-disk-image-to-kvm-virtual-machine-with-virsh-command/)

```
virsh attach-disk system1 /var/lib/libvirt/images/system1.img vdb --driver qemu --subdriver qcow2 --targetbus virtio --persistent

```

\_source : [http://debiantjw.blogspot.com/2016/07/attach-qcow2-disk-to-kvm-guest-with.html\_](http://debiantjw.blogspot.com/2016/07/attach-qcow2-disk-to-kvm-guest-with.html_)

Comme tu peux le voir, il y a plusieurs options, que tu ne sembles pas utiliser.

---

<div class="post-metadata">

**Author:** ![jhfra](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/j/eb9ed0/32.png) [@jhfra](https://www.debian-fr.org/u/jhfra)\
**Post date:** [Août 27, 2019, 10:36 UTC](https://www.debian-fr.org/t/creation-dimages-qcow2-a-la-mauvaise-taille-dans-la-vm/79987/9 "2019-08-27T10:36:51Z")

</div>

> [@sk4hrr](#):
>
> virsh attach-disk system1 /var/lib/libvirt/images/system1.img vdb --driver qemu --subdriver qcow2 --targetbus virtio --persistent

Hello,

Eh bien vous avez raison tous les deux, c’est cette dernière variante de la commande qui attribue l’espace disque comme il faut dans la VM.  
Je vais aller jeter un oeil au man pour savoir exactement quoi permet d’attribuer l’espace explicitement dans les options (même si je soupçonne _–driver qemu --subdriver qcow2_ d’y être pour quelque-chose).

Merci à vous !