Bonjour

Le 30/03/2023 à 14:47, Olivier a écrit :

Bonjour,

J'ai une procédure pour créer une VM libvirt à partir d'une Debian
Cloud Image telle que [1].
Quand je l'applique, j'ai une VM fonctionnelle dont le disque a une
taille de 2Go.

J'aimerai faire en sorte que le disque de ma VM ait une taille
spécifique (exemple: 8Go).
Comment procéder ?

J'ai trouvé pas mal d'exemple sur Internet en fournissant les
mots-clés "qemu increase disk" mais en essayant ces recettes (à base
de qemu-img puis virt-resize), la VM ne démarre pas avec le nouveau
disque.

[1] https://cloud.debian.org/images/cloud/bullseye/20220911-1135/debian-11-generic-amd64-20220911-1135.qcow2

Ne pas utiliser de fichier comme disque de la VM mais un espace LVM. Ex:

. créer un volume LVM de 2Go
. installer Debian
. étendre le volume LVM à 8Go
. dans la VM, fdisk => suppression de la partition existe [uis
recréation immédiate en utilisant tout l'espace disque disponible
. redémarrer et voilà :)

--
Daniel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

En fait si ton but est différent alors ne tiens pas compte de ce qui suit,

mais si ce que tu cherches est seulement à préserver ton espace disque
en déterminant avec parcimonie la taille des stockages de machines
virtuelles, je crois que tu t'embêtes pour rien.

Pour voir je viens de créer via virt-manager (au-dessus de Qemu/KVM, pas au-dessus d'une autre couche) un volume de 400GB nommé test1 dans mon répertoire /home/machines_virtuelles, volontairement gros pour bien
illustrer sur mon disque de 1TB, sur lequel dans /home il restait 433GB
de libre.

AVANT:

didier@hp-notebook14:~$ df -h
[...]
/dev/mapper/VG_SSD-LV_HOME 636G 171G 433G 29% /home
[...]

APRES:

didier@hp-notebook14:~$ df -h
[...]
/dev/mapper/VG_SSD-LV_HOME 636G 171G 433G 29% /home
[...]
(là on voit bien que les 400GB du volume de stockage test1 n'ont pas été retranchés de l'espace disponible sur /home)

didier@hp-notebook14:~$ ls -lh /home/machines_virtuelles
total 57G
-rw------- 1 root root 51G 12 mars 17:45 Almalinux.qcow2
-rw------- 1 root root 51G 16 mars 18:04 debian.qcow2
-rw------- 1 root root 51G 26 mars 21:52 fedora.qcow2
-rw------- 1 root root 401G 30 mars 19:47 test1.qcow2
-rw------- 1 root root 51G 24 mars 16:01 win10.qcow2

didier@hp-notebook14:~$ du -h /home/machines_virtuelles/*
9,8G /home/machines_virtuelles/Almalinux.qcow2
18G /home/machines_virtuelles/debian.qcow2
6,4G /home/machines_virtuelles/fedora.qcow2
63M /home/machines_virtuelles/test1.qcow2
23G /home/machines_virtuelles/win10.qcow2
didier@hp-notebook14:~$

POUR CONCLURE:

En faisant une pré-allocation je suppose que ce serait bien différent
mais sans celle-ci, chez moi, des machines virtuelles (dans lesquelles
sont installés respectivement Almalinux, Debian, Fedora et Windows 10, quasiment "nus") auxquelles j'ai attribué 50GB n'en prennent qu'entre
6,4GB et 23GB.
Quant au volume de stockage auquel j'ai attribué 400G sans y créer de
machine virtuelle, il ne prend que 63MB.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) -----------------------9e5d3457a94332aee6ec97b02424b219 Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Bonjour,

------- Original Message -------
Le jeudi 30 mars 2023 à 15:16, Olivier <oza.4h07@gmail.com> a écrit :

Je viens à l'instant de trouver le lien ci-après. Il décrit
parfaitement mon cas de figure.
Il propose l'utilisation de virt-rescue pour ré-installer grub sur le
disque élargi.
Dans cet exemple, virt-rescue est utilisé de façon interactive.
Pour ma part, j'ai besoin d'une solution non-interactive.

Effectivement virt-rescue ne semble pas permettre une utilisation non-interactive.
Dans l'exemple il est utilisé pour réinstaller grub car les partitions sont réorganisées pour que la partition à étendre soit la dernière. En réalité ce n'est
pas nécessaire car la numérotation ne correspond pas à l'ordre physique des partitions sur le disque et c'est déjà la dernière, donc voilà une méthode pour
la redimensionner à 8G sans casser grub :

wget -O debian-11-generic-amd64.qcow2 https://cloud.debian.org/images/cloud/bullseye/20220911-1135/debian-11-generic-amd64-20220911-1135.qcow2

qemu-img resize debian-11-generic-amd64.qcow2 8G # augmente la taille virtuelle à 8Go
modprobe nbd # charge le module nbd (networck block device)
qemu-nbd -c /dev/nbd0 debian-11-generic-amd64.qcow2 # connecte l'image à /dev/nbd0
printf "p\nd\n1\nn\n\n\n\npwq" | fdisk /dev/nbd0 # Supprime la partition 1 et la recrée avec les valeurs par défaut (tout l'espace disponible)
resize2fs /dev/nbd0p1 # redimensionne les système de fichier à la taille de la partition
qemu-nbd -d /dev/nbd0 # déconnecte l'image de /dev/nbd0
sleep 1 # attend 1 seconde
rmmod nbd # décharge le module nbd

Un test rapide pour voir si ça boot :
kvm -m 1G -drive cache=writeback,file=debian-11-generic-amd64.qcow2 -serial stdio
Booting `Debian GNU/Linux'

Loading Linux 5.10.0-21-amd64 ...
Loading initial ramdisk ...^C
kvm: terminating on signal 2

C'est bon !

@+
Hugues

https://blog.dachary.org/2020/12/23/virt-resize-applied-to-debian-gnu-linux-cloud-images/

Le jeu. 30 mars 2023 à 15:05, Olivier oza.4h07@gmail.com a écrit :

Le jeu. 30 mars 2023 à 14:58, NoSpam no-spam@tootai.net a écrit :

. installer Debian
Puis-je justement installer Debian en utilisant ce fichier .qcow2 originel ?
Même s'il n'est pas parfait (clavier Qwerty, ...) on intérêt est de m'éviter l'utilisation de l'installeur Debian.
J'aimerai si possible, continuer à ne pas utiliser ce dernier.

-----------------------9e5d3457a94332aee6ec97b02424b219
Content-Type: application/pgp-keys; filename="publickey - hlarrive@pm.me - 0xE9429B87.asc"; name="publickey - hlarrive@pm.me - 0xE9429B87.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - hlarrive@pm.me - 0xE9429B87.asc"; name="publickey - hlarrive@pm.me - 0xE9429B87.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4ak1FWUZFMWNSWUpLd1lCQkFI YVJ3OEJBUWRBWlB0M2dhekNrdHVzaXFla2gzcnNsM0FLV0lUaUR1VGEKWk9tZEhCWjBtb3pOSDJo c1lYSnlhWFpsUUhCdExtMWxJRHhvYkdGeWNtbDJaVUJ3YlM1dFpUN0Nqd1FRCkZnb0FJQVVDWUZF MzRRWUxDUWNJQXdJRUZRZ0tBZ1FXQWdFQUFoa0JBaHNEQWg0QkFDRUpFRnZWSk5jdgo0dmswRmlF RTZVS2JoNHIyQ0RlSDZZRkJXOVVrMXkvaStUUWpDQUQvYTNwQ0hBSStsT2o1NHVOVVNTU0MKTDE4 NjFQYjI4YWs2K2JvRnN6bnVHc0FCQVBVczh3QnJLQXZxZ0RWYXFZdVd6d1BjTXNnZWJ3U0huOER3 Cmp1SDV6VmdPempnRVlGRTFjUklLS3dZQkJBR1hWUUVGQVFFSFFPbDZ3OXNiR1lmZHZOeVVPb3pj cExiZgp0aW56SWMraDVicS9rMU91TXdVRkF3RUlCOEo0QkJnV0NBQUpCUUpnVVRmaEFoc01BQ0VK RUZ2VkpOY3YKNHZrMEZpRUU2VUtiaDRyMkNEZUg2WUZCVzlVazF5L2krVFRoUEFEOUZTNFlrcFR0 RXJWNDFPRTBBaTNYClIxNlcrT3REa1p3bTZRVTY0VnUzSmJvQkFMMURMQngxRExLRE5kclZhTUZ1 NGp4MXBZV0JqTEpVZ0xLegpzbDMzakRNTQo9NXVpVgotLS0tLUVORCBQR1AgUFVCTElDIEtFWSBC TE9DSy0tLS0tCg==
-----------------------9e5d3457a94332aee6ec97b02424b219--

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wnUEARYKACcFAmQmEegJEFvVJNcv4vk0FiEE6UKbh4r2CDeH6YFBW9Uk1y/i +TQAACMfAP9scjOLEGrfLuN8s2uVYtCU3y0kN8OQhNuTWqzobEVY6wD+PB0n +AYjjnz6t4KWLSWWcr5pN4sLcDwUhPIyKitABgw=
=iv+z
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Génial !
Je vais tester cette dernière méthode dès que possible.

@didier
Ici mon objectif est d'améliorer un script Ansible avec lequel je crée
des VM libvirt/QEMU personnalisées.
Mon script fonctionne parfaitement à partir d'image Debian Cloud Image.
Le seul problème est que ces images ont une taille disque par défaut
de 2Go que l'on sature très rapidement.
D'où mon souhait de pouvoir contrôler cette taille.

Elle utilise nbd que je découvre pour la toute première fois.
Je me suis toujours demandé s'il était possible, sous conditions, de manipuler le partitionnement d'un disque par le réseau (ie d'une
machine à une autre).
nbd semble être un outil pour ce genre de chose.
À explorer.


Une autre piste est que l'image d'origine est de type cloud-init et supporterait cloud-init-growroot.
Je ne connais ni cloud-init ni cloud-init-growroot, mais il semble que
ce dernier soit automatiquement exécuté au premier boot et que son
rôle serait justement d'étendre l'unique partition root.
Il se pourrait (pas testé du tout) qu'il suffise d'exécuter un
virt-resize avant le premier boot pour que ça fonctionne.

Autre piste pas explorée du tout: comme les images supportent
cloud-init , il existe peut-être des outils dans cette mouvance qui
permettent de les instancier facilement.

Le ven. 31 mars 2023 à 00:50, Hugues Larrive <hlarrive@pm.me> a écrit :

Bonjour,

------- Original Message -------
Le jeudi 30 mars 2023 à 15:16, Olivier <oza.4h07@gmail.com> a écrit :

Je viens à l'instant de trouver le lien ci-après. Il décrit
parfaitement mon cas de figure.
Il propose l'utilisation de virt-rescue pour ré-installer grub sur le disque élargi.
Dans cet exemple, virt-rescue est utilisé de façon interactive.
Pour ma part, j'ai besoin d'une solution non-interactive.

Effectivement virt-rescue ne semble pas permettre une utilisation non-interactive.
Dans l'exemple il est utilisé pour réinstaller grub car les partitions sont réorganisées pour que la partition à étendre soit la dernière. En réalité ce n'est
pas nécessaire car la numérotation ne correspond pas à l'ordre physique des
partitions sur le disque et c'est déjà la dernière, donc voilà une méthode pour
la redimensionner à 8G sans casser grub :

wget -O debian-11-generic-amd64.qcow2 https://cloud.debian.org/images/cloud/bullseye/20220911-1135/debian-11-generic-amd64-20220911-1135.qcow2

qemu-img resize debian-11-generic-amd64.qcow2 8G # augmente la taille virtuelle à 8Go
modprobe nbd # charge le module nbd (networck block device)
qemu-nbd -c /dev/nbd0 debian-11-generic-amd64.qcow2 # connecte l'image à /dev/nbd0
printf "p\nd\n1\nn\n\n\n\npwq" | fdisk /dev/nbd0 # Supprime la partition 1 et la recrée avec les valeurs par défaut (tout l'espace disponible)
resize2fs /dev/nbd0p1 # redimensionne les système de fichier à la taille de la partition
qemu-nbd -d /dev/nbd0 # déconnecte l'image de /dev/nbd0
sleep 1 # attend 1 seconde
rmmod nbd # décharge le module nbd

Un test rapide pour voir si ça boot :
kvm -m 1G -drive cache=writeback,file=debian-11-generic-amd64.qcow2 -serial stdio
Booting `Debian GNU/Linux'

Loading Linux 5.10.0-21-amd64 ...
Loading initial ramdisk ...^C
kvm: terminating on signal 2

C'est bon !

@+
Hugues

https://blog.dachary.org/2020/12/23/virt-resize-applied-to-debian-gnu-linux-cloud-images/

Le jeu. 30 mars 2023 à 15:05, Olivier oza.4h07@gmail.com a écrit :

Le jeu. 30 mars 2023 à 14:58, NoSpam no-spam@tootai.net a écrit :

. installer Debian
Puis-je justement installer Debian en utilisant ce fichier .qcow2 originel ?
Même s'il n'est pas parfait (clavier Qwerty, ...) on intérêt est de m'éviter l'utilisation de l'installeur Debian.
J'aimerai si possible, continuer à ne pas utiliser ce dernier.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Je confirme que la procédure d'Hugues marche parfaitement (ajouter un
e2fsck -f /dev/nbd0p1 avant le resize2fs) !
Encore merci !

Le ven. 31 mars 2023 à 00:50, Hugues Larrive <hlarrive@pm.me> a écrit :

Bonjour,

------- Original Message -------
Le jeudi 30 mars 2023 à 15:16, Olivier <oza.4h07@gmail.com> a écrit :

Je viens à l'instant de trouver le lien ci-après. Il décrit
parfaitement mon cas de figure.
Il propose l'utilisation de virt-rescue pour ré-installer grub sur le disque élargi.
Dans cet exemple, virt-rescue est utilisé de façon interactive.
Pour ma part, j'ai besoin d'une solution non-interactive.

Effectivement virt-rescue ne semble pas permettre une utilisation non-interactive.
Dans l'exemple il est utilisé pour réinstaller grub car les partitions sont réorganisées pour que la partition à étendre soit la dernière. En réalité ce n'est
pas nécessaire car la numérotation ne correspond pas à l'ordre physique des
partitions sur le disque et c'est déjà la dernière, donc voilà une méthode pour
la redimensionner à 8G sans casser grub :

wget -O debian-11-generic-amd64.qcow2 https://cloud.debian.org/images/cloud/bullseye/20220911-1135/debian-11-generic-amd64-20220911-1135.qcow2

qemu-img resize debian-11-generic-amd64.qcow2 8G # augmente la taille virtuelle à 8Go
modprobe nbd # charge le module nbd (networck block device)
qemu-nbd -c /dev/nbd0 debian-11-generic-amd64.qcow2 # connecte l'image à /dev/nbd0
printf "p\nd\n1\nn\n\n\n\npwq" | fdisk /dev/nbd0 # Supprime la partition 1 et la recrée avec les valeurs par défaut (tout l'espace disponible)
resize2fs /dev/nbd0p1 # redimensionne les système de fichier à la taille de la partition
qemu-nbd -d /dev/nbd0 # déconnecte l'image de /dev/nbd0
sleep 1 # attend 1 seconde
rmmod nbd # décharge le module nbd

Un test rapide pour voir si ça boot :
kvm -m 1G -drive cache=writeback,file=debian-11-generic-amd64.qcow2 -serial stdio
Booting `Debian GNU/Linux'

Loading Linux 5.10.0-21-amd64 ...
Loading initial ramdisk ...^C
kvm: terminating on signal 2

C'est bon !

@+
Hugues

https://blog.dachary.org/2020/12/23/virt-resize-applied-to-debian-gnu-linux-cloud-images/

Le jeu. 30 mars 2023 à 15:05, Olivier oza.4h07@gmail.com a écrit :

Le jeu. 30 mars 2023 à 14:58, NoSpam no-spam@tootai.net a écrit :

. installer Debian
Puis-je justement installer Debian en utilisant ce fichier .qcow2 originel ?
Même s'il n'est pas parfait (clavier Qwerty, ...) on intérêt est de m'éviter l'utilisation de l'installeur Debian.
J'aimerai si possible, continuer à ne pas utiliser ce dernier.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)