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
    
    
  3. Re-démarrer la VM:

    gnt-instance reboot foo.koumbit.net
    
  4. Sur la node de l'instance (donc il faut ssh vers là en premier): 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.

  5. 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:
      • partprobe
      • kpartx (e.g. kpartx -u /dev/xvda1)

      • redémarrer la vm
    • Use online resizing for ext3/ext4:

      resize2fs /dev/vda1 # ou /dev/xvda1 sous ganeti/xen
      
      
  6. Enlèver le snapshot LVM de backup

    lvremove data/foo-snap
    
  7. Aggrandir le swap
    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

  1. Checker quels disques sont présents:

    gnt-instance info asdf.koumbit.net
  2. Ajouter un disque avec un différent

    gnt-instance modify --disk add:size=30G 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.

    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

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

Créer une image d'une VM

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

Sur le master:

Sur la node:

GanetiStorageMaintenance (last edited 2022-09-21 11:43:47 by hubide)