Gestion des volumes et disques dans ganeti

Identifier les partitions LVM d'une instance

Les partitions lvm ont des noms impossibles à comprendre parce que ce sont des UUID. Pour retrouver facilement quelle partition LVM est associée à quelle instance,

sur le master

# gnt-node volumes

sur une node des nodes

On peut faire afficher les tags des partitions:

root@vania:~# lvs -o+tags
  LV                                         VG   Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert LV Tags                           
  0797d85c-ae2f-4c53-b7d6-dcd95fe1b668.disk0 data -wi-ao---- 18.00g                                                     originstname+someinstance1.koumbit.net
  08123707-dc16-4318-becd-baa648090886.disk1 data -wi-ao----  2.00g                                                     originstname+someinstance2.koumbit.net  
  0c4f5efa-4691-44d1-98ab-7ff6d0f55fd1.disk0 data -wi-ao---- 90.00g                                                     originstname+somevps1.aegirvps.net

Trouver les UUID des partitions tel que vu par les VM

Les partitions LVM contiennent aussi des partitions (généralement une seule). Par exemple, une partition <uuid>.disk0 contient aussi une partition <uuid>.disk0p1. Dans une VM, le fstab n'utilise pas le UUID de la partition LVM, mais de la partition que cette dernière contient.

Pour une partition swap, c'est facile. On peut directement y aller avec blkid avec le device file de la partition

root@versa:/# blkid /dev/mapper/data-a97ef754--417f--4edf--bee3--b64d2b7b2add.disk1   
/dev/mapper/data-a97ef754--417f--4edf--bee3--b64d2b7b2add.disk1: UUID="106977b5-87bd-4112-9810-73f3e043df2b" TYPE="swap"

Pour les partition ext4, blkid nous donne pas le UUID. Il faut que la partition soit mountée pour utiliser lsblk -o +uuid, puis grep le point de montage.

root@versa:/mnt/rm12100# mount -o offset=1048576 /dev/data/auth-dev-rm12100 /mnt/rm12100/
root@versa:/mnt/rm12100# lsblk -o +uuid | grep /mnt
loop0                                                              7:0    0    14G  0 loop  /mnt/rm12100 f9d54c4c-21cc-4d6e-9e03-87451bd8835b

faire un fsck d'un volume d'une instance (non drbd)

Identifier et mounter le volume pour analyser la situation

root@vania:~# gnt-instance info fmas0.koumbit.net
 Disks:
    - disk/0: plain, size 28.0G
      access mode: rw
      logical_id: data/9525b33a-94bc-47e2-b27f-ec0ea9794369.disk0
      on primary: /dev/data/9525b33a-94bc-47e2-b27f-ec0ea9794369.disk0 (253:24)
      name: None
      UUID: d30c3440-cf66-45bd-958a-7c3bb0ef93af
root@vania:~# instance=fmas0.koumbit.net
root@vania:~# gnt-instance shutdown $instance
root@vania:~# disk=$(gnt-instance activate-disks "$instance" | cut -d ":" -f 3)
root@vania:~# echo $disk
/dev/data/9525b33a-94bc-47e2-b27f-ec0ea9794369.disk0 /dev/data/4971d4ef-348f-451a-8a29-8a9a49ed9c8e.disk1
root@vania:~# ssh valerie
root@valerie:~# disk="/dev/data/9525b33a-94bc-47e2-b27f-ec0ea9794369.disk0 /dev/data/4971d4ef-348f-451a-8a29-8a9a49ed9c8e.disk1"
root@valerie:~# kpartx -av $disk | cut -d " " -f 3
data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1
# parted /dev/data/9525b33a-94bc-47e2-b27f-ec0ea9794369.disk0
GNU Parted 3.2
Using /dev/dm-24
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Linux device-mapper (linear) (dm)
Disk /dev/dm-24: 30,1GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags:

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  30,1GB  30,1GB  primary  ext4         boot
(parted) q
root@valerie:~# mount /dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1 /mnt/

On peut bien voir les fichiers sur le fs donc, on n'est pas complètement perdu

vérification du système de fichier

root@valerie:~# umount /mnt
root@valerie:~# e2fsck -f  /dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1
e2fsck 1.42.12 (29-Aug-2014)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
l'i-noeud 262641 (/usr/share/zoneinfo/right/Africa/Ouagadougou) a un mode invalide (0136743).
Effacer<o>? oui
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe

/dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ *****
/dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1 : 133008/1835008 fichiers (0.2% non contigus), 1997546/7339776 blocs
root@valerie:~# e2fsck -f  /dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1
e2fsck 1.42.12 (29-Aug-2014)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
/dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1 : 133008/1835008 fichiers (0.2% non contigus), 1997546/7339776 blocs
root@valerie:~# kpartx -d $disk
root@valerie:~# déconnexion
Connection to valerie closed.
root@vania:~# gnt-instance deactivate-disks "$instance"
root@vania:~# gnt-instance startup "$instance"
Waiting for job 382018 for fmas0.koumbit.net ...

Il y a seulement un fichier de mort, il a été supprimé. On va devoir réinstaller le package

Référence de l'opération : 26910

Réduire la taille d'un volume

N.B. Si c'est un volume DRBD, il faudra transférer en volume plain avant de faire le resize. -- voir #Changer_le_template_des_disques_d.27une_instance.

Attention: prévoir un downtime assez large, le resize peut prendre assez longtemps (jusqu'à 1h30).

En général il y a 3 endoits où le disque doit être manipuler pour réduire la taille:

• retailler le système de fichiers
• retailler la table de partitions sur le disque
• retailler le LVM
• modifier le config ganeti

Basé sur https://groups.google.com/forum/#!topic/ganeti/tTZmOK0r5NM

1. Prendre un backup et assurer que les backups sont à jour. Il n'est pas possible de prendre un snapshot LVMs dans ces cas

2. Arrêter le VM:

   gnt-instance stop example.koumbit.ent

3. Prender en note le UUID et path de disque:

   gnt-instance info example.koumbit.net

4. Activer les disques pour qu'on puisse les modifier sur leur dom0:

   gnt-instance activate-disks example.koumbit.net

5. Checker si la disque est dans le nouveau format (wrapped dans une 'disque'), ou le système de fichier directe (plus commun avec les vieilles VMs importé de Xen):

   e2fsck /dev/data/XXXXXX.disk0

   • Dans le cas d'un erreur, c'est probablement le premier cas. Verifier avec fdisk /dev/data/XXXXXX.disk0 que ça contient une table de partition. Procèder au "Procédure disque 'wrapped' avec une table de partition"

   • Dans le cas il n'y a pas d'erreur, c'est probablement le système de fichiers directe. Procèder au "Procédure système de fichiers directe"

Procédure disque "wrapped" avec une table de partition

Ici on a besoin de retailler à la fois le FS imbriqué et la table de partition et la LVM.

• Partir un tmux ou screen

• Identifier le padding sur la disque:

  fdisk /dev/data/XXXXX.disk0
  
  Command (m for help): p
  Disk /dev/data/ffaa5c3f-6027-4131-b7ce-c36933a2313f.disk0: 355 GiB, 381178347520 bytes, 744488960 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
  Disklabel type: dos
  Disk identifier: 0x586fe072
  
  Device                                                 Boot Start       End   Sectors  Size Id Type
  /dev/data/XXXXX.disk0p1       2048 744488959 744486912  355G 83 Linux

  • Dans ce cas, il ya 2048 secteurs au début d'la disque. En haut, chaque secteur est indiqué pour être 512 bytes, donc on a 1Mo de padding.
  • Si on fait le calcul de "Sectors" / 2 / 1024 on aura la taille en Mo de système de fichiers (ce qui est /dev/xvdaX sur la VM). Dans l'example, c'est 363519Mo + 1Mo de padding == 363520Mo
  • Garder le padding en tête pour le retaille du LVM plus tard
• Rapetisser la FS

  • Activer la partition de /dev/data/XXXXX.disk0 avec kpartx:

    kpartx -av /dev/data/XXXXX.disk0 | cut -d ' ' -f 3

  • Verifier le système de fichiers:

    e2fsck -f /dev/mapper/XXXXX.disk0p1

  • Resize:

    resize2fs -p /dev/mapper/XXXXX.disk0p1 337920M

• Modifier la table de partitions sur "XXXXX.disk0":

  fdisk /dev/data/XXXXX.disk0
  Command (m for help): d
  Selected partition 1
  Partition 1 has been deleted.
  
  Command (m for help): n
  Partition type
     p   primary (0 primary, 0 extended, 4 free)
     e   extended (container for logical partitions)
  Select (default p): p
  Partition number (1-4, default 1):
  First sector (2048-744488959, default 2048):
  Last sector, +sectors or +size{K,M,G,T,P} (2048-744488959, default 744488959): +337920M
  
  Created a new partition 1 of type 'Linux' and of size 330 GiB.
  Partition #1 contains a ext4 signature.
  
  Do you want to remove the signature? [Y]es/[N]o: N   
  Command (m for help): w
  The partition table has been altered.
  Calling ioctl() to re-read partition table.
  Re-reading the partition table failed.: Invalid argument
  
  The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).

• Déactiver les partitions de la disque avec kpartx:

  kpartx -d /dev/data/XXXXX.disk0

• Re-tailler le LVM:

  lvresize --size 337921M /dev/data/XXXX.disk0

  • Note: La taille de la LVM est 1Mo plus grand que la taille qu'on donne à /dev/xvdX afin de conserver le padding de 1Mo dans l'example. Si votre padding est différent au début, modifier la taille en conséquence.

• Faire la proécdure "Modifier les metadonnées / config Ganeti"
• Déactiver les disques "gnt-instance deactivate-disks xxxxx.koumbit.net"
• Repasser les disques en DRBD si on avait changé pour plain
• Redémarrer la VM

Procédure système de fichiers directe

1. Retailler les affaires sur le dom0:

   ssh dom0.koumbit.net
   tmux # or screen, but this can take a long time!
   # Backup - NEVERMIND - cannot resize lvm's that have snapshots. make sure backups are done through backupninja etc.
   # lvcreate --size=30G --snapshot --name example-pre-resize data/XXXXX.disk0
   # Force check
   e2fsck -f /dev/data/XXXXXX.disk0
   # Resize
   resize2fs -p /dev/data/XXXXXX.disk0 100G # Set the new size
   # Resize partition table
   fdisk /dev/data/XXXXXX.disk0 # follow prompts
   # Resize lvm
   lvresize --size 100G /dev/data/XXXXXX.disk0
   

2. Faire la procédure "Modifier les metadonnées / config Ganeti"

3. Déactiver les disques:

   gnt-instance deactivate-disks xxxxx.koumbit.net

4. Repasser les disques en DRBD si on avait changé pour plain
5. Booter la VM

   1. J'ai du appliquer le fix: https://wiki.koumbit.net/XenMaintenance#unable_to_find_partition_containing_kernel#-#0 pour faire booter la

machine après

Modifier les metadonnées / config Ganeti

Basé sur https://github.com/ganeti/ganeti/wiki/Editing-the-Configuration

1. Arrêter de surveiller les VMs:

   gnt-cluster watcher pause 6h
   

2. Arrêter d'accepter des nouveaux jobs:

   gnt-cluster queue drain
   

3. Assurer que les jobs en cours terminent:

   gnt-job list # Should all be done / failed / etc.
   
   

4. Arrêter le service ganeti sur le node master:

   service ganeti stop
   

5. Faire une copie de la config:

   cp /var/lib/ganeti/config.data /root/ganeti-config.data.DATEMACHIN.bak
   

6. Get a readable copy of the config:

   /usr/lib/ganeti/tools/fmtjson < /var/lib/ganeti/config.data > /root/ganeti-config.data.readable
   

7. Faire les modifications nécessaires: trouver le host puis l'ID du disque, et modifier "size" dans la section correspondant à l'ID du disque. Attention, la taille devrait être identique à celle du LV, sinon la VM ne bootera pas correctement (voir 38283). Pour vérifier la taille du LV, rouler cette commande sur le primary node pour le disque correspondant: lvs --units m | grep 2c36294b

8. Copier le config:

   cp /root/ganeti-config.data.readable /var/lib/ganeti/config.data
   

9. Re-démarrer ganeti sur le master:

   service ganeti start
   

10. Commencer d'accepter les nouveaux jobs:

    gnt-cluster queue undrain
    

11. Re-distribuer la config si le cluster a plus qu'un node:

    gnt-cluster redist-conf
    

12. Verifier la configuration:

    gnt-cluster verify
    

13. Assurer que tes modifs sont visibles, (eg. pour la taille d'une disque):

    gnt-instance info xxxxx.koumbit.net
    

14. Recommencer le watch:

    gnt-cluster watcher continue
    

Augmenter la taille d'un volume

Option A: gnt-instance grow-disk (plain et DRBD)

1. Identifier les disques:

   gnt-instance info foo.koumbit.net
   ...
     Disks:
       - disk/0: plain, size 14.0G
         access mode: rw
         logical_id: data/2146aafa-8bbe-4496-99d8-07a105886a92.disk0
         on primary: /dev/data/2146aafa-8bbe-4496-99d8-07a105886a92.disk0 (253:2)
         name: None
         UUID: c3c2265d-f6bf-4694-a8f8-669ce47bd43a
       - disk/1: plain, size 1.0G
         access mode: rw
         logical_id: data/be090847-fa1b-4579-b683-00142ea41f04.disk1
         on primary: /dev/data/be090847-fa1b-4579-b683-00142ea41f04.disk1 (253:3)
         name: None
         UUID: 4c5b473e-af39-4f96-8e55-f7a1c5df1fcb

2. Augmenter la taille des disques (n.b. le VM peut-être ON pour cet étape):

   • N.B. si les disques sont en DRBD, il va y avoir une alerte critique dans icinga car les deux disques ne seront pas en sync pendant un petit bout: penser à mettre un downtime sur le disque de la machine (les disques des VPS ne sont normalement pas en DRBD)

   gnt-instance grow-disk foo.koumbit.net 0 14g # grow main disk by 14GB
   gnt-instance grow-disk foo.koumbit.net 1 1g # grow swap disk by 1GB
   
   

Avec des disques en DRBD de 470G, il y a eu un sync après le grow-disk de 1h20 (2h pour 570G, donc peu moins de 5G/mn). Il faut le prévoir quand on planifie notre intervention.

1. Re-démarrer la VM:

   gnt-instance reboot foo.koumbit.net
   

Notez que parfois la VM affiche un message d'erreur, dit qu'elle ne s'est pas arrêtée mais a vraiment arrêté et ne redémarre pas. On a un message d'erreur du style :

Could not reboot instance: Failed to stop instance 'foo.koumbit.net': Failed to send command 'system_powerdown' to instance 'foo.koumbit.net', reason 'exited with exit code 1' ... ... ... : No such file or directory

Il faut lui faire un gnt-instance start foo.koumbit.net pour la faire redémarrer.

1. Sur la node qui héberge l'instance, donc il faut ssh vers là en premier (ex.: pour wpdev0.k.n, le lvcreate doit se faire sur varan.k.n): Prendre un snapshot du LVM sur la node au cas où..

      lvcreate -L1G -s -n foo_snap_202X_03_06 /dev/data/2146aafa-8bbe-4496-99d8-07a105886a92.disk0
   

   • Si on est en drbd, ça complique ici. Ça reste à analyse de comment faire des snapshots de lvm sur du drbd.

   On peut faire l'agrandissement online en suivant VserverService/ResizeDisks#Augmenter_la_taille_d.27une_disque_virtuel au lieu de la procédure plus bas.

2. Agrandir la partition principale (Ext3 ou Ext4 seulement)

   • Réf: https://askubuntu.com/questions/24027/how-can-i-resize-an-ext-root-partition-at-runtime

   • Dans la VM, on a besoin de re-créer la table de partitions

     • Pour augmenter le volume d'un instance à plus de +2TB, vous allez devoir:

       • changer le type de table de partition de msdos->gpt (option g dans fdisk)

       • créer une partition pour le "bios" à la fin du volume (1MB fait l'affaire) (type de partition "bios boot" type 4 dans fdisk)
       • faire un dpkg-reconfiguration grub-pc

       Ici, on assume que vous allez faire l'opération sur un cluster avec ganeti/kvm qui a des instances avec grub d'installé, c'est pas le cas avec ganeti/xen

     • Ouvrir fdisk

       fdisk /dev/vda # ou /dev/xvda sous ganeti/xen
       
       

     • Lister les partitions pour avoir une référence visible:

       p
       # ceci affichera quelquechose comme:
       # Disk /dev/vda: 14 GiB, xxx bytes, xxx 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
       # Disklabel type: dos
       # Disk identifier: 0x00000000
       #
       # Device     Boot Start      End  Sectors Size Id Type
       # /dev/vda1       2048 58720255 58718208  28G 83 Linux

     • Supprimer la partition qu'on veut aggrandir:

       d
       # Choisir la partition par numéro
       1

       Si à cette étape-ci on obtient un message comme le suivant, ça veut dire qu'on est dans une vieille VM qui n'a pas de table de partitions (e.g. tout le LVM est un volume ext4). On doit alors passer à la méthode option B après la commande grow-disk.

       Command (m for help): d
       No partition is defined yet!
       Could not delete partition 1

     • Créer une nouvelle partition:

       n
       # Choisir le type de partition: primaire
       p
       # Choisir le numéro de partition
       1
       # Choisir la début, 2048 par défaut. Fié à informations affiché par 'p'
       2048
       # Choisir la fin, la valeur par défaut suffiera dans les cas simples
       58720255
       # Il y aura un warning que une signature ext4 est présent. est-ce qu'on veut le détruire? non. gardes le
       n
       # Sauvegarder les changements (ça quitte automatique)
       w

   • Re-charger la table à partitions. Il y a trois façons (ces outils ne sont pas disponibles sur tous les serveurs) :
     • partprobe (est dans le package Debian "parted")

     • kpartx (e.g. kpartx -u /dev/xvda1)

     • redémarrer la vm

On a agrandi la partition, mais pas le filesystem.

1. Use online resizing for ext3/ext4:

   resize2fs /dev/vda1 # ou /dev/xvda1 sous ganeti/xen
   
   

1. Enlèver le snapshot LVM de backup (encore une fois sur la node du cluster, ex.: varan.k.n pour wpdev0.k.n)

   lvremove /dev/data/foo-snap_202X_XX_XX
   

2. Aggrandir le swap (on le fait rarement, d'habitude on n'agrandit que le disque principal)

   1. Checher l'information sur le swap actuel:

      swapon -s
      # Filename                                Type            Size    Used    Priority
      # /dev/xvdb                               partition       1048572 0       -1

   2. Désactiver le swap

      swapoff -v /dev/xvdb
      

   3. Re-créer la disque swap (la partition / disque / fichier au complete est pris par défaut):

      mkswap /dev/xvdb
      

   4. Re-activer le swap

      swapon -v /dev/xvdb
      

   5. Checker le UUID de la disque swap:

      lsblk -no UUID /dev/xvdb
      

   6. Modifier /etc/fstab si nécessaire

Option B: Procédure LVM

Similaire à l'inspection des disques de l'externe (ci-bas), mais il faut aussi utiliser "grow-disks" et "parted" pour redimensionner les partitions.

Pour a swap, mettons que vous vous faites demander de passer de chiquito a mediano, vous pouvez faire la même proc, sauf en faisant mkswap /dev/mapper/DISK1 , sauf que le UUID de la swap va changer, j'ai pas trouvé comment le faire clean.

# gnt-instance info palantetech2.koumbit.net
[...]
  Disks:
    - disk/0: plain, size 56.0G
      access mode: rw
      logical_id: data/978d4ec0-225b-4e4e-85c4-3ff814dcd2e5.disk0
      on primary: /dev/data/978d4ec0-225b-4e4e-85c4-3ff814dcd2e5.disk0 (253:18)
      name: None
      UUID: ccbd71c1-631d-4428-aeb9-b595be3b149a
    - disk/1: plain, size 4.0G
      access mode: rw
      logical_id: data/08498c6f-2196-4105-9c3f-8d386bb7f7c0.disk1
      on primary: /dev/data/08498c6f-2196-4105-9c3f-8d386bb7f7c0.disk1 (253:19)
      name: None
      UUID: 1db5f2ff-efe9-414a-8fbd-8627b93dbc14

# gnt-instance grow-disk palantetech2.koumbit.net 0 30G
Wed Jul 29 14:32:40 2015 Growing disk 0 of instance 'palantetech2.koumbit.net' by 30.0G to 86.0G
Wed Jul 29 14:32:41 2015  - INFO: Waiting for instance palantetech2.koumbit.net to sync disks
Wed Jul 29 14:32:41 2015  - INFO: Instance palantetech2.koumbit.net's disks are in sync

# instance=palantetech2.koumbit.net
# gnt-instance shutdown "$instance"
Waiting for job 90687 for palantetech2.koumbit.net ...

# disk=$(gnt-instance activate-disks "$instance" | cut -d ":" -f 3)
# echo $disk
/dev/data/978d4ec0-225b-4e4e-85c4-3ff814dcd2e5.disk0 /dev/data/08498c6f-2196-4105-9c3f-8d386bb7f7c0.disk1

• on doit se rendre sur la node qui contient la VM

# ssh node1.koumbit.net 

# disk="/dev/data/978d4ec0-225b-4e4e-85c4-3ff814dcd2e5.disk0 /dev/data/08498c6f-2196-4105-9c3f-8d386bb7f7c0.disk1"
# lvcreate -n data/palantetech2-snap -L4G  -s data/978d4ec0-225b-4e4e-85c4-3ff814dcd2e5.disk0
  Logical volume "palantetech2-snap" created
# kpartx -av $disk | cut -d " " -f 3
data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1
# parted /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0

GNU Parted 2.3
Using /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) p
Model: Linux device-mapper (snapshot-origin) (dm)
Disk /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0: 92,3GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start   End     Size    Type     File system  Flags
 1      1049kB  60,1GB  60,1GB  primary  ext4         boot

(parted) unit
Unit?  [compact]? b
(parted) p
Model: Linux device-mapper (snapshot-origin) (dm)
Disk /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0: 92341796864B
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start     End           Size          Type     File system  Flags
 1      1048576B  60129542143B  60128493568B  primary  ext4         boot

(parted) rm 1 

Note here that the end value is the full size of the disk MINUS 1 byte from the start of the above 'p' command

(parted) mkpart p ext4 1048576B 92341796863B
(parted) quit
Information: You may need to update /etc/fstab.

# partprobe
# e2fsck -f /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1
e2fsck 1.42.5 (29-Jul-2012)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
/dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1 : 485526/3670016 fichiers (0.1% non contigüs), 10670575/14679808 blocs

resize2fs -p /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1
resize2fs 1.42.5 (29-Jul-2012)
En train de redimensionner le système de fichiers sur /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1 à 22544128 (4k) blocs.
Le système de fichiers /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1 a maintenant une taille de 22544128 blocs.

e2fsck -f /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1
[...]
kpartx -d $disk

lvremove data/palantetech2-snap
Do you really want to remove active logical volume palantetech2-snap? [y/n]: y

Erreurs rencontrées :

• Le volume logique ( snap ) ne voulait pas se supprimer pour cause : utilisé par autre device

  • on vérifie les blocs disponibles lsblk

  • On roule kpartx -d leblocutilisé

  • on relance lvremove data/palantetech2-snap

• on revient sur le master du cluster

logout

• On reactive la machine

# gnt-instance deactivate-disks "$instance"
# gnt-instance startup "$instance"
Waiting for job 90694 for palantetech2.koumbit.net ...

Changer le template des disques d'une instance

Avec ganeti, il est possible de changer le template de disque utilisé pour passer de plain à drbd ou l'inverse.

Pour ça, il faut que la VM soit offline, donc on doit prévoir des courts downtimes pour faire les changements de templates.

Une instance peut avoir un seul template de disques, donc soit tous ses disques sont plain, soit tous ses disques sont en drbd.

De plain à DRBD

gnt-instance shutdown foo.koumbit.net
gnt-instance modify -t drbd -n NEW_SECONDARY --no-wait-for-sync foo.koumbit.net

Prendre qq secondes au moins pour vérifier l'état des disques.

Un nouveau device drbd apparaîtra dans la liste et on devrait voir que c'est en train de synchroniser:

cat /proc/drbd

C'est terminé, on peut repartir l'instance:

gnt-instance start foo.koumbit.net

De DRBD à plain

Pour faire le chemin inverse, on fait exactement la même chose et ici il n'y a même pas question d'attendre après un sync donc la commande est plus simple:

gnt-instance shutdown foo.koumbit.net
gnt-instance modify -t plain foo.koumbit.net
gnt-instance start foo.koumbit.net

c.f.: http://docs.ganeti.org/ganeti/2.15/html/admin.html#conversion-of-an-instance-s-disk-type

Prendre un snapshot d'une instance

1. Lister l'info:

   gnt-instance info foo.koumbit.net

2. Se connecter sur le node qui héberge l'instance:

   ssh X.koumbit.net

3. Créer le snapshot:

   lvcreate --size 28G --snapshot --name foo0-snapshot-description data/2146aafa-8bbe-4496-99d8-07a105886a92.disk0

4. Après ça, on peut mounter le snapshot si on veut avoir accès aux fichiers, sauf qu'un simple mount ne marchera pas. Pour mount un snapshot, il faut ajouter un offset pour la partition contenue dans le snapshot.

   1. Trouver le offset:

      fdisk -l /dev/data/foo0-snapshot-description
      Disk /dev/data/fb580070-ce7c-4c19-9e95-a76d489368bf.disk0: 14 GiB, 15032385536 bytes, 29360128 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
      Disklabel type: dos
      Disk identifier: 0xf131daf5
      
      Device                                                 Boot Start      End  Sectors Size Id Type             
      /dev/data/fb580070-ce7c-4c19-9e95-a76d489368bf.disk0p1 *     2048 29360127 29358080  14G 83 Linux

   2. On multiplie le secteur où commence la partition (Start, ici 2048) par le nombre de bytes par secteur (Sector size, ici 512). Pour l'exemple ci-haut, la partition commence au offset 1048576

   3. On mount avec l'option -p offset=xxx:

      mount -o offset=1048576 /dev/data/foo0-snapshot-description /mnt/

Restaurer à partir d'un snapshot d'une instance

1. Fermer la VM:

   gnt-instance shutdown foo.koumbit.net

2. Se connecter sur le node qui héberge l'instance:

   ssh X.koumbit.net

3. Remplacer le disque avec le snapshot:

   lvconvert --merge data/foo0-snapshot-description

   • Note: Le snapshot va être enlèver

4. Re-créer la snapshot:

   lvcreate --size 28G --snapshot --name foo0-snapshot-description data/2146aafa-8bbe-4496-99d8-07a105886a92.disk0

5. Retourner sur le cluster master et démarrer l'instance:

   gnt-instance start foo0.koumbit.net

retirer un volume (disque) d'une instance

gnt-instance modify --disk 1:remove

ajouter un nouveau volume (disque) à une instance

Si tu veux avoir un deuxième disque dans VM au lieu de grossir le 1er disque, tu peux. Pis, le plus hot, c'est que tu peux ajouter un disque sur un autre volume group (vg dans lvm), par exemple sur un vg qui est composé de HDD.

1. Checker quels disques sont présents:

   gnt-instance info asdf.koumbit.net

2. Ajouter un disque avec nouveau disque:

   • sur le vg défini dans le gnt-cluster (généralement nommé 'data')

     gnt-instance modify --disk add:size=30G asdf.koumbit.net

   • sur un autre vg que celui défini dans le gnt-cluster (p.ex. un vg pour les backups sur hdd) et que l'on aura préalablement créé avec pvcreate sur la node. Ici, le vg est nommé 'backup'

     gnt-instance modify --disk add:vg=backup,size=15T asdf.koumbit.net

3. Redémarrer la vm:

   gnt-instance shutdown asdf.koumbit.net
   gnt-instance start asdf.koumbit.net

4. Configurer le disque côté machine virtuelle (eg. créer une partition, etc...), eg.
   • Si c'est une VM sur Xen, il semble qu'il faut créer une partition avant. Ce n'est pas nécessaire avec KVM.

   • Si VM sous Xen:

     fdisk -l # avoir les infos
     # disons qu'on travail sur /dev/xvdc
     fdisk /dev/xvdc
     Commande: n # nouvelle partition
     Sélection: p # partition primaire
     Numéro: 1
     Premier secteur: <retour> # par défaut
     Dernier secteur: <retour> # par défaut
     
     Commande: w # faire les changements
     
     # format and mount
     mkfs.ext4 /dev/xvdc1
     cat '/dev/xvdc1 /var/aegir/backups ext4 defaults 0 0' >> /etc/fstab
     mount /dev/xvdc1 /var/aegir/backups
     # make sure everything is okay
     reboot

   • Si VM sous KVM, créer directement le filesystem sur la nouvelle partition et l'ajouter au fstab puis mounter (changer le mount point au besoin):

     mkfs.ext4 /dev/vdX
     echo "UUID=$(blkid | grep /dev/vdX | cut -d " " -f 2 | cut -d "=" -f 2 | sed 's/"//g')   /srv/BACKUP     ext4    defaults        0       1" >> /etc/fstab
     mount -a
     reboot  # probablement une bonne idée de tester que tout revient

Monter les disques d'un domU dans le dom0

Tout d'abord il faut s'assurer de fermer la VM et activer ses disques:

instance=XXX.koumbit.net
gnt-instance shutdown "$instance"
gnt-instance activate-disks "$instance"

Ensuite il faut se rendre sur la machine primaire de la VM (e.g. le nom de node dans l'output de la sous-commande activate-disks qui ressemble à qqch comme node3:disk/0:/dev/mapper/...)

Pour toutes les nouvelles VMs, les disques sont configurés d'une manière particulière dans les domU: le volume créé pour la VM contient plusieurs partitions! Il faut donc passer par certains détours pour accéder aux fichiers. pour chaque chemin sous /dev/mapper dans l'output de la sous-commande activate-disks plus haut:

disk=/dev/mapper/<uid>.disk[01]
mount /dev/mapper/$(kpartx -av "$disk" | cut -d " " -f 3) /mnt
chroot /mnt
# do stuff in the VM here
exit
umount /mnt/
kpartx -d "$disk"

Dans le cas des VMs qui auraient été importées d'un ancien setup xen, les fichiers de disques ne contiennent p-e qu'une seul partition par "disque". Dans ce cas on peut monter la partition directement:

mount /dev/mapper/<uid>.disk[01] /mnt
chroot /mnt
# do stuff in the VM here
exit
umount /mnt/

Une fois terminé, ne pas oublier de redémarrer la VM à partir du master du cluster:

gnt-instance deactivate-disks "$instance"
gnt-instance start "$instance"

Voir: http://docs.ganeti.org/ganeti/2.15/html/admin.html#accessing-an-instance-s-disks

Si vous importez les données d'une machine physique

rm -fr /etc/udev/conf.d/70-persistent-*
vi /etc/network/interfaces # you wanna set the new ip in there
vi /etc/crypttab # remove all entries that won't be needed anymore (probably all)
vi /etc/mdadm/mdadm.conf # comment out all the lines, we won't be using raid devices anymore
rm -fr /boot/grub # Destroy, for better rebuilding later

Suivre ensuite les instructions à: https://wiki.koumbit.net/XenMaintenance#pygrub

Il faut éditer aussi inittab. pour ce fichier là il faut:

• mettre en commentaire toutes les entrées console série (normalement T0 ou T1)

• mettre en commentaire toutes les entrées getty sauf celle qui commence par "1" au début de la ligne. Pour cette entrée, on veut changer "tty1" en "hvc0"

vi /etc/inittab

Une fois que la VM est bootée, on peut corriger quels disques sont utilisés pour quoi.

• changer le root fs pour utiliser "UUID=..." au lieu de /dev/mapper/... ou /dev/sdX

• ajouter la partition swap (avec "UUID=..." aussi)
• retirer ou mettre en commentaire toutes les partitions qui n'existent pas

ls -l /dev/disk/by-uuid
vim /etc/fstab

Troubleshooting

kpartx -av donne une erreur "device or resource busy"

Première chose: as-tu bien fait gnt-instance activate-disks $instance? Sinon, check d'abord si si voit le même LV 2x (tu veux surtout voir si ya ses partitions) avec dmsetup ls. Si une de ses partition est présente, c'est qu'il est déjà mapped. Donc, essaie de le mounter. Si ça marche pas, il faut chercher plus loin.

Problème #1: le disk est mapped, mais pas mountable

Peut-être qu'il a déjà été mapped, mais que c'est resté collé pis que là, c'est corrompu. On va donc s'assurer que rien roule dessus avant d'effacer le mapping.

# Étape 1: trouver l'adresse du disque (changez 'bb54' pour un pattern qui identifie le disque de la VM qu'on essaie de mapper)
dmsetup ls | grep grep bb54
data-bb54a656--63d4--4300--9ce2--e411926f6b96.disk0     (253:4)
data-bb54a656--63d4--4300--9ce2--e411926f6b96.disk0p1     (253:15)

# Étape 2: lister les processus qui pourraient rouler sur le device
root@monserveur:/# lsof 2>/dev/null | grep 253,15

# Étape 3: voir si on peut fermer les processes d'une façon clean.
# Étape 4: veut si on peut killer les processes

# Quand pu rien roule sur le device: 
# On veut effacer le mapping en utilisant le nom 
dmsetup remove data-bb54a656--63d4--4300--9ce2--e411926f6b96.disk0p1

Problème #2: un fuck avec DRBD

Voir (45093-22 et 28288-50) Ça se peut que la VM du device qu'on veut mount soit configurée en DRBD, ou qu'elle l'ait déjà été pis que les devices ont restés collés.

# Check s'il existe des device files pour des disque DRBD
root@monserveur:/home/hubide/rm45093$ ls /dev/drbd* -lh
brw-rw---- 1 root disk 147, 0 Aug 24 07:38 /dev/drbd0

# On veut checker si ces disques sont mapped
root@monserveur:/home/hubide/rm45093$ dmsetup ls | grep drbd
data-testdrbd   (253:26)
data-testdrbd--meta     (253:27)
data-testdrbd2_meta     (253:41)
data-testdrbd2  (253:40)

# Dans ce cas, on peut juste voir qu'il y a eu des tests.
# Comme il n'y a pas de map, on peut présumer que rien roule dessus pis maper le disque

# Si on voit un mapping, checker les process comme dans le problème #1. Si ta VM est bien shutdown, il ne devrait rien avoir comme process. Si on voit des process, c'est que c'est pas une VM shutdown. On va pas essayer de mapper ou mounter ces disques là, ni de tuer les process.
# À noter qu'une VM up qui est up et qui a un device DRDB (configuré comme ça ou avec un truc resté collé) n'aura pas nécessairement de mapping. 

# S'il y a un mapping, c'est probablement pas ta VM non plus, mais je me trompe peut-être.

# Quand on trouve un disque pas de mapping ou de process
root@monserveur:/home/hubide/rm45093$ kpartx -av -p- /dev/drbd0
add map drbd0-1 (253:49): 0 465565696 linear 147:0 2048

# On mount et on check si c'est le device que la VM à laquelle on veut accéder
root@monserveur:/home/hubide/rm45093$ mount /dev/mapper/drbd0-1 monserveur-nc-test/                                              
root@monserveur:/home/hubide/rm45093$ cat /monserveur-nc-testetc/hostname
monserveur-nc-test.koumbit.net

# On fait ce qu'on voulait faire, pis on supprime le mapping
root@monserveur:/home/hubide/rm45093$ umount monserveur-nc-test
root@monserveur:/home/hubide/rm45093$ kpartx -dv -p- /dev/drbd0
del devmap : drbd0-1
root@monserveur:/home/hubide/rm45093$ gnt-instance deactivate-disks monserveur-nc-test.koumbit.net

Créer une image d'une VM

Sur le master:

• Fermer la VM: gnt-instance shutdown exemple.koumbit.net

• Trouver sur quelle node est hébergé la VM: gnt-instance list | grep exemple.koumbit.net

• Trouver le path du disque:

  • gnt-instance info exemple.koumbit.net

    ...
      Disks: 
        - disk/0: plain, size 14.0G
          access mode: rw
          logical_id: data/01b93ad7-0c0c-4799-b352-23ba6a4000ec.disk0
          on primary: /dev/data/01b93ad7-0c0c-4799-b352-23ba6a4000ec.disk0 (253:24)
          name: None
          UUID: f071f102-6229-437c-a71a-f0ce55661950
        - disk/1: plain, size 1.0G
          access mode: rw
          logical_id: data/a059f227-2978-4353-bade-9c72596486df.disk1
          on primary: /dev/data/a059f227-2978-4353-bade-9c72596486df.disk1 (253:25)
          name: swap
          UUID: 19d5313a-7180-4c89-bced-fb9304f64f1a

  • Dans l'exemple ci-haut, le path est /dev/data/01b93ad7-0c0c-4799-b352-23ba6a4000ec.disk0

Sur la node:

• Pour connaitre les format disponible:

  qemu-img --help | grep "Supported formats"

• Créer l'image (-p pour voir le progrès. on remplace [path] par le path du disque de la VM trouvé plus haut sur le master et on remplace [format] par le format désiré comme output:

  qemu-img convert -p [path] -O [format] /tmp/exemple.koumbit.net.img

Troubleshooting

Ajouter un gros volume (disque) donne 'Failure: prerequisites not met for this operation'

1. Si, comme dans l'exemple ci-bas, on voit violates policy: disk-size/2 value 15728640 is not in range [1024, 1048576], c'est que le disque qu'on ajoute à la VM est plus gros que les policies du cluster ganeti.

2. Exemple d'erreur pour un nouveau volume plus gros que ce que permet le cluster:

   root@rouch:~# gnt-instance modify --disk add:vg=backup,size=15T backup0.bureau.monserveur.net
   Failure: prerequisites not met for this operation:
   error type: wrong_input, error details:
   Instance allocation to group {'name': 'default', 'ndparams': {}, 'diskparams': {}, 'ipolicy': {}, 
   'serial_no': 1, 'alloc_policy': 'preferred', 'networks': {}, 'ctime': 0, 'mtime': 1671045051.5270655, 
   'uuid': '30983cb3-a089-4195-9e1b-e4359474cce2', 'tags': []} (default) violates policy: disk-size/2 
   value 15728640 is not in range [1024, 1048576]

3. Voir GanetiConfiguration pour changer les 'instances policy'

4. Quand c'est fait, ré-essaie d'ajouter ton volume.