Hello,
Je cherche à agrandir le disque dur de mes VMs à chaud, mais ça ne fonctionne pas. Pour rappel, la procédure consiste à: 1) Agrandir l'image disque de la VM depuis l'hyperviseur (du qcow2 ici) 2) Aller sur la VM, et vérifier que la VM a bien détecté le changement de taille 3) Supprimer la partition LVM, puis la recréer avec la nouvelle taille 4) Agrandir le PV 5) Jouer avec les LV ...
Jusque là, tout le monde est d'accord, sauf que je suis _systématiquement_ obligé de rebooter mes VMs, même après relecture de la table de partition. Le reboot fonctionne plutôt bien (quoique là j'ai un cas, même après reboot, il veut pas se mettre à jour)
Évidement, le message qui revient tout le temps est le suivant (partprobe, sfdisk, blockdev, kpartx ...): BLKRRPART: Device or resource busy This disk is currently in use.
On voit bien que les nouvelles tailles sont prises en compte: root@vmdb:~#cat /proc/partitions major minor #blocks name
254 0 20971520 vda 254 1 195520 vda1 254 2 20775968 vda2 <== c'est lui 20775968 = 20Go, donc c'est bon 253 0 1048576 dm-0 ...
Mais LVM, ba ... il s'en fou: root@vmdb:~# pvs PV VG Fmt Attr PSize PFree /dev/vda2 systemvm lvm2 a-- 9.58g 416.00m <== et là, juste 9Go
Bon, reboot, et ça se règle, mais ça me gonfle ... Que faire pour que ça fonctionne à chaud ? Est-ce que vous avez le même problème? C'est aléatoire ? Faut modifier la conf de LVM ? Rajouter des arguments sur le kernel ... Je sais plus où chercher pour le coup ...
Plus d'infos sur ma config: #######################
Hyperviseur: - libvirt/qemu-kvm - Debian Wheezy
VM: - Debian Wheezy - Disques: # pvs PV VG Fmt Attr PSize PFree /dev/vda2 systemvm lvm2 a-- 9.58g 416.00m # lblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 254:0 0 20G 0 disk ├─vda1 254:1 0 191M 0 part /boot └─vda2 254:2 0 19.8G 0 part ├─systemvm-slash (dm-0) 253:0 0 1G 0 lvm / ├─systemvm-home (dm-1) 253:1 0 100M 0 lvm /home ├─systemvm-tmp (dm-2) 253:2 0 100M 0 lvm /tmp ├─systemvm-var (dm-3) 253:3 0 1G 0 lvm /var ├─systemvm-var_log (dm-4) 253:4 0 1000M 0 lvm /var/log ├─systemvm-swap (dm-5) 253:5 0 1G 0 lvm [SWAP] └─systemvm-var_lib_mysql (dm-6) 253:6 0 5G 0 lvm /var/lib/mysql
Bonjour,
Le 28/05/2015 05:53, Mrjk a écrit :
Je cherche à agrandir le disque dur de mes VMs à chaud, mais ça ne fonctionne pas.
[SNIP]
Bon, reboot, et ça se règle, mais ça me gonfle ... Que faire pour que ça fonctionne à chaud ? Est-ce que vous avez le même problème? C'est aléatoire ? Faut modifier la conf de LVM ? Rajouter des arguments sur le kernel ... Je sais plus où chercher pour le coup ...
[SNIP]
Hyperviseur:
- libvirt/qemu-kvm
Il faut chercher côté libvirt, avec "virsh blockresize" : # virsh blockresize --help NAME blockresize - Resize block device of domain.
SYNOPSIS blockresize <domain> <path> <size>
DESCRIPTION Resize block device of domain.
OPTIONS [--domain] <string> domain name, id or uuid [--path] <string> Fully-qualified path of block device [--size] <number> New size of the block device, as scaled integer (default KiB)
Hello,
yep j'allais le dire, pour moi c'est un problème d'hyperviseur.
Par exemple avec du Xen + stockage sur block devices «normaux» (=RBD avec drivers kernel au niveau de l'host), ça se fait à chaud sans problème. Mais si je remplace le driver kernel par le driver qdisk, ça ne fonctionne plus, ou du moins, pas en natif.
Olivier
Le jeudi 28 mai 2015 à 07:46 +0200, Benjamin Boudoir a écrit :
Bonjour,
Le 28/05/2015 05:53, Mrjk a écrit :
Je cherche à agrandir le disque dur de mes VMs à chaud, mais ça ne fonctionne pas.
[SNIP]
Bon, reboot, et ça se règle, mais ça me gonfle ... Que faire pour que ça fonctionne à chaud ? Est-ce que vous avez le même problème? C'est aléatoire ? Faut modifier la conf de LVM ? Rajouter des arguments sur le kernel ... Je sais plus où chercher pour le coup ...
[SNIP]
Hyperviseur:
- libvirt/qemu-kvm
Il faut chercher côté libvirt, avec "virsh blockresize" : # virsh blockresize --help NAME blockresize - Resize block device of domain.
SYNOPSIS blockresize <domain> <path> <size>
DESCRIPTION Resize block device of domain.
OPTIONS [--domain] <string> domain name, id or uuid [--path] <string> Fully-qualified path of block device [--size] <number> New size of the block device, as scaled integer (default KiB)
Le 28/05/2015 05:53, Mrjk a écrit :
Hello,
Je cherche à agrandir le disque dur de mes VMs à chaud, mais ça ne fonctionne pas. Pour rappel, la procédure consiste à:
- Agrandir l'image disque de la VM depuis l'hyperviseur (du qcow2 ici)
- Aller sur la VM, et vérifier que la VM a bien détecté le changement
de taille 3) Supprimer la partition LVM, puis la recréer avec la nouvelle taille 4) Agrandir le PV 5) Jouer avec les LV ...
Jusque là, tout le monde est d'accord, sauf que je suis _systématiquement_ obligé de rebooter mes VMs, même après relecture de la table de partition. Le reboot fonctionne plutôt bien (quoique là j'ai un cas, même après reboot, il veut pas se mettre à jour)
Évidement, le message qui revient tout le temps est le suivant (partprobe, sfdisk, blockdev, kpartx ...): BLKRRPART: Device or resource busy This disk is currently in use.
On voit bien que les nouvelles tailles sont prises en compte: root@vmdb:~#cat /proc/partitions major minor #blocks name
254 0 20971520 vda 254 1 195520 vda1 254 2 20775968 vda2 <== c'est lui 20775968 = 20Go, donc c'est bon 253 0 1048576 dm-0 ...
Mais LVM, ba ... il s'en fou:
lo,
Tu as bien fait un pvresize sur le device /dev/vda2 ici ? Ce serait peut-être bien si tu nous mettais l'ensemble des commandes tapées.
root@vmdb:~# pvs PV VG Fmt Attr PSize PFree /dev/vda2 systemvm lvm2 a-- 9.58g 416.00m <== et là, juste 9Go
Bon, reboot, et ça se règle, mais ça me gonfle ... Que faire pour que ça fonctionne à chaud ? Est-ce que vous avez le même problème? C'est aléatoire ? Faut modifier la conf de LVM ? Rajouter des arguments sur le kernel ... Je sais plus où chercher pour le coup ...
Plus d'infos sur ma config: #######################
Hyperviseur:
- libvirt/qemu-kvm
- Debian Wheezy
VM:
- Debian Wheezy
- Disques:
# pvs PV VG Fmt Attr PSize PFree /dev/vda2 systemvm lvm2 a-- 9.58g 416.00m # lblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 254:0 0 20G 0 disk ├─vda1 254:1 0 191M 0 part /boot └─vda2 254:2 0 19.8G 0 part ├─systemvm-slash (dm-0) 253:0 0 1G 0 lvm / ├─systemvm-home (dm-1) 253:1 0 100M 0 lvm /home ├─systemvm-tmp (dm-2) 253:2 0 100M 0 lvm /tmp ├─systemvm-var (dm-3) 253:3 0 1G 0 lvm /var ├─systemvm-var_log (dm-4) 253:4 0 1000M 0 lvm /var/log ├─systemvm-swap (dm-5) 253:5 0 1G 0 lvm [SWAP] └─systemvm-var_lib_mysql (dm-6) 253:6 0 5G 0 lvm /var/lib/mysql
-- Robin Cordier
JYL
Bonjour,
J’ai eu le même type de problèmatique pour des VM hyperV que j’ai adressé de la façon suivante (partitionnement GPT) :
- Je créé une nouvelle (4eme dans mon cas) partition type lvm (8e) avec tout l’espace disque supplémentaire (sgdisk --move-second-header --largest-new=4 --typecode=4:8E00 /dev/sda)
- Je mets à jour la table de partition (partprobe)
- Je crée un nouveau PV sur cette nouvelle partition (pvcreate /dev/sda4)
- J’ajoute ce nouveau PV dans mon VG (vgextend vg01 /dev/sda4)
- J’étends mon LV avec tout le nouvel espace disque de mon VG (racine / dans mon cas) (lvextend -l +100%FREE /dev/vg01/root)
- J’étends mon filesystem ext4 pour prendre en compte le nouvel espace disque de mon LV (resize2fs /dev/vg01/root)
Cette méthode fonctionne sans reboot
J’avais eu une autre approche pour ne pas à avoir à recréer un nouveau PV mais pas assez propre à mon goût et qui nécessitait un reboot. De souvenir plutôt que de recréer une nouvelle partition, je supprimais l’entrée de ma partition PV de ma table de partition pour la recréer avec le nouvel espace disque (nouveau dernier block), là c’était reboot obligatoire (partprobe pas suffisant car périph occupé forcément). Ensuite redimensionnement du PV (pvresize), puis lvextend et resize2fs.
Si jamais ça peut aider.
Laurent
De : FRsAG [mailto:frsag-bounces@frsag.org] De la part de Jean-Yves LENHOF Envoyé : jeudi 28 mai 2015 07:48 À : frsag@frsag.org Objet : Re: [FRsAG] Fwd: Agrandissement du disque dur d'une VM
Le 28/05/2015 05:53, Mrjk a écrit : Hello,
Je cherche à agrandir le disque dur de mes VMs à chaud, mais ça ne fonctionne pas. Pour rappel, la procédure consiste à: 1) Agrandir l'image disque de la VM depuis l'hyperviseur (du qcow2 ici) 2) Aller sur la VM, et vérifier que la VM a bien détecté le changement de taille 3) Supprimer la partition LVM, puis la recréer avec la nouvelle taille 4) Agrandir le PV 5) Jouer avec les LV ...
Jusque là, tout le monde est d'accord, sauf que je suis _systématiquement_ obligé de rebooter mes VMs, même après relecture de la table de partition. Le reboot fonctionne plutôt bien (quoique là j'ai un cas, même après reboot, il veut pas se mettre à jour) Évidement, le message qui revient tout le temps est le suivant (partprobe, sfdisk, blockdev, kpartx ...): BLKRRPART: Device or resource busy This disk is currently in use.
On voit bien que les nouvelles tailles sont prises en compte: root@vmdb:~#cat /proc/partitions major minor #blocks name
254 0 20971520 vda 254 1 195520 vda1 254 2 20775968 vda2 <== c'est lui 20775968 = 20Go, donc c'est bon 253 0 1048576 dm-0 ...
Mais LVM, ba ... il s'en fou:
lo,
Tu as bien fait un pvresize sur le device /dev/vda2 ici ? Ce serait peut-être bien si tu nous mettais l'ensemble des commandes tapées.
root@vmdb:~# pvs PV VG Fmt Attr PSize PFree /dev/vda2 systemvm lvm2 a-- 9.58g 416.00m <== et là, juste 9Go
Bon, reboot, et ça se règle, mais ça me gonfle ... Que faire pour que ça fonctionne à chaud ? Est-ce que vous avez le même problème? C'est aléatoire ? Faut modifier la conf de LVM ? Rajouter des arguments sur le kernel ... Je sais plus où chercher pour le coup ...
Plus d'infos sur ma config: ####################### Hyperviseur: - libvirt/qemu-kvm - Debian Wheezy
VM: - Debian Wheezy - Disques: # pvs PV VG Fmt Attr PSize PFree /dev/vda2 systemvm lvm2 a-- 9.58g 416.00m # lblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT vda 254:0 0 20G 0 disk ├─vda1 254:1 0 191M 0 part /boot └─vda2 254:2 0 19.8G 0 part ├─systemvm-slash (dm-0) 253:0 0 1G 0 lvm / ├─systemvm-home (dm-1) 253:1 0 100M 0 lvm /home ├─systemvm-tmp (dm-2) 253:2 0 100M 0 lvm /tmp ├─systemvm-var (dm-3) 253:3 0 1G 0 lvm /var ├─systemvm-var_log (dm-4) 253:4 0 1000M 0 lvm /var/log ├─systemvm-swap (dm-5) 253:5 0 1G 0 lvm [SWAP] └─systemvm-var_lib_mysql (dm-6) 253:6 0 5G 0 lvm /var/lib/mysql
-- Robin Cordier
JYL
Le Wed, May 27, 2015 at 11:53:59PM -0400, Mrjk [mrjk.78@gmail.com] a écrit:
Hello,
Je cherche à agrandir le disque dur de mes VMs à chaud, mais ça ne fonctionne pas. Pour rappel, la procédure consiste à:
- Agrandir l'image disque de la VM depuis l'hyperviseur (du qcow2 ici)
- Aller sur la VM, et vérifier que la VM a bien détecté le changement de
taille 3) Supprimer la partition LVM, puis la recréer avec la nouvelle taille 4) Agrandir le PV
Hein ?! Il suffit de créer une nouvelle partition, à la suite du disque, puis tu pvcreate dessus et vgextend, c'est moins casse-gueule que supprimer la partition et la recréer, et tu auras probablement moins de problème de détection de la nouvelle partition que de modification de taille.
En cas de problème de détection d'un nouveau disque/changement de taille, tu peux essayer de faire rescanner les disuqes :
echo "- - - " > /sys/class/scsi_host/hostX/scan
(avec X correspondant au controleur où est le disque, vu de la VM)
Et sinon, le fait que les changements soient correctement détectés, c'est un problème de communication entre l'hyperviseur et le noyau, et donc, dépend de l'hyperviseur et de la version de noyau :)
Et... pourquoi pas directement un pvresize ?
Le jeudi 28 mai 2015 à 09:43 +0200, Dominique Rousseau a écrit :
Il suffit de créer une nouvelle partition, à la suite du disque, puis tu pvcreate dessus et vgextend, c'est moins casse-gueule que supprimer la partition et la recréer, et tu auras probablement moins de problème de détection de la nouvelle partition que de modification de taille.
Le Thu, May 28, 2015 at 09:59:00AM +0200, Olivier Bonvalet [frsag.list@daevel.fr] a écrit:
Et... pourquoi pas directement un pvresize ?
Pour faire un pvresize "directement", après un agrandissement de disque, il faut que le PV soit sur le disque, et pas sur une partition.
Le jeudi 28 mai 2015 à 09:43 +0200, Dominique Rousseau a écrit :
Il suffit de créer une nouvelle partition, à la suite du disque, puis tu pvcreate dessus et vgextend, c'est moins casse-gueule que supprimer la partition et la recréer, et tu auras probablement moins de problème de détection de la nouvelle partition que de modification de taille.
Ok... je comprends mieux votre problème.
Du coup avec Xen en PV, le kernel étant en dehors de la VM, on n'a pas de /boot/ à gérer et effectivement le PV est directement sur le disque.
Bref, je n'ai jamais de partitions classiques dans les VMs, ce qui visiblement simplifie grandement les choses.
Et du coup, pourquoi ne pas déclarer un block device spécifique au /boot/, et attribuer un disque complet au PV ? Genre «vda» pour le /boot/, et «vdb» pour le PV. Ainsi, pas de partitions à gérer, et tout le monde est content.
Le jeudi 28 mai 2015 à 10:20 +0200, Dominique Rousseau a écrit :
Le Thu, May 28, 2015 at 09:59:00AM +0200, Olivier Bonvalet [frsag.list@daevel.fr] a écrit:
Et... pourquoi pas directement un pvresize ?
Pour faire un pvresize "directement", après un agrandissement de disque, il faut que le PV soit sur le disque, et pas sur une partition.
Le 2015-05-28 09:43, Dominique Rousseau a écrit :
Le Wed, May 27, 2015 at 11:53:59PM -0400, Mrjk [mrjk.78@gmail.com] a écrit:
Hello,
Je cherche à agrandir le disque dur de mes VMs à chaud, mais ça ne fonctionne pas. Pour rappel, la procédure consiste à:
- Agrandir l'image disque de la VM depuis l'hyperviseur (du qcow2
ici) 2) Aller sur la VM, et vérifier que la VM a bien détecté le changement de taille 3) Supprimer la partition LVM, puis la recréer avec la nouvelle taille 4) Agrandir le PV
Hein ?! Il suffit de créer une nouvelle partition, à la suite du disque, puis tu pvcreate dessus et vgextend, c'est moins casse-gueule que supprimer la partition et la recréer, et tu auras probablement moins de problème de détection de la nouvelle partition que de modification de taille.
Ne fonctionne que dans la limite de 16 agrandissement si la partition est de type msdos... Sinon plutôt que de supprimer/recréer, avec parted il existe la commande "resizepart"
De tête si le LVM est la dernière partition (à part éventuellement le /boot qui peut ne pas être sous LVM, je ne vois aucune raison de ne pas mettre tout le reste en LVM), je crois me souvenir qu'un resizepart numeropartition taille avec une taille à -1 agrandi jusqu'à la taille max.
Cdlt,
JYL
Le 2015-05-28 10:09, Jean-Yves LENHOF a écrit :
Le 2015-05-28 09:43, Dominique Rousseau a écrit :
Le Wed, May 27, 2015 at 11:53:59PM -0400, Mrjk [mrjk.78@gmail.com] a écrit:
Hello,
Je cherche à agrandir le disque dur de mes VMs à chaud, mais ça ne fonctionne pas. Pour rappel, la procédure consiste à:
- Agrandir l'image disque de la VM depuis l'hyperviseur (du qcow2
ici) 2) Aller sur la VM, et vérifier que la VM a bien détecté le changement de taille 3) Supprimer la partition LVM, puis la recréer avec la nouvelle taille 4) Agrandir le PV
Hein ?! Il suffit de créer une nouvelle partition, à la suite du disque, puis tu pvcreate dessus et vgextend, c'est moins casse-gueule que supprimer la partition et la recréer, et tu auras probablement moins de problème de détection de la nouvelle partition que de modification de taille.
Ne fonctionne que dans la limite de 16 agrandissement si la partition est de type msdos...
Un autre alternative étant lorsque tu atteinds cette limite est de créer un nouveau disque plutôt que d'agrandir l'existant. Ensuite tu fais un vgextend et roule..
Cdlt,
JYL
Le 28/05/2015 10:09, Jean-Yves LENHOF a écrit :
De tête si le LVM est la dernière partition (à part éventuellement le /boot qui peut ne pas être sous LVM, je ne vois aucune raison de ne pas mettre tout le reste en LVM
Ne peut pas ? Ça fait des années que c'est résolu. Ça fait au moins 5 ans que mon /boot est sous LVM en prod.
Par contre, je ne saurai pas de dire depuis quelle version de GRUB c'est possible et avec un autre bootloader, je ne me prononcerai pas.
Le 28/05/2015 18:53, Benjamin Boudoir a écrit :
Le 28/05/2015 10:09, Jean-Yves LENHOF a écrit :
De tête si le LVM est la dernière partition (à part éventuellement le /boot qui peut ne pas être sous LVM, je ne vois aucune raison de ne pas mettre tout le reste en LVM
Ne peut pas ? Ça fait des années que c'est résolu. Ça fait au moins 5 ans que mon /boot est sous LVM en prod.
Par contre, je ne saurai pas de dire depuis quelle version de GRUB c'est possible et avec un autre bootloader, je ne me prononcerai pas.
Bon j'ai fait la version courte... je vais donc faire une version un poil plus longue :
Sur plusieurs versions RedHat Entreprise / CentOs, en installation interactive tu es obligé de mettre un /boot sur une partition... On peut s'en sortir en faisant un kickstart et là on arrive à mettre la partie boot sur le lvm (pas sur que ce soit possible avec toutes les versions et notamment pas testé en version 7)
Sur Debian j'ai pas de soucis...
Après il reste le problème du /boot avec du LVM en RAID1 directement en LVM, sans passer par la couche raid DM... J'ai ouvert un bug report chez Debian sur le sujet et il existe un patch upstream mais les nouvelles versions de grub ne sortent pas très souvent (il semble que le mainteneur principal n'est plus très présent) .... Toutes les infos sont ds le bug report : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782591
Voilà le pourquoi de ma nuance....
Cdlt,
JYL
Bonjour,
Le 28/05/2015 05:53, Mrjk a écrit :
Je cherche à agrandir le disque dur de mes VMs à chaud, mais ça ne fonctionne pas. Pour rappel, la procédure consiste à:
- Agrandir l'image disque de la VM depuis l'hyperviseur (du qcow2 ici)
- Aller sur la VM, et vérifier que la VM a bien détecté le changement de taille
- Supprimer la partition LVM, puis la recréer avec la nouvelle taille
- Agrandir le PV
- Jouer avec les LV ...
Je n'ai jamais réussi avec Xen PV ni KVM+libvirt. Chez nous chaque VM a 1 disque (/dev/vda) qui est directement le filesystem sans partition. Le noyau et l'initrd sont sur la machine hôte. Ça fonctionne très bien avec EXT4, btrfs et ZFS. La procédure est ensuite : - lvresize -L+10G /dev/kvm_data/mavm - virsh block-resize mavm vda 100G - mavm:# resize2fs /dev/vda
Pas de swap, par de partitions.
Fred
-
Benjamin Boudoir -
Dominique Rousseau -
Frédéric VANNIÈRE -
Jean-Yves LENHOF -
Laurent Hulot -
Mrjk -
Olivier Bonvalet