Re: KVM sur host debian

[didier gaumet <didier.gaumet@gmail.com>]

Le 08/11/2024 à 11:30, BERTRAND Joël a écrit :
> didier gaumet a écrit :
> > Apparemment je me trompe: un ls sur une image qcow2 montre l'espace
> > alloué (virtual size), pas réellement occupé (disk size):
> >
> > didier@hp-notebook14:~$ sudo qemu-img info
> > /home/machines_virtuelles/win10.qcow2image:
> > /home/machines_virtuelles/win10.qcow2
> > file format: qcow2
> > virtual size: 50 GiB (53687091200 bytes)
> > disk size: 23.9 GiB
> > cluster_size: 65536
> > Format specific information:
> >      compat: 1.1
> >      compression type: zlib
> >      lazy refcounts: true
> >      refcount bits: 16
> >      corrupt: false
> >      extended l2: false
> >
> > didier@hp-notebook14:~$ ls -al /home/machines_virtuelles
> > total 41245288
> > drwxrwxr-x 2 libvirt-qemu libvirt        4096  7 nov.  13:39 .
> > drwxr-xr-x 5 root         root           4096 15 août  14:43 ..
> > -rw------- 1 root         root    53695545344 18 août  22:14 debian.qcow2
> > -rw------- 1 root         root    53695545344  7 nov.  14:35
> > opensuse_leap.qcow2
> > -rw------- 1 root         root    53695545344 17 août  22:54 win10.qcow2
> >
> > tu peux peut-être tenter (si la commande veut bien répondre),
> > - un qemu-img info pour avoir la taille réellement occupée
>
> hilbert:[~/.local/share/libvirt/images] > qemu-img info
> Virtual10-disk001.qcow2
> image: Virtual10-disk001.qcow2
> file format: qcow2
> virtual size: 128 GiB (137438953472 bytes)
> disk size: 32.8 GiB
> cluster_size: 65536
> Format specific information:
>      compat: 0.10
>      compression type: zlib
>      refcount bits: 16
> Child node '/file':
>      filename: Virtual10-disk001.qcow2
>      protocol type: file
>      file length: 32.8 GiB (35205677056 bytes)
>      disk size: 32.8 GiB
> hilbert:[~/.local/share/libvirt/images] >
>
> > - un qemu-check pour vérifier sir l'image est corrompue
> > - éventuellement un qemu-img resize pour agrandir ton image qcow2 sans
> > arrêter ta machine virtuelle, même si ça me semble douteux que le
> > changement de taille soit pris en compte immédiatement plutôt qu'au
> > prochain démarrage de la VM.
> >
> > En tout cas bon courage :-)
> >
> > PS: si je comprends à peu près (c'est incertain), si l'option
> > data_file_raw a été choisie, qemu crée une image supplémentaire avec les
> > entrées-sorties sur l'image principale, ce qui explique tes deux images
> > qcow pour une seule machine virtuelle.
> > cf doc qemu:
> > https://www.qemu.org/docs/master/tools/qemu-img.html#notes
>
> 	Je ne vois pas comment voir l'état de ce paramètre :-(
>
> 	JB

- je ne sais pas comment constater si le paramètre data_file_raw a été 
spécifié ou non à la création de l'image

- tu as un paramètre compat=0.10 alors que j'ai un 1.1, ce qui pourrait 
(je répète que j'y connais rien, c'est une pure supputation) influer 
négativement sur les performances en entrées-sorties

extrait de la doc:
"[...]
compat
    Determines the qcow2 version to use. compat=0.10 uses the 
traditional image format that can be read by any QEMU since 0.10. 
compat=1.1 enables image format extensions that only QEMU 1.1 and newer 
understand (this is the default). Amongst others, this includes zero 
clusters, which allow efficient copy-on-read for sparse images.
[...]"

peut-être peux-tu utiliser qemu-img amend pour mettre compat à 1.1 
(hypothèse, je ne sais pas)

Désolé, j'y connais rien :-)