Proxmox 1.9 Installation, notes techniques - Historique des versions

Frank : a déplacé Proxmox Installation, notes techniques vers Proxmox 1.9 Installation, notes techniques

2012-10-12T11:45:10Z

a déplacé Proxmox Installation, notes techniques vers Proxmox 1.9 Installation, notes techniques

Frank le 5 janvier 2012 à 11:38

2012-01-05T11:38:54Z

Frank : /* Migration VMware -> KVM */

2011-05-09T07:34:14Z

‎Migration VMware -> KVM

Frank le 2 mai 2011 à 17:21

2011-05-02T17:21:15Z

Frank : /* Conversion de disque virtuel - transfert qcow2 -> LVM */

2011-03-31T11:02:58Z

‎Conversion de disque virtuel - transfert qcow2 -> LVM

Frank le 31 mars 2011 à 10:42

2011-03-31T10:42:35Z

Frank : /* Installation manuelle de Proxmox */

2011-03-29T09:25:35Z

‎Installation manuelle de Proxmox

Frank le 29 mars 2011 à 07:45

2011-03-29T07:45:53Z

Frank : /* TIPS */

2011-03-29T07:45:36Z

‎TIPS

Frank : /* TIPS */

2011-03-29T07:45:23Z

‎TIPS

← Version précédente		Version du 5 janvier 2012 à 11:38
Ligne 133 :		Ligne 133 :
	qemu-img convert -O raw vm-103-disk-1.qcow2 vm-103-disk-1.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		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>

← Version précédente		Version du 9 mai 2011 à 07:34
Ligne 133 :		Ligne 133 :
	qemu-img convert -O raw vm-103-disk-1.qcow2 vm-103-disk-1.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		dd if=vm-103-disk-1.raw of=/dev/drbdvg/vm-101-disk-1
−
−	~~= 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).~~
−
−	* 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~~
−
−	'''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) est incompatible avec ces migrations.
−	~~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.~~

← Version précédente		Version du 2 mai 2011 à 17:21
Ligne 46 :		Ligne 46 :
	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~~
−	~~pveca -l~~
−
−	~~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 3 mns pour un fichier qcow2 de 800M, sur un réseau 100Mb/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 sur l'interface peut aussi aider.
−
−	~~== Opérations sur le cluster ==~~
−	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 sur un des noeuds !</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.
−
−	~~=== Configuration ===~~
−	~~Les 2 serveurs en cluster utilisés pour tester DRBD avec Proxmox n'ont qu'un disque (2*250Go en RAID1). Proxmox a partitionné / (pve-root) à 54Go et /var/lib/vz (pve-data) à 163 Go.~~
−
−	~~==== Réduction de la partition pve-data ====~~
−	~~OPTIONNEL. 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 # On remonte pve-data~~
−
−	~~vgdisplay # vérifiez l'espace disponible dans le volume LVM~~
−	~~lvcreate -n data2 -L 158G pve # créer un emplacement data2 (NOTE : pas de "pve-" dans le nom, c'est le nom du VG ajouté automatiquement)~~
−	~~/etc/init.d/pvedaemon start~~
−
−	~~==== Installation DRBD ====~~
−	~~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~~
−
−	~~==== Création d'un volume group répliqué ====~~
−	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 si on formate en ext3, mais les modifications du filesystem ne sont tout simplement pas répliquées et pas vu sur les autres noeuds). 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). On a donc l'empilage suivant :~~
−	~~Disque~~
−	~~partition LVM (fdisk 8E)~~
−	~~Groupe de volume~~
−	~~Volume logique~~
−	~~DRBD~~
−	~~partition LVM~~
−	~~Groupe de volume~~
−	~~Les volumes logiques des VMs seront ensuite gérés par Proxmox.~~
−
−	~~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~~
−	~~kpartx -a /dev/drbd0~~
−
−	~~=== Notes sur DRBD ===~~
−	~~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.~~
−
−	'''<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>
−
−	'''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.
−
−	~~=== 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 (en d'autres termes, il n'arrive plus à décider qui doit répliquer sur qui pour re-synchroniser les volumes).
−
−	~~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 =		= TIPS =

@@ Ligne 274 : / Ligne 274 : @@
 Rebooter une dernière fois.
 = Conversion de disque virtuel - transfert qcow2 -> LVM =
 Pour convertir un fichier disque virtuel utiliser qemu-img.
-Exemple : si on décide de transférer une image qcow2 vers un volume logique LVM, la copie directe avec dd ne fonctionnera pas (disque non bootable à l'arrivée).
+== Transfert fichier -> LVM ==
-Donc on transforme d'abord en disque non dynamique (raw) puis on transfère :
+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

← Version précédente		Version du 31 mars 2011 à 10:42
Ligne 273 :		Ligne 273 :

	Rebooter une dernière fois.		Rebooter une dernière fois.
		+	= Conversion de disque virtuel - transfert qcow2 -> LVM =
		+	Pour convertir un fichier disque virtuel utiliser qemu-img.
		+
		+	Exemple : si on décide de transférer une image qcow2 vers un volume logique LVM, la copie directe avec dd ne fonctionnera pas (disque non bootable à l'arrivée).
		+
		+	Donc on transforme d'abord en disque non dynamique (raw) puis on transfère :
		+	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 =		= Migration VMware -> KVM =

← Version précédente	Version du 12 octobre 2012 à 11:45
(Aucune différence)

← Version précédente		Version du 29 mars 2011 à 09:25
Ligne 211 :		Ligne 211 :

	Installation sur Squeeze 64 bits (Partitionnement LVM, une partition / de 10 Go, et le reste pour /var/lib/vz) de base (juste serveur SSH).		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 :		Modifier le sources.list :

← Version précédente		Version du 29 mars 2011 à 07:45
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 205 : / Ligne 205 : @@
 = 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.
 -------------------

@@ Ligne 206 : / Ligne 206 : @@
 * 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 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 !