Outils personnels

Proxmox 1.9 Installation, notes techniques : Différence entre versions

De wikiGite

(→‎DRBD)
 
(34 révisions intermédiaires par 2 utilisateurs non affichées)
Ligne 1 : Ligne 1 :
 
= Installation de Proxmox VE 1.7 à partir de l'ISO. =
 
= Installation de Proxmox VE 1.7 à partir de l'ISO. =
−
 
−
<span style="color:red">'''A FINIR DE METTRE EN PAGE'''</span>
 
−
 
  
 
L'ISO est une debian version 5.0.7 (lenny) minimum avec les paquets PVE. Le noyau installé est en 64bits.
 
L'ISO est une debian version 5.0.7 (lenny) minimum avec les paquets PVE. Le noyau installé est en 64bits.
Ligne 23 : Ligne 20 :
 
Passer tout de suite l'interface en français (Menu System/ onglet Options)
 
Passer tout de suite l'interface en français (Menu System/ onglet Options)
  
−
Le réseau de l'hôte est manageable par l'interface (!) Même le bonding est reconnu et peut être configuré (mode, etc...) (création par l'icone à côté du titre "configuration de l'interface").
+
Le réseau de l'hôte est manageable par l'interface. Même le bonding est reconnu et peut être configuré (mode, etc...) (création par l'icone à côté du titre "configuration de l'interface").
  
−
Par contre, pour une interface eth2, j'ai du ajouter la gateway à la main, il ne proposait pas le champ. Par contre une fois ajoutée manuellement dans le fichier /etc/network/interfaces et le réseau redémarré, il l'affiche bien dans le GUI et le champ apparait dans la config de eth2.
+
Par contre, pour une interface eth2 non configurée au départ, j'ai du ajouter la gateway à la main, il ne proposait pas le champ. Mais une fois ajoutée manuellement dans le fichier /etc/network/interfaces et le réseau redémarré, il l'affiche bien dans le GUI et le champ apparait dans la config de eth2.
  
−
'''Note''' : En fait quand on modifie le réseau par le GUI il créé un "interfaces.new" qui est pris en compte au prochain redémarrage. Il suffit de modifier ce fichier juste avant de redémarrer pour que ce soit pris en compte (ajout de la gateway, par exemple).
+
'''Note''' : Quand on modifie le réseau par le GUI il créé un "interfaces.new" qui est pris en compte au prochain redémarrage. Il suffit de modifier ce fichier juste avant de redémarrer pour que ce soit pris en compte (ajout de la gateway, par exemple).
  
−
Téléchargement des isos de machines virtuelles par l'interface. ça tombe dans /var/lib/vz/template/iso/.
+
= Utilisation =
  
−
= Utilisation =
 
 
== Création VM full (KVM) ==
 
== Création VM full (KVM) ==
−
par l'interface, pas de problème, c'est intuitif. On indique l'iso d'installation comme "CD de démarrage", cette iso doit avoir été téléchargée préalablement.
+
Téléchargement des isos pour l'installation des machines virtuelles par l'interface. ça tombe dans /var/lib/vz/template/iso/.
 +
 
 +
Création des VMs par l'interface, pas de problème, c'est intuitif. On indique l'iso d'installation comme "CD de démarrage".
 +
 
 +
La VM est bien lancée avec /usr/bin/kvm (pas de qemu sur Debian).
  
−
La vm est bien lancée avec /usr/bin/kvm (pas de qemu sur Debian).
+
== OpenVZ ==
  
−
Pour les appliances openvz, on peut uploader d'un poste ou choisir dans la liste des appliances disponibles directement chez Proxmox.
+
Pour les appliances openVZ, on peut uploader d'un poste ou choisir dans la liste des appliances disponibles directement chez Proxmox.
  
 
Mais apparement elles n'y sont pas toutes. On en a un plus grand choix ici : http://pve.proxmox.com/wiki/Get_Virtual_Appliances
 
Mais apparement elles n'y sont pas toutes. On en a un plus grand choix ici : http://pve.proxmox.com/wiki/Get_Virtual_Appliances
 
(notamment une BlueOnyx !)
 
(notamment une BlueOnyx !)
  
−
== OpenVZ ==
 
 
Test OpenVZ est avec une image debian6. Il faut paramétrer le réseau manuellement, mais sinon tout fonctionne. On peut paramétrer en venet (non-bridge) avec une adresse sur le sous-réseau quand même, la VM est bien accessible par son adresse dédiée (=> à priori pas besoin de bridge ici, donc pourquoi proposer l'option ?)
 
Test OpenVZ est avec une image debian6. Il faut paramétrer le réseau manuellement, mais sinon tout fonctionne. On peut paramétrer en venet (non-bridge) avec une adresse sur le sous-réseau quand même, la VM est bien accessible par son adresse dédiée (=> à priori pas besoin de bridge ici, donc pourquoi proposer l'option ?)
 +
 
La VM relance un système complet, avec un init [2] qui est pour l'OS virtuel son init de pid 1, à partir duquel sont lancés les processus spécifiques à la VM. Ces processus sont lancés sur la machine physique elle-même et donc visibles avec "ps -ef".
 
La VM relance un système complet, avec un init [2] qui est pour l'OS virtuel son init de pid 1, à partir duquel sont lancés les processus spécifiques à la VM. Ces processus sont lancés sur la machine physique elle-même et donc visibles avec "ps -ef".
  
−
= Cluster =
 
−
== Configuration ==
 
−
Sur le maitre :
 
−
pveca -c
 
−
Génère des clés RSA pour les échanges entre serveurs, et déclare ce serveur comme master (il gèrera tous les autres noeuds et toutes les opérations standards, voir plus bas).
 
  
−
Vérifier la configuration avec
+
= TIPS =
−
pveca -l
+
* En cas d'erreur dans le choix du stockage (ex. choix de LVM au lieu de Directory), pour enlever une référence à un "storage" qu'on ne pourrait pas enlever par l'UI, on peut éditer /etc/pve/storage.cfg sur tous les noeuds, puis relancer pvedaemon.
−
 
 
−
Sur le(s) esclaves(s) :
 
−
pveca -a -h 192.168.1.33
 
−
(ou 192.168.1.33 est l'IP du maître)
 
−
 
 
−
Vérifier que les deux noeuds se voient bien
 
−
pveca -l
 
−
RELANCER les 2 serveurs.
 
−
 
 
−
== Suppression d'un noeud ==
 
−
Sur le master :
 
−
pveca -d <ID du noeud>
 
−
Et sur l'esclave, resynchroniser la configuration à partir de celle du maître
 
−
pveca -s 192.168.1.33
 
−
 
 
−
== Migration de VMs ==
 
−
La migration d'un VM locale (hébergée sur le disque local d'un noeud) doit se faire machine arrêtée (la migration "live" ne peut se faire que si le vdisk est stocké sur un espace partagé par les 2 noeuds concernées - voir plus bas "[[#drbd|DRBD]]".
 
−
 
 
−
La migration "offline" est réalisée avec rsync (environ 1/4 d'heure pour un fichier qcow2 de 800M, sur un réseau 10Mb/s).
 
−
 
 
−
== Erreurs possibles ==
 
−
* Erreur "Ticket authentication failed - invalid ticket..." à la création d'un noeud esclave.
 
−
** Vérifier en premier lieu l'heure des serveurs.
 
−
** Si l'heure est identique, vérifier que les serveurs ont accès à un serveur DNS (le contraire peut ralentir les échanges ssh, et causer des timeouts).
 
−
** Si tout ça est bon, l'erreur peut disparaitre seul après quelques minutes, le temps que les serveurs se synchronisent. Se déconnecter et se reconnecter à l'interface peut aussi aider.
 
−
 
 
−
 
 
−
ATTENTION : Les opération de démarrage/arrêt des VM, les consoles VNC, la soumission de jobs, ne peuvent être réalisés QU'A PARTIR DU MASTER. La gestion de tous les noeuds et de toutes les VMs doit se faire de ce serveur-ci.
 
−
 
 
−
Sur un autre noeud, on obtient "Vous n'avez pas les droits d'accès en écriture." ("You do not have write access").
 
−
Si le master est défaillant, ou pour utiliser ces fonctions à partir d'un autre noeud, il faut passer celui-ci en maître. Sur le noeud en question :
 
−
pveca -m
 
  
−
Et avertir éventuellement tous les autres noeuds du changement de maître. Sur chacun d'eux :
 
−
pveca -s -h <IP du nouveau maître>
 
−
leur fait découvrir le nouveau maître, mais ne les ré-enregistre pas automatiquement dessus. Pour ça relancer :
 
−
pveca -a -h <IP du nouveau maître>
 
  
−
=== Visualisation des stockage ===
 
−
On ne voit les disques locaux ("storage" de type "local") qu'en se connectant individuellement à l'interface de chacun des noeuds. Seuls les emplacements partagés sur le maître apparaissent sur les autres, mais attention aux pertes de VM à la migration si '''[[#bug_storage|<span style="color:red">ces emplacements n'existent pas à l'arrivée !</span>]]'''.
 
  
 
-------------------
 
-------------------
−
== <span id="drbd">DRBD</span> ==
 
−
N'est utile que pour migrer à chaud les VM full (KVM), car il sait migrer à chaud les VZ (penser à fermer les consoles VNC dans ce cas, sinon il ne peut pas suspendre la VM au moment de basculer sur l'autre serveur). La migration a froid est une copie disque à disque avec rsync, il n'y a donc pas besoin non plus de drbd.
 
−
 
−
Les 2 serveurs en cluster utilisés pour configurer DRBD n'ont qu'un disque (2*250Go en RAID1). Proxmox a partitionné / (pve-root) à 54Go et /var/lib/vz (pve-data) à 163 Go.
 
−
Pour un premier test on réduit pve-data à 10G, on crée un pve-data2 sur la place libre et on le réplique en DRBD.
 
−
 
−
/etc/init.d/pvedaemon stop
 
−
umount /dev/mapper/pve-data
 
−
e2fsck -f /dev/mapper/pve-data
 
−
resize2fs -p /dev/mapper/pve-data -p 10G : la nouvelle taille devient 10 Go 
 
−
lvresize -L 11G /dev/mapper/pve-data : légèrement plus grand pour être sûr de ne rien couper sur le FS
 
−
mount /var/lib/vz
 
−
df -h : vérifiez la taille disponible dans le système de fichier modifié
 
−
vgdisplay : vérifiez l'espace disponible dans le volume lvm
 
−
lvcreate -n data2 -L 158G pve : créer un emplacement pour les sauvegardes (NOTE : pas de "pve-" dans le nom, c'est le nom du VG ajouté automatiquement)
 
−
/etc/init.d/pvedaemon start
 
−
 
−
A partir de là, on a une partition LVM utilisable pour drbd. Voir http://wiki.systea.fr/index.php/R%C3%A9plication_de_syst%C3%A8mes_de_fichiers_avec_DRBD
 
−
 
−
Quand DRBD est opérationnel, il faut déclarer ce volume répliqué dans Proxmox. On ne peut pas utiliser ext3 sur le volume DRBD en primary/primary car il faut un filesystem qui fonctionne en cluster (pas d'erreurs sir on formatte en ext3, mais les modifications du filesystem ne sont tout simplement pas répliquées). On utilisera donc LVM, qu'on remet par-dessus DRBD, lui-même étant déjà par-dessus LVM...
 
−
D'ABORD CREER UNE PARTITION LVM SUR LE DEVICE DRBD ! Avec fdisk, en donnant le type 8E (LVM).
 
−
Vérifier si la partition apparait dans /dev/mapper (elle doit être nommée par défaut drbd0p1). Si ce n'est pas le cas, la déclarer avec kpartx
 
−
kpartx -a /dev/drbd0
 
−
Si kpartx n'est pas installé :
 
−
apt-get install kpartx
 
−
'''ATTENTION :'' LANCER KPARTX SUR LES '''2''' NOEUDS, SINON LE SECOND NE VERRA PAS LE NOUVEAU VOLUM GROUP !!
 
−
Ensuite :
 
−
pvcreate /dev/mapper/drbd0p1
 
−
pvscan
 
−
  PV /dev/sda2  VG pve            lvm2 [231.75 GB / 764.00 MB free]
 
−
  PV /dev/dm-4                      lvm2 [157.99 GB]
 
−
  Total: 2 [389.73 GB] / in use: 1 [231.75 GB] / in no VG: 1 [157.99 GB]
 
−
vgcreate drbdvg /dev/mapper/drbd0p1
 
−
pvscan
 
−
  PV /dev/dm-4  VG drbdvg  lvm2 [157.98 GB / 157.98 GB free]
 
−
  PV /dev/sda2  VG pve      lvm2 [231.75 GB / 764.00 MB free]
 
−
  Total: 2 [389.73 GB] / in use: 2 [389.73 GB] / in no VG: 0 [0  ]
 
−
 
−
Il reste à ajouter un storage de type "LVM" dans l'interface Proxmox, sur le VG "drbdvg", en "Partagé".
 
  
−
'''IMPORTANT''': kpartx est nécessaire au reboot pour que la machine re-découvre bien la partition contenant drbd. Ajouter dans /etc/rc.local
+
= Installation manuelle de Proxmox =
−
kpartx -a /dev/drbd0
+
L'installation est recommandée sur Lenny. Ici problème : le Dell R610 refuse de booter sur un CD Lenny, on teste donc sur une Squeeze, et ça marche !
  
−
Limitation : on ne peut dans ce cas que créer des VM avec un disque raw (sur un volume logique créé pour l'occasion) dont plus question de diques extensibles type qcow2.
+
Installation sur Squeeze 64 bits (Partitionnement LVM, une partition / de 10 Go, et le reste pour /var/lib/vz) de base (juste serveur SSH).
  
−
'''<span style="color:red">NOTE IMPORTANTE :</span>'''<span id="bug_storage"> Si on ajoute d'autres noeuds au clusters et que ceux-ci ne font pas partie de la réplication DRBD, il y a risque de perte de VM. L'emplacement DRBD étant partagé sur le maître, ilo sera visible '''sur tous les noeuds''', même ceux qui ne l'ont pas. On peut donc par erreur migrer une VM de l'emplacement DRBD vers un noeud qui n'a pas cet emplacement : Proxmox ne l'interdit pas, mais la VM est perdue ! Elle fait 0 octet à l'arrivée, et impossible de la ramener vers le noeud de départ car il ne trouve plus le volume correspondant, et s'arrête en erreur !</span>
+
Quelques réglages réseau utiles à la fin de l'installation de Debian :
 +
vi /etc/sysctl.conf
  
−
'''Il est donc préférable''' de créer un cluster pour les noeuds partageant un emplacement de type DRBD (pour les migrations à chaud), et un autre cluster pour les noeuds n'ayant que des emplacements locaux. Ce second cluster permettra de centraliser la gestion de ces machines et autorisera des migrations "à froid" d'emplacement local vers emplacement local.
+
net.ipv4.conf.all.rp_filter=1
 +
net.ipv4.icmp_echo_ignore_broadcasts=1
 +
net.ipv4.conf.default.forwarding=1
 +
net.ipv4.conf.default.proxy_arp = 0
 +
net.ipv4.ip_forward=1
 +
kernel.sysrq = 1
 +
net.ipv4.conf.default.send_redirects = 1
 +
net.ipv4.conf.all.send_redirects = 0
 +
net.ipv4.conf.eth0.proxy_arp=1
 +
Eventuellement ajouter "avec précaution" :
 +
#optimiser en cas d'attaque
 +
net.ipv4.conf.all.log_martians = 1
 +
net.ipv4.conf.default.log_martians = 1
 +
net.ipv4.tcp_max_syn_backlog = 2048
 +
net.ipv4.tcp_synack_retries = 3
 +
net.ipv4.tcp_syn_retries = 2
 +
Appliquer les changements
 +
sysctl -p
  
−
=== Erreur SPLIT BRAIN ===
 
−
En cas de coupure du lien, un reboot d'un des noeuds, ou toute autre raison désynchronisant le DRBD, le primary/primary cause une erreur SPLIT BRAIN. On peut voir dans les logs par exemple :
 
−
kernel: block drbd0: helper command: /sbin/drbdadm split-brain minor-0 exit code 0 (0x0)
 
−
 
−
Si on essaie de passer DRBD sur le noeud esclave en secondaire, on a :
 
−
drbdadm secondary all
 
−
  0: State change failed: (-12) Device is held open by someone
 
−
  Command 'drbdsetup 0 secondary' terminated with exit code 11
 
−
 
−
Pour relancer la réplication :
 
−
Sur les 2 noeuds :
 
−
drbdadm disconnect data2
 
−
 
−
Sur le secondaire :
 
−
vgchange -an drbdvg
 
−
kpartx -d /dev/drbd0
 
−
drbdadm secondary data2
 
−
drbdadm -- --discard-my-data connect data2
 
−
/proc/drbd doit indiquer une tentative de connexion au primaire "cs:WFConnection"
 
−
 
−
Sur le primaire :
 
−
drbdadm connect data2
 
−
/proc/drbd doit indiquer un état "cs:Connected" sur les 2
 
−
 
−
Vérifier la synchronisation :
 
−
cat /proc/drbd
 
−
Lorsque c'est UpToDate/UpToDate, sur le secondaire :
 
−
drbdadm primary data2
 
−
kpartx -a /dev/drbd0
 
−
vgchange -ay drbdvg
 
−
Pour valider la synchronisation des volumes :
 
−
drbdadm verify data2
 
−
watch cat /proc/drbd
 
−
 
−
-------------
 
−
 
−
= TIPS =
 
−
* En cas d'erreur dans le choix du stockage (ex. choix de LVM au lieu de Directory), pour enlever une référence à un "storage" qu'on ne pourrait pas enlever par l'UI, on peut éditer /etc/pve/storage.cfg sur tous les noeuds, puis relancer pvedaemon.
 
−
 
−
*La console VNC semble lancée par perl (/usr/sbin/qm qui est le script global utilisé par Proxmox) avec un "vncproxy" qui lie l'id de la VM à son port VNC.
 
−
 
−
= Installation manuelle =
 
−
A tester install recommandée sur Lenny. Ici prob. Dell R610 qui refuse de booter sur un CD Lenny, on teste sur une squeeze.
 
−
Installation au-dessus d'une Squeeze 64 bits (Partitionnement LVM, une partition / de 10 Go, et le reste pour /var/lib/vz) de base (juste serveur SSH).
 
 
Modifier le sources.list :
 
Modifier le sources.list :
 
  vi  /etc/apt/sources.list
 
  vi  /etc/apt/sources.list
Ligne 228 : Ligne 120 :
  
 
Rebooter une dernière fois.
 
Rebooter une dernière fois.
 +
= Conversion de disque virtuel - transfert qcow2 -> LVM =
 +
== Conversion ==
 +
Pour convertir un fichier disque virtuel utiliser qemu-img.
 +
qemu-img convert -O qcow2 vm-103-disk-1.raw vm-103-disk-1.qcow2
 +
convertir un disque raw en disque qcow2 (taille dynamique).
 +
 +
== Transfert fichier -> LVM ==
 +
Exemple : si on décide de transférer une image qcow2 vers un volume logique LVM, créer une VM avec disque LVM de la même taille et ''avec les mêmes périphériques''' ! (attention notamment au type de disque !). Puis transférer le fichier avec dd :
 +
dd if=vm-103-disk-1.qcow2 of=/dev/drbdvg/vm-101-disk-1
 +
 +
Si la copie ne fonctionnera pas (disque non bootable à l'arrivée), transformer d'abord en disque non dynamique (raw) :
 +
qemu-img convert -O raw vm-103-disk-1.qcow2 vm-103-disk-1.raw
 +
dd if=vm-103-disk-1.raw of=/dev/drbdvg/vm-101-disk-1
  
−
== Migration VMware -> KVM ==
+
= Gestion en ligne de commande =
−
La migration se passera en un ou deux temps, selon qu'on veut que la VM KVM soit en fichier qcow2 ou dans un volume logique (utile pour le cluster avec LVM).
+
L'outils '''qm''' permet de gérer les machines virtuelles en ligne de commande. "qm help" est la première chose à faire !
−
* Migration en fichier qcow2
+
* Liste les VMs
−
  kvm-img convert -O qcow2 VM_vmware.vmdk VM_kvm.qcow2
+
qm list
−
* Migration en raw puis transfert dans un volume logique
+
* Gestion de l'état
−
Créer la machine virtuelle par l'interface, de façon à ce que le volume logique existe. Puis :
+
qm start <vmid>
−
  qemu-img convert VM_kvm.qcow2 -O raw VM_kvm.raw
+
qm stop <vmid>
−
  dd if=VM_kvm.raw of=/dev/pve/vm-102-disk-1
+
  qm reset <vmid>
 +
* Gestion des VMs
 +
qm [create|set] <vmid> [voir l'aide pour la liste des paramètres à créer/modifier]
 +
qm status <vmid>
 +
  qm destroy <vmid>
 +
* VNC
 +
  qm vncproxy <vmid> <ticket>

Version actuelle datée du 12 octobre 2012 à 11:45

Installation de Proxmox VE 1.7 à partir de l'ISO.

L'ISO est une debian version 5.0.7 (lenny) minimum avec les paquets PVE. Le noyau installé est en 64bits.

L'installateur crée automatiquement un bridge vmbr0 vers l'interface eth0.

Partitionnement sur un RAID1 232G (automatique, pas moyen de le modifier au cours de l'install) 

Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/pve-root   58G  1.1G   54G   3% /                   ---> 54G un peu excessif ?
tmpfs                 2.0G     0  2.0G   0% /lib/init/rw
udev                   10M  616K  9.4M   7% /dev
tmpfs                 2.0G     0  2.0G   0% /dev/shm
/dev/mapper/pve-data  164G  601M  163G   1% /var/lib/vz
/dev/sda1             504M   31M  448M   7% /boot

A la fin de l'install, connexion à l'interface par http://192.168.37.110 --> renvoie vers https.

login root/<mot_de_passe donné à l'installation>

Passer tout de suite l'interface en français (Menu System/ onglet Options)

Le réseau de l'hôte est manageable par l'interface. Même le bonding est reconnu et peut être configuré (mode, etc...) (création par l'icone à côté du titre "configuration de l'interface").

Par contre, pour une interface eth2 non configurée au départ, j'ai du ajouter la gateway à la main, il ne proposait pas le champ. Mais une fois ajoutée manuellement dans le fichier /etc/network/interfaces et le réseau redémarré, il l'affiche bien dans le GUI et le champ apparait dans la config de eth2.

Note : Quand on modifie le réseau par le GUI il créé un "interfaces.new" qui est pris en compte au prochain redémarrage. Il suffit de modifier ce fichier juste avant de redémarrer pour que ce soit pris en compte (ajout de la gateway, par exemple).

Utilisation

Création VM full (KVM)

Téléchargement des isos pour l'installation des machines virtuelles par l'interface. ça tombe dans /var/lib/vz/template/iso/.

Création des VMs par l'interface, pas de problème, c'est intuitif. On indique l'iso d'installation comme "CD de démarrage".

La VM est bien lancée avec /usr/bin/kvm (pas de qemu sur Debian).

OpenVZ

Pour les appliances openVZ, on peut uploader d'un poste ou choisir dans la liste des appliances disponibles directement chez Proxmox.

Mais apparement elles n'y sont pas toutes. On en a un plus grand choix ici : http://pve.proxmox.com/wiki/Get_Virtual_Appliances (notamment une BlueOnyx !)

Test OpenVZ est avec une image debian6. Il faut paramétrer le réseau manuellement, mais sinon tout fonctionne. On peut paramétrer en venet (non-bridge) avec une adresse sur le sous-réseau quand même, la VM est bien accessible par son adresse dédiée (=> à priori pas besoin de bridge ici, donc pourquoi proposer l'option ?)

La VM relance un système complet, avec un init [2] qui est pour l'OS virtuel son init de pid 1, à partir duquel sont lancés les processus spécifiques à la VM. Ces processus sont lancés sur la machine physique elle-même et donc visibles avec "ps -ef".


TIPS

  • En cas d'erreur dans le choix du stockage (ex. choix de LVM au lieu de Directory), pour enlever une référence à un "storage" qu'on ne pourrait pas enlever par l'UI, on peut éditer /etc/pve/storage.cfg sur tous les noeuds, puis relancer pvedaemon.


Installation manuelle de Proxmox

L'installation est recommandée sur Lenny. Ici problème : le Dell R610 refuse de booter sur un CD Lenny, on teste donc sur une Squeeze, et ça marche !

Installation sur Squeeze 64 bits (Partitionnement LVM, une partition / de 10 Go, et le reste pour /var/lib/vz) de base (juste serveur SSH).

Quelques réglages réseau utiles à la fin de l'installation de Debian : 

vi /etc/sysctl.conf

net.ipv4.conf.all.rp_filter=1
net.ipv4.icmp_echo_ignore_broadcasts=1
net.ipv4.conf.default.forwarding=1
net.ipv4.conf.default.proxy_arp = 0
net.ipv4.ip_forward=1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.eth0.proxy_arp=1

Eventuellement ajouter "avec précaution" : 

#optimiser en cas d'attaque
net.ipv4.conf.all.log_martians = 1
net.ipv4.conf.default.log_martians = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_syn_retries = 2

Appliquer les changements 

sysctl -p

Modifier le sources.list : 

vi  /etc/apt/sources.list

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

Charger la clé Proxmox et mettre à jour APT 

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

Installer le noyau proxmox 

aptitude install pve-kernel-2.6.32-4-pve

Les dépendance installent Grub, mais sur Squeeze c'est Grub 2 ! Il faut donc enregistrer le nouveau kernel : 

update-grub

Afficher le fichier /boot/grub/grub.cfg généré pour repérer la place du noyau pve, et changer le noyau par défaut dans /etc/default/grub (rien que ça !!) 

vi /etc/default/grub

GRUB_DEFAULT=2

Et enfin re-re-générer grub.cfg 

update-grub

OK! On peut rebooter, puis vérifier que le noyau PVE a été chargé 

uname -a
Linux 2.6.32-4-pve ...

Vérifier que les interfaces réseau n'ont pas changé de nom dans la bataille 

ifconfig eth0

Si un message d'erreur "No device found" apparait, éditer le fichier /etc/udev/rules.d/70-persistent-net.rules et modifier les noms des interfaces.

Installer les paquets Proxmox VE et quelques dépendances 

apt-get install postfix
aptitude install proxmox-ve-2.6.32 ntp ssh

Sur un DELL R610 avec des cartes réseau Broadcom, le paquet pve-firmware a refusé de s'installer car il voulait remplacer le firmware bnx2 déjà présent sur le système et utilisé. Il a fallu forcer la désinstallation de ce dernier avant de terminer l'installation 

dpkg -r firmware-bnx2
apt-get -f install

Rebooter, et vérifier que les processus pve ont bien été lancés.

On peut maintenant se connecter à l'interface web et configurer vmbr0 (le bridge pour les VMs) dans System Configuration / Network : mettre l'adresse IP de eth0, cocher autostart et indiquer "eth0" comme bridge ports".

Rebooter une dernière fois.

Conversion de disque virtuel - transfert qcow2 -> LVM

Conversion

Pour convertir un fichier disque virtuel utiliser qemu-img. 

qemu-img convert -O qcow2 vm-103-disk-1.raw vm-103-disk-1.qcow2

convertir un disque raw en disque qcow2 (taille dynamique).

Transfert fichier -> LVM

Exemple : si on décide de transférer une image qcow2 vers un volume logique LVM, créer une VM avec disque LVM de la même taille et avec les mêmes périphériques' ! (attention notamment au type de disque !). Puis transférer le fichier avec dd : 

dd if=vm-103-disk-1.qcow2 of=/dev/drbdvg/vm-101-disk-1

Si la copie ne fonctionnera pas (disque non bootable à l'arrivée), transformer d'abord en disque non dynamique (raw) : 

qemu-img convert -O raw vm-103-disk-1.qcow2 vm-103-disk-1.raw
dd if=vm-103-disk-1.raw of=/dev/drbdvg/vm-101-disk-1

Gestion en ligne de commande

L'outils qm permet de gérer les machines virtuelles en ligne de commande. "qm help" est la première chose à faire !

  • Liste les VMs
qm list
  • Gestion de l'état
qm start <vmid>
qm stop <vmid>
qm reset <vmid>
  • Gestion des VMs
qm [create|set] <vmid> [voir l'aide pour la liste des paramètres à créer/modifier]
qm status <vmid>
qm destroy <vmid>
  • VNC
qm vncproxy <vmid> <ticket>
Récupérée de « https://wiki.kogite.fr/index.php?title=Proxmox_1.9_Installation,_notes_techniques&oldid=5365 »