Groupe de volumes LVM partagé entre l'hôte KVM / libvirt et les invités: est-ce une mauvaise idée?

Je viens de construire un nouvel hôte de machine virtuelle basé sur KVM / libvirt, contenant 4 disques durs SATA II et exécutant CentOS 5.5 x86_64.

J'ai décidé de créer des disques de machine virtuelle en tant que volumes logiques dans un groupe de volumes LVM géré comme un pool de stockage libvirt, au lieu de la pratique habituelle de créer les disques en tant qu'images qcow.

Je ne peux pas décider si je dois créer les volumes logiques de la machine virtuelle dans le groupe de volumes de l'hôte VM ou dans un groupe de volumes dédié.

Quelle méthode dois-je choisir et pourquoi?

Méthode 1: utiliser le groupe de volumes de l'hôte VM

La mise en oeuvre:

• petit RAID1 md0contenant le /bootsystème de fichiers
• grand RAID10 md1occupant l'espace restant, qui contient un groupe de volumes LVM vghost. vghostcontient le système de fichiers racine et la partition d'échange de l'hôte VM
• créer des disques de machine virtuelle en tant que volumes logiques vghostselon les besoins

Avantages:

• si le système de fichiers racine de l'hôte VM manque d'espace, je peux allouer plus d'espace vghostavec une relative facilité
• Le système est déjà opérationnel (mais ce n'est pas grave de recommencer)

Les inconvénients:

En dépit du fait que cette méthode semble fonctionner, je ne peux pas me débarrasser du sentiment que c'est en quelque sorte une mauvaise idée. Je sens ça:

• cela peut en quelque sorte être un risque pour la sécurité
• à un moment donné dans le futur, je trouverai peut-être des limites avec la configuration, et j'aimerais utiliser un groupe dédié
• le système (CentOS, libvirt, etc.) peut ne pas être vraiment conçu pour être utilisé comme ça, et donc à un moment donné, je pourrais accidentellement corrompre / perdre les fichiers et / ou le système de fichiers de l'hôte VM

Méthode 2: utiliser un groupe de volumes dédié

La mise en oeuvre:

• identique md0et md1comme dans la méthode 1, sauf qu'il est md1juste assez grand pour contenir pour l'hôte VM (par exemple 5 à 10 Go)
• grand RAID10 md2occupant l'espace restant. md2contient un groupe de volumes LVM vgvms, dont les volumes logiques doivent être utilisés exclusivement par des machines virtuelles

Avantages:

• Je peux bricoler vgvmssans craindre de casser le système d'exploitation hôte
• cela semble être une solution plus élégante et plus sûre

Les inconvénients:

• si le système de fichiers de l'hôte VM manque d'espace, je devrais déplacer des parties de son système de fichiers (par exemple. / usr ou / var) vgvms, ce qui ne semble pas très agréable.
• Je dois réinstaller le système d'exploitation hôte (ce qui, comme indiqué précédemment, ne me dérange pas vraiment)

MISE À JOUR # 1:

L'une des raisons pour lesquelles je m'inquiète de manquer d'espace disque sur l'hôte VM dans la méthode 2 est parce que je ne sais pas si l'hôte VM est suffisamment puissant pour exécuter tous les services sur les machines virtuelles, c'est-à-dire. Il se peut que je doive migrer certains / tous les services des machines virtuelles vers le système d'exploitation hôte.

Spécifications matérielles de l'hôte VM:

• Processeur Phenom II 955 X4 Black Edition (3,2 GHz, processeur 4 cœurs)
• 2 x 4 Go de mémoire RAM Kingston PC3-10600 DDR3
• Carte mère Gigabyte GA-880GM-USB3
• 4 disques durs WD Caviar RE3 500 Go SATA II (7200 tr / min)
• Antec BP500U Basiq 500W alimentation ATX
• Boîtier CoolerMaster CM 690

MISE À JOUR # 2:

L'une des raisons pour lesquelles je pense que le système n'est peut-être pas conçu pour utiliser l'hôte VG comme pool de stockage libvirt dans la méthode 1 est un comportement que j'ai remarqué dans virt-manager:

• une fois ajouté, il s'est plaint de ne pas avoir pu activer le VG (évidemment, car le système d'exploitation hôte l'a déjà activé)
• lors de la suppression, il a refusé de le faire car il ne pouvait pas désactiver le VG (évidemment, car le système d'exploitation hôte utilise toujours les LV racine et swap)

Question bien pensée!

J'irais avec la méthode 2, mais c'est plus une préférence personnelle. Pour moi, les inconvénients de la méthode 2 ne sont pas vraiment un problème. Je ne vois pas le système d'exploitation hôte dépasser sa partition de 5 à 10 Go, à moins que vous ne commenciez à y installer des éléments supplémentaires, ce que vous ne devriez vraiment pas. Pour des raisons de simplicité et de sécurité, le système d'exploitation hôte devrait vraiment être une installation minimale nue, n'exécutant rien sauf le strict minimum nécessaire à l'administration (par exemple sshd).

Les inconvénients de la méthode 1 ne sont pas vraiment un problème non plus, OMI. Je ne pense pas qu'il y aurait un risque de sécurité supplémentaire, car si une machine virtuelle enracinée est en mesure de se détacher de sa partition et d'infecter / endommager d'autres partitions, avoir le système d'exploitation hôte sur un VG séparé pourrait ne faire aucune différence. Les deux autres inconvénients ne sont pas quelque chose à quoi je peux parler par expérience directe, mais mon intuition dit que CentOS, LVM et libvirt sont suffisamment flexibles et robustes pour ne pas se soucier d'eux.

EDIT - Réponse à la mise à jour 1

De nos jours, les performances de la virtualisation sont très faibles, en particulier en utilisant des processeurs avec une prise en charge intégrée, donc je ne pense pas que le déplacement d'un service d'une machine virtuelle invitée dans le système d'exploitation hôte en vaille la peine. Vous pouvez obtenir une augmentation de vitesse de 10% en exécutant sur le "bare metal", mais vous perdriez les avantages d'avoir un petit OS hôte, serré et sécurisé, et potentiellement un impact sur la stabilité de l'ensemble du serveur. Pas la peine, OMI.

À la lumière de cela, je serais toujours en faveur de la méthode 2.

Réponse à la mise à jour 2

Il semble que la façon particulière dont libvirt suppose que le stockage est organisé est un autre point en faveur de la méthode 2. Ma recommandation est: optez pour la méthode 2.

Tant qu'un seul système tente à tout moment d'utiliser un LV donné en mode lecture / écriture, il est possible d'utiliser le même VG pour l'hôte et les invités. Si plusieurs systèmes tentent d'écrire dans le même LV, la corruption du système de fichiers en résultera.

Vous voudrez peut-être jeter un œil à cela, peut-être bricoler et voir comment ce projet fait ce dont vous parlez.

ProxmoxVE est un hôte KVM sans système d'exploitation qui utilise une implémentation perl de libvirt plutôt que l'homologue plus lourd de RHEL. Il implémente les deux scénarios.

Les disques virtuels sont .raw et clairsemés, similaires à .qcow mais plus rapides.

Les formats d'image disque qcow et vmdk sont également pris en charge, mais je pense qu'il pourrait y avoir des limitations LVM impliquées. Je ne les utilise pas, donc je ne peux pas en dire beaucoup à ce sujet.

Le stockage LVM est partagé entre les machines virtuelles sur le nœud et peut être des périphériques DRBD.

En ce qui concerne le partage de l'espace VG du système d'exploitation, la seule limite à prendre en compte est la taille de l'instantané lors des sauvegardes. Ici, cette valeur peut être modifiée dans un fichier de configuration, et je vois parfois dans les forums où les gens ont dû la changer, mais les valeurs par défaut me servent bien depuis quelques années maintenant, même avec d'énormes disques virtuels.

Détails de stockage LVM de PVE:

http://pve.proxmox.com/wiki/Storage_Model#LVM_Groups_with_Network_Backing

Voici comment les VG sont présentés:

Groupe de volumes trouvé "LDatastore1" utilisant le type de métadonnées lvm2

Groupe de volumes trouvé "LDatastore0" utilisant le type de métadonnées lvm2

Groupe de volumes "pve" trouvé à l'aide du type de métadonnées lvm2

Ce sont mes LVs:

ACTIVE '/ dev / LDatastore1 / vm-9098-disk-1' [4,00 Go] héritent

ACTIVE '/ dev / LDatastore1 / vm-7060-disk-1' [2,00 Go] héritent

ACTIVE '/ dev / LDatastore1 / vm-5555-disk-1' [8,00 Go] héritent

ACTIVE '/ dev / LDatastore0 / vm-4017-disk-1' [8,00 Go] héritent

ACTIVE '/ dev / LDatastore0 / vm-4017-disk-2' [512,00 Go] héritent

ACTIVE '/ dev / LDatastore0 / vm-7057-disk-1' [32,00 Go] héritent

ACTIVE '/ dev / LDatastore0 / vm-7055-disk-1' [32,00 Go] héritent

ACTIVE '/ dev / LDatastore0 / vm-6030-disk-1' [80.01 Go] héritent

ACTIVE '/ dev / pve / swap' [3,62 Go] hérite

ACTIVE '/ dev / pve / root' [7,25 Go] hérite

ACTIVE '/ dev / pve / data' [14,80 Go] hérite

Il s'agit de LVM sur RAID10 composé de 6 disques Seagate Barracuda SATA à 7200 tr / min:

CPU BOGOMIPS: 53199.93

REGEX / SECOND: 824835

TAILLE HD: 19,69 Go (/ dev / mapper / LDatastore0-testlv)

LECTURES TAMPONS: 315,17 Mo / sec

TEMPS DE RECHERCHE MOYEN: 7,18 ms

FSYNCS / SECOND: 2439.31

Et ceci est LVM sur un seul SSD Intel X25-E SATA, même VG que les données / dev / pve / susmentionnées sur lesquelles les machines virtuelles vivent:

CPU BOGOMIPS: 53203.97

REGEX / SECOND: 825323

TAILLE HD: 7,14 Go (/ dev / mapper / pve-root)

LECTURES TAMPONS: 198,52 Mo / sec

TEMPS DE RECHERCHE MOYEN: 0,26 ms

FSYNCS / SECOND: 1867.56