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 LVMvghost.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
md0etmd1comme dans la méthode 1, sauf qu'il estmd1juste 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 LVMvgvms, 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)