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

Support Debian
#1

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 ‘/stockage/disques_additionnels/test.domaine.org_disk2’, 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 ?

#2

“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 ?

#3

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…

#4

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

#5

Ah ok, je regarde la doc à ce sujet ici, 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…

#6

Bonjour,
Je n’y connais rien non plus :slight_smile:
On dirait que tu choisis le format de l’image.
Voir ce tutoriel
’ sudo qemu-img create -f raw ubuntu-box1-vm-disk1-5G 5G’
Si ça peut t’aider !

#7

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 :wink:

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.

#8

Bonjour,

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

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. 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 “virsh attach-disk qcow” 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/

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/

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

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

#9

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 !

1 J'aime