Contents

  1. Gestion des volumes et disques dans ganeti
    1. Identifier les partitions LVM d'une instance
      1. sur le master
      2. sur une node des nodes
      3. Trouver les UUID des partitions tel que vu par les VM
    2. faire un fsck d'un volume d'une instance (non drbd)
      1. Identifier et mounter le volume pour analyser la situation
      2. vérification du système de fichier
    3. Réduire la taille d'un volume
      1. Procédure disque "wrapped" avec une table de partition
      2. Procédure système de fichiers directe
      3. Modifier les metadonnées / config Ganeti
    4. Augmenter la taille d'un volume
      1. Option A: gnt-instance grow-disk (plain et DRBD)
      2. Option B: Procédure LVM
    5. Changer le template des disques d'une instance
      1. De plain à DRBD
      2. De DRBD à plain
    6. Prendre un snapshot d'une instance
    7. Restaurer à partir d'un snapshot d'une instance
    8. retirer un volume (disque) d'une instance
    9. ajouter un nouveau volume (disque) à une instance
    10. Monter les disques d'un domU dans le dom0
      1. Si vous importez les données d'une machine physique
      2. Troubleshooting
        1. kpartx -av donne une erreur "device or resource busy"
    11. Créer une image d'une VM
  2. Troubleshooting
    1. Ajouter un gros volume (disque) donne 'Failure: prerequisites not met for this operation'

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:

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.

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

Il faut se faire payer avant de faire une modification à un contrat existant!

Attention, pour toute modification ou ajout de services à un contract existant, il faut s'assurer d'avoir été payé avant d'appliquer le changement. Voir Réunion SysAdmin 2022-01-11 pour la décision.

Pour que la facture soit traitée rapidement par l'équipe ComptAdmin et envoyée le plus rapidement possible au client, il faut mettre 'ASAP' dans le sujet du ticket RT créé dans la file 'facturation'.

Pour augmenter le volume d'un instance à plus de +1TB, vous allez rencontrer quelques embûches...

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

Pour augmenter le volume d'un instance à plus de +2TB, vous allez devoir quelques étapes de plus. C'est documenté +bas.

Options A a été testé autant sur un setup avec des volumes "plain", purement lvm et aussi sur des volumes avec drbd/lvm (nos setups de Ganeti/Kvm)

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 

    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. 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

      • 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 data/foo-snap
  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

Utilisé la procédure option A, c'est bien plus simple et bien moins de downtime!

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.

Certaines VMs qui datent de l'ère de Xen tout nu avec xen-create-image ont leur disque dans un format un peut différent: les disques sont direct une partition ext4 au lieu d'être un block device dans lequel il y a des partitions.

Donc dans le cas des VMs qui ont été importées par le script lors de l'import massif des instances sur toutes les nodes, il faut sauter par dessus tout l'étape de gestion des partitions avec parted.

Un indice pour si vous êtes dans un tel cas: kpartx ne donne aucun output pour la commande kpartx -av $disk plus bas. 

# 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

# 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 : 

logout

# 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

La technique utilisée ici n'attend pas que les disques soient complètement synchronisés avant de redémarrer la VM. C'est pour pouvoir rendre le downtime le plus court possible (par contre si le disque dur est beaucoup sollicité après le reboot, le resync va être plus long). 

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

Attention, l'action de retirer un disque a comme effet de détruire toutes les données sur le disque retiré (e.g. le VG est effacé).

Donc faites attention à ce que vous écrivez en faisant cette action là! 

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: 

vi /etc/inittab

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

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

Attention, la VM doit être offline pour cette opération!

Sur le master:

Sur la node:

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.

GanetiStorageMaintenance (last edited 2023-09-07 21:55:57 by hubide)