Comment étendre un disque existant d’un domaine utilisateur OVM sans créer de nouveau disque ?
Nous prendrons dans cet exemple une machine (DomU) avec un disque « pv1_vgexadb.img » de 60GB que l’on désire étendre à 110GB.
Il faut dans un premier temps se logguer sur le Dom0 (dans cet exemple un Exadata), et y créer un fichier qui deviendra notre futur disque à coup de dd :
cd /EXAVMIMAGES/GuestImages/mamachine.mondomaine/ dd if=/dev/zero of=pv1_vgexadb_110g.img bs=1M count=112640
Nous avons donc créé la coque pleine de vide (venant du /dev/zero) de notre futur disque.
Pour le moment, nous n’avons généré que de l’activité disque sur le stockage à l’aide du dd, mais aucune coupure.
C’est à ce moment là que la rupture de service du DomU arrive.
On se logue sur le DomU « mamachine.mondomaine » et on l’arrête :
init 0
Une fois la machine virtuelle, notre DomU, arrêtée, nous pouvons démarrer la phase qui prend du temps : la copie depuis l’ancien disque vers le nouveau.
dd if=pv1_vgexadb.img of=pv1_vgexadb_110g.img conv=notrunc,noerror
Une fois la copie des blocs réalisée, on fait une petite sauvegarde de l’ancien disque – on ne sait jamais ! – et on place le nouveau en remplacement :
mv pv1_vgexadb.img pv1_vgexadb.img.08122017-beforeExtendDisk mv pv1_vgexadb_110g.img pv1_vgexadb.img
On redémarre la machine depuis le Dom0 :
xm create vm.cfg
Une fois la machine en route, on se connecte dessus et on retaille la partition (ici avec parted, mais la même chose se fait avec fdisk) :
[root@mamachine ~]# df -h /u01 Filesystem Size Used Avail Use% Mounted on /dev/mapper/VGExaDb-LVDbOra1 20G 4.5G 15G 24% /u01 [root@mamachine ~]# parted (parted) select /dev/xvdd Using /dev/xvdd (parted) print Warning: Not all of the space available to /dev/xvdd appears to be used, you can fix the GPT to use all of the space (an extra 100663296 blocks) or continue with the current setting? Fix/Ignore? Fix Model: Xen Virtual Block Device (xvd) Disk /dev/xvdd: 110GB Sector size (logical/physical): 512B/512B Partition Table: gpt Number Start End Size File system Name Flags 1 32.8kB 66.6GB 66.6GB primary lvm
On constate ici que le disque est plus volumineux qu’avant : 110GB.
On supprime maintenant la partition et on la recrée à la bonne dimension :
(parted) rm 1 Warning: WARNING: the kernel failed to re-read the partition table on /dev/xvdd (Device or resource busy). As a result, it may not reflect all of your changes until after reboot. (parted) mkpart Partition name? []? primary File system type? [ext2]? Start? 32.8kB End? 100% Warning: The resulting partition is not properly aligned for best performance. Ignore/Cancel? Ignore Warning: WARNING: the kernel failed to re-read the partition table on /dev/xvdd (Device or resource busy). As a result, it may not reflect all of your changes until after reboot.
On indique que la partition 1 que l’on vient de recréer est de type LVM :
(parted) set 1 lvm New state? [on]/off? Warning: WARNING: the kernel failed to re-read the partition table on /dev/xvdd (Device or resource busy). As a result, it may not reflect all of your changes until after reboot. (parted) quit
On redémarre la machine virtuelle (DomU) afin que la nouvelle partition soit prise en compte :
init 6
Il ne reste maintenant qu’à faire les manipulation d’extension côté LVM (si LVM il y a sur votre DomU).
On vérifie que le Physical Volume a son ancienne taille, ici 62GB :
[root@mamachine ~]# pvdisplay /dev/xvdd1 --- Physical volume --- PV Name /dev/xvdd1 VG Name VGExaDb PV Size 62.00 GiB / not usable 3.76 MiB Allocatable yes PE Size 4.00 MiB Total PE 15871 Free PE 255 Allocated PE 15616 PV UUID QUwRiD-ZUKt-I0NC-LROZ-9COq-FtFD-Gfuu0o
On le retaille :
[root@mamachine ~]# pvresize /dev/xvdd1 Physical volume "/dev/xvdd1" changed 1 physical volume(s) resized / 0 physical volume(s) not resized
Vérification sur le Physical Volume … puis sur le Volume Group :
[root@mamachine ~]# pvdisplay /dev/xvdd1 --- Physical volume --- PV Name /dev/xvdd1 VG Name VGExaDb PV Size 110.00 GiB / not usable 3.77 MiB Allocatable yes PE Size 4.00 MiB Total PE 28159 Free PE 12543 Allocated PE 15616 PV UUID QUwRiD-ZUKt-I0NC-LROZ-9COq-FtFD-Gfuu0o [root@mamachine ~]# vgdisplay VGExaDb --- Volume group --- VG Name VGExaDb System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 11 VG Access read/write VG Status resizable MAX LV 0 Cur LV 5 Open LV 3 Max PV 0 Cur PV 2 Act PV 2 VG Size 134.49 GiB PE Size 4.00 MiB Total PE 34430 Alloc PE / Size 21760 / 85.00 GiB Free PE / Size 12670 / 49.49 GiB VG UUID 2HvLtm-COvb-SGJh-rEvf-xJAx-ncm5-yqHANi
49GB de libre dans le VG ! Bonne nouvelle !
On étend le Logical Volume de 20GB parce que j’ai décidé de garder environ 30GB sous le coude pour des augmentations futures, à chaud :
[root@mamachine ~]# lvextend -L+20G /dev/mapper/VGExaDb-LVDbOra1 Size of logical volume VGExaDb/LVDbOra1 changed from 20.00 GiB (5120 extents) to 40.00 GiB (10240 extents). Logical volume LVDbOra1 successfully resized
Il ne reste qu’à faire grossir le filesystem en conséquence – si XFS, alors remplacer resize2fs par xfs_growfs) – :
[root@mamachine ~]# resize2fs /dev/mapper/VGExaDb-LVDbOra1 resize2fs 1.43-WIP (20-Jun-2013) Filesystem at /dev/mapper/VGExaDb-LVDbOra1 is mounted on /u01; on-line resizing required old_desc_blocks = 2, new_desc_blocks = 3 Performing an on-line resize of /dev/mapper/VGExaDb-LVDbOra1 to 10485760 (4k) blocks. The filesystem on /dev/mapper/VGExaDb-LVDbOra1 is now 10485760 blocks long.
Le moment de vérité, on vérifie :
[root@mamachine ~]# df -h /u01 Filesystem Size Used Avail Use% Mounted on /dev/mapper/VGExaDb-LVDbOra1 40G 4.5G 33G 13% /u01
Objectif atteint !
Nous avons étendu un filesystem d’un domaine utilisateur d’une infra OVM en augmentant la taille d’un disque virtuel.
Cette manipulation vous permet de ne pas ajouter sans arrêt des disques à vos machines, mais bien d’étendre l’existant.
Pour en savoir plus sur l’administration Exadata, découvrez notre formation « Exadata Database Machine 12c : Administration Workshop« , ainsi que l’ensemble de nos formations Oracle.
