Machine Virtuelle on Zwindler's Reflection

[Tutoriel] Installation d’Oracle VM for x86 – partie 2

Tue, 18 Oct 2016 12:00:57 +0000

Cet article fait suite à l’article Installation d’Oracle VM for x86 - partie 1 dans lequel j’ai introduis Oracle VM et installé la console de management Oracle VM Manager. Je vous conseille de commencer par là ;-).

Connexion du serveur Oracle VM avec la console OVMM

Maintenant que la console OVMM est opérationnelle et qu’on a pu s’y connecter, on remarque que les menus sont assez intuitifs bien qu’un peu austères !

Un onglet Health donne l’état général de la plateforme, puis les autres onglets permettent de configurer les différents aspects attendus d’une console d’administration de virtualisation x86.

La première étape pour nous est donc bien entendu d’ajouter dans OVMM le serveur Oracle VM préalablement installé, au même titre qu’on pourrait le faire avec un ESXi dans un vCenter.

Hormis les icônes pas forcément très parlantes, le menu de « découverte » de nouveaux serveurs est très simple. On a juste besoin de l’IP et du compte OVM Agent créé lors du déploiement de l’ISO d’installation.

En bas de l’écran, un bandeau vous donne l’état des dernières opérations déclenchées sur le cluster.

Un bref coup d’œil permet de voir que le serveur est bien ajouté. Des informations sur sa configuration s’affichent.

Créer un groupe de serveurs « server pool »

Vous aurez peut être remarqué que votre serveur de virtualisation a été ajouté dans le groupe de serveurs « Unassigned ». Intellectuellement ça me gène, et j’ai donc voulu créer un groupe de serveurs, pour « faire propre ».

Au delà de ça, c’est notamment via la création de ces groupes (clusters dans VMware) que l’on peut gérer la haute disponibilité et les clusters de machines. C’est donc plutôt important ;-).

Ce groupe peut se créer via l’icône située juste à droite de celle sur laquelle nous avons cliqué pour « découvrir » le serveur Oracle VM.

Cependant, lorsque j’ai tenté de créer mon groupe de serveurs, j’ai reçu l’erreur suivante :

OVMAPI_4010E Attempt to send command: create_server_pool to server: lab01 failed.
OVMAPI_4004E Sync command failed on server: x.x.x.32.
Command: create_server_pool, Server error: org.apache.xmlrpc.XmlRpcException: <type 'exceptions.Exception'>:
Invalid hostname resolution: lab01 -> 127.0.0.1 [Wed Jul 20 16:30:40 CEST 2016]

Lors de l’installation automatique de l’ISO Oracle VM, le hostname lab01 a été ajouté par défaut dans le fichier /etc/hosts. Or, ceci pose problème.

Connectez vous en SSH sur le serveur et retirez le hostname (ici lab01) du fichier /etc/hosts :

vi /etc/hosts
127.0.0.1 lab01 localhost localhost.localdomain localhost4 localhost4.localdomain4

Création de pools de stockage

La seconde opération consiste à ajouter du stockage au cluster.

Avec Oracle VM, on peut utiliser du stockage local via des disques inutilisés. La procédure est détaillée à l’adresse suivante.

On peut également découvrir des cibles iSCSI ou éventuellement utiliser l’espace disponible sur le filesystem local. Pour ce dernier choix, l’espace ne sera cependant bien entendu uniquement visible depuis le serveur local uniquement.

Pour l’exemple, j’ai créé un disque de test de 200 Go sur un NAS Windows.

La procédure est la suivante. On commence par ouvrir l’onglet « Storage ». Dans SAN Servers, il n’y a encore aucun serveur déclaré. Au même titre que pour le serveur de virtualisation, il y a un bouton « Discover SAN Server ».

On peut déclarer un ou plusieurs hôtes, avec ou non de l’authentification. J’ai rarement vu des contextes où l’authentification CHAP (côté client ou serveur) était activée, mais je trouve ça bien en production. Pour autant, dans le cas du PoC je n’en ai pas mis.

Editer les access groups

Et enfin, on ajoute les serveurs qui peuvent avoir accès aux périphériques de stockage. Ici lab01.

Cliquer sur Finish pour valider.

Dans mon cas, juste avec la configuration de cet article, je suis tombé sur l’erreur suivante. A l’écran d’avant j’avais loupé la modification des access groups et en particulier l’onglet storage initiators. Si vous avez une erreur, c’est surement le même problème.

Le stockage nouvellement intégré apparait maintenant avec les volumes disponibles

Créer des repositories pour stocker des images

Une fois les périphériques de stockage déclarés auprès de vos serveurs de virtualisation, on peut maintenant créer des pools appelés repositories.

L’ensemble des opérations qui suivent sont a effectuer dans l’onglet Repositories. Ces pools logiques de stockage vous permettent de stocker vos fichiers ISO, mais aussi vos templates et vos disques durs virtuels pour vos machines virtuelles. Sur VMware on parlerait de Datastores.

Avec le disque local

Comme indiqué précédemment, ce type de stockage aura l’inconvénient de n’être accessible que d’une seule machine. Cependant c’est le plus simple à utiliser.

Cliquer sur le logo « + » pour créer un nouveau repository.

On doit d’abord renseigner quelques informations descriptives et d’appartenance.

Enfin, on sélectionne le disque (Physical Disk) sur lequel placer le repository.

La dernière étape consiste à ajouter les serveurs qui verront ce stockage. Dans ce cas précis, seul lab01 pourra le voir.

Après validation, le nouveau repository apparait dans la liste des repositories.

Avec le disque SAN

Le principe est le même pour les disques SAN, à ceci près que celui ci pourra bien être partagé entre plusieurs serveurs d’un même cluster (pour peu que les serveurs concernés aient bien été autorisés à voir ce stockage lors de l’étape précédente).

Gestion du réseau

Vous l’aurez deviné, pour la gestion du réseau, tout se passe dans l’onglet « Network » de la console OVMM.

Petite subtilité, par défaut, le réseau de management ne peut pas être utilisé par les VMs. Vous ne pourrez donc pas affecter de réseaux virtuels aux machines virtuelles en l’état actuel des choses.

Dans mon cas (PoC), je ne souhaite pas créer un nouveau réseau pour me simplifier la vie, et j’ai donc ajouté « Virtual Machine » au réseau de management créé par défaut lors de l’installation du serveur OracleVM.

Dans un contexte de production, on préfèrera en ajouter un nouveau et lui affecter des interfaces réseaux et des VLANs (comme on le ferait sur VMware ou RHEV).

Créer une nouvelle VM

Maintenant que les aspects stockage et réseau ont été réglés, on peut enfin créer une machine virtuelle. La documentation officielle donne quelques informations utiles sur le sujet.

Le début de la création de machine virtuelle est similaire à n’importe quel outil de virtualisation.

HVM, HVM + PV, PVM

Cependant, par rapport aux autres hyperviseurs (full virtualisation vs paravirtualisation, différences que j’aborde dans cet article), Xen et donc OracleVM apporte une subtilité dans la méthode de virtualiser : la paravirtualisation (PVM). On a le choix entre HVM, HVM + PV et PVM.

En réalité il s’agit de :

Xen HVM: Hardware virtualization, or fully virtualized
Xen HVM, PV Drivers: Identical to Xen HVM, but with additional paravirtualized drivers for improved performance
Xen PVM: Paravirtualized

En théorie, vous aurez donc de meilleures performances lorsque vous disposerez d’un OS capable d’être paravirtualisé (mode Xen PVM) que lorsque vous aurez une HVM.

Ça c’est la théorie. En fait en pratique, certains OS, même Linux, seront plus performants en HVM + PV selon Oracle. Pour plus d’informations, voir la page de documentation officielle qui traite du sujet

La liste des OS supporté pour chaque mode est disponible dans les release notes.

Créer des interfaces virtuelles

La seconde étape du wizard permet de configurer les interfaces virtuelles et les réseaux qui y sont associés.

Ajouter des disques virtuels

L’étape d’après permet de configurer les différents périphériques qui sont associés à la VM. Dans le cas du disque dur virtuel, il faut le créer ou en réutiliser un existant.

Lorsqu’on clique sur le « + », on peut créer un nouveau disque virtuel qui sera stocké sur le repository choisi.

Enfin, on peut affecter ou non les différents périphériques éligibles à la séquence de boot et les ordonner.

Une fois la VM créée, on peut la démarrer et ouvrir sa console.

Boot

Dans l’état actuel des choses, la VM démarre mais n’a aucun disque bootable (CD ou HDD). En effet, il faut monter un ISO sur la VM, mais pour ça on doit l’uploader dans un premier temps sur un des repositories précédemment créés.

A priori, dans le menu d’import du repository, on ne peut uploader que des ISO depuis un partage web HTTP. Une solution alternative probable est que l’on peut simplement aller déposer le fichier en SSH mais je trouve que clairement il manque une fonctionnalité à la console d’upload en directe depuis un navigateur !

Une fois qu’on dispose d’un ISO pour booter notre VM, on peut éditer la machine virtuelle et y ajouter l’ISO.

On redémarre la machine virtuelle qui boote sur l’ISO comme souhaité.

Sources

Partage de VMDK entre plusieurs VMs

Wed, 07 Jan 2015 16:05:17 +0000

Si vous déjà voulu faire un POC de cluster Linux sur des machines virtuelles VMware, vous vous êtes déjà demandé comment vous alliez faire pour partager entre deux serveurs un espace de stockage commun à ces deux machines.

Une façon de faire consiste à rajouter une couche d’abstraction du stockage au dessus de l’OS (via GlusterFS ou DRBD par exemple), mais dans le cas d’un POC pour valider un cluster connecté au SAN, ce n’est pas forcément la première solution qui vient à l’esprit. Personnellement, la plupart des clusters que je construis sont encore dans un schéma plus simple à base de LUNs iSCSI ou FC partagés sur un SAN en actif/actif ou actif/passif.

Cependant, pour simuler ce fonctionnement sur vos VMs, il va falloir bidouiller un peu.

En effet, pour éviter toute erreur malencontreuse (et même désastreuse), VMware interdit par défaut le démarrage de toute machine virtuelle qui aurait un disque en cours d’utilisation par une autre machine virtuelle. Aïe…

Voici un petit mode opératoire pour s’en sortir ;-)

Dans ce mode opératoire, les disques qu’on souhaite partager entre les deux serveurs sont des disques LVM en miroir, hébergés sur les baies de disques qui sont accessibles depuis les deux serveurs ESXi.

Cet exemple permet de valider la fiabilité de la méthode dans le cadre d’un cluster Linux virtuel de type RedHat Cluster Suite. Le principe reste tout de même valide pour une utilisation en dehors de RedHat Cluster Suite, certaines opérations ne seront juste pas nécessaires (qui peut le plus peut le moins).

Prérequis

Pour les besoins de la documentation, deux machines virtuelles test_partage_vmdk_1 et test_partage_vmdk_2 ont été créés. Elles disposent des caractéristiques techniques suivantes :

test_partage_vmdk_1
- hébergée sur ESXi1
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.1/24 sur un réseau virtuel
test_partage_vmdk_2
- hébergée sur ESXi2
- RedHat Entreprise Linux 5.8
- 2 vCPU, 1 Go de RAM
- 50 Go de disque interne sur un espace partagé
- IP 192.168.111.2/24 sur un réseau virtuel

Création des disques virtuels

Les machines test_partage_vmdk_1 et test_partage_vmdk_2 doivent être éteintes avant de réaliser les modifications.

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_1, et ajouter un nouveau périphérique (Disque dur).

Le provisionnement du disque doit impérativement être « statique immédiatement mis à zéro ». De plus, il doit aussi être hébergé sur un datastore commun aux deux machines physiques ESXi.

Créer le disque et l’affecter à un Nœud périphérique virtuel qui n’est pas encore utilisé.

Ici, le disque interne est stocké sur l’adresse SCSI (0:0). Par défaut VMware propose de créer le disque à la suite en SCSI (**0:**1).

Il faut impérativement dérouler la liste pour affecter le disque à l’adresse SCSI (**1:**0) qui représente un nouveau contrôleur SCSI.

De plus, pour permettre l’usage des snapshots sur la partie disque dur interne, les disques doivent être créés en Mode Indépendant/Persistant. Dans le cas contraire, les snapshots seront impossibles sur la machine virtuelle.

Une fois le disque créé, un nouveau contrôleur SCSI est également créé. Avant de valider la création du disque et du contrôleur SCSI, il faut modifier le paramètre de Partage de bus de SCSI en mode « Physique ».

[4]Le second disque dur devra être créé de la même manière, et affecté au même contrôleur SCSI (on prendra l’adresse 1:1).

Remettre test_partage_vmdk_1 sous tension.

Ajout des disques virtuels sur la deuxième machine virtuelle

Ouvrir les paramètres de la machine virtuelle test_partage_vmdk_2, ajouter un nouveau périphérique (Disque dur) puis sélectionner « Utiliser un disque virtuel déjà configuré ».

Sélectionner le premier disque créé précédemment.

De la même manière que précédemment, on doit créer un disque dur virtuel sur un nouveau contrôleur SCSI et en mode Indépendant-Persistant.

Modifier le nouveau contrôleur SCSI comme précédemment :

Ajouter enfin le second disque de la même manière à l’adresse SCSI (1:1).

Valider et mettre la machine virtuelle sous tension. Si elle boot correctement c’est que le partage fonctionne.

Créer le miroir LVM partagé

Sur les deux serveurs, exécuter les commandes suivantes :

chkconfig acpid off #seulement pour RHCS
service acpid stop #seulement pour RHCS
vi /etc/lvm/lvm.conf
     filter = [ "a/.*/" ]
   #filter = [ "a|/dev/cciss/.*|", "a|/dev/mpath.*|", "r|.*|" ] #utiliser cette ligne en cas d’utilisation de multipath et de disques locaux présentés en tant que /dev/cciss. A adapter au contexte
[…]
volume_list = [ "vg01" , "@[TAG]" ]

Dans le cas de RedHat Cluster Suite, remplacer [TAG] par le nom de la machine tel qu’il est définit dans le fichier /etc/cluster/cluster.conf.

En dehors du cas d’un traitement automatisé par cluster, n’importe quel tag convient du moment qu’il est unique à la machine. Dans le cas présent, les tags choisis sont respectivement tag_vm1 et tag_vm2.

Quelques précisions :

filter permet de traiter les cas où on doit ignorer certains disques. C’est typiquement nécessaire lorsque l’on utilise LVM avec multipath ou powerpath, car l’OS voit plusieurs « disques » sda ,sdb, … pour un même disque mpath (1 sdX pour chaque chemin vers mpathY).
volume_list indique à LVM que seul le vg01 (interne) et les VG explicitement taggués avec le nom de la machine qui peuvent être utilisés. Cela permet de s’assurer qu’il n’y a qu’une seule machine qui peut activer le VG du moment qu’on n’ajoute jamais plus d’un tag au VG.

Même si les modifications du fichier lvm.conf sont prises en compte immédiatement, RedHat Cluster Suite impose une recompilation de l’initrd. Dans le cas d’un cluster RHCS, il faut donc lancer la commande suivante :

mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)

Sur un seul nœud (le premier) :

pvcreate /dev/sdb
pvcreate /dev/sdc
vgcreate -c n vg_mirror /dev/sdb /dev/sdc

Tagger le VG pour pouvoir travailler dessus sur ce nœud.

vgchange --addtag tag_vm1 -ay vg_mirror
lvcreate -n lv_mirror -m1 -l 5116 /dev/vg_mirror
Logical volume "lv_mirror" created

Le journal des écritures doit lui aussi être en miroir

lvconvert --mirrorlog mirrored /dev/vg_mirror/lv_mirror
Logical volume lv_mirror converted.

Il est enfin possible de formater le disque, et de le monter sur le test_partage_vmdk_1

mkfs.ext3 /dev/vg_mirror/lv_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Tester la bascule

Scanner les VGs pour vérifier que le nouveau VG est bien disponible sur le test_partage_vmdk_2

vgscan
vgs

Même s’il le VG est visible, il n’est pas possible de le monter car il n’a pas le bon tag (tel que spécifié dans le lvm.conf). Cela permet de vérifier que l’on ne pourra pas écrire sur les disques sur les deux nœuds en même temps.

Not activating vg_mirror/lv_mirror since it does not pass activation filter.
0 logical volume(s) in volume group “vg_mirror” now active

On peut démonter le FS, désactiver le vg et enlever le tag sur le serveur test_partage_vmdk_1 et vérifier qu’on peut bien le monter et écrire dessus sur le test_partage_vmdk_2.

Ce comportement est automatique sous RedHat Cluster Suite, qui gère lui même les tags lors de la bascule d’un VG/LV.

Sur test_partage_vmdk_1

umount /mnt
vgchange --deltag tag_vm1 -an vg_mirror

Sur test_partage_vmdk_2

vgchange --addtag tag_vm1 -ay vg_mirror
mount /dev/vg_mirror/lv_mirror /mnt

Have fun