# Proxmox VE

# Proxmox Openvz

## <span class="mw-headline" id="bkmrk-container-blueonyx-0">Container BlueOnyx</span>

- Télécharger un template de [http://devel.blueonyx.it/openvz/](http://devel.blueonyx.it/openvz/) dans /var/lib/vz/template/cache
- Le renommer (&lt;OS&gt;-&lt;OSVERSION&gt;-&lt;NAME&gt;\_&lt;VERSION&gt;\_&lt;ARCH&gt;.tar.gz) pour que Proxmox le voit
- S'assurer qu'un fichier de config existe pour la blueonyx (dans /etc/vz/dists il cherche &lt;OS&gt;.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

## <span class="mw-headline" id="bkmrk-activation-sys_time-0">Activation sys\_time</span>

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

```

## <span class="mw-headline" id="bkmrk-modules-iptables-0">Modules IPTABLES</span>

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 <strong>ipt_state</strong>"
```

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.

## <span class="mw-headline" id="bkmrk-migration-kvm-vers-o-0">migration KVM vers openVZ</span>

[https://kb.systea.fr/books/proxmox-ve/page/proxmox-migration-kvm-openvz](https://kb.systea.fr/books/proxmox-ve/page/proxmox-migration-kvm-openvz)

## <span class="mw-headline" id="bkmrk-templates-0">Templates</span>

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

Le nom des templates doit obligatoirement respecter cette régle : &lt;OS&gt;-&lt;OSVERSION&gt;-&lt;NAME&gt;\_&lt;VERSION&gt;\_&lt;ARCH&gt;.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 =&gt; 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.

# <span class="mw-headline" id="bkmrk-debian-0">Debian</span>

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é.

# <span class="mw-headline" id="bkmrk-centos-0">CentOS</span>

**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

<div class="toc" id="bkmrk-%C2%A0%5Bmasquer%5D%C2%A0-1%C2%A0instal"><div class="toctitle"><span class="toctoggle"> \[<a class="togglelink" role="button" tabindex="0">masquer</a>\] </span></div>- [<span class="tocnumber">1</span> <span class="toctext">Installation</span>](https://wiki.kogite.fr/index.php/Proxmox_s%C3%A9curisation_certificats_SSL_clients#Installation)
    - [<span class="tocnumber">1.1</span> <span class="toctext">Création du certificat client</span>](https://wiki.kogite.fr/index.php/Proxmox_s%C3%A9curisation_certificats_SSL_clients#Cr.C3.A9ation_du_certificat_client)
    - [<span class="tocnumber">1.2</span> <span class="toctext">Configuration d'Apache</span>](https://wiki.kogite.fr/index.php/Proxmox_s%C3%A9curisation_certificats_SSL_clients#Configuration_d.27Apache)
- [<span class="tocnumber">2</span> <span class="toctext">Utilisation</span>](https://wiki.kogite.fr/index.php/Proxmox_s%C3%A9curisation_certificats_SSL_clients#Utilisation)
    - [<span class="tocnumber">2.1</span> <span class="toctext">Navigateurs</span>](https://wiki.kogite.fr/index.php/Proxmox_s%C3%A9curisation_certificats_SSL_clients#Navigateurs)
    - [<span class="tocnumber">2.2</span> <span class="toctext">JAVA (pour les consoles VNCviewer)</span>](https://wiki.kogite.fr/index.php/Proxmox_s%C3%A9curisation_certificats_SSL_clients#JAVA_.28pour_les_consoles_VNCviewer.29)
- [<span class="tocnumber">3</span> <span class="toctext">Notes</span>](https://wiki.kogite.fr/index.php/Proxmox_s%C3%A9curisation_certificats_SSL_clients#Notes)

</div># <span class="mw-headline" id="bkmrk-installation-0">Installation</span>

## <span class="mw-headline" id="bkmrk-cr%C3%A9ation-du-certific-0">Création du certificat client</span>

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
```

## <span class="mw-headline" id="bkmrk-configuration-d%27apac-0">Configuration d'Apache</span>

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
```

# <span class="mw-headline" id="bkmrk-utilisation-0">Utilisation</span>

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").

## <span class="mw-headline" id="bkmrk-navigateurs-0">Navigateurs</span>

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

## <span class="mw-headline" id="bkmrk-java-%28pour-les-conso-0">JAVA (pour les consoles VNCviewer)</span>

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

Résolution temporaire : -&gt; private.

# <span class="mw-headline" id="bkmrk-notes-0">Notes</span>

- 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".

# <span class="mw-headline" id="bkmrk-sauvegarde-0">Sauvegarde</span>

## <span class="mw-headline" id="bkmrk-manuellement%2C-vm-arr-0">Manuellement, VM arrêtée</span>

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

## <span class="mw-headline" id="bkmrk-snapshot-1">Snapshot</span>

- 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>
```

## <span class="mw-headline" id="bkmrk-tar.gz-1">Tar.gz</span>

- 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>
```

# <span class="mw-headline" id="bkmrk-restauration-0">Restauration</span>

## <span class="mw-headline" id="bkmrk-snapshot-2">Snapshot</span>

TODO -

## <span class="mw-headline" id="bkmrk-tar.gz-2">Tar.gz</span>

Le backup se remonte en ligne de commande par :

```
qmrestore vzdump-qemu-<strong>103</strong>-2011_03_31-12_07_01.tgz <strong>106</strong>
```

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 :

### <span class="mw-headline" id="bkmrk-centos-0">CentOS</span>

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
        <strong>vlan_raw_device eth1</strong>

auto vmbr1
iface vmbr1 inet static
        address 192.168.2.128
        netmask 255.255.255.0
        bridge_ports <strong>vlan51</strong>
        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
```

<div class="visualClear" id="bkmrk-">  
</div><div id="bkmrk--0" role="contentinfo"></div>

# Proxmox - Migration VMWare ESXi - Proxmox

# <span class="mw-headline" id="bkmrk-migration-vmware--%3E--0">Migration VMware -&gt; KVM</span>

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](https://wiki.kogite.fr/index.php/Cloner_une_VM "Cloner une 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 :

1. Machine virtuelle démarrée normalement, aller dans /boot
2. 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)
3. Sauvegarder l'initrd en question par "cp"
4. 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)
```

1. Eteindre la machine virtuelle
2. 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").
3. Lancer la VM

# Proxmox - Installation d'une VM Windows server 2008R2

Drivers invité : [https://github.com/YanVugenfirer/kvm-guest-drivers-windows](https://github.com/YanVugenfirer/kvm-guest-drivers-windows)

Direct 3D : [http://www.nongnu.org/wined3d/](http://www.nongnu.org/wined3d/)

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

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

## <span class="mw-headline" id="bkmrk-installation-%C3%A0-parti-0">Installation à partir des ISO</span>

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](http://pve.proxmox.com/wiki/Downloads)), booter sur le CD, suivre les indications... Voilà.

## <span class="mw-headline" id="bkmrk-installation-manuell-0">Installation manuelle sur Squeeze par les paquets deb</span>

D'après [http://pve.proxmox.com/wiki/Install\_Proxmox\_VE\_on\_Debian\_Squeeze](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- "<a class="external free" href="http://download.proxmox.com/debian/key.asc" rel="nofollow">http://download.proxmox.com/debian/key.asc</a>" | 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 &lt;nom\_du\_fichier&gt;.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"](https://fr.wikipedia.org/wiki/Agr%C3%A9gation_de_liens%7C), é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 <strong>bond0</strong> inet manual
	<strong>slaves eth0 eth1</strong>
	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 <strong>bond0</strong>
	bridge_stp <strong>off</strong>
	bridge_fd 0
```

Activer la configuration :

```
reboot
```

## <span class="mw-headline" id="bkmrk-mise-en-cluster-0">Mise en cluster</span>

### <span class="mw-headline" id="bkmrk-cr%C3%A9ation-du-cluster-0">Création du cluster</span>

```
D'après <a class="external free" href="http://pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster" rel="nofollow">http://pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster</a>
```

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.

### <span class="mw-headline" id="bkmrk-fencing-0">Fencing</span>

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, ...).

*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="<strong>2</strong>">
```

Ajouter la definition des fencing devices à utiliser, juste après &lt;/clusternodes&gt;

```
<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).

### <span class="mw-headline" id="bkmrk-haute-disponibilit%C3%A9-0">Haute disponibilité</span>

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)

### <span class="mw-headline" id="bkmrk-glusterfs-0">GLusterFS</span>

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](http://gluster.org/community/documentation//index.php/Main_Page)

Sur tous les noeuds :

Ajouter la clé gluster.org :

```
wget -O - <a class="external free" href="http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/gpg.key" rel="nofollow">http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/gpg.key</a> | apt-key add -
```

Ajouter le dépôt Glusterfs :

```
vi /etc/apt/sources.list.d/glusterfs.list
  deb <a class="external free" href="http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/squeeze.repo" rel="nofollow">http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/squeeze.repo</a> 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.

### <span class="mw-headline" id="bkmrk-fonctionnement-du-cl-0">Fonctionnement du cluster</span>

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").

### <span class="mw-headline" id="bkmrk-ligne-de-commande-0">Ligne de commande</span>

```
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
```

## <span class="mw-headline" id="bkmrk-tips-0">TIPS</span>

### <span class="mw-headline" id="bkmrk-drivers-virtio-pour--0">Drivers virtio pour Windows</span>

Charger l'iso virtio-win : [http://www.linux-kvm.org/page/WindowsGuestDrivers/Download\_Drivers](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.

### <span class="mw-headline" id="bkmrk-clavier-fran%C3%A7ais-dan-0">Clavier français dans les consoles VNC</span>

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

# <span class="mw-headline" id="bkmrk-installation-0">Installation</span>

L'installation se fait à partir de l'image ISO ([http://www.proxmox.com/downloads](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.

Une fois installé, l'accès à l'interface web se fait à l'adresse https://&lt;IP du serveur&gt;:8006

# <span class="mw-headline" id="bkmrk-configuration-0">Configuration</span>

### <span class="mw-headline" id="bkmrk-mises-%C3%A0-jour-0">Mises à jour</span>

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 <a class="external free" href="http://ftp.debian.org/debian" rel="nofollow">http://ftp.debian.org/debian</a> wheezy main contrib

# PVE pve-no-subscription repository provided by proxmox.com, NOT recommended for production use
deb <a class="external free" href="http://download.proxmox.com/debian" rel="nofollow">http://download.proxmox.com/debian</a> wheezy pve-no-subscription

# security updates
deb <a class="external free" href="http://security.debian.org/" rel="nofollow">http://security.debian.org/</a> 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
```

### <span class="mw-headline" id="bkmrk-fichiers-hosts-0">Fichiers hosts</span>

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@<strong>pm0</strong> : #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@<strong>pm2</strong> : #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
```

### <span class="mw-headline" id="bkmrk-mise-en-cluster-0">Mise en cluster</span>

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
```

### <span class="mw-headline" id="bkmrk-fencing-0">Fencing</span>

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, ...).

*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="<strong>2</strong>">
```

Ajouter la definition des fencing devices à utiliser, juste après &lt;/clusternodes&gt;

```
<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.

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).

### <span class="mw-headline" id="bkmrk-glusterfs-0">GLusterFS</span>

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 soit comme une partition GlusterFS (Proxmox 3, par la librairie glusterfs), soit comme un partage NFS (fourni par GlusterFS).

[http://gluster.org/community/documentation//index.php/Main\_Page](http://gluster.org/community/documentation//index.php/Main_Page)

Sur tous les noeuds :

Ajouter la clé gluster.org :

```
wget -O - <a class="external free" href="http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/gpg.key" rel="nofollow">http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/gpg.key</a> | apt-key add -
```

Ajouter le dépôt Glusterfs :

```
vi /etc/apt/sources.list.d/glusterfs.list
  deb <a class="external free" href="http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/squeeze.repo" rel="nofollow">http://download.gluster.org/pub/gluster/glusterfs/3.3/3.3.1/Debian/squeeze.repo</a> 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
```

#### <span class="mw-headline" id="bkmrk-acc%C3%A8s-par-la-librair-0">Accès par la librairie glusterfs</span>

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").

#### <span class="mw-headline" id="bkmrk-acc%C3%A8s-en-nfs-0">Accès en NFS</span>

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").

#### <span class="mw-headline" id="bkmrk-benchmark-librairie--0">Benchmark librairie glusterfs / NFS</span>

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 !

## <span class="mw-headline" id="bkmrk-quorum-0">Quorum</span>

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.

### <span class="mw-headline" id="bkmrk-iscsi-0">iSCSI</span>

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](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.
<strong>node.startup = automatic</strong>
...
```

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
```

### <span class="mw-headline" id="bkmrk-configurer-qdisk-0">Configurer QDisk</span>

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
```

### <span class="mw-headline" id="bkmrk-ajouter-qdisk-au-clu-0">Ajouter QDisk au cluster</span>

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
<strong>/dev/block/8:16                                     0 Online, Quorum Disk</strong>
```

# <span class="mw-headline" id="bkmrk-astuces-et-notes-0">Astuces et notes</span>

### <span class="mw-headline" id="bkmrk-supprimer-l%27avertiss-0">Supprimer l'avertissement de souscription</span>

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 (<strong>false</strong>) {
Ext.Msg.show({
                       title: gettext('No valid subscription'),
                       icon: Ext.Msg.WARNING,
                       msg: PVE.Utils.noSubKeyHtml,
                       buttons: Ext.Msg.OK,
```

### <span class="mw-headline" id="bkmrk-probl%C3%A8mes-connus-ave-0">Problèmes connus avec QDisk</span>

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

# <span class="mw-headline" id="bkmrk-installation-0">Installation</span>

L'installation se fait à partir de l'image ISO ([http://www.proxmox.com/downloads](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://&lt;IP du serveur&gt;:8006

# <span class="mw-headline" id="bkmrk-configuration-0">Configuration</span>

### <span class="mw-headline" id="bkmrk-mises-%C3%A0-jour-0">Mises à jour</span>

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. Dans source.list :

```
# vi /etc/apt/sources.list
```

Ajouter :

```
# PVE pve-no-subscription repository provided by proxmox.com, NOT recommended for production use
deb <a class="external free" href="http://download.proxmox.com/debian" rel="nofollow">http://download.proxmox.com/debian</a> 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.

### <span class="mw-headline" id="bkmrk-fichiers-hosts-0">Fichiers hosts</span>

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@<strong>pm0</strong> : #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@<strong>pm2</strong> : #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
```

### <span class="mw-headline" id="bkmrk-mise-en-cluster-0">Mise en cluster</span>

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
```

### <span class="mw-headline" id="bkmrk-fencing-0">Fencing</span>

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.

### <span class="mw-headline" id="bkmrk-glusterfs-0">GLusterFS</span>

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 soit comme une partition GlusterFS (Proxmox 3, par la librairie glusterfs), soit comme un partage NFS (fourni par GlusterFS).

[http://gluster.org/community/documentation//index.php/Main\_Page](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 - <a class="external free" href="http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.6/pub.key" rel="nofollow">http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.6/pub.key</a> | apt-key add -
echo deb <a class="external free" href="http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.6/Debian/jessie/apt" rel="nofollow">http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.6/Debian/jessie/apt</a> 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
```

#### <span class="mw-headline" id="bkmrk-acc%C3%A8s-par-la-librair-0">Accès par la librairie glusterfs</span>

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").

#### <span class="mw-headline" id="bkmrk-acc%C3%A8s-en-nfs-0">Accès en NFS</span>

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").

#### <span class="mw-headline" id="bkmrk-benchmark-librairie--0">Benchmark librairie glusterfs / NFS</span>

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 !

## <span class="mw-headline" id="bkmrk-quorum-0">Quorum</span>

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.

### <span class="mw-headline" id="bkmrk-iscsi-0">iSCSI</span>

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](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.
<strong>node.startup = automatic</strong>
...
```

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
```

### <span class="mw-headline" id="bkmrk-configurer-qdisk-0">Configurer QDisk</span>

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
```

### <span class="mw-headline" id="bkmrk-ajouter-qdisk-au-clu-0">Ajouter QDisk au cluster</span>

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
<strong>/dev/block/8:16                                     0 Online, Quorum Disk</strong>
```

# <span class="mw-headline" id="bkmrk-astuces-et-notes-0">Astuces et notes</span>

### <span class="mw-headline" id="bkmrk-supprimer-l%27avertiss-0">Supprimer l'avertissement de souscription</span>

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 (<strong>false</strong>) {
Ext.Msg.show({
                       title: gettext('No valid subscription'),
                       icon: Ext.Msg.WARNING,
                       msg: PVE.Utils.noSubKeyHtml,
                       buttons: Ext.Msg.OK,
```

### <span class="mw-headline" id="bkmrk-probl%C3%A8mes-connus-ave-0">Problèmes connus avec QDisk</span>

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.