Proxmox VE

Proxmox Openvz
Proxmox : migration KVM - OpenVZ
Proxmox sécurisation certificats SSL clients
KVM backup - snapshot - restore
Proxmox - Monter une image qcow2
Proxmox 4 - configuration de VLANs
Proxmox 4 - configuration bonding + bridge
Proxmox - Migration VMWare ESXi - Proxmox
Proxmox - convertir disque IDE vers Virtio
Proxmox - Installation d'une VM Windows server 2008R2
Proxmox 2.x - Installation, cluster (avec GlusterFS)
Proxmox 3.3 - Installation, configuration cluster
Proxmox 4.0 - Installation, configuration cluster

Proxmox Openvz

Container BlueOnyx

Télécharger un template de http://devel.blueonyx.it/openvz/ dans /var/lib/vz/template/cache
Le renommer (<OS>-<OSVERSION>-<NAME>_<VERSION>_<ARCH>.tar.gz) pour que Proxmox le voit
S'assurer qu'un fichier de config existe pour la blueonyx (dans /etc/vz/dists il cherche <OS>.conf)
- S'il n'existe pas : cp /etc/vz/dists/centos.conf /etc/vz/dists/blueonyx.conf

Créer la VZ :
- container (openVZ) et choisir le modèle (template)
- nom, RAM, disque, swap et mot de passe
- ethernet bridgé

AVANT DE LA DEMARRER LA PREMIERE FOIS
- aller dans l'onglet Options de la VM, activer les quotas (sinon le container BlueOnyx ne finit pas sa configuration, il manquera entre autres l'utilisateur admin), sauvegarder.
- paraméter le réseau : vzctl set 211 --ifname eth0 --ipadd 192.168.0.3 --save
- activer sys_time pour pouvoir changer la date/heure dans le container ensuite (voir ci-dessous)

Lancer la VM

Faire le premier paramétrage Blueonyx par l'interface web en :444

Activation sys_time

Activer la capacité sys_time (sinon on ne peut pas changer la date du container)

Arrêter la VM et activer sys_time :

vzctl stop 211
vzctl set 211 --capability sys_time:on --save

Relancer :

vzctl start 211

On peut modifier directement le fuseau horaire depuis la machine hote :
On entre dans le container :

vzctl enter 211

On définit par exemple le fuseau horaire de Paris:

mv /etc/localtime /etc/localtime.old
ln -s /usr/share/zoneinfo/Europe/Paris /etc/localtime

Modules IPTABLES

Si on veut utiliser un "stateful firewall" dans une machine virtuelle ("VE"), il faut que 'ipt_state' soit déclaré dans l'option IPTABLES du fichier /etc/vz/vz.conf du serveur physique ("HN") :

IPTABLES="ipt_REJECT ipt_tos ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state"

S'assurer que le module 'xt_state' est chargé aussi :

modprobe xt_state

et l'ajouter dans /etc/modules pour qu'il soit rechargé au redémarrage du HN.

migration KVM vers openVZ

https://kb.systea.fr/books/proxmox-ve/page/proxmox-migration-kvm-openvz

Templates

Site de templates :
https://src.openvz.org/projects/OVZT
http://wiki.openvz.org/Download/template/precreated
http://download.openvz.org

Le nom des templates doit obligatoirement respecter cette régle : <OS>-<OSVERSION>-<NAME>_<VERSION>_<ARCH>.tar.gz

EX :

archinux-2010.05-minimal_2010.05-1_amd64.tar.gz
blueonyx-5106R-standard_5.6-1_i386.tar.gz
debian-6.0-standard_6.0-4_i386.tar.gz

ATTENTION : Dans le menu Gestionnaire de VM => Modèles d'Appliance. Si la description des templates est -- unknown -- cela ne veut pas dire qu'il ne fonctionne pas

Proxmox : migration KVM - OpenVZ

Créer une machine virtuelle (VM) OpenVZ de mêmes caractéristiques que la VM KVM. Sur la VM KVM, stopper tous les services.

Debian

Sur le serveur Proxmox, si la VM KVM est accessible à l'adresse 192.168.0.100, et la VM OpenVZ a pour ID 211 :

rsync -avz --numeric-ids --exclude dev --exclude proc --exclude sys --exclude boot --exclude tmp -e "ssh -l root@192.168.0.100" root@192.168.0.100:/ /vz/private/211/ > migr2vz.log

Arrêter la VM OpenVZ. Activer la capacité sys_time (sinon on ne peut pas changer la date du container) :

vzctl stop 211
vzctl set 211 --save --capability sys_time:on

Relancer

vzctl start 211

Supprimer les paquets en trop :

apt-get remove grub-pc linux-image-* acpid

Relancer encore une fois par sécurité.

CentOS

TODO

Proxmox sécurisation certificats SSL clients

L'interface d'administration Proxmox est accessible en HTTPS, donc échanges cryptés et sécurisés par SSL. Les login/mot de passe demandés à la connexion ne passent donc pas en clair.

Pour encore plus de sécurité, on peut forcer le serveur à n'autoriser que les clients disposant d'un certificat local. Sans ce certificat généré avec le CA du serveur, le client n'arrive pas jusqu'à la page de login et reçoit une erreur (certificat erroné, ou certificat client requis, selon les navigateurs).

Sommaire

[masquer]

Installation

Création du certificat client

Eventuellement, modifier

/usr/share/ssl-cert/ssleay.cnf

pour intégrer le nom du serveur ("@HostName@" ne revoit pas toujours le hostname en question). Puis :

cd /tmp
mkdir ssl
cd ssl/
openssl genrsa -out proxmox-cli-cert.key 2048
openssl req -config /usr/share/ssl-cert/ssleay.cnf -new -key proxmox-cli-cert.key -out proxmox-cli-cert.req
openssl x509 -req -in proxmox-cli-cert.req -CA /etc/pve/pve-root-ca.pem -CAkey /etc/pve/pve-root-ca.key -set_serial 101 -days 3650 -outform PEM -out proxmox-cli-cert.pem

Puis on exporte ce certificat dans un format lisible par les navigateurs

openssl pkcs12 -export -inkey proxmox-cli-cert.key -in proxmox-cli-cert.pem -out proxmox-cli-cert.p12

Donner un mot de passe ET S'EN SOUVENIR !

Le fichier P12 contient tout ce qu'il faut, on peut supprimer le reste.

rm proxmox-cli-cert.req proxmox-cli-cert.key proxmox-cli-cert.pem

Configuration d'Apache

Editer /etc/apache2/sites-enabled/pve.conf. Après les lignes "SSLCertificate..." ajouter :

    SSLVerifyClient require
    SSLVerifyDepth 4
    SSLCACertificateFile /etc/pve/pve-root-ca.pem

Et ne pas oublier

/etc/init.d/apache2 reload

Utilisation

A partir d'un client sans certificat, vérifier que Proxmox interdit l'accès à l'interface web (on doit avoir une erreur du type "connexion réinitialisée").

Navigateurs

Télécharger le fichier p12 (par FTP, SCP, ou tout autre moyen). L'importer dans le navigateur.

Firefox

Edition / Préférences / Avancé / Chiffrement / Afficher les certificats / Vos certificats / Importer...

Chrome

Préférences / Options avancées / HTTPS/SSL / Gérer les certificats / Importer...

Une fois importé, vérifier que le navigateur accède (après validation) à la page de login

JAVA (pour les consoles VNCviewer)

Problème à résoudre : la console VNC ne fonctionne plus avec ces certificats.

Résolution temporaire : -> private.

Notes

Les certificats Proxmox (pve-root-ca) étant générés à l'installation, il contiennent un nom d'hôte générique "@HostName". C'est ce nom qui apparaitra dans le gestionnaire de certificats des navigateurs pour tous les serveur Proxmox.

KVM backup - snapshot - restore

Le backup des machines virtuelles KVM peut se faire de deux façons :

par snapshot LVM si la machine virtuelle est elle-même dans un volume logique, et qu'il existe un volum group LVM séparé pour les snapshots.

(En effet LVM refuse de créer le snapshot dans le même VG). Par défaut, Proxmox prend le volume pve qu'il a créé à l'installation pour le système : malheureusement, le volume logique "root" prend souvent déjà toute la place.

par suspension (ou arrêt) de la VM, puis copie tar.gz du disque virtuel vers un répertoire de backup.

Ce répertoire doit exister et avoir été ajouté comme emplacement dans storage, en paramétrant le contenu comme "VZDump backups".

Sauvegarde

Manuellement, VM arrêtée

vzdump --dumpdir /var/lib/vz/backup <ID de la VM>

Snapshot

par l'interface Proxmox, menu "Sauvegardes", cliquer sur la flèche et "ajouter un nouveau job".

Paramétrer les heures, la destination, les machines à sauvegarder. Indiquer le mode "snapshot".

Ou, pour une sauvegarde ponctuelle, en ligne de commande, par

vzdump --compress --dumpdir /var/lib/vz/backup --snapshot <ID de la VM>

Tar.gz

par l'interface Proxmox, menu "Sauvegardes", cliquer sur la flèche et "ajouter un nouveau job". Indiquer le mode "suspend".
Ou, pour une sauvegarde ponctuelle, en ligne de commande, par

vzdump --suspend <ID de la VM>

Restauration

Snapshot

TODO -

Tar.gz

Le backup se remonte en ligne de commande par :

qmrestore vzdump-qemu-103-2011_03_31-12_07_01.tgz 106

où le fichier tgz est celui créé par le backup, et "106" un ID de machine virtuelle disponible (elle n'a pas besoin d'être créée avant, qemu se débrouille de tout).

Si on souhaite remonter cette sauvegarde dans la même VM qu'avant, il faut d'abord supprimer celle-ci via l'interface puis lancer qmrestore avec son ancien ID.

NOTE : la configuration est restaurée aussi, donc si on utilise cette méthode pour cloner des VMs, attention aux adresses MAC des interfaces réseau qui sont restaurées à l'identique sur les clones !

Pour régénérer une nouvelle adresse MAC, supprimer et recréer l'interface réseau dans la configuration de la VM (Virtual machines/ double-clic sur la VM / onglet Hardware).

Ensuite plusiuers fichiers de conf peuvent devoir être modifiés :

CentOS

Modifier le fichier /etc/udev/rules.d/70-persistent-net.rules. On doit ici supprimer la ligne correspondant à l'interface copiée de l'ancienne vm (se référer aux adresses mac) et changer le champ "NAME=eth1" de la seconde en "NAME=eth0".

Enfin, dans le fichier /etc/sysconfig/network-scripts/ifcfg-eth0, changer la ligne HWADDR= avec l'adresse mac de la nouvelle interface.

Proxmox - Monter une image qcow2

Monter une image qcow2 comme un disque sur le host

# modprobe nbd
# qemu-nbd -c /dev/nbd0 /path/to/image.qcow2

ça charge le module Network Block Device kernel module et crée un device NBD.

Identifier la partition :

# fdisk -l /dev/nbd0

Et la monter :

# mount /mnt/vmroot /dev/nbd0p3

Une fois terminé, démonter la partition et décharger le module :

# umount /mnt/vmroot
# qemu-nbd -d /dev/nbd0
# rmmod nbd

NOTE: S'il y a des erreurs I/O, essayer l'option ‘-n’ de qemu-nbd pour désactiver le cache du host.

Proxmox 4 - configuration de VLANs

Contrairement à VMware qui propose de créer des "interfaces virtuelles" et des "réseaux virtuels", Proxmox/KVM a besoin de s'appuyer sur les interfaces physiques de l'hôte.

Pour créer des réseaux internes, on a donc deux possibilités :

une carte inutilisée sur l'hôte, qui sert de base au réseau "internal only"
des VLANs sur les cartes physiques, qui permettent de déclarer plusieurs adresses par cartes.

Pour ces VLANs, éditer /etc/network.interfaces, créer les VLANs, et déclarer des bridges dessus. Exemple :

auto vlan51
iface vlan51 inet manual
        vlan_raw_device eth1

auto vmbr1
iface vmbr1 inet static
        address 192.168.2.128
        netmask 255.255.255.0
        bridge_ports vlan51
        bridge_stp off
        bridge_fd 0

L'interface eth1 utilisée ci-dessus peut très bien avoir sa propre IP utilisable par l'hôte ou des VM pour accéder au "vrai" réseau.

Proxmox 4 - configuration bonding + bridge

NETWORK : Attention !

Si plusieurs cartes de l'hôte doivent être sur le même réseau, elles doivent être liée par bonding (voir ci-dessous), sinon ça pose un problème de route (il a la même route pour un network donné vers plusieurs interfaces. C'est la dernière configurée qui gagne, mais dans ce cas les interfaces précédentes ne répondent plus car elles ne savent plus router). On aurait pu imaginer répartir les VMs sur différentes interfaces physique de l'hôte pour faire de la répartition de charge, mais ça ne passe pas au niveau paramétrage.

Il faut mettre en place du bonding dans ce cas. Dans l'exemple suivant, eth0 et eth1 sont en bonding sur le réseau local, ET eth2 est connectée à un réseau publique. Le bonding sert de bridge aux machines virtuelles sur le réseau local, eth2 sert de bridge aux machines devant avoir accès au réseau publique (et pour un firewall par exemple, il accèdera aux 2 bridges).

Toute la configuration a été faite par l'interface, seule la gateway de vmbr1 a été ajoutée manuellement (le champ gateway n'apparaissait pas au départ dans l'interface web) :

# network interface settings
auto lo
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

iface eth2 inet manual

iface eth3 inet manual

auto bond0
iface bond0 inet manual
	 slaves eth0 eth1
	 bond_miimon 100
	 bond_mode active-backup

auto vmbr0
iface vmbr0 inet static
	 address  192.168.1.110
	 netmask  255.255.255.0
	 bridge_ports bond0
	 bridge_stp off
	 bridge_fd 0

auto vmbr1
iface vmbr1 inet static
	 address  10.12.0.2
	 netmask  255.255.255.0
	 gateway  10.12.0.254
	 bridge_ports eth2
	 bridge_stp off
	 bridge_fd 0

Proxmox - Migration VMWare ESXi - Proxmox

Migration VMware -> KVM

La transformation varie selon que la VM KVM de destination fonctionne en fichier qcow2 ou dans un volume logique (utile pour le cluster avec LVM).

Noter la taille du disque d'origine, le type de contrôleur, le nombre de CPU, la taille mémoire en prévision de la re-création de la VM KVM.

Arrêter la VM VMware. Le fichier d'origine ne sera pas touché, une sauvegarde n'est donc pas obligatoire.

Copier le disque de la VM vers le serveur Proxmox, avec vmkfstools (plus sûr et plus rapide que cp)

Migration en fichier qcow2

qemu-img convert -O qcow2 VM_vmware.vmdk VM_kvm.qcow2

Transfert dans un volume logique

Créer la machine virtuelle par l'interface (attention à la taille disque qui doit correspondre à la taille de la VM d'origine ! On peut la voir après conversion en raw, le fichier aura la taille exacte finale), de façon à ce que le volume logique existe. Puis :

dd if=VM_vmware.vmdk of=/dev/pve/vm-102-disk-1

Créer une VM proxmox, full virtualized, avec un disque de taille correspondante. Copier le disque migré dans le répertoire

NOTE : si la VM ne démarre pas ensuite (que ce soit en qcow2 ou en LVM, message "booting from hard disk...boot failed: not a bootable disk"), changer le disque vmdk en "preallocated". Le mode "single growable" (dynamique) peut poser problème lors de la migration. Sur une machine vmware (Server ou ESX) modifier le fichier avec :

vmware-vdiskmanager -r VM_vmware.vmdk -t 2 VM_vmware-pa.vmdk

Et retenter la conversion en qcow2 ou la copie vers le volume logique.

Proxmox - convertir disque IDE vers Virtio

Si on a monté une machine virtuelle linux en déclarant un disque IDE (ou si on récupère une image d'un autre hyperviseur), on peut vouloir monter le disque en VIRTIO pour augmenter les performances.

Problème : sur linux (CentOS au moins, à tester sur Debian), on a un kernel panic au boot car la machine virtuelle ne retrouve pas ses partitions. Le problème vient de l'initrd. Solution :

Machine virtuelle démarrée normalement, aller dans /boot
Vérifier dans /boot/grub/menu.lst quel est le noyau et l'initrd utilisés au boot (attention à l'option "default" ! On ne fera pas de cours sur Grub ici, ce n'est pas le sujet)
Sauvegarder l'initrd en question par "cp"
Générer un nouvel initrd (en s'assurant qu'il retrouve un nom compatible avec le menu.lst !) :

mkinitrd -f --with=virtio_pci --with=virtio_blk --with=virtio -f /boot/initrd-$(uname -r).img $(uname -r)

Eteindre la machine virtuelle
Dans l'onglet "Matériel" de Proxmox, supprimer le disque (par un clic sur la flèche à gauche du disque), puis re-ajouter ce même disque en virtio (sur la flèche de "Liste des interfaces matériel...", "ajouter un disque dur", dans la partie basse du tableau qui doit lister le disque en question, choisir VIRTIO et cliquer sur "add").
Lancer la VM

Proxmox - Installation d'une VM Windows server 2008R2

Drivers invité : https://github.com/YanVugenfirer/kvm-guest-drivers-windows

Direct 3D : http://www.nongnu.org/wined3d/

Utilisation du drivers graphique vmware : http://www.linux-kvm.com/content/using-vmware-vga-kvm-windows-guests

Proxmox 2.x - Installation, cluster (avec GlusterFS)

Installation à partir des ISO

Le problème de l'installation à partir des CD est que le partitionnement est automatique, et impossible à modifier. Jusqu'à la version 2, la partition root était un pourcentage de l'espace total, ce qui pouvait amener à avoir des centaines de Go pour le système ! Depuis la version 2.xx, la partition racine semble être dimensionnée à une centaine de Go quelque soit la taille disponible. Mais c'est encore énorme, pour un système qui n'a besoin que d'à peine 800Mb de base ! Mais admettons...

L'installation est on ne peut plus simple : graver l'ISO téléchargée chez Proxmox (http://pve.proxmox.com/wiki/Downloads), booter sur le CD, suivre les indications... Voilà.

Installation manuelle sur Squeeze par les paquets deb

D'après http://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Squeeze

Installer une Squeeze de base, avec une partition root (10Go minimum) et une partition LVM (Volum Group "pve", et un volume logique "data" pour respecter leurs nommages) montée sur /var/lib/vz qui recevra les machines virtuelles. Avec la Squeeze, on peut utiliser ext3 ou ext4.

Editer /etc/apt/sources.list

Ajouter "contrib" aux lignes "[...] squeeze main" s'il n'y est pas déjà
Ajouter :

# PVE packages provided by proxmox.com
deb http://download.proxmox.com/debian squeeze pve

Charger la clé de signature des paquets Proxmox

wget -O- "http://download.proxmox.com/debian/key.asc" | apt-key add -
apt-get update
aptitude full-upgrade

Activer l'IP forwarding :

echo 1 > /proc/sys/net/ipv4/ip_forward

Et enregistrer la modification dans /etc/sysctl.conf pour les prochains redémarrages :

net.ipv4.ip_forward=1

Installer le noyau Proxmox

aptitude search pve-kernel # trouver le noyau pve le plus récent
aptitude install pve-firmware
aptitude install pve-kernel-2.6.32-19-pve
reboot
uname -a # vérifier que le noyau PVE est chargé
  Linux proxmox1 2.6.32-19-pve #1 SMP [.....] x86_64 GNU/Linux

IMPORTANT : vérifier que le nom du serveur correspond bien à son ip dans le fichier /etc/hosts, exemple :

10.0.0.2        proxmox1.localdomain       proxmox1

L'installation de Proxmox cherche l'adresse IP et le nom de serveur dans /etc/hosts.

Installer Proxmox VE

aptitude install proxmox-ve-2.6.32

Si quelque chose s'est mal passé pendant l'installation, corriger le problème et finir l'installation par

apt-get install -f

Activer l'interface webUI

a2ensite pve-redirect.conf
/etc/init.d/apache2 restart

Installer le reste des paquets nécessaires

aptitude install ntp ssh lvm2 postfix ksm-control-daemon vzprocps open-iscsi

Accepter le remplacement d'Exim, paramétrer Postfix selon le réseau ("site internet" par défaut)

Accéder à l'interface d'admin (login root du serveur)

https://<adresse du serveur>:8006/

Dans l'onglet réseau, enlever les paramètres d'eth0, paramétrer le bridge vmbr0 (eth0 en "bridge port")

Note : Proxmox VE copie le fichier de configuration (ici /etc/network/interfaces, mais c'est ne même principe pour les fichiers proxmox eux-mêmes dans /etc/pve) en <nom_du_fichier>.new. Au prochain redémarrage, ces fichiers prendront la place des fichiers des "vrais" et la nouvelle configuration sera prise en compte durant le boot du système.

Le fichier interfaces.new doit ressembler à ça (ATTENTION AU "bridge_stp on" et pas "off") :

# network interface settings
auto lo
iface lo inet loopback

iface eth0 inet manual
	broadcast  10.255.255.255
	network 10.0.0.0
	dns-nameservers 10.0.0.254
	dns-search local.systea.net
# dns-* options are implemented by the resolvconf package, if installed

iface eth1 inet manual

auto vmbr0
iface vmbr0 inet static
	address  10.0.0.2
	netmask  255.0.0.0
	gateway  10.0.0.254
	bridge_ports eth0
	bridge_stp on
	bridge_fd 0

TIPS : Pour lier 2 cartes réseau et faire du "bonding", éditer manuellement ce fichier (au besoin, le créer en copiant le fichier interfaces) et modifier la configuration en ajoutant "bond0" pour lier eth0 et eth1 par exemple, et lier vmbr0 à cette nouvelle interface :

# network interface settings
auto lo
iface lo inet loopback

iface eth0 inet manual

iface eth1 inet manual

auto bond0
iface bond0 inet manual
	slaves eth0 eth1
	bond_miimon 100
       bond_mode active-backup

auto vmbr0
iface vmbr0 inet static
	address  10.0.0.2
	netmask  255.0.0.0
	gateway  10.0.0.254
	bridge_ports bond0
	bridge_stp off
	bridge_fd 0

Activer la configuration :

reboot

Mise en cluster

Création du cluster

D'après http://pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster

Si les DNS ne sont pas disponibles sur le réseau, paramétrer /etc/hosts sur chaque serveur du cluster pour qu'ils se reconnaissent entre eux (IP et nom).

Créer le cluster sur un des noeuds

pvecm create YOUR-CLUSTER-NAME

Et vérifier :

pvecm status

Aller sur chacun des autres noeuds et les ajouter au cluster

pvecm add IP-DU-PREMIER-NOEUD-DU-CLUSTER

Après échange de clés, le nouveau noeud doit apparaitre dans l'interface web.

Attention, les clés SSL des noeuds "secondaires" ont changé pendant ce processus (identiques sur tous les noeuds à celles du premier noeud), vider le cache du navigateur et se reconnecter à l'interface.

Fencing

La configuration des fencing devices sur Proxmox est manuelle.

D'abord, tester si les fencing device sont joignables et si on a les bons paramètres. Proxmox installe les outils pour la plupart des cartes connues, exemple :
(On utilise fence_ilo ici, mais cette commande varie en fonction de la marque du matériel (ex: fence_drac, fence_ipmi...). fence_ilo est associé au matériel HP)

fence_ilo -o status -a 192.168.0.2 -l admin -p mot_de_passe
 Status: ON

Pour un matériel IPMI (par exemple Dell iDrac), installer ipmitool

apt-get install ipmitool

Puis:

fence_ipmilan -a 192.168.0.2 -l admin -p mot_de_passe -o status
 Getting status of IPMI:192.168.0.2...Chassis power = On

Pour un Dell iDrac7, ajouter les argument "-P" et "-C 2"

fence_ipmilan -a 192.168.0.2 -l root -p root -o status -P -C 2

Sur tous les noeuds : vi /etc/default/redhat-cluster-pve

FENCE_JOIN="yes"

Joindre le noeud au domaine de fencing

fence_tool join
fence_tool ls

Sur un des noeuds, on va modifier cluster.conf. On commence par le copier en .new et on édite celui-ci

cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new
vi /etc/pve/cluster.conf.new

Première chose : augmenter le "config_version", sinon le fichier ne sera pas répliqué sur les autres noeuds !

<cluster name="hpiloclust" config_version="2">

Ajouter la definition des fencing devices à utiliser, juste après </clusternodes>

<fencedevices>
       <fencedevice agent="fence_ipmilan" hostname="nomDNS_du_fencing_device_nodeA" login="admin" name="fenceNodeA" passwd="mot_de_passe"/>
       <fencedevice agent="fence_idrac" ipaddr="IP_du_fencing_device_nodeB" login="admin" name="fenceNodeB" passwd="mot_de_passe"/>
</fencedevices>

Noter l'utilisation de "hostname" ou "ipaddr" selon ce qu'on choisit d'indiquer.

Puis, enlever le "/" à la fin de chaque stanza "clusternode" (au singulier) et lier le "fence device" au "clusternode" :

<clusternode name="nodeA.your.domain" nodeid="1" votes="1">
  <fence>
      <method name="1">
         <device name="fenceNodeA" action="reboot"/>
      </method>
  </fence>
</clusternode>
<clusternode name="nodeB.your.domain" nodeid="2" votes="1">
  <fence>
      <method name="1">
         <device name="fenceNodeB" action="reboot"/>
      </method>
  </fence>
</clusternode>

Valider la nouvelle configuration :

ccs_config_validate -v -f /etc/pve/cluster.conf.new

Aller sur l'interface graphique, sélectionner le datacenter à gauche puis l'onglet HA.

Il charge alors le cluster.conf.new, vérifie la syntaxe (corriger les erreurs éventuelles qu'il affiche avec numéro de ligne et colonne) et affiche en bas les modifications à faire. Si c'est OK, cliquer sur Activer (bouton "Activate" dans la barre de menu).

Haute disponibilité

Pour qu'une VM soit prise en compte dans la haute dispo (migration en cas de crash), sélectionner le datacenter à gauche, onglet "HA", bouton "Ajouter", une "VM/CT gérée par HA"

Indiquer l'ID de la VM à prendre en compte.

Valider, Activer la modification.

Des erreurs de migrations (mauvaise configuration, etc...) peuvent "verrouiller" la VM et empêcher des migrations futures (erreur 254 en général). Pour débloquer il faut stopper la VM proprement pour ne rien perdre, puis clic droit sur la VM à gauche et "Stopper" (le bouton Stopper n'est pas disponible en haut à droite à ce moment, que dans le menu contextuel)

GLusterFS

Glusterfs permet très simplement et de façon fiable d'avoir un système de fichiers partagé, répliqué et/ou distribué entre plusieurs serveurs. Le répertoire géré par GlusterFS sera vu comme un partage NFS dans Proxmox.

http://gluster.org/community/documentation//index.php/Main_Page

Sur tous les noeuds :

Ajouter la clé gluster.org :

wget -O - http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/gpg.key | apt-key add -

Ajouter le dépôt Glusterfs :

vi /etc/apt/sources.list.d/glusterfs.list
  deb http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/squeeze.repo squeeze main

Et installer le serveur (le client suivra en dépendance) :

aptitude install glusterfs-server

Préparer le terrain :

mkdir /var/lib/glusterfs

Sur un seul des noeuds, connecter un ou plusieurs autres noeuds et créer un volume. Exemple, à partir de "node1", on ajoute "node2" et on crée un volume répliqué sur les 2 machines (RAID1) :

gluster peer probe node2
gluster volume create glusterstorage replica 2 node1:/var/lib/glusterfs node2:/var/lib/glusterfs
gluster volume start glusterstorage

Pour ajouter un serveur (une "brique") par la suite, sur n'importe lequel des noeud existant taper :

gluster peer probe node3
gluster volume add-brick glusterstorage replica 3 proxmox3:/var/lib/glusterfs
gluster volume info

Dans l'interface, Créer un stockage NFS, sur localhost : le volume gluster est vu tout de suite comme partage NFS, et monté en localhost sur tous les noeuds.

Fonctionnement du cluster

le répertoire /etc/pve est en réalité un device FUSE (monté en mémoire, en espace utilisateur) afin d'être répliqué par Corosync et sauvegardé sur disque dans une base SQLite.

On modifie (ou l'interface modifie) les fichiers en créant une copie en .new. Au moment de la validation (ou du reboot, comme pour la configuration réseau) ce fichier remplace le "vrai" et celui-ci est répliqué sur tous les noeuds.

Pour basculer toutes les VM sur un autre host (pour maintenance par exemple) arrêter le Resource Group manager (par l'interface, onglet Services, ou en ligne de commande "/etc/init.d/rgmanager stop").

Ligne de commande

clustat # Etat du cluster

ccs_config_validate -v -f /etc/pve/cluster.conf.new # Validation des modifications apportées

ccs_tool lsnode -v # Détail des noeuds

Migration à froid (arrêt de la VM avant migration, ou pour une VM déjà arrêtée)

clusvcadm -r pvevm:101 -m proxmox2

Migration à chaud

clusvcadm -M pvevm:101 -m proxmox2

TIPS

Drivers virtio pour Windows

Charger l'iso virtio-win : http://www.linux-kvm.org/page/WindowsGuestDrivers/Download_Drivers

pendant l'install de Windows dans la VM, l'écran de sélection de disque n'affiche aucun préiphérique. Sur la VM, dans l'interface web, changer le CD et charger virtio-win. Demander à l'installateur windows de parcourir ce CD, sélectionner la version win voulue et charger les drivers redhat*. Une fois chargés, Windows doit voir le disque. Remettre le CD Windows dans le lecteur virtuel.

Clavier français dans les consoles VNC

Dans l'onglet options du datacenter, forcer le clavier en French. Si ça ne suffit pas, sur les VM dans l'onglet Matériel, faire de même (il faut redémarrer la VM dans ce cas)

Proxmox 3.3 - Installation, configuration cluster

Installation

Une fois installé, l'accès à l'interface web se fait à l'adresse https://<IP du serveur>:8006

Configuration

Mises à jour

Depuis la version 3, les éditeurs de Proxmox ont modifié les dépôts. Les dépôts configurés de base sont réservés aux clients qui ont souscrit au support de Proxmox. N'étant pas notre cas, il faut modifier les sources pour accéder aux dépôts gratuits. REMPLACER le contenu du fichier source.list

# vi /etc/apt/sources.list

Par :

deb http://ftp.debian.org/debian wheezy main contrib

# PVE pve-no-subscription repository provided by proxmox.com, NOT recommended for production use
deb http://download.proxmox.com/debian wheezy pve-no-subscription

# security updates
deb http://security.debian.org/ wheezy/updates main contrib

Puis supprimer le fichier qui contient le dépôt par défaut. Ceci évite des messages d'erreurs (connection refusée) lors des "apt-get update".

rm /etc/apt/sources.list.d/pve-enterprise.list

On peut maintenant effectuer les mises à jour

apt-get update
apt-get install debian-keyring debian-archive-keyring
apt-get upgrade

IMPORTANT : upgrade met à jour les paquets mais pas le noyau. Si celui-ci doit être mis à jour (exemple : zfs 0.6.4-4~wheezy demande le noyau 2.6.32-40 spécialement adapté pour cette version), lancer plutôt :

apt-get dist-upgrade

Fichiers hosts

Il faut modifier les fichiers /etc/hosts sur chacun des noeuds qui seront ajoutés au cluster. Ceux-ci doivent contenir les adresses et noms de tous les noeuds. Exemple :

Sur le noeud "pm0" :

root@pm0 : #cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
10.10.168.5    pm0.local           pm0  pvelocalhost
10.10.168.10   pm1.local           pm1
10.10.168.15   pm2.local           pm2

Sur un second noeud :

root@pm2 : #cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
10.10.168.5    pm0.local           pm0  
10.10.168.10   pm1.local           pm1
10.10.168.15   pm2.local           pm2 pvelocalhost

Mise en cluster

On considère ici deux machines Proxmox fraîchement installées à l'identique. Pour fonctionner en cluster, il faut définir un noeud Maître. Sur une des deux machines éxecuter

pvecm create <nom_du_cluster>

Pour vérifier la création du cluster, lancer

# pvecm status

Version: 6.2.0
Config Version: 1
Cluster Name: FWCluster
Cluster Id: 40372
Cluster Member: Yes
Cluster Generation: 4
Membership state: Cluster-Member
Nodes: 1
Expected votes: 1
Total votes: 1
Node votes: 1
Quorum: 1  
Active subsystems: 5
Flags: 
Ports Bound: 0  
Node name: herrena
Node ID: 1
Multicast addresses: 239.192.157.82  
Node addresses: 192.168.37.11

Une fois le cluster créé, il faut ajouter la seconde machine. Pour cela, sur le second Proxmox, lancer la commande :
(où l'adresse IP correspond à celle du nœud Maître)

pvecm add <adresse_du_maitre>

Echangez les clés, puis vérifier l'ajout

pvecm status

Si cette commande fonctionne sur le second nœud, l'ajout a fonctionné. On peut s'en assurer en regardant dans la sortie de la commande précédente, la ligne :

Nodes: 2

Fencing

La configuration des fencing devices sur Proxmox est manuelle.

fence_ilo -o status -a 192.168.0.2 -l admin -p mot_de_passe
 Status: ON

Pour un matériel IPMI (par exemple Dell iDrac), installer ipmitool

apt-get install ipmitool

Puis:

fence_ipmilan -a 192.168.0.2 -l admin -p mot_de_passe -o status
 Getting status of IPMI:192.168.0.2...Chassis power = On

Pour un Dell iDrac7, ajouter les argument "-P" et "-C 2"

fence_ipmilan -a 192.168.0.2 -l root -p root -o status -P -C 2

Sur tous les noeuds : vi /etc/default/redhat-cluster-pve

FENCE_JOIN="yes"

Joindre le noeud au domaine de fencing

fence_tool join
fence_tool ls

Sur un des noeuds, on va modifier cluster.conf. On commence par le copier en .new et on édite celui-ci

cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new
vi /etc/pve/cluster.conf.new

Première chose : augmenter le "config_version", sinon le fichier ne sera pas répliqué sur les autres noeuds !

<cluster name="hpiloclust" config_version="2">

Ajouter la definition des fencing devices à utiliser, juste après </clusternodes>

<fencedevices>
       <fencedevice agent="fence_ipmilan" hostname="nomDNS_du_fencing_device_nodeA" login="admin" name="fenceNodeA" passwd="mot_de_passe"/>
       <fencedevice agent="fence_idrac" ipaddr="IP_du_fencing_device_nodeB" login="admin" name="fenceNodeB" passwd="mot_de_passe" cipher="2" lanplus="on"/>
</fencedevices>

Noter l'utilisation de "hostname" ou "ipaddr" selon ce qu'on choisit d'indiquer. Noter également la présence de paramètre supplémentaires, ajoutés selon les besoins, comme par exemple cipher="2" et lanplus="on" (IDrac 7).

Puis, enlever le "/" à la fin de chaque stanza "clusternode" (au singulier) et lier le "fence device" au "clusternode" :

<clusternode name="nodeA.your.domain" nodeid="1" votes="1">
  <fence>
      <method name="1">
         <device name="fenceNodeA" action="reboot"/>
      </method>
  </fence>
</clusternode>
<clusternode name="nodeB.your.domain" nodeid="2" votes="1">
  <fence>
      <method name="1">
         <device name="fenceNodeB" action="reboot"/>
      </method>
  </fence>
</clusternode>

Valider la nouvelle configuration :

ccs_config_validate -v -f /etc/pve/cluster.conf.new

Aller sur l'interface graphique, sélectionner le datacenter à gauche puis l'onglet HA.

GLusterFS

http://gluster.org/community/documentation//index.php/Main_Page

Sur tous les noeuds :

Ajouter la clé gluster.org :

wget -O - http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/gpg.key | apt-key add -

Ajouter le dépôt Glusterfs :

vi /etc/apt/sources.list.d/glusterfs.list
  deb http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/squeeze.repo squeeze main

Et installer le serveur (le client suivra en dépendance) :

aptitude install glusterfs-server

Préparer le terrain (la partition partagée sera dans le volume des VMs de Proxmox):

mkdir /var/lib/vz/glusterfs

Sur un seul des noeuds, connecter un ou plusieurs autres noeuds et créer un volume. Exemple, à partir de "node1", on ajoute "node2" et on crée un volume répliqué sur les 2 machines (RAID1) :

gluster peer probe node2
gluster volume create glusterstorage replica 2 node1:/var/lib/vz/glusterfs node2:/var/lib/vz/glusterfs
gluster volume start glusterstorage

Pour ajouter un serveur (une "brique") par la suite, sur n'importe lequel des noeud existant taper :

gluster peer probe node3
gluster volume add-brick glusterstorage replica 3 node3:/var/lib/vz/glusterfs
gluster volume info

Accès par la librairie glusterfs

Dans l'interface, Créer un stockage GlusterFS, remplissez les champs Serveur principal et Serveur secondaire avec les noms de vos serveurs. Dans le menus déroulant Nom du volume devrait apparaître le volume que vous avez créé précédemment (ici "glusterstorage").

Accès en NFS

Dans l'interface, Créer un stockage NFS, remplissez le champ Serveur avec "localhost". Dans le menus déroulant Nom du volume devrait apparaître le volume que vous avez créé précédemment (ici "glusterstorage").

Benchmark librairie glusterfs / NFS

La différence est notable. En fonctionnement en HA, proxmox est capable de migrer une machine, lorsqu'il perd un noeud du cluster, sur un second. Ceci est vrai seulement avec la librairie NFS. De notre expérience, non seulement les machines ne sont pas migrées, mais les disques virtuels sont parfois endommagés !

Quorum

Le Quorum est une partition partagée, à partir d'une troisième machine, qui permet d'utiliser la HA. Cette machine sert en fait de référent aux Proxmox, qui ont parfois du mal à déterminer s'il y a une panne ou non dans un configuration avec uniquement 2 noeuds Proxmox. On ajoute donc de la stabilité et une couche de sécurité pour les VMs/données.

Cette troisième machine sera ici une CentOS 6.5.

iSCSI

iSCSI est choisi pour partager la partition entre les différents noeuds du cluster.

Pour commencer, créer la partition. (Réduire une autre si cela est nécessaire, en théorie QDisk n'utilise qu'une partition de 10Mo)

lvcreate -n quorumdisk -L 10M vg_QUORUM

Installer le serveur iSCSI :

yum -y install scsi-target-utils # (nom du paquet sous CentOS)

Important ! : le port 3260 doit être ouvert pour permettre les connexions à la cible iSCSI.

Créer ensuite la cible iSCSI (Des conventions de nommage ont été mises en place. Il est recommandé de les utiliser : http://en.wikipedia.org/wiki/ISCSI#Addressing)

# vim /etc/tgt/targets.conf

<target iqn.2012-06.com.domain.hostname:server.p1qdisk>
   backing-store /dev/vg_QUORUM/quorumdisk
   initiator-address <IP_du_noeud_1>
   initiator-address <IP_du_noeud_2>
</target>

Démarrer ensuite le service tgt, et le paramétrer pour le démarrage automatique :

service tgtd start
chkconfig tgtd on
tgt-admin -s    #notre volume doit apparaître ici

Il faut maintenant monter la cible sur les Proxmox. Installer tgt (il installe open-iscsi en dépendance sur le client, c'est lui dont on a besoin) :

apt-get install tgt # (nom du paquet sous Debian / Proxmox).

Modifier ensuite le fichier /etc/iscsi/iscsid.conf. Le champ node.startup doit être configuré en automatic

#vim /etc/iscsi/iscsid.conf

...
#*****************
# Startup settings
#*****************

# To request that the iscsi initd scripts startup a session set to "automatic".
# node.startup = automatic
#
# To manually startup the session set to "manual". The default is manual.
node.startup = automatic
...

Redémarrer le client iscsi :

service open-iscsi restart

On peut maintenant tester quelles cibles les clients voient :

iscsiadm --mode discovery --type sendtargets --portal <IP_du_ serveur iSCSI>

Puis se connecter à la cible qui nous interesse :

iscsiadm -m node -T iqn.BLAHBLAH -p <IP_du_serveur_iSCSI> -l

Configurer QDisk

Il faut identifier la partition qui correspond au volume logique précédemment créé. On crée ensuite une partition sur celui-ci, via fdisk (ici sdc1 mais peut varier suivant la configuration de votre système). Une fois ceci fait on peut créer le disque de Quorum :

mkqdisk -c /dev/sdc1 -l qdisk_proxmox
#Noter que le paramètre -l est suivi du nom que vous souhaitez donner à votre disque de Quorum

Déconnecter et reconnecter les clients pour voir les changements :

iscsiadm --mode node --target <IQN> --portal x.x.x.x --logout
iscsiadm --mode node --target <IQN> --portal x.x.x.x --login

Ajouter QDisk au cluster

Sur un des deux noeuds :

Copier le fichier cluster.conf en cluster.conf.new

cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new

Editer ce fichier en prenant soins de :
1) Incrémenter "config_version" de 1
2) Supprimer 2node="1"
3) Ajouter la définition du Quorum

Cela doit ressembler à peu près à ceci :

 <cman expected_votes="3" keyfile="/var/lib/pve-cluster/corosync.authkey"/>
 <quorumd votes="1" allow_kill="0" interval="1" label="qdisk_proxmox" tko="10"/>
 <totem token="54000"/>

Activer les modifications : Sur l'interface Web de Proxmox, selectionner le datacenter (dans le menu de gauche) puis sélectionner l'onglet HA. On voit ici apparaître le fichier fraîchement modifié. cliquer sur Activate pour charger les modifications dans le cluster.

Lancer la commande pvecm s et vérifier que les deux noeuds on bien reçu les modifications du cluster.conf. Puis sur chacun des noeuds, un à la fois :

service rgmanager stop
service cman reload

la dernière commande devrait reancer rgmanager, si non, relancez le manuellement.

Vérification On peut utiliser la commande clustat pour vérifier que le quorum est présent et connecté

#clustat
Cluster Status for proxmox1 @ Mon Nov 24 16:46:23 2014
Member Status: Quorate

Member Name                                         ID   Status
------ ----                                         ---- ------
proxmox1                                              1 Online, Local, rgmanager
proxmox2                                              2 Online, rgmanager
/dev/block/8:16                                     0 Online, Quorum Disk

Astuces et notes

Supprimer l'avertissement de souscription

Lorsqu'on utilise Proxmox 3 sans souscription, un message apparrait à chaque login sur l'interface web. Pour se débarrasser de ce message, il faut modifier le fichier pvemanagerlib.js. On commence par sauvegarder le fichier d'origine :

# cp /usr/share/pve-manager/ext4/pvemanagerlib.js /usr/share/pve-manager/ext4/pvemanagerlib.js.OLD

Puis on édite

# vim /usr/share/pve-manager/ext4/pvemanagerlib.js

Il faut chercher l'instruction IF de la forme suivante :

if (data.status !== 'Active') {
Ext.Msg.show({
                       title: gettext('No valid subscription'),
                       icon: Ext.Msg.WARNING,
                       msg: PVE.Utils.noSubKeyHtml,
                       buttons: Ext.Msg.OK,

En fait, Proxmox teste si on a un abonnement non actif, auquel cas, il affiche le message. Il nous suffit donc de remplacer le test par false

if (false) {
Ext.Msg.show({
                       title: gettext('No valid subscription'),
                       icon: Ext.Msg.WARNING,
                       msg: PVE.Utils.noSubKeyHtml,
                       buttons: Ext.Msg.OK,

Problèmes connus avec QDisk

Les noeuds Proxmox utilisent iSCSI pour se connecter au disque de Quorum partagé. Les machines proxmox, au démarrage, lancent une connexion à la cible iSCSI. Or, si la machine de Quorum n'est pas présente lors de cette étape, les connexion échouent logiquement. Les proxmox ne sont ensuite pas capables de se reconnecter automatiquement au disque de quorum, il faut soit les redémarrer, soit connecter la cible manuellement, en ligne de commande. Bien que ce soit un scénario plus rare, il est toujours bon de savoir quoi faire.

Proxmox 4.0 - Installation, configuration cluster

Installation

L'installation se fait à partir de l'image ISO (http://www.proxmox.com/downloads). L'installation est simple, se fait par une interface graphique mais ne propose toujours pas de partitionner manuellement les disques. La particularité de la version 4 est qu'on peu (enfin !) décider de la taille de la partition root et de celle des données. Au moment de sélectionner le disque où sera installé Proxmox, cliquer sur "options", indiquer au moins : taille de la swap (en Go, idéalement 2*taille de la RAM) et taille de la partition root (20Go doivent suffire au système).

Une fois installé, l'accès à l'interface web se fait à l'adresse https://<IP du serveur>:8006

Configuration

Mises à jour

# vi /etc/apt/sources.list

Ajouter :

# PVE pve-no-subscription repository provided by proxmox.com, NOT recommended for production use
deb http://download.proxmox.com/debian jessie pve-no-subscription

Puis supprimer le fichier qui contient le dépôt par défaut. Ceci évite des messages d'erreurs (connection refusée) lors des "apt-get update".

rm /etc/apt/sources.list.d/pve-enterprise.list

On peut maintenant effectuer les mises à jour

apt-get update
apt-get install debian-keyring debian-archive-keyring
apt-get dist-upgrade

"apt-get upgrade" met à jour les paquets mais pas le noyau. C'est pourquoi on lui préfère dist-upgrade au moment de l'installation.

Fichiers hosts

Il faut modifier les fichiers /etc/hosts sur chacun des noeuds qui seront ajoutés au cluster. Ceux-ci doivent contenir les adresses et noms de tous les noeuds. Exemple :

Sur le noeud "pm0" :

root@pm0 : #cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
10.10.168.5    pm0.local           pm0  pvelocalhost
10.10.168.10   pm1.local           pm1
10.10.168.15   pm2.local           pm2

Sur un second noeud :

root@pm2 : #cat /etc/hosts
127.0.0.1 localhost.localdomain localhost
10.10.168.5    pm0.local           pm0  
10.10.168.10   pm1.local           pm1
10.10.168.15   pm2.local           pm2 pvelocalhost

Mise en cluster

On considère ici deux machines Proxmox fraîchement installées à l'identique. Pour fonctionner en cluster, il faut définir un noeud Maître. Sur une des deux machines éxecuter

pvecm create <nom_du_cluster>

Pour vérifier la création du cluster, lancer

# pvecm status

Version: 6.2.0
Config Version: 1
Cluster Name: FWCluster
Cluster Id: 40372
Cluster Member: Yes
Cluster Generation: 4
Membership state: Cluster-Member
Nodes: 1
Expected votes: 1
Total votes: 1
Node votes: 1
Quorum: 1  
Active subsystems: 5
Flags: 
Ports Bound: 0  
Node name: herrena
Node ID: 1
Multicast addresses: 239.192.157.82  
Node addresses: 192.168.0.5

Une fois le cluster créé, il faut ajouter la seconde machine. Pour cela, sur le second Proxmox, lancer la commande :
(où l'adresse IP correspond à celle du nœud Maître)

pvecm add <adresse_du_maitre>

Echangez les clés, puis vérifier l'ajout

pvecm status

Si cette commande fonctionne sur le second nœud, l'ajout a fonctionné. On peut s'en assurer en regardant dans la sortie de la commande précédente, la ligne :

Nodes: 2

Fencing

le "fencing" est l'action pour une machine d'interagir sur une autre host en l'arrêtant, ou le redémarrant, via un "fencing device" souvent implémenté par les contructeurs sur des "management cards" (BMC, DRAC, ILO, ...). Depuis la version 4, le fencing est géré par Watchdog et est automatiquement configuré. Joie et bonheur. Si le matériel dispose d'un watchdog, il est détecté et utilisé. Sinon Proxmox utilise le module linux softdog.

GLusterFS

http://gluster.org/community/documentation//index.php/Main_Page

Sur tous les noeuds :

Ajouter la clé gluster.org et le dépôt Glusterfs :

wget -O - http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.6/pub.key | apt-key add -
echo deb http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.6/Debian/jessie/apt jessie main > /etc/apt/sources.list.d/gluster.list 
apt-get update

Et installer le serveur (le client suivra en dépendance) :

aptitude install glusterfs-server

Préparer le terrain (la partition partagée sera dans le volume des VMs de Proxmox):

mkdir /var/lib/vz/glusterfs

Sur un seul des noeuds, connecter un ou plusieurs autres noeuds et créer un volume. Exemple, à partir de "node1", on ajoute "node2" et on crée un volume répliqué sur les 2 machines (RAID1) :

gluster peer probe node2
gluster volume create glusterstorage replica 2 node1:/var/lib/vz/glusterfs node2:/var/lib/vz/glusterfs
gluster volume start glusterstorage

Pour ajouter un serveur (une "brique") par la suite, sur n'importe lequel des noeud existant taper :

gluster peer probe node3
gluster volume add-brick glusterstorage replica 3 node3:/var/lib/vz/glusterfs
gluster volume info

Accès par la librairie glusterfs

Accès en NFS

Benchmark librairie glusterfs / NFS

Quorum

Cette troisième machine sera ici une CentOS 6.5.

iSCSI

iSCSI est choisi pour partager la partition entre les différents noeuds du cluster.

Pour commencer, créer la partition. (Réduire une autre si cela est nécessaire, en théorie QDisk n'utilise qu'une partition de 10Mo)

lvcreate -n quorumdisk -L 10M vg_QUORUM

Installer le serveur iSCSI :

yum -y install scsi-target-utils # (nom du paquet sous CentOS)

Important ! : le port 3260 doit être ouvert pour permettre les connexions à la cible iSCSI.

Créer ensuite la cible iSCSI (Des conventions de nommage ont été mises en place. Il est recommandé de les utiliser : http://en.wikipedia.org/wiki/ISCSI#Addressing)

# vim /etc/tgt/targets.conf

<target iqn.2012-06.com.domain.hostname:server.p1qdisk>
   backing-store /dev/vg_QUORUM/quorumdisk
   initiator-address <IP_du_noeud_1>
   initiator-address <IP_du_noeud_2>
</target>

Démarrer ensuite le service tgt, et le paramétrer pour le démarrage automatique :

service tgtd start
chkconfig tgtd on
tgt-admin -s    #notre volume doit apparaître ici

Il faut maintenant monter la cible sur les Proxmox. Installer tgt (il installe open-iscsi en dépendance sur le client, c'est lui dont on a besoin) :

apt-get install tgt # (nom du paquet sous Debian / Proxmox).

Modifier ensuite le fichier /etc/iscsi/iscsid.conf. Le champ node.startup doit être configuré en automatic

#vim /etc/iscsi/iscsid.conf

...
#*****************
# Startup settings
#*****************

# To request that the iscsi initd scripts startup a session set to "automatic".
# node.startup = automatic
#
# To manually startup the session set to "manual". The default is manual.
node.startup = automatic
...

Redémarrer le client iscsi :

service open-iscsi restart

On peut maintenant tester quelles cibles les clients voient :

iscsiadm --mode discovery --type sendtargets --portal <IP_du_ serveur iSCSI>

Puis se connecter à la cible qui nous interesse :

iscsiadm -m node -T iqn.BLAHBLAH -p <IP_du_serveur_iSCSI> -l

Configurer QDisk

mkqdisk -c /dev/sdc1 -l qdisk_proxmox
#Noter que le paramètre -l est suivi du nom que vous souhaitez donner à votre disque de Quorum

Déconnecter et reconnecter les clients pour voir les changements :

iscsiadm --mode node --target <IQN> --portal x.x.x.x --logout
iscsiadm --mode node --target <IQN> --portal x.x.x.x --login

Ajouter QDisk au cluster

Sur un des deux noeuds :

Copier le fichier cluster.conf en cluster.conf.new

cp /etc/pve/cluster.conf /etc/pve/cluster.conf.new

Editer ce fichier en prenant soins de :
1) Incrémenter "config_version" de 1
2) Supprimer 2node="1"
3) Ajouter la définition du Quorum

Cela doit ressembler à peu près à ceci :

 <cman expected_votes="3" keyfile="/var/lib/pve-cluster/corosync.authkey"/>
 <quorumd votes="1" allow_kill="0" interval="1" label="qdisk_proxmox" tko="10"/>
 <totem token="54000"/>

Lancer la commande pvecm s et vérifier que les deux noeuds on bien reçu les modifications du cluster.conf. Puis sur chacun des noeuds, un à la fois :

service rgmanager stop
service cman reload

la dernière commande devrait reancer rgmanager, si non, relancez le manuellement.

Vérification On peut utiliser la commande clustat pour vérifier que le quorum est présent et connecté

#clustat
Cluster Status for proxmox1 @ Mon Nov 24 16:46:23 2014
Member Status: Quorate

Member Name                                         ID   Status
------ ----                                         ---- ------
proxmox1                                              1 Online, Local, rgmanager
proxmox2                                              2 Online, rgmanager
/dev/block/8:16                                     0 Online, Quorum Disk

Astuces et notes

Supprimer l'avertissement de souscription

# cp /usr/share/pve-manager/ext4/pvemanagerlib.js /usr/share/pve-manager/ext4/pvemanagerlib.js.OLD

Puis on édite

# vim /usr/share/pve-manager/ext4/pvemanagerlib.js

Il faut chercher l'instruction IF de la forme suivante :

if (data.status !== 'Active') {
Ext.Msg.show({
                       title: gettext('No valid subscription'),
                       icon: Ext.Msg.WARNING,
                       msg: PVE.Utils.noSubKeyHtml,
                       buttons: Ext.Msg.OK,

En fait, Proxmox teste si on a un abonnement non actif, auquel cas, il affiche le message. Il nous suffit donc de remplacer le test par false

if (false) {
Ext.Msg.show({
                       title: gettext('No valid subscription'),
                       icon: Ext.Msg.WARNING,
                       msg: PVE.Utils.noSubKeyHtml,
                       buttons: Ext.Msg.OK,