Table des matières
DRBD: Xen, lvm, shrink et grow
Réduire ou agrandir un volume est parfois indispensable…
~~READMORE~~
Shrink
Réduire à chaud une partition Ext2-3-4, c'est pas possible, donc on arrête le DomU et puis:
On repère le device “drbd
” associé au disk qu'on veut réduire.
# drbd-overview
Pour moi, c'est “/dev/drbd0
”.
On vérifie le “role”, et si besoin, on devient primary. (sinon, on change de partenaire)
# drbdadm -- role <resource> Secondary/Secondary # drbdadm -- primary <resource>
Une petite vérification :
# e2fsck -f /dev/drbd0 ...
Tout va bien.
La taille mini possible:
# resize2fs -P /dev/drbd0 resize2fs 1.42.5 (29-Jul-2012) Estimated minimum size of the filesystem: 432865
La “size” retournée est le nombre de blocks . Avec la commande tune2fs -l /dev/drbd0
, on sait qu'un block vaut 4096 octets.
Donc, calcul:
echo $(( ( 432865 * 4096 ) / 1024**2 )) 1690
Soit, le nombre “Méga-octets” minimum. Ouf.
Plus haut, “e2fsck
” m'a dit que le file-system occupait “2621351 blocks”, soit 10G environ.
Donc, on redimensionne d'abord le file-system, bien au dessus du minimum :
# resize2fs -p /dev/drbd0 3000M
On peut maintenant réduire la partition, du point de vue de “drbd
” :
# drbdadm -- --size=3500M resize <resource>
On note que j'ai réduit à une taille supérieure au file-system…
On peut maintenant réduire le volume lvm, sur les 2 partenaires “drbd
” :
# lvresize -L 5G /dev/vg0/<lv_name>
Maintenant:
# drbdadm -- resize test-drbd-disk
… ce qui force “drbd
” a utiliser toute la place (5G) du disk LVM !
Et enfin:
# resize2fs -p /dev/drbd0
… ce qui augmente la taille du file-system jusqu'au max possible (un peu moins de 5G).
On remarquera que cette dernière opération annonce que la taille est de “1310720 blocks”, soit
# echo $(( 1310720 * 4096 / 1024**2 )) 5120
Correct.
Voila.
Grow
Source: http://www.drbd.org/users-guide/s-resizing.html
Avec “lvm
”, et “online”, c'est rapide.
Sur le "Dom0"
Agrandir la partition LVM, sur les 2 partenaires (peers), et qui sont connectés (“Connected”).
# lvresize -L +5G /dev/vg0/<lv_name>
Agrandir la couche drbd
, ce qui va adapter les “meta data” et les recaler sur la partition (En internal, au debut? à la fin?).
# drbdadm -- resize <resource>
Ce qui provoque immediatement une resynchronisation , et ce n'est pas nécessaire d'après la doc.
Donc, il faut mieux faire:
# drbdadm -- --assume-clean resize <resource>
Sur le "DomU"
Maintenant, on peut agrandir le “file system” à partir de la machine virtuelle.
Donc, dans le “DomU” (qui est le seul a pouvoir manipuler le filesystem sans le corrompre) :
# resize2fs -p <mount_point>