DRBD: Xen, lvm, shrink et grow

Réduire ou agrandir un volume est parfois indispensable…

~~READMORE~~

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.

Source: http://www.drbd.org/users-guide/s-resizing.html

Avec “lvm”, et “online”, c'est rapide.

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>

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>