Ajout d'un disque à une VM KVM, besoin de conseils!

Support Debian
#1

Hello,

J’ai une VM qui tourne sur une image Qcow2, cette image est côté hyperviseur sur un raid 1 avec 2 disques nvme. Mais la place est limitée.

J’ai, sur le même hyperviseur, un raid 10 de 20T environ, dont je vais me service pour du stockage de donnée et aussi pour provisionner mes VM si elles ont besoin d’un peu plus d’espace disque.

J’en suis donc là :

Personalities : [raid1] [raid10] [linear] [multipath] [raid0] [raid6] [raid5] [raid4]
md2 : active raid1 sda2[1] sdb2[0]
      233250368 blocks super 1.2 [2/2] [UU]
      bitmap: 2/2 pages [8KB], 65536KB chunk

md3 : active raid10 sdd1[3] sdf1[1] sde1[0] sdc1[2]
      23437503488 blocks super 1.2 512K chunks 2 near-copies [4/4] [UUUU]
      bitmap: 0/175 pages [0KB], 65536KB chunk

Tout roule.

Pour construire mon md3, je n’ai pas présenté le disque au RAID directement, mais à chaque fois une partition de type RAID présente sur chaque disque (sur les bons conseils de quelqu’un ici), ça donne donc ceci une fois le RAID composé, en le divisant en 2 :

Disk /dev/md3: 21,8 TiB, 24000003571712 bytes, 46875006976 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disklabel type: gpt
Disk identifier: D7B773A2-F3DA-44AC-97F4-B5B5E9BD7E49

Device          Start         End     Sectors  Size Type
/dev/md3p1       2048  4294969343  4294967296    2T Linux filesystem
/dev/md3p2 4294969344 46875006942 42580037599 19,8T Linux filesystem

On est toujours bon, ici, je vais utiliser md3p1 pour l’intégrer à un DRDB, je me me mets ça de côté pour plus tard.

Ce qui m’intéresse, c’est md3p2 .

Je veux me servir de cette partition aussi bien pour mettre des choses dessus directement depuis l’hyperviseur (c’est à dire que je pense y coller un montage NAS et mettre du backup dessus, vu la taille, on ne va pas se priver…) mais également pour présenter des disques à mes VMs.

Allez hop, je passe en mode LVM :

pvcreate /dev/md3p2
vgcreate storage /dev/md3p2
lvcreate -L500G --name storage/app5_nextcloud_1
lvcreate -L8000G --name storage/backup_global

Ces quelques commandes LVM plus tard, j’obtiens ceci :

  LV               VG      Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  app5_nextcloud_1 storage -wi-a----- 500,00g                                                     /dev/md3p2(0)
  backup_global    storage -wi-a-----   7,81t                                                     /dev/md3p2(128000)

On est pas mal. Ma VM qui va contenir le disque additionnel me servant de volume de stockage pour une grosse instance nextcloud est app5_nextcloud_1, backup_global quant à lui, je vais monter une partition dessus directement sur l’hyperviseur et transformer ça en directory de stockage.

Et c’est là que je fais appel à vos bons conseils. Quelle serait la meilleurs méthode, la plus secure, pour présenter l’espace disque de mon LV app5_nextcloud_1 à ma VM ?

J’ai deux idées là :

  • Monter une partition LVM sur mon hyperviseur, avoir un directory donc, et dans mon directory, créer un Qcow2 et donner ça à ma VM.
  • Présenter directement mon LV app5_nextcloud_1 à ma VM KVM, mais je n’ai pas l’impression que KVM permette ça…

La première solution me parait vraiment crado et la seconde impossible (à ma connaissance) à faire. Voyez-vous une autre solution ?

#2

Ta VM est un debian, donc coté système elle s’en fout: soit la taille du disque système augmente et si tu as implementé du LVM dessus, suffira d’augmenter le disque. Ou bien Tu veux séparer au niveau système avec son propre point de montage auquel cas tu créé un nouveau LV au sein du VG que tu auras augmenté ainsi.

Coté hyperviseur, c’est le mode e montage des disques de ta VM qu’il vaut mieux garder homogène.

#3

Dans ce cas pour plus de lisibilité il serait bon de changer l’identifiant de type de la partition utilisée comme volume physique LVM de « Linux filesystem » en « Linux LVM ».

« Ma VM » ? Tu veux dire le volume logique (LV) ?

Monter une partition sur un volume logique ???
Tu veux dire y créer un système de fichiers et le monter ?

Les seules partitions dans LVM, ce sont les volumes physiques, et ça ne se monte pas, ce ne sont pas des systèmes de fichiers.

Pourquoi ?

Je ne connais pas grand-chose à QEMU/KVM, mais je serais étonné qu’il ne soit pas possible d’utiliser un volume logique ou tout autre périphérique bloc comme disque virtuel en format « raw ». Par contre il faut regarder les permissions. Une VM QEMU/KVM, ça tourne avec quels privilèges sur l’hyperviseur ?

#4

Ça tourne normalement avec les droits d’un utilisateur ajouté au groupe kvm.

#5

Hello,

Finalement, j’ai laissé tomber toute la solution LVM. Il s’avère que si j’ai une VM sur une image en Qcow2, et que j’y adjoins un disque supplémentaire sur une base LVM, QEMU/KVM saura le faire, sans problème, le hic c’est que cela rend la prise de snapshot KVM tout simplement impossible dans la mesure où on ne peut pas le faire autrechose qu’une image Qcow2.

Pour faire mon snapshot KVM, il faudrait en gros que je démonte mon second disque, puisque je le réintègre. C’est inenvisageable.

L’autre solution serait de présenter à KVM lors de la création de mon image, non pas du Qcow2, mais directement un LV lvm pour chaque VM, et derrière je ne travaillerais que avec LVM. Concernant les snpashots, je laisserais plus KVM les gérer, mais directement LVM depuis l’hyperviseur (ça deviendrait donc de bêtes snapshots LVM).

Cette dernière solution est pas mal, mais va me poser 2 problèmes :

  • Il faut que je passe toutes mes VM d’un systèmes basé sur Qcow2 à full LVM
  • Je perds la flexibilité de l’image Qcow2, si je veux déplacer facilement ma VM d’un HV à l’autre. Avec LVM, c’est un poil plus compliqué.

En conclusion, pour le moment, je reste avec du Qcow2 pour l’image de base de mes VMs ainsi que les disques additionnels.

Je vais quand même tester la solution full LVM dans mon environnement de test, voir ce que ça donne, peut-être que ça vaudra quand même le coup de tout migrer sur du full LVM si je m’apperçois que c’est pas trop complexe pour les déplacements de VM entre hyperviseur (je rappelle que je n’ai pas de SAN à dispo, sinon d’office je ne me serais pas posé la question).

#6

Pour moi la solution serait d’ajouter un second disque de type Qcow2, surlequel tu monte un PV LVM que tu ajoute à ton VG LVM sur ta machine virtuelle.

Ensuite tu peux faire un export depuis ta VM en NFS que tu monte depuis ton hyperviseur.

Depuis KVM tu pourra effectuer des sauvegarde de confort de chaque disque Qcow2 (excepté ce dernier qui sert de stockage) directement dessus.

1 J'aime
#7

Effectivement, cette solution est pas mal non plus, je vais tester.

Par contre, côté VM, là je suis en train de me demander si j’ai tout bien fait correctement.

Pour mon instance Nextcloud, les répertoires users sont dans un répertoire data. Ce répertoire data est précisément un montage de ce disque secondaire, j’ai donc ceci :

 grep nextcloud /etc/fstab
/dev/users/nextcloudvol /var/www/nextcloud/data ext4 noatime 1 2

 mount |grep nextcloud
/dev/mapper/users-nextcloudvol on /var/www/nextcloud/data type ext4 (rw,noatime)

fdisk /dev/vdb -l
Disk /dev/vdb: 4 TiB, 4398046511104 bytes, 8589934592 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: gpt
Disk identifier: 2AEC15B4-D0C4-42CE-99F4-9D1297C8D139

Device     Start        End    Sectors Size Type
/dev/vdb1   2048 8589932543 8589930496   4T Linux filesystem

 lvs -ao +devices
  LV           VG    Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert Devices
  nextcloudvol users -wi-ao---- <4,00t                                                     /dev/vdb1(0)

On est bon là ?

#8

Pourquoi pas, par contre j’ai édite mon message, je souligne le fait qu’une sauvegarde doit être externaliser, seul ce que l’on pourrais appelé une sauvegarde de confort peux résider sur l’hôte d’après moi.

Pour le restant monter un PV et un LV unique sur ce deuxième disque aura l’avantage de pouvoir le déplacer sur une autre machine et remontée le LV afin d’accéder à la donnée.

Si la machine vouait à remplacer celle-ci est installé de manière identique tu peux effectivement te resservir de ce disk tel quel en toute transparence.