---------- Message transféré ---------- De : "Alexis Lameire" <alexis.lameire@gmail.com> Date : 22 oct. 2015 2:40 PM Objet : Re: [FRsAG] Resize de QCOW À : "Feraudet Cyril" <cyril@feraudet.com> Cc : Qemu gère le resize de qcow2 à chaud pour l'agrandissement et à froid pour la réduction. Le man de qemu-img est très clair à ce sujet Alexis Le 22 oct. 2015 10:55 AM, "Feraudet Cyril" <cyril@feraudet.com> a écrit :
Salut,
Merci pour ta réponse, malheureusement le seul espace disponible est celui que je veux récupérer, l'hyperviseur est plein comme une barrique -_-
Une voie que j'explore pour faire de la place, ré-étendre le PV, créer un LV vide avec des 0 grâce à dd puis récupérer la place avec qemu-img compact.
Je cherche tout de même une solution plus élégante avant ...
On 22/10/2015 10:43, jr@captainadmin.com wrote:
Hello,
Normalement ton disque Qcow2 est extensible et suit le volume physique pris par la vm. Si tu veux faire du ménage proprement sans tout casser, j'éviterais de shrinker le disque. C'est assez sensible et sans garantie de perte de données ou de machine.
Lorsque l'on fait de la virtualisation, il y a une facon très simple de procéder. Tu génères une nouvelle vm à coté avec les nouveaux systèmes de fichiers que tu souhaites mettre en place pour finir rien de plus simple, tu synchronises les 2 serveurs Depuis l'ancien serveur : rsync -axvH "--exclude=/dev --exclude=/proc --exclude=/boot" / root@newhost:/
Tu coupes l'ancien, démarre le nouveau, et tout devrait être opérationnel.
Tu évites les manipulations douteuses et les possibles pertes de disques sur ton serveur. La coupure de service est minime.
Bon courage http://www.captainadmin.com
Le 22-10-2015 10:08, Feraudet Cyril a écrit :
Bonjour à tous,
Avant qu'il soit trop tard je prends conseil :
J'ai un QCOW2 de 100GB sur un ProxMox, je veux le shrinker à ~ 20GB
Dedans j'ai :
root@pouet:~# fdisk -l /dev/sda
Disk /dev/sda: 107.4 GB, 107374182400 bytes
255 heads, 63 sectors/track, 13054 cylinders, total 209715200 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000cb9d9
Device Boot Start End Blocks Id System /dev/sda1 * 2048 499711 248832 83 Linux /dev/sda2 501758 209713151 104605697 5 Extended /dev/sda5 501760 209713151 104605696 8e Linux LVM
Dans le sda5 j'ai un VG :
root@pouet:~# pvs
PV VG Fmt Attr PSize PFree /dev/sda5 pouet lvm2 a-- 99,76g 85,76g
Dans mon VG j'ai :
root@pouet:~# lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert root pouet -wi-ao-- 10,00g swap_1 pouet -wi-ao-- 4,00g
Le LV root a déjà subi un shrink FS + LV de 95GB à 10GB et c'est donc le bazar dans le PV /dev/sda5 :
root@pouet:~# pvs -v --segments /dev/sda5
Using physical volume(s) on command line PV VG Fmt Attr PSize PFree Start SSize LV Start Type PE Ranges /dev/sda5 pouet lvm2 a-- 99,76g 85,76g 0 2560 root 0 linear /dev/sda5:0-2559 /dev/sda5 pouet lvm2 a-- 99,76g 85,76g 2560 21954 0 free /dev/sda5 pouet lvm2 a-- 99,76g 85,76g 24514 1024 swap_1 0 linear /dev/sda5:24514-25537
Alors je range :
root@feraudet:~# pvmove --alloc anywhere /dev/sda5:24514-25537
/dev/sda5: Moved: 0,2% /dev/sda5: Moved: 10,9% /dev/sda5: Moved: 44,2% /dev/sda5: Moved: 83,5% /dev/sda5: Moved: 100,0%
Je réduis le PV à 20GB :
root@pouet:~# pvresize --setphysicalvolumesize 20G /dev/sda5
Physical volume "/dev/sda5" changed 1 physical volume(s) resized / 0 physical volume(s) not resized
Mes questions : - Comment réduire ma partition LVM sda5 à la taille du PV ? Online ? - Comment je réduis mon QCOW2 à la taille totale de mes partitions ? qemu-img ?
Merci d'avance pour vos lumières :-)
Cyril
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Ce qui me stresse toujours quand je fais du shrink c'est : * ext3/4 ne supporte pas le shrink à chaud * Une fois le filesystem resizé, il faut shrinker la partition : comment elle sait où commence et où termine le fs ? * Et quand on resize le qcow2 : comment il sait où commencent (vraisemblablement secteur 0) et terminent les partitions pour éviter d'écraser la fin d'une part ? D'ailleurs, que ce soit du qcow2 ou un LV en RAW, même combat. Julien Le 22/10/2015 14:41, Alexis Lameire a écrit :
---------- Message transféré ---------- De : "Alexis Lameire" <alexis.lameire@gmail.com <mailto:alexis.lameire@gmail.com>> Date : 22 oct. 2015 2:40 PM Objet : Re: [FRsAG] Resize de QCOW À : "Feraudet Cyril" <cyril@feraudet.com <mailto:cyril@feraudet.com>> Cc :
Qemu gère le resize de qcow2 à chaud pour l'agrandissement et à froid pour la réduction.
Le man de qemu-img est très clair à ce sujet
Alexis
Le 22 oct. 2015 10:55 AM, "Feraudet Cyril" <cyril@feraudet.com <mailto:cyril@feraudet.com>> a écrit :
Salut,
Merci pour ta réponse, malheureusement le seul espace disponible est celui que je veux récupérer, l'hyperviseur est plein comme une barrique -_-
Une voie que j'explore pour faire de la place, ré-étendre le PV, créer un LV vide avec des 0 grâce à dd puis récupérer la place avec qemu-img compact.
Je cherche tout de même une solution plus élégante avant ...
On 22/10/2015 10:43, jr@captainadmin.com <mailto:jr@captainadmin.com> wrote:
Hello,
Normalement ton disque Qcow2 est extensible et suit le volume physique pris par la vm. Si tu veux faire du ménage proprement sans tout casser, j'éviterais de shrinker le disque. C'est assez sensible et sans garantie de perte de données ou de machine.
Lorsque l'on fait de la virtualisation, il y a une facon très simple de procéder. Tu génères une nouvelle vm à coté avec les nouveaux systèmes de fichiers que tu souhaites mettre en place pour finir rien de plus simple, tu synchronises les 2 serveurs Depuis l'ancien serveur : rsync -axvH "--exclude=/dev --exclude=/proc --exclude=/boot" / root@newhost:/
Tu coupes l'ancien, démarre le nouveau, et tout devrait être opérationnel.
Tu évites les manipulations douteuses et les possibles pertes de disques sur ton serveur. La coupure de service est minime.
Bon courage http://www.captainadmin.com
Le 22-10-2015 10:08, Feraudet Cyril a écrit :
Bonjour à tous,
Avant qu'il soit trop tard je prends conseil :
J'ai un QCOW2 de 100GB sur un ProxMox, je veux le shrinker à ~ 20GB
Dedans j'ai :
root@pouet:~# fdisk -l /dev/sda
Disk /dev/sda: 107.4 GB, 107374182400 bytes 255 heads, 63 sectors/track, 13054 cylinders, total 209715200 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x000cb9d9
Device Boot Start End Blocks Id System /dev/sda1 * 2048 499711 248832 83 Linux /dev/sda2 501758 209713151 104605697 5 Extended /dev/sda5 501760 209713151 104605696 8e Linux LVM
Dans le sda5 j'ai un VG :
root@pouet:~# pvs PV VG Fmt Attr PSize PFree /dev/sda5 pouet lvm2 a-- 99,76g 85,76g
Dans mon VG j'ai :
root@pouet:~# lvs LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert root pouet -wi-ao-- 10,00g swap_1 pouet -wi-ao-- 4,00g
Le LV root a déjà subi un shrink FS + LV de 95GB à 10GB et c'est donc le bazar dans le PV /dev/sda5 :
root@pouet:~# pvs -v --segments /dev/sda5 Using physical volume(s) on command line PV VG Fmt Attr PSize PFree Start SSize LV Start Type PE Ranges /dev/sda5 pouet lvm2 a-- 99,76g 85,76g 0 2560 root 0 linear /dev/sda5:0-2559 /dev/sda5 pouet lvm2 a-- 99,76g 85,76g 2560 21954 0 free /dev/sda5 pouet lvm2 a-- 99,76g 85,76g 24514 1024 swap_1 0 linear /dev/sda5:24514-25537
Alors je range :
root@feraudet:~# pvmove --alloc anywhere /dev/sda5:24514-25537 /dev/sda5: Moved: 0,2% /dev/sda5: Moved: 10,9% /dev/sda5: Moved: 44,2% /dev/sda5: Moved: 83,5% /dev/sda5: Moved: 100,0%
Je réduis le PV à 20GB :
root@pouet:~# pvresize --setphysicalvolumesize 20G /dev/sda5 Physical volume "/dev/sda5" changed 1 physical volume(s) resized / 0 physical volume(s) not resized
Mes questions : - Comment réduire ma partition LVM sda5 à la taille du PV ? Online ? - Comment je réduis mon QCOW2 à la taille totale de mes partitions ? qemu-img ?
Merci d'avance pour vos lumières :-)
Cyril
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Julien Escario wrote on Thu, Oct 22, 2015:
Ce qui me stresse toujours quand je fais du shrink c'est : * ext3/4 ne supporte pas le shrink à chaud
Effectivement, faut tout couper. Personellement si possible, je préfère faire tout ça hors de la VM (c'est toujours subtil de shrink un / depuis le système en question... Je crois que le plus joli que j'ai fait est un boot en pxe/init=/bin/sh, un tar dans /dev/shm, on efface tout et on recommence) Pour du qcow ça se fait assez bien avec qemu-nbd, si votre distro le permet (module kernel nbd dispo dans les debian-like, mais pas dans les redhat-like...)
* Une fois le filesystem resizé, il faut shrinker la partition : comment elle sait où commence et où termine le fs ? * Et quand on resize le qcow2 : comment il sait où commencent (vraisemblablement secteur 0) et terminent les partitions pour éviter d'écraser la fin d'une part ?
On fait des maths. Attention à ce que resize2fs, lvm, et qemu-img parlent en puissance de 1024, mais pas mal d'outils comme fdisk en puissance de 1000... ou (mieux) en secteurs Le plus safe si on n'a pas envie de compter est simplement de prendre de la marge un peu à tout les niveaux: - shrink beaucoup trop le fs - shrink un peu trop la partition (le début n'est pas un problème, il ne bouge pas; il faut seulement faire attention à remettre le même donc d'utiliser une unité qui tombe rond avec le début de partition existant) - shrink comme souhaité l'image disque - refaire la partition pour prendre tout l'espace dispo - refaire un resize2fs pour prendre tout l'espace dispo -- Dominique Martinet | Asmadeus
Pour ma part, voici ma procédure (ca ne se fait pas à chaud non plus, malheureusement). - Sur l'espace que tu veux réduire, tu crée un FS bidon, type ext3 sur lequel tu rempli avec tout plein de zero. - Une fois que tu as remplis ton FS, tu supprime ton FS, et puis tu coupe ta VM - Tu utilise la fonction shrink de l'outil qemu-img (j'ai pas de man sous les yeux, désolé) - Tu relance ta VM. et vala. L'astuce consiste à utiliser les fonctions "natives" de l'outil qemu-img, qui lui va te réduire l'image que s'il trouve des zeros. C'est ce qu'il y'a a de mieux à ma connaissance. Si tu veux partir la dessus, j'essayerai de te retrouver la procédure plus en détails/technique. Cldt -- MrJK GPG: https://jeznet.org/jez.asc Le 22 octobre 2015 18:39, Dominique Martinet <asmadeus+frsag@codewreck.org> a écrit :
Julien Escario wrote on Thu, Oct 22, 2015:
Ce qui me stresse toujours quand je fais du shrink c'est : * ext3/4 ne supporte pas le shrink à chaud
Effectivement, faut tout couper. Personellement si possible, je préfère faire tout ça hors de la VM (c'est toujours subtil de shrink un / depuis le système en question... Je crois que le plus joli que j'ai fait est un boot en pxe/init=/bin/sh, un tar dans /dev/shm, on efface tout et on recommence)
Pour du qcow ça se fait assez bien avec qemu-nbd, si votre distro le permet (module kernel nbd dispo dans les debian-like, mais pas dans les redhat-like...)
* Une fois le filesystem resizé, il faut shrinker la partition : comment elle sait où commence et où termine le fs ? * Et quand on resize le qcow2 : comment il sait où commencent (vraisemblablement secteur 0) et terminent les partitions pour éviter d'écraser la fin d'une part ?
On fait des maths. Attention à ce que resize2fs, lvm, et qemu-img parlent en puissance de 1024, mais pas mal d'outils comme fdisk en puissance de 1000... ou (mieux) en secteurs Le plus safe si on n'a pas envie de compter est simplement de prendre de la marge un peu à tout les niveaux: - shrink beaucoup trop le fs - shrink un peu trop la partition (le début n'est pas un problème, il ne bouge pas; il faut seulement faire attention à remettre le même donc d'utiliser une unité qui tombe rond avec le début de partition existant) - shrink comme souhaité l'image disque - refaire la partition pour prendre tout l'espace dispo - refaire un resize2fs pour prendre tout l'espace dispo
-- Dominique Martinet | Asmadeus _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Merci pour vos retours, Je m'en suis sorti avec le coup des zéro pour faire de la place puis j'ai créé un autre QCOW2 et fait des pvmove pour les volumes LVM, du dd pour le /boot et du grub-install pour le MBR. Je ne me suis pas lancé dans les maths des Gi, GiB, Gb, GB, secteurs et autres faute de backup en cas de loupé ... Cyril On 23/10/2015 05:29, Mrjk wrote:
Pour ma part, voici ma procédure (ca ne se fait pas à chaud non plus, malheureusement).
- Sur l'espace que tu veux réduire, tu crée un FS bidon, type ext3 sur lequel tu rempli avec tout plein de zero. - Une fois que tu as remplis ton FS, tu supprime ton FS, et puis tu coupe ta VM - Tu utilise la fonction shrink de l'outil qemu-img (j'ai pas de man sous les yeux, désolé) - Tu relance ta VM. et vala.
L'astuce consiste à utiliser les fonctions "natives" de l'outil qemu-img, qui lui va te réduire l'image que s'il trouve des zeros. C'est ce qu'il y'a a de mieux à ma connaissance. Si tu veux partir la dessus, j'essayerai de te retrouver la procédure plus en détails/technique.
Cldt
-- MrJK GPG: https://jeznet.org/jez.asc
Le 22 octobre 2015 18:39, Dominique Martinet <asmadeus+frsag@codewreck.org <mailto:asmadeus+frsag@codewreck.org>> a écrit :
Julien Escario wrote on Thu, Oct 22, 2015: > Ce qui me stresse toujours quand je fais du shrink c'est : > * ext3/4 ne supporte pas le shrink à chaud
Effectivement, faut tout couper. Personellement si possible, je préfère faire tout ça hors de la VM (c'est toujours subtil de shrink un / depuis le système en question... Je crois que le plus joli que j'ai fait est un boot en pxe/init=/bin/sh, un tar dans /dev/shm, on efface tout et on recommence)
Pour du qcow ça se fait assez bien avec qemu-nbd, si votre distro le permet (module kernel nbd dispo dans les debian-like, mais pas dans les redhat-like...)
> * Une fois le filesystem resizé, il faut shrinker la partition : comment elle > sait où commence et où termine le fs ? > * Et quand on resize le qcow2 : comment il sait où commencent (vraisemblablement > secteur 0) et terminent les partitions pour éviter d'écraser la fin d'une part ?
On fait des maths. Attention à ce que resize2fs, lvm, et qemu-img parlent en puissance de 1024, mais pas mal d'outils comme fdisk en puissance de 1000... ou (mieux) en secteurs Le plus safe si on n'a pas envie de compter est simplement de prendre de la marge un peu à tout les niveaux: - shrink beaucoup trop le fs - shrink un peu trop la partition (le début n'est pas un problème, il ne bouge pas; il faut seulement faire attention à remettre le même donc d'utiliser une unité qui tombe rond avec le début de partition existant) - shrink comme souhaité l'image disque - refaire la partition pour prendre tout l'espace dispo - refaire un resize2fs pour prendre tout l'espace dispo
-- Dominique Martinet | Asmadeus _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
- Sur l'espace que tu veux réduire, tu crée un FS bidon, type ext3 sur lequel tu rempli avec tout plein de zero.
Pourquoi ne pas juste créer une partition vide et remplir le device (genre /dev/sdf3) avec des zéros ? Le fait de formater n'est qu'une étape superflue, non ? On 23/10/2015 05:29, Mrjk wrote:
Pour ma part, voici ma procédure (ca ne se fait pas à chaud non plus, malheureusement).
- Sur l'espace que tu veux réduire, tu crée un FS bidon, type ext3 sur lequel tu rempli avec tout plein de zero. - Une fois que tu as remplis ton FS, tu supprime ton FS, et puis tu coupe ta VM - Tu utilise la fonction shrink de l'outil qemu-img (j'ai pas de man sous les yeux, désolé) - Tu relance ta VM. et vala.
L'astuce consiste à utiliser les fonctions "natives" de l'outil qemu-img, qui lui va te réduire l'image que s'il trouve des zeros. C'est ce qu'il y'a a de mieux à ma connaissance. Si tu veux partir la dessus, j'essayerai de te retrouver la procédure plus en détails/technique.
Cldt
-- MrJK GPG: https://jeznet.org/jez.asc
Le 22 octobre 2015 18:39, Dominique Martinet <asmadeus+frsag@codewreck.org <mailto:asmadeus+frsag@codewreck.org>> a écrit :
Julien Escario wrote on Thu, Oct 22, 2015: > Ce qui me stresse toujours quand je fais du shrink c'est : > * ext3/4 ne supporte pas le shrink à chaud
Effectivement, faut tout couper. Personellement si possible, je préfère faire tout ça hors de la VM (c'est toujours subtil de shrink un / depuis le système en question... Je crois que le plus joli que j'ai fait est un boot en pxe/init=/bin/sh, un tar dans /dev/shm, on efface tout et on recommence)
Pour du qcow ça se fait assez bien avec qemu-nbd, si votre distro le permet (module kernel nbd dispo dans les debian-like, mais pas dans les redhat-like...)
> * Une fois le filesystem resizé, il faut shrinker la partition : comment elle > sait où commence et où termine le fs ? > * Et quand on resize le qcow2 : comment il sait où commencent (vraisemblablement > secteur 0) et terminent les partitions pour éviter d'écraser la fin d'une part ?
On fait des maths. Attention à ce que resize2fs, lvm, et qemu-img parlent en puissance de 1024, mais pas mal d'outils comme fdisk en puissance de 1000... ou (mieux) en secteurs Le plus safe si on n'a pas envie de compter est simplement de prendre de la marge un peu à tout les niveaux: - shrink beaucoup trop le fs - shrink un peu trop la partition (le début n'est pas un problème, il ne bouge pas; il faut seulement faire attention à remettre le même donc d'utiliser une unité qui tombe rond avec le début de partition existant) - shrink comme souhaité l'image disque - refaire la partition pour prendre tout l'espace dispo - refaire un resize2fs pour prendre tout l'espace dispo
-- Dominique Martinet | Asmadeus _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Oui, en effet :-) C'est juste par habitude que je fais ça. Et puis, avec un simple "df", tu es sûre que tout est remplis. Sinon, effectivement, avec un "dd if=/dev/zero of=..." sur la partition (sans FS), ça devrait aussi marcher. Mais bon, avec les FS, j'aime bien être sûre à 400% de ce que je fais ... hinhin, que celui qui n'a jamais perdu sa partoche avec ses données dessus lève le doigt! (si son n+1 ne lui a pas déjà tous coupé XD) Cldt -- MrJK GPG: https://jeznet.org/jez.asc Le 23 octobre 2015 16:20, merlin8282 <merlin8282@gmail.com> a écrit :
- Sur l'espace que tu veux réduire, tu crée un FS bidon, type ext3 sur lequel tu rempli avec tout plein de zero.
Pourquoi ne pas juste créer une partition vide et remplir le device (genre /dev/sdf3) avec des zéros ? Le fait de formater n'est qu'une étape superflue, non ?
On 23/10/2015 05:29, Mrjk wrote:
Pour ma part, voici ma procédure (ca ne se fait pas à chaud non plus, malheureusement).
- Sur l'espace que tu veux réduire, tu crée un FS bidon, type ext3 sur lequel tu rempli avec tout plein de zero. - Une fois que tu as remplis ton FS, tu supprime ton FS, et puis tu coupe ta VM - Tu utilise la fonction shrink de l'outil qemu-img (j'ai pas de man sous les yeux, désolé) - Tu relance ta VM. et vala.
L'astuce consiste à utiliser les fonctions "natives" de l'outil qemu-img, qui lui va te réduire l'image que s'il trouve des zeros. C'est ce qu'il y'a a de mieux à ma connaissance. Si tu veux partir la dessus, j'essayerai de te retrouver la procédure plus en détails/technique.
Cldt
-- MrJK GPG: https://jeznet.org/jez.asc
Le 22 octobre 2015 18:39, Dominique Martinet <asmadeus+frsag@codewreck.org <mailto:asmadeus+frsag@codewreck.org>> a écrit :
Julien Escario wrote on Thu, Oct 22, 2015: > Ce qui me stresse toujours quand je fais du shrink c'est : > * ext3/4 ne supporte pas le shrink à chaud
Effectivement, faut tout couper. Personellement si possible, je préfère faire tout ça hors de la VM (c'est toujours subtil de shrink un / depuis le système en question... Je crois que le plus joli que j'ai fait est un boot en pxe/init=/bin/sh, un tar dans /dev/shm, on efface tout et on recommence)
Pour du qcow ça se fait assez bien avec qemu-nbd, si votre distro le permet (module kernel nbd dispo dans les debian-like, mais pas dans les redhat-like...)
> * Une fois le filesystem resizé, il faut shrinker la partition : comment elle > sait où commence et où termine le fs ? > * Et quand on resize le qcow2 : comment il sait où commencent (vraisemblablement > secteur 0) et terminent les partitions pour éviter d'écraser la fin d'une part ?
On fait des maths. Attention à ce que resize2fs, lvm, et qemu-img parlent en puissance de 1024, mais pas mal d'outils comme fdisk en puissance de 1000... ou (mieux) en secteurs Le plus safe si on n'a pas envie de compter est simplement de prendre de la marge un peu à tout les niveaux: - shrink beaucoup trop le fs - shrink un peu trop la partition (le début n'est pas un problème, il ne bouge pas; il faut seulement faire attention à remettre le même donc d'utiliser une unité qui tombe rond avec le début de partition existant) - shrink comme souhaité l'image disque - refaire la partition pour prendre tout l'espace dispo - refaire un resize2fs pour prendre tout l'espace dispo
-- Dominique Martinet | Asmadeus _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
participants (6)
-
Alexis Lameire -
Dominique Martinet -
Feraudet Cyril -
Julien Escario -
merlin8282 -
Mrjk