Contents
-
Gestion des volumes et disques dans ganeti
- Identifier les partitions LVM d'une instance
- faire un fsck d'un volume d'une instance (non drbd)
- Réduire la taille d'un volume
- Augmenter la taille d'un volume
- Changer le template des disques d'une instance
- Prendre un snapshot d'une instance
- Restaurer à partir d'un snapshot d'une instance
- retirer un volume (disque) d'une instance
- ajouter un nouveau volume (disque) à une instance
- Monter les disques d'un domU dans le dom0
- Créer une image d'une VM
- Troubleshooting
Gestion des volumes et disques dans ganeti
Identifier les partitions LVM d'une instance
Les partitions lvm ont des noms impossibles à comprendre parce que ce sont des UUID. Pour retrouver facilement quelle partition LVM est associée à quelle instance,
sur le master
# gnt-node volumes
sur une node des nodes
On peut faire afficher les tags des partitions:
root@vania:~# lvs -o+tags LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert LV Tags 0797d85c-ae2f-4c53-b7d6-dcd95fe1b668.disk0 data -wi-ao---- 18.00g originstname+someinstance1.koumbit.net 08123707-dc16-4318-becd-baa648090886.disk1 data -wi-ao---- 2.00g originstname+someinstance2.koumbit.net 0c4f5efa-4691-44d1-98ab-7ff6d0f55fd1.disk0 data -wi-ao---- 90.00g originstname+somevps1.aegirvps.net
Trouver les UUID des partitions tel que vu par les VM
Les partitions LVM contiennent aussi des partitions (généralement une seule). Par exemple, une partition <uuid>.disk0 contient aussi une partition <uuid>.disk0p1. Dans une VM, le fstab n'utilise pas le UUID de la partition LVM, mais de la partition que cette dernière contient.
Pour une partition swap, c'est facile. On peut directement y aller avec blkid avec le device file de la partition
root@versa:/# blkid /dev/mapper/data-a97ef754--417f--4edf--bee3--b64d2b7b2add.disk1 /dev/mapper/data-a97ef754--417f--4edf--bee3--b64d2b7b2add.disk1: UUID="106977b5-87bd-4112-9810-73f3e043df2b" TYPE="swap"
Pour les partition ext4, blkid nous donne pas le UUID. Il faut que la partition soit mountée pour utiliser lsblk -o +uuid, puis grep le point de montage.
root@versa:/mnt/rm12100# mount -o offset=1048576 /dev/data/auth-dev-rm12100 /mnt/rm12100/ root@versa:/mnt/rm12100# lsblk -o +uuid | grep /mnt loop0 7:0 0 14G 0 loop /mnt/rm12100 f9d54c4c-21cc-4d6e-9e03-87451bd8835b
faire un fsck d'un volume d'une instance (non drbd)
Identifier et mounter le volume pour analyser la situation
root@vania:~# gnt-instance info fmas0.koumbit.net Disks: - disk/0: plain, size 28.0G access mode: rw logical_id: data/9525b33a-94bc-47e2-b27f-ec0ea9794369.disk0 on primary: /dev/data/9525b33a-94bc-47e2-b27f-ec0ea9794369.disk0 (253:24) name: None UUID: d30c3440-cf66-45bd-958a-7c3bb0ef93af root@vania:~# instance=fmas0.koumbit.net root@vania:~# gnt-instance shutdown $instance root@vania:~# disk=$(gnt-instance activate-disks "$instance" | cut -d ":" -f 3) root@vania:~# echo $disk /dev/data/9525b33a-94bc-47e2-b27f-ec0ea9794369.disk0 /dev/data/4971d4ef-348f-451a-8a29-8a9a49ed9c8e.disk1 root@vania:~# ssh valerie root@valerie:~# disk="/dev/data/9525b33a-94bc-47e2-b27f-ec0ea9794369.disk0 /dev/data/4971d4ef-348f-451a-8a29-8a9a49ed9c8e.disk1" root@valerie:~# kpartx -av $disk | cut -d " " -f 3 data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1 # parted /dev/data/9525b33a-94bc-47e2-b27f-ec0ea9794369.disk0 GNU Parted 3.2 Using /dev/dm-24 Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: Linux device-mapper (linear) (dm) Disk /dev/dm-24: 30,1GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags: Number Start End Size Type File system Flags 1 1049kB 30,1GB 30,1GB primary ext4 boot (parted) q root@valerie:~# mount /dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1 /mnt/
On peut bien voir les fichiers sur le fs donc, on n'est pas complètement perdu
vérification du système de fichier
root@valerie:~# umount /mnt root@valerie:~# e2fsck -f /dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1 e2fsck 1.42.12 (29-Aug-2014) Passe 1 : vérification des i-noeuds, des blocs et des tailles Passe 2 : vérification de la structure des répertoires l'i-noeud 262641 (/usr/share/zoneinfo/right/Africa/Ouagadougou) a un mode invalide (0136743). Effacer<o>? oui Passe 3 : vérification de la connectivité des répertoires Passe 4 : vérification des compteurs de référence Passe 5 : vérification de l'information du sommaire de groupe /dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1: ***** LE SYSTÈME DE FICHIERS A ÉTÉ MODIFIÉ ***** /dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1 : 133008/1835008 fichiers (0.2% non contigus), 1997546/7339776 blocs root@valerie:~# e2fsck -f /dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1 e2fsck 1.42.12 (29-Aug-2014) Passe 1 : vérification des i-noeuds, des blocs et des tailles Passe 2 : vérification de la structure des répertoires Passe 3 : vérification de la connectivité des répertoires Passe 4 : vérification des compteurs de référence Passe 5 : vérification de l'information du sommaire de groupe /dev/mapper/data-9525b33a--94bc--47e2--b27f--ec0ea9794369.disk0p1 : 133008/1835008 fichiers (0.2% non contigus), 1997546/7339776 blocs root@valerie:~# kpartx -d $disk root@valerie:~# déconnexion Connection to valerie closed. root@vania:~# gnt-instance deactivate-disks "$instance" root@vania:~# gnt-instance startup "$instance" Waiting for job 382018 for fmas0.koumbit.net ...
Il y a seulement un fichier de mort, il a été supprimé. On va devoir réinstaller le package
Référence de l'opération : 26910
Réduire la taille d'un volume
N.B. Si c'est un volume DRBD, il faudra transférer en volume plain avant de faire le resize. -- voir #Changer_le_template_des_disques_d.27une_instance.
Attention: prévoir un downtime assez large, le resize peut prendre assez longtemps (jusqu'à 1h30).
En général il y a 3 endoits où le disque doit être manipuler pour réduire la taille:
- retailler le système de fichiers
- retailler la table de partitions sur le disque
- retailler le LVM
- modifier le config ganeti
Basé sur https://groups.google.com/forum/#!topic/ganeti/tTZmOK0r5NM
- Prendre un backup et assurer que les backups sont à jour. Il n'est pas possible de prendre un snapshot LVMs dans ces cas
Arrêter le VM:
gnt-instance stop example.koumbit.ent
Prender en note le UUID et path de disque:
gnt-instance info example.koumbit.net
Activer les disques pour qu'on puisse les modifier sur leur dom0:
gnt-instance activate-disks example.koumbit.net
Checker si la disque est dans le nouveau format (wrapped dans une 'disque'), ou le système de fichier directe (plus commun avec les vieilles VMs importé de Xen):
e2fsck /dev/data/XXXXXX.disk0
Dans le cas d'un erreur, c'est probablement le premier cas. Verifier avec fdisk /dev/data/XXXXXX.disk0 que ça contient une table de partition. Procèder au "Procédure disque 'wrapped' avec une table de partition"
- Dans le cas il n'y a pas d'erreur, c'est probablement le système de fichiers directe. Procèder au "Procédure système de fichiers directe"
Procédure disque "wrapped" avec une table de partition
Ici on a besoin de retailler à la fois le FS imbriqué et la table de partition et la LVM.
- Partir un tmux ou screen
Identifier le padding sur la disque:
fdisk /dev/data/XXXXX.disk0 Command (m for help): p Disk /dev/data/ffaa5c3f-6027-4131-b7ce-c36933a2313f.disk0: 355 GiB, 381178347520 bytes, 744488960 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x586fe072 Device Boot Start End Sectors Size Id Type /dev/data/XXXXX.disk0p1 2048 744488959 744486912 355G 83 Linux
- Dans ce cas, il ya 2048 secteurs au début d'la disque. En haut, chaque secteur est indiqué pour être 512 bytes, donc on a 1Mo de padding.
- Si on fait le calcul de "Sectors" / 2 / 1024 on aura la taille en Mo de système de fichiers (ce qui est /dev/xvdaX sur la VM). Dans l'example, c'est 363519Mo + 1Mo de padding == 363520Mo
- Garder le padding en tête pour le retaille du LVM plus tard
- Rapetisser la FS
Activer la partition de /dev/data/XXXXX.disk0 avec kpartx:
kpartx -av /dev/data/XXXXX.disk0 | cut -d ' ' -f 3
Verifier le système de fichiers:
e2fsck -f /dev/mapper/XXXXX.disk0p1
Resize:
resize2fs -p /dev/mapper/XXXXX.disk0p1 337920M
Modifier la table de partitions sur "XXXXX.disk0":
fdisk /dev/data/XXXXX.disk0 Command (m for help): d Selected partition 1 Partition 1 has been deleted. Command (m for help): n Partition type p primary (0 primary, 0 extended, 4 free) e extended (container for logical partitions) Select (default p): p Partition number (1-4, default 1): First sector (2048-744488959, default 2048): Last sector, +sectors or +size{K,M,G,T,P} (2048-744488959, default 744488959): +337920M Created a new partition 1 of type 'Linux' and of size 330 GiB. Partition #1 contains a ext4 signature. Do you want to remove the signature? [Y]es/[N]o: N Command (m for help): w The partition table has been altered. Calling ioctl() to re-read partition table. Re-reading the partition table failed.: Invalid argument The kernel still uses the old table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8).
Déactiver les partitions de la disque avec kpartx:
kpartx -d /dev/data/XXXXX.disk0
Re-tailler le LVM:
lvresize --size 337921M /dev/data/XXXX.disk0
Note: La taille de la LVM est 1Mo plus grand que la taille qu'on donne à /dev/xvdX afin de conserver le padding de 1Mo dans l'example. Si votre padding est différent au début, modifier la taille en conséquence.
- Faire la proécdure "Modifier les metadonnées / config Ganeti"
- Déactiver les disques "gnt-instance deactivate-disks xxxxx.koumbit.net"
- Repasser les disques en DRBD si on avait changé pour plain
- Redémarrer la VM
Procédure système de fichiers directe
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
- Faire la procédure "Modifier les metadonnées / config Ganeti"
Déactiver les disques:
gnt-instance deactivate-disks xxxxx.koumbit.net
- Repasser les disques en DRBD si on avait changé pour plain
- Booter la VM
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
Arrêter de surveiller les VMs:
gnt-cluster watcher pause 6h
Arrêter d'accepter des nouveaux jobs:
gnt-cluster queue drain
Assurer que les jobs en cours terminent:
gnt-job list # Should all be done / failed / etc.
Arrêter le service ganeti sur le node master:
service ganeti stop
Faire une copie de la config:
cp /var/lib/ganeti/config.data /root/ganeti-config.data.DATEMACHIN.bak
Get a readable copy of the config:
/usr/lib/ganeti/tools/fmtjson < /var/lib/ganeti/config.data > /root/ganeti-config.data.readable
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
Copier le config:
cp /root/ganeti-config.data.readable /var/lib/ganeti/config.data
Re-démarrer ganeti sur le master:
service ganeti start
Commencer d'accepter les nouveaux jobs:
gnt-cluster queue undrain
Re-distribuer la config si le cluster a plus qu'un node:
gnt-cluster redist-conf
Verifier la configuration:
gnt-cluster verify
Assurer que tes modifs sont visibles, (eg. pour la taille d'une disque):
gnt-instance info xxxxx.koumbit.net
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...
la configuration du cluster peut ne pas permettre, voici ici pour changé la configuration GanetiMaintenance#Changer_la_politique_d.27instance
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)
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
- Augmenter la taille des disques (n.b. le VM peut-être ON pour cet étape):
N.B. si les disques sont en DRBD, il va y avoir une alerte critique dans icinga car les deux disques ne seront pas en sync pendant un petit bout: penser à mettre un downtime sur le disque de la machine (les disques des VPS ne sont normalement pas en DRBD)
gnt-instance grow-disk foo.koumbit.net 0 14g # grow main disk by 14GB gnt-instance grow-disk foo.koumbit.net 1 1g # grow swap disk by 1GB
Avec des disques en DRBD de 470G, il y a eu un sync après le grow-disk de 1h20 (2h pour 570G, donc peu moins de 5G/mn). Il faut le prévoir quand on planifie notre intervention.
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.
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.
- 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.
Use online resizing for ext3/ext4:
resize2fs /dev/vda1 # ou /dev/xvda1 sous ganeti/xen
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
- Aggrandir le swap (on le fait rarement, d'habitude on n'agrandit que le disque principal)
Checher l'information sur le swap actuel:
swapon -s # Filename Type Size Used Priority # /dev/xvdb partition 1048572 0 -1
Désactiver le swap
swapoff -v /dev/xvdb
Re-créer la disque swap (la partition / disque / fichier au complete est pris par défaut):
mkswap /dev/xvdb
Re-activer le swap
swapon -v /dev/xvdb
Checker le UUID de la disque swap:
lsblk -no UUID /dev/xvdb
- 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
- on doit se rendre sur la node qui contient la VM
# ssh node1.koumbit.net
# disk="/dev/data/978d4ec0-225b-4e4e-85c4-3ff814dcd2e5.disk0 /dev/data/08498c6f-2196-4105-9c3f-8d386bb7f7c0.disk1" # lvcreate -n data/palantetech2-snap -L4G -s data/978d4ec0-225b-4e4e-85c4-3ff814dcd2e5.disk0 Logical volume "palantetech2-snap" created # kpartx -av $disk | cut -d " " -f 3 data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1 # parted /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0
GNU Parted 2.3 Using /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0 Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) p Model: Linux device-mapper (snapshot-origin) (dm) Disk /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0: 92,3GB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 60,1GB 60,1GB primary ext4 boot (parted) unit Unit? [compact]? b (parted) p Model: Linux device-mapper (snapshot-origin) (dm) Disk /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0: 92341796864B Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1048576B 60129542143B 60128493568B primary ext4 boot
(parted) rm 1
Note here that the end value is the full size of the disk MINUS 1 byte from the start of the above 'p' command
(parted) mkpart p ext4 1048576B 92341796863B (parted) quit Information: You may need to update /etc/fstab.
# partprobe # e2fsck -f /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1 e2fsck 1.42.5 (29-Jul-2012) Passe 1 : vérification des i-noeuds, des blocs et des tailles Passe 2 : vérification de la structure des répertoires Passe 3 : vérification de la connectivité des répertoires Passe 4 : vérification des compteurs de référence Passe 5 : vérification de l'information du sommaire de groupe /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1 : 485526/3670016 fichiers (0.1% non contigüs), 10670575/14679808 blocs
resize2fs -p /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1 resize2fs 1.42.5 (29-Jul-2012) En train de redimensionner le système de fichiers sur /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1 à 22544128 (4k) blocs. Le système de fichiers /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1 a maintenant une taille de 22544128 blocs.
e2fsck -f /dev/mapper/data-978d4ec0--225b--4e4e--85c4--3ff814dcd2e5.disk0p1 [...] kpartx -d $disk
lvremove data/palantetech2-snap Do you really want to remove active logical volume palantetech2-snap? [y/n]: y
Erreurs rencontrées :
- Le volume logique ( snap ) ne voulait pas se supprimer pour cause : utilisé par autre device
on vérifie les blocs disponibles lsblk
On roule kpartx -d leblocutilisé
on relance lvremove data/palantetech2-snap
- on revient sur le master du cluster
logout
- On reactive la machine
# gnt-instance deactivate-disks "$instance" # gnt-instance startup "$instance" Waiting for job 90694 for palantetech2.koumbit.net ...
Changer le template des disques d'une instance
Avec ganeti, il est possible de changer le template de disque utilisé pour passer de plain à drbd ou l'inverse.
Pour ça, il faut que la VM soit offline, donc on doit prévoir des courts downtimes pour faire les changements de templates.
Une instance peut avoir un seul template de disques, donc soit tous ses disques sont plain, soit tous ses disques sont en drbd.
De plain à DRBD
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
Lister l'info:
gnt-instance info foo.koumbit.net
Se connecter sur le node qui héberge l'instance:
ssh X.koumbit.net
Créer le snapshot:
lvcreate --size 28G --snapshot --name foo0-snapshot-description data/2146aafa-8bbe-4496-99d8-07a105886a92.disk0
- 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.
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
- 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
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
Fermer la VM:
gnt-instance shutdown foo.koumbit.net
Se connecter sur le node qui héberge l'instance:
ssh X.koumbit.net
Remplacer le disque avec le snapshot:
lvconvert --merge data/foo0-snapshot-description
Note: Le snapshot va être enlèver
Re-créer la snapshot:
lvcreate --size 28G --snapshot --name foo0-snapshot-description data/2146aafa-8bbe-4496-99d8-07a105886a92.disk0
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.
Checker quels disques sont présents:
gnt-instance info asdf.koumbit.net
- 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
Redémarrer la vm:
gnt-instance shutdown asdf.koumbit.net gnt-instance start asdf.koumbit.net
- Configurer le disque côté machine virtuelle (eg. créer une partition, etc...), eg.
- Si c'est une VM sur Xen, il semble qu'il faut créer une partition avant. Ce n'est pas nécessaire avec KVM.
Si VM sous Xen:
fdisk -l # avoir les infos # disons qu'on travail sur /dev/xvdc fdisk /dev/xvdc Commande: n # nouvelle partition Sélection: p # partition primaire Numéro: 1 Premier secteur: <retour> # par défaut Dernier secteur: <retour> # par défaut Commande: w # faire les changements # format and mount mkfs.ext4 /dev/xvdc1 cat '/dev/xvdc1 /var/aegir/backups ext4 defaults 0 0' >> /etc/fstab mount /dev/xvdc1 /var/aegir/backups # make sure everything is okay reboot
Si VM sous KVM, créer directement le filesystem sur la nouvelle partition et l'ajouter au fstab puis mounter (changer le mount point au besoin):
mkfs.ext4 /dev/vdX echo "UUID=$(blkid | grep /dev/vdX | cut -d " " -f 2 | cut -d "=" -f 2 | sed 's/"//g') /srv/BACKUP ext4 defaults 0 1" >> /etc/fstab mount -a reboot # probablement une bonne idée de tester que tout revient
Monter les disques d'un domU dans le dom0
Tout d'abord il faut s'assurer de fermer la VM et activer ses disques:
instance=XXX.koumbit.net gnt-instance shutdown "$instance" gnt-instance activate-disks "$instance"
Ensuite il faut se rendre sur la machine primaire de la VM (e.g. le nom de node dans l'output de la sous-commande activate-disks qui ressemble à qqch comme node3:disk/0:/dev/mapper/...)
Pour toutes les nouvelles VMs, les disques sont configurés d'une manière particulière dans les domU: le volume créé pour la VM contient plusieurs partitions! Il faut donc passer par certains détours pour accéder aux fichiers. pour chaque chemin sous /dev/mapper dans l'output de la sous-commande activate-disks plus haut:
disk=/dev/mapper/<uid>.disk[01] mount /dev/mapper/$(kpartx -av "$disk" | cut -d " " -f 3) /mnt chroot /mnt # do stuff in the VM here exit umount /mnt/ kpartx -d "$disk"
Dans le cas des VMs qui auraient été importées d'un ancien setup xen, les fichiers de disques ne contiennent p-e qu'une seul partition par "disque". Dans ce cas on peut monter la partition directement:
mount /dev/mapper/<uid>.disk[01] /mnt chroot /mnt # do stuff in the VM here exit umount /mnt/
Une fois terminé, ne pas oublier de redémarrer la VM à partir du master du cluster:
gnt-instance deactivate-disks "$instance" gnt-instance start "$instance"
Voir: http://docs.ganeti.org/ganeti/2.15/html/admin.html#accessing-an-instance-s-disks
Si vous importez les données d'une machine physique
rm -fr /etc/udev/conf.d/70-persistent-* vi /etc/network/interfaces # you wanna set the new ip in there vi /etc/crypttab # remove all entries that won't be needed anymore (probably all) vi /etc/mdadm/mdadm.conf # comment out all the lines, we won't be using raid devices anymore rm -fr /boot/grub # Destroy, for better rebuilding later
Suivre ensuite les instructions à: https://wiki.koumbit.net/XenMaintenance#pygrub
Il faut éditer aussi inittab. pour ce fichier là il faut:
mettre en commentaire toutes les entrées console série (normalement T0 ou T1)
- mettre en commentaire toutes les entrées getty sauf celle qui commence par "1" au début de la ligne. Pour cette entrée, on veut changer "tty1" en "hvc0"
vi /etc/inittab
Une fois que la VM est bootée, on peut corriger quels disques sont utilisés pour quoi.
changer le root fs pour utiliser "UUID=..." au lieu de /dev/mapper/... ou /dev/sdX
- ajouter la partition swap (avec "UUID=..." aussi)
- retirer ou mettre en commentaire toutes les partitions qui n'existent pas
ls -l /dev/disk/by-uuid vim /etc/fstab
Troubleshooting
kpartx -av donne une erreur "device or resource busy"
Première chose: as-tu bien fait gnt-instance activate-disks $instance? Sinon, check d'abord si si voit le même LV 2x (tu veux surtout voir si ya ses partitions) avec dmsetup ls. Si une de ses partition est présente, c'est qu'il est déjà mapped. Donc, essaie de le mounter. Si ça marche pas, il faut chercher plus loin.
Problème #1: le disk est mapped, mais pas mountable
Peut-être qu'il a déjà été mapped, mais que c'est resté collé pis que là, c'est corrompu. On va donc s'assurer que rien roule dessus avant d'effacer le mapping.
# Étape 1: trouver l'adresse du disque (changez 'bb54' pour un pattern qui identifie le disque de la VM qu'on essaie de mapper) dmsetup ls | grep grep bb54 data-bb54a656--63d4--4300--9ce2--e411926f6b96.disk0 (253:4) data-bb54a656--63d4--4300--9ce2--e411926f6b96.disk0p1 (253:15) # Étape 2: lister les processus qui pourraient rouler sur le device root@monserveur:/# lsof 2>/dev/null | grep 253,15 # Étape 3: voir si on peut fermer les processes d'une façon clean. # Étape 4: veut si on peut killer les processes # Quand pu rien roule sur le device: # On veut effacer le mapping en utilisant le nom dmsetup remove data-bb54a656--63d4--4300--9ce2--e411926f6b96.disk0p1
Problème #2: un fuck avec DRBD
Voir (45093-22 et 28288-50) Ça se peut que la VM du device qu'on veut mount soit configurée en DRBD, ou qu'elle l'ait déjà été pis que les devices ont restés collés.
# Check s'il existe des device files pour des disque DRBD root@monserveur:/home/hubide/rm45093$ ls /dev/drbd* -lh brw-rw---- 1 root disk 147, 0 Aug 24 07:38 /dev/drbd0 # On veut checker si ces disques sont mapped root@monserveur:/home/hubide/rm45093$ dmsetup ls | grep drbd data-testdrbd (253:26) data-testdrbd--meta (253:27) data-testdrbd2_meta (253:41) data-testdrbd2 (253:40) # Dans ce cas, on peut juste voir qu'il y a eu des tests. # Comme il n'y a pas de map, on peut présumer que rien roule dessus pis maper le disque # Si on voit un mapping, checker les process comme dans le problème #1. Si ta VM est bien shutdown, il ne devrait rien avoir comme process. Si on voit des process, c'est que c'est pas une VM shutdown. On va pas essayer de mapper ou mounter ces disques là, ni de tuer les process. # À noter qu'une VM up qui est up et qui a un device DRDB (configuré comme ça ou avec un truc resté collé) n'aura pas nécessairement de mapping. # S'il y a un mapping, c'est probablement pas ta VM non plus, mais je me trompe peut-être. # Quand on trouve un disque pas de mapping ou de process root@monserveur:/home/hubide/rm45093$ kpartx -av -p- /dev/drbd0 add map drbd0-1 (253:49): 0 465565696 linear 147:0 2048 # On mount et on check si c'est le device que la VM à laquelle on veut accéder root@monserveur:/home/hubide/rm45093$ mount /dev/mapper/drbd0-1 monserveur-nc-test/ root@monserveur:/home/hubide/rm45093$ cat /monserveur-nc-testetc/hostname monserveur-nc-test.koumbit.net # On fait ce qu'on voulait faire, pis on supprime le mapping root@monserveur:/home/hubide/rm45093$ umount monserveur-nc-test root@monserveur:/home/hubide/rm45093$ kpartx -dv -p- /dev/drbd0 del devmap : drbd0-1 root@monserveur:/home/hubide/rm45093$ gnt-instance deactivate-disks monserveur-nc-test.koumbit.net
Créer une image d'une VM
Attention, la VM doit être offline pour cette opération!
Sur le master:
Fermer la VM: gnt-instance shutdown exemple.koumbit.net
Trouver sur quelle node est hébergé la VM: gnt-instance list | grep exemple.koumbit.net
- Trouver le path du disque:
gnt-instance info exemple.koumbit.net
... Disks: - disk/0: plain, size 14.0G access mode: rw logical_id: data/01b93ad7-0c0c-4799-b352-23ba6a4000ec.disk0 on primary: /dev/data/01b93ad7-0c0c-4799-b352-23ba6a4000ec.disk0 (253:24) name: None UUID: f071f102-6229-437c-a71a-f0ce55661950 - disk/1: plain, size 1.0G access mode: rw logical_id: data/a059f227-2978-4353-bade-9c72596486df.disk1 on primary: /dev/data/a059f227-2978-4353-bade-9c72596486df.disk1 (253:25) name: swap UUID: 19d5313a-7180-4c89-bced-fb9304f64f1a
Dans l'exemple ci-haut, le path est /dev/data/01b93ad7-0c0c-4799-b352-23ba6a4000ec.disk0
Sur la node:
Pour connaitre les format disponible:
qemu-img --help | grep "Supported formats"
Créer l'image (-p pour voir le progrès. on remplace [path] par le path du disque de la VM trouvé plus haut sur le master et on remplace [format] par le format désiré comme output:
qemu-img convert -p [path] -O [format] /tmp/exemple.koumbit.net.img
Troubleshooting
Ajouter un gros volume (disque) donne 'Failure: prerequisites not met for this operation'
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.
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]
Voir GanetiConfiguration pour changer les 'instances policy'
- Quand c'est fait, ré-essaie d'ajouter ton volume.