OVH Community, votre nouvel espace communautaire.

Debian + IP failover + bridge + VM


cassiopee
17/02/2015, 00h45
Merci à vous deux, ça me donne du grain à moudre

captainadmin
16/02/2015, 08h47
Hello,

Après avoir scripté virt-install et virsh tout le weekend, voici la commande que tu cherches je pense

virt-install \
--connect qemu:///system \
--virt-type kvm \
--os-type linux \
--name $NAME \
--ram $RAM \
--disk path=$directory/$NAME.qcow2,format=qcow2 \
--network bridge=br1 \
--vcpus $cpu \
--location "http://ftp.debian.org/debian/dists/wheezy/main/installer-amd64/" \
--extra-args="auto=true hostname=$NAME url=http://127.0.0.1/preseed.cfg text console=tty1 console=ttyS0,115200" \
--hvm \
--nographics


Il faut que tu génères un preseed bien formaté suivant tes besoins

Bonne journée
http://www.captainadmin.com

Pascal [ZR]
15/02/2015, 21h20
Je n'ai pas testé les redirections de console en tty mais tant que ta pile réseau n'est pas opérationnelle tes possibilités sont limitées: une redirection de la sortie graphique (donc VNC ou SPICE) ou install "unattended" (avec un fichier kickstart comme tu l'as déjà dit).

Moi j'ai contourné le problème en faisant un peu différemment:
- install minimale d'une vm avec VNC dans un fichier image
- clonage puis montage avec kpartx et remplacement automatisé des configs réseaux, UUID des disques/partition (si risque de déplacement sur d'autre clones), clés SSH, fichiers de définitions utilisés par la surcouche d'administration (.xml pour libvirt, .conf pour proxmox), etc..
On peut même automatiser le redimensionnement des systèmes de fichiers ou des disques, bien que dans la pratique la base de mes VM varient très peu en taille, j'ajuste juste les dimensions des disques additionnels ou les quotas des stockages réseaux.

ça permet de partir sur une base mini en automatique et de reprendre la main assez tôt en SSH pour personnaliser, sans se prendre trop la tête avec VNC qui n'est pas très pratique il faut bien le reconnaître.
Surtout que pour l'utiliser il ne faut pas oublier de bien sécuriser ses accès, avec du cryptage TLS ET de la vérification X509 des certificats, ou en laissant tout écouter explicitement sur 127.0.0.1 sur l'host et passer par du tunnel SSH ou du VPN. Et les configs TLS de libvirt et de VNC ne sont pas consistantes, c'est un peu le bronx. Mais une fois calé au niveau des droits et en gérant ses propres Certificate Authority, on peut scripter la génération des certificats SSL et TLS et sortir des configs de bases à la fois sures et customisables.

cassiopee
09/02/2015, 23h16
Citation Envoyé par Freemaster
par exemple :

sur le host
Vu, ça marche déjà mieux, merci

Maintenant, je me heurte à l'obstacle suivant, à savoir
créer en mode texte seulement une machine virtuelle.

Par exemple, avec la commande :

Code:
virt-install --name=test1 --accelerate --hvm --arch=x86_64 --vcpus=2 --ram=2048 --os-type=linux \
             --os-variant=debianwheezy \
             --connect=qemu:///system --network bridge=br0,mac=02:xx:xx:xx:xx:xx \
             --noautoconsole \
             -f /home/vm/test1.img \
             --cdrom /home/iso/debian-7.8.0-amd64-CD-1.iso
(où "02:xx:xx:xx:xx:xx" est la MAC virtuelle créée par OVH et associée à l'IP failover)

Normalement cela devrait me créer une VM avec 2 Go de RAM, 2 vCPU, en 64 bits, en Debian Wheezy.

Le souci est que la plupart des documentations explique la fin de l'installation de la machine virtuelle
via VNC (ici le paramétrage d'installation de la Debian guest), or je préfèrerais en mode texte
(voire mieux, en tout automatisé).

J'ai bien trouvé un moyen en utilisant l'option :

Code:
-x "console=ttyS0"
mais il faut alors obligatoirement utiliser également l'option "location" :

Code:
-l http://ftp.fr.debian.org/debian/dists/stable/main/installer-amd64/
à la place de l'option :

Code:
--cdrom /home/iso/debian-7.8.0-amd64-CD-1.iso
On a alors droit à l'installation classique de Debian en mode texte
(parfait) mais à un moment ça bloque sur la configuration réseau
(la passerelle n'étant pas dans la même classe que l'IP de la VM)
et l'installation, qui dans ce contexte va tout chercher en réseau,
s'arrête là.

Je n'ai pas trop creusé car je préfèrerais de toute façon utiliser l'ISO locale,
en mode texte, sans VNC mais je ne sais pas si c'est seulement possible ?

ou alors tout automatiser depuis le "virt-install"
via un fichier Kickstart ou équivalent ?
("Preseed" pour Debian si j'ai bien compris)

cassiopee
09/02/2015, 22h40
Citation Envoyé par captainadmin
Tu mets quelle techno en place?
Du kvm et virtio ?
Kvm

Ton bridge doit contenir l'ip du dédié et non celle de la vm.
Ok, c'est en effet plus logique

- - - Mise à jour - - -

Citation Envoyé par bbr18
tu es allergique à Proxmox ou à la virtualisation ?
Ni l'un ni l'autre

Avant d'utiliser éventuellement une surcouche comme Proxmox,
j'aime bien maitriser les couches d'en-dessous.

Freemaster
09/02/2015, 18h09
par exemple :

sur le host
Code:
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
        address xx.xx.xx.xx (ip principal du serveur)
        netmask 255.255.255.0
        network xx.xx.xx.0
        broadcast xx.xx.xx.255
        gateway xx.xx.xx.254
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0
et sur la vm, bridgé sur br0, et avec la mac associé
Code:
auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet static
        address 1.2.3.4 (ip failover)
        netmask 255.255.255.255
        broadcast 1.2.3.4
        post-up route add xx.xx.xx.254 dev eth0
        post-up route add default gw xx.xx.xx.254
        pre-down route del xx.xx.xx.254 dev eth0
        pre-down route del default gw xx.xx.xx.254

bbr18
09/02/2015, 17h53
Citation Envoyé par cassiopee
Bonjour à tous,

PS: Non Bbr18, je ne cherche pas à faire ça avec Proxmox

tu es allergique à Proxmox ou à la virtualisation ?

captainadmin
09/02/2015, 17h09
Hello,

Tu mets quelle techno en place?
Du kvm et virtio ?

Ton bridge doit contenir l'ip du dédié et non celle de la vm.
Ensuite c'est la vm (relié au bridge) qui portera la conf de l'ip failover.

La gateway n'est pas connu de tes interface, en l'état ca va avoir du mal a marcher.

Il y a pas mal de chose à revoir ou il manque des infos dans ton message

Bonne soirée
http://www.captainadmin.com

cassiopee
09/02/2015, 17h01
Bonjour à tous,

Je cherche à faire quelque chose qui me paraissait simple a priori.

Soit un serveur dédié avec une IP "normale" (non failover) + mettons 4 IP failover.
Chaque IP failover s'est vu attribuer une adresse MAC virtuelle dans le backoffice d'OVH.

Idéalement j'aimerais que le serveur dédié (= machine hôte) soit accessible via son adresse IP "normale"
et que chaque machine virtuelle (VM) soit accessible directement via une adresse IP failover
(donc pas de NAT ou autre).

Il me semble avoir compris que pour se faire on doit monter un "pont" (bridge)
dans la machine hôte.

Le serveur hôte est sous Debian 7.8 fraichement installé.

Au début, j'avais laissé la configuration d'eth0 présente par défaut
dans "/etc/network/interfaces" mais visiblement il faut la retirer

(c'était quelque chose comme :

Code:
auto eth0
iface eth0 inet static
        address 88.77.66.55
        netmask 255.255.255.0
        network 88.77.66.55.0
        broadcast 88.77.66.255
        gateway 88.77.66.254
où "88.77.66.55" représente l'adresse IP "normale" du serveur dédié
)

Actuellement le fichier "/etc/network/interfaces" ressemble à ça :

Code:
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto br0
iface br0 inet static
        address 12.34.56.78 # ip failover
        netmask 255.255.255.255
        broadcast 12.34.56.78 # ip failover
        gateway 88.77.66.254 # ip normale du dedié avec 254 a la fin

        bridge_ports eth0
mais si je reboot ça ne fonctionne pas (serveur inaccessible, merci le script "fusible"
lancé par cron qui me remet la configuration réseau antérieure en place).

Dans les logs, je vois seulement un laconique :

Code:
Feb  9 17:14:12 ns123456 kernel: br0: port 1(eth0) entered forwarding state
Feb  9 17:14:12 ns123456 kernel: br0: port 1(eth0) entered forwarding state
Feb  9 17:14:12 ns123456 kernel: IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
Feb  9 17:14:22 ns123456 kernel: br0: port 1(eth0) entered forwarding state

Si quelqu'un a une idée de ce qui ne va pas ou bien un exemple de configuration qui fonctionne,
je lui en serais très reconnaissant

PS: Non Bbr18, je ne cherche pas à faire ça avec Proxmox