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
    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. Prendre un snapshot d'une instance
    6. Restaurer à partir d'un snapshot d'une instance
    7. retirer un volume (disque) d'une instance
    8. ajouter un nouveau volume (disque) à une instance
    9. Monter les disques d'un domU dans le dom0
      1. Si vous importez les données d'une machine physique
    10. Migrer une instance entre cluster (xen->kvm)
      1. Création de l'instance sur le cluster de destination
      2. DÉBUT de l'INTERVENTION
      3. Faire un redémarrage de l'instance d'origine
      4. (De retour sur la destination) Activer le volume pour la destination
      5. Activer la partition
      6. DOWNTIME
      7. Arrêter l'instance d'origine
      8. Activer les volumes de l'instance d'orgine
      9. Activer les partitions sur l'instance d'orgine
      10. Échanger le clé ssh public pour permettre de logguer en root entre les serveurs
      11. faire le transfert des données à partir de la node source
      12. désactiver les partitions et disques sur l'origine
      13. Installer grub
      14. tester
      15. Retirer l'échanger le clé ssh public pour logguer en root entre les serveurs
      16. Supprimer l'instance source
      17. Troubleshooting
        1. Les mounts /dev /proc sont occupés

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

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:~# 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 faudrait pt-être le transferer en volume plain avant de faire le resize. Cf. https://wiki.rg.net/wiki/ShrinkLinuxDisk

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
  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. 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 tes modifications
  8. Copier le config:

    cp /root/ganeti-config.data.readable /var/lib/ganeti/config.data
  9. Re-démarré 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

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

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

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

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

Migrer une instance entre cluster (xen->kvm)

Cette documentation est inspiré de celle de RiseUp https://we.riseup.net/riseup+tech/ganeti#move-an-instance-from-one-cluster-to-another-from

La procédure est applicable autant sur une configuration "plain" ou Drbd.

Création de l'instance sur le cluster de destination

En premier lieu, créer une instance sur le cluster de destination. Les flags importants pour la création sont ceux qui empêche l'instance de démarrer. Pour le reste, la commande ressemble à la création d'une instance normale.

gnt-instance add --no-start --no-ip-check --no-name-check \
 -o debootstrap+default -t plain -n destination-node.koumbit.net \
 --disk 0:size=6G --disk 1:size=1G -B memory=1G,vcpus=1 \
 --net 0:ip=199.58.81.xxx,network=colo1-arin01.koumbit.net \
  <instance>

Note, on veut créer l'instance complète, ça nous permet de nous assurer que l'instance démarre bien et surtout que les partitions sont bien créées. Bien sur on ne veut pas démarrer l'instance cette instance avant de fermer l'autre, s'il partage le même ip.

DÉBUT de l'INTERVENTION

Faire un redémarrage de l'instance d'origine

Ici, ça fait parfois très longtemps que l'instance a été redémarré et c'est pas sur que tous les services remontent correctement. Une redémarrage assure d'avoir le dernier kernel avec les patchs de sécu aussi. On veut donc tester un redémarrage et vérifier que ça fonctionne minimalement.

Quand l'instance d'origine est fermée, c'est le bon moment, pour faire un test de démarrage sur la destination! On veut tester si la création de la vm a bien été sur la destination. Normalement... c'est bon.

(De retour sur la destination) Activer le volume pour la destination

# gnt-instance activate-disks <instance>
destination-node.koumbit.net:disk/0:/dev/data/84b73100-d103-47d0-a777-c5422883b466.disk0
destination-node.koumbit.net:disk/1:/dev/data/d2dc028f-072f-4dce-9069-d68dc10eb67a.disk1

Attention, les disques ont été activé sur la node de destination, il faut donc se déplacer sur celle-ci pour les oppérations qui suivent.

Activer la partition

Trouver la partition avant.

# gnt-node volumes | grep <instance> 
destination-node.koumbit.net /dev/mapper/md2_crypt data 84b73100-d103-47d0-a777-c5422883b466.disk0        6.0G <instance>.koumbit.net
destination-node.koumbit.net /dev/mapper/md2_crypt data d2dc028f-072f-4dce-9069-d68dc10eb67a.disk1        1.0G <instance>.koumbit.net

D'abord se déplacer sur la node où les disques ont été activé

# ssh <destination-node>

Activer la partition

# kpartx -av -p- /dev/data/84b73100-d103-47d0-a777-c5422883b466.disk0
... /dev/mapper/data-84b73100--d103--47d0--a777--c5422883b466.disk0-1

ou en drbd

# kpartx -av -p- /dev/drbd14
# ls -al /dev/mapper/drbd14-1
lrwxrwxrwx 1 root root 8 avr 15 19:52 /dev/mapper/drbd14-1 -> ../dm-37

Elle est bien là:

# ls -alrt /dev/mapper/ | grep data-84b73100--d103--47d0--a777--c5422883b466.disk0-1
lrwxrwxrwx  1 root root       8 jun 28 15:27 data-84b73100--d103--47d0--a777--c5422883b466.disk0-1 -> ../dm-xx

DOWNTIME

Rendu ici, on a préparé les volumes et partitions pour recevoir les données sur la node de destination.

On a testé nos 2 instances autant l'origine que la destination, on fonce pour faire le transfert des données.

On doit procéder à la fermeture de l'instance maintenant pour préparer le transfert de données.

Arrêter l'instance d'origine

# gnt-instance shutdown <instance>

Activer les volumes de l'instance d'orgine

# gnt-instance activate-disks <instance>
<node>:disk/0:/dev/data/e58b9aa0-1195-43ad-8fa4-512052df320b.disk0
<node>:disk/1:/dev/data/16d1d2a0-57ab-4b74-aa41-a0dc1920d6f3.disk1

Activer les partitions sur l'instance d'orgine

ssh vers node et activer la partition

ssh <source-node>
# kpartx -av -p- /dev/data/e58b9aa0-1195-43ad-8fa4-512052df320b.disk0

Échanger le clé ssh public pour permettre de logguer en root entre les serveurs

Ici, vous pouvez choisir de pousser à partir de l'origine vers la destination ou encore de la destination aller chercher les données sur l'origine.

Pour des questions de sécurité on doit être très attentif.

faire le transfert des données à partir de la node source

# dd if=/dev/mapper/data-e58b9aa0--1195--43ad--8fa4--512052df320b.disk0p1 bs=64K | \
 ssh root@destination-node.koumbit.net 'dd of=/dev/mapper/data-84b73100--d103--47d0--a777--c5422883b466.disk0p1 status=progress'
294896+0 enregistrements lus
294896+0 enregistrements écrits
19326304256 octets (19 GB) copiés, 420,043 s, 46,0 MB/s
37746688+0 enregistrements lus
37746688+0 enregistrements écrits
19326304256 bytes (19 GB, 18 GiB) copied, 491,646 s, 39,3 MB/s

désactiver les partitions et disques sur l'origine

ssh <source-node>
# kpartx -dv -p- /dev/mapper/data-e58b9aa0--1195--43ad--8fa4--512052df320b.disk0p1

sur le cluster source

# gnt-instance deactivate-disks <instance>

Installer grub

sur la node de destination

Mounter un chroot

mount /dev/mapper/data-84b73100--d103--47d0--a777--c5422883b466.disk0p1 target
for i in proc dev ; do mount -o bind /$i target/$i ; done
chroot target

Installer les packages de GRUB

apt-get update
apt-get install grub-pc

# La configuration va échouer
# On continue plus loin

  • Attention, ca va vouloir repartir des services dans le chroot ! c'est un calice de chior d'arrêter ca avant de démonter si vous le laissez faire. La dernier fois on du faire un reboot de la node par erreur :,(

Configurer la console??

cat >> /etc/default/grub <<EOG
GRUB_CMDLINE_LINUX="text console=ttyS0,38400n8" 
GRUB_TERMINAL=serial
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=38400 --word=8 --parity=no --stop=1" 
EOG

Faire la configuration du kernet et initramfs

update-initramfs -u -k all
update-grub

Grub n'aime pas fare l'installation avec du LVM et device mapper. Il crois qu'on tente d'installer GRUB à l'intérieur d'une partion, et non dans le MBR On peut outrepasser ça avec loop dev. (voir les scripts de création de ganeti) Il faut toujours être dans le chroot

# losetup --show -f /dev/data/84b73100-d103-47d0-a777-c5422883b466.disk0
/dev/loop1
# grub-install /dev/loop1
Installing for i386-pc platform.
Installation finished. No error reported.
#losetup -d /dev/loop1

On peut fermer le chroot et démonter les partitions:

# exit
# umount target/dev target/proc target
kpartx -d /dev/mapper/data-84b73100--d103--47d0--a777--c5422883b466.disk0p1

tester

Retirer l'échanger le clé ssh public pour logguer en root entre les serveurs

C'est très important!

Supprimer l'instance source

Peut-être qu'on veut commencer par la mettre "offline" mais une fois que la nouvelle instance est démarré, les données de la source sont périmées...

Aussi bien aller supprimer l'instance.

Troubleshooting

Les mounts /dev /proc sont occupés

Utiliser lsof ou fuser pour trouver les process qui sont restés collés à l'intérieur du chroot puis les Fermer

NOTER!! ici, c'est PAS -D mais bien D, ici, /mnt est la base du chroot

# lsof D /mnt

Un autre affaire, ça peut ça soit encore impossible de faire un umount! C'est peut-être un loopX.

GanetiStorageMaintenance (last edited 2020-07-03 19:32:32 by kienan)