Ce billet aborde la configuration des VLANs pour une VM reliée à un OpenVswitch.

Configuration avec VLAN

Configuration manuelle

La première possibilité qui vient à l'esprit est d'ajouter manuellement le VLAN après que la VM soit lancée. Avec l'exemple de configuration cité plus haut, la carte réseau de la VM sera automatiquement branchée sur notre br0 OpenVswitch. La partie visible sur l'hyperviseur de cette carte réseau "virtuelle" est un périphérique de type tap. Le nom de ce tap est configurable dans la libvirt ainsi que dans le fichier XML de la VM. Par défaut il sera préfixé vnet et suffixé par un identifiant numérique. Admettons que notre VM soit la seule de l'hyperviseur, logiquement il y aura donc un tap "vnet0" (vu comme port et interface) dans notre br0. Voyons voir:

[root@hyperviseur01 ~]# ovs-vsctl show
c5f92e84-adaa-4b87-beac-c7f6c8129a7c
    Bridge "br0"
        Port "vnet0"
            Interface "vnet0"
        Port "br0"
            Interface "br0"
                type: internal
    ovs_version: "2.4.0"

[root@hyperviseur01 ~]# ovs-vsctl set port vnet0 tag=99
[root@hyperviseur01 ~]# ovs-vsctl show
c5f92e84-adaa-4b87-beac-c7f6c8129a7c
    Bridge "br0"
        Port "vnet0"
            tag: 99
            Interface "vnet0"
        Port "br0"
            Interface "br0"
                type: internal
    ovs_version: "2.4.0"

Configuration via la libvirt

<vlan>
   <tag id='99'/>
</vlan>

Il est aussi possible de définir plusieurs VLAN en utilisant la balise trunk et non tag. Mais il faudra du coup "tagguer" vos interfaces dans l'OS de la VM. Classique quand il faut utiliser plusieurs VLAN. Mais quand un seul VLAN est utilisé, un seul tag, il s'agit d'un "access port", et il n'y a rien à faire de particuler dans l'OS de la VM.

Je décrirais peut être plus tard dans un autre billet une méthode plus répandue mais que je trouve plus contraignante qui passe toujours par la libvirt mais via la configuration d'un réseau/switch virtuel (notre br0) dans lequel il est possible de définir des portgroups. C'est au niveau des portgroups du switch qu'il faut définir les VLANs. Ensuite dans la configuration de la VM il faut la relier à ces portgroups. C'est moins direct vu qu'il faut modifier deux fichiers de configuration, mais ça rajoute une couche d'abstraction qui dans certains cas peut être utile.

En attendant, voici le bloc complet de configuration de l'interface réseau de ma VM:

<interface type='bridge'>
    <mac address='52:54:00:06:7e:aa'/>
    <source bridge='br0'/>
    <vlan>
        <tag id='99'/>
    </vlan>
    <virtualport type='openvswitch'/>
    <model type='virtio'/>
</interface>

Et voici l 'état de mon br0 après avoir démarrer 2 VMs:

[root@hyperviseur01 ~]# ovs-vsctl show
c5f92e84-adaa-4b87-beac-c7f6c8129a7c
    Bridge "br0"
        Port "vnet0"
            tag: 99
            Interface "vnet0"
        Port "br0"
            Interface "br0"
                type: internal
        Port "vnet1"
            tag: 99
            Interface "vnet1"
    ovs_version: "2.4.0"

Voilà, les 2 VMs étant sur le VLAN 99 elles communiquent bien ensemble.

OpenNebula permet de créer/gérer un datacenter virtualisé. Ce billet traite de l'installation d'OpenNebula 4.10 sur CentOS 7.

Présentation du fonction d'OpenNebula

OpenNebula est constitué d'un service de gestion centralisé (démon oned) qui orchestre le déploiement des machines virtuelles, pilote et supervise les hyperviseurs (host). Ce démon est écrit en ruby, et est pilotable en ligne de commande (CLI) via un compte utilisateur dédié : oneadmin. Il dispose aussi d'une interface web : sunstone.

Pour le pilotage des hyperviseurs, des scripts ruby sont déployés via ssh.

OpenNebula gère plusieurs type de stockage pour les images des VM (ssh, NFS, Ceph, gluster etc). Le plus simple pour disposer d'un espace partagé entre les serveurs restant NFS.

Prérequis

Comparé à d'autres solutions comme OpenStack, OpenNebula est beaucoup moins intrusif.

Matériels

Comme prérequis:

• 1 serveur de gestion
• 1 ou plusieurs hyperviseurs

Il est cependant possible d'installer la partie gestion centrale d'OpenNebulla et la partie de gestion d'hyperviseur sur la même machine. Il faudra donc au minimum disposer d'une seul machine pour tester OpenNebula.

Ici je ne parlerais que de l'installation d'OpenNebula sur CentOS 7. Le serveur de gestion ainsi que les hyperviseurs sont installés avec le profil "installation minimale".

Dépôts RPMs

Il faut disposer du dépôt EPEL 7, principalement pour des paquets en rapport avec ruby :

# yum install http://epel.mirrors.ovh.net/epel/7/x86_64/e/epel-release-7-2.noarch.rpm

Il faut ensuite configurer le dépôt officiel OpenNebula sur toutes les machines :

[opennebula]
name=opennebula
baseurl=http://downloads.opennebula.org/repo/4.10/CentOS/7/x86_64/
enabled=1
gpgcheck=0

SeLinux

Il est conseillé de passer SeLinux en permissif voire de le désactiver :

# setenforce 0

Editer le fichier /etc/selinux/config pour que ça soit permanent. C'est principalement sur le serveur de gestion, a priori sur les hyperviseurs SeLinux ne devrait pas poser de problèmes.

Parefeu

Penser du moins au début à couper le parefeu:

systemctl disable firewalld
systemctl stop firewalld

Nous verrons peut être dans un autre billet la configuration du parefeu si besoin.

Installation du serveur de gestion

Installation d'OpenNebula

Installation des paquets pour le serveur et l'interface web sunstone:

# yum install opennebula opennebula-sunstone

Installation des bibliothèques gem supplémentaires. Ici un script est fournit pour faciliter cette étape, mais nécessite tout de même la compilation de certains fichiers:

# /usr/share/one/install_gems

Activation des services:

# systemctl enable opennebula
# systemctl enable opennebula-sunstone

La partie serveur est installée.

Configuration du stockage partagé

Le stockage partagé n'est nécessaire que si vous avec plusieurs machines.

Le plus simple pour mettre en oeuvre OpenNebula est d'avoir un système de fichiers partagés entre les différentes machines. Surtout pour faciliter le déploiement des clefs SSH. En effet OpenNebula utilise des connexions SSH entre les différentes machines pour travailler. Nous allons donc exporter le répertoire de travail principal d'OpenNebula, qui est aussi le répertoire maison de l'utilisateur oneadmin.

Tout d'abord installer le paquet nfs-utils pour la gestion du service NFS:

# yum install nfs-utils

Pour configurer l'export NFS, ajouter cette ligne dans /etc/exports:

/var/lib/one/ *(rw,sync,no_subtree_check,root_squash)

Activer et demarrer le service NFS:

# systemctl enable nfs-server
# systemctl start nfs-server

Taper la commande suivante pour vérifier que l'export NFS est actif:

# exportfs -v
/var/lib/one    <world>(rw,wdelay,root_squash,no_subtree_check,sec=sys,rw,secure,root_squash,no_all_squash)

Configuration de la base de données

Il est fortement recommandé de réfléchir au choix du type de base de données à utiliser au tout début car la migration n'est pas triviale. Par défaut, OpenNebula utilise une base de type SQLITE. Cela peut suffire si vous ne prévoyez que peu de machines virtuelles. Mais il peut y avoir un impact sur les performances de l'interface web dans notre cas car le chemin par défaut de la base sqlite est sur notre export NFS. Le choix d'une base MySQL s'impose presque:

# yum install mysql-server

Ce qui en réalité installera sur CentOS 7 les paquets mariadb.

Pour activer et démarrer le service mysql :

# systemctl enable mysqld
# systemctl start mysqld

Il faut ensuite créer la base pour OpenNebula, ainsi qu'un utilisateur pour s'y connecter :

# mysql
> CREATE DATABASE opennebula
> GRANT ALL ON opennebula.* TO oneadmin@localhost IDENTIFIED BY 'oneadmin_secret';

La configuration du type de base SQL à utiliser se fait dans le fichier /etc/one/oned.conf :

#DB = [ backend = "sqlite" ]

# Sample configuration for MySQL
DB = [ backend = "mysql",
       server  = "localhost",
       port    = 0,
       user    = "oneadmin",
       passwd  = "oneadmin_secret192.168.2.11:/var/lib/one/  /var/lib/one/  nfs   soft,intr,rsize=8192,wsize=8192        0 0",
       db_name = "opennebula" ]

Démarrage des services

Maintenant que la partie base de données est configurée, les services peuvent être demarrés :

# systemctl start opennebula
# systemctl start opennebula-sunstone

L'interface web est accessible sur le port 9869.

Installation d'un hyperviseur

Montage NFS

Ce chapitre sur le montage NFS est à suivre que si vous avec plusieurs machines.

Le serveur export le répertoire de travail /var/lib/one de l'utilisateur oneadmin. Pour activer son montage il faut ajouter la ligne suivante dans /etc/fstab :

192.168.0.1:/var/lib/one/  /var/lib/one/  nfs   soft,intr,rsize=8192,wsize=8192        0 0

En admettant que 192.168.0.1 soit l'adresse IP de votre serveur NFS.

Il faut ensuite monter ce partage NFS avant l'installation des paquets OpenNebula (qui vont créer l'utilisateur oneadmin) :

# mkdir -p /var/lib/one
# mount /var/lib/one

Installation d'un noeud hyperviseur OpenNebula

Installation des paquets pour la partie hyperviseur sous KVM:

# yum install opennebula-node-kvm

Ceci s'occupera d'ajouter tous les paquets nécessaires à la virtualisation.

Penser à activer et démarrer le service libvirtd:

# systemctl enable libvirtd
# systemctl start libvirtd

C'est tout.

Vérification

Sur le noeud de gestion, avec l'utilisateur oneadmin, il faut s'assurer que la connexion SSH se fait sans intervention:

[root@one] # su - oneadmin
[oneadmin@one] $ ssh node01
[oneadmin@node01] $ exit
[oneadmin@one] $ ssh node02
[oneadmin@node02] $ exit

etc

Normalement c'est le cas, car l'utilsateur oneadmin possède une clef SSH autorisée (dans ~/.ssh/authorized_keys) et comme son repertoire est partagé en NFS sur l'ensemble des machines, la connexion est possible.

Ajout des hyperviseurs

A partir de maintenant tout peut se faire via l'interface web sunstone. Le login par défaut est "oneadmin" et le mot de passe a été généré lors de l'installation et il se trouve dans /var/lib/one/.one/one_auth.

Voici cependant un exemple d'ajout d'hyperviseur KVM avec driver réseau OpenVswitch :

[root@one] # su - oneadmin
[oneadmin@one] $ onehost create node01 -i kvm -v kvm -n ovswitch
[oneadmin@one] $ onehost create node02 -i kvm -v kvm -n ovswitch

Pour vérifier la liste des hyperviseurs :

[oneadmin@one] $ onehost list

Si tout ce passe bien :

  ID NAME            CLUSTER   RVM      ALLOCATED_CPU      ALLOCATED_MEM STAT  
   0 node01          -           1      10 / 200 (5%)  768M / 15.5G (4%) on    
   1 node02          -           2     20 / 200 (10%)  1.5G / 15.5G (9%) on 

Conclusion

L'installation d'OpenNebula est vraiment simple, et la partie gérant les hyperviseurs est très peu intrusive. L'interface web est complète et permet de gerer vraiment beaucoup de point, y compris des ACL, des quotas, de l'accounting, le tout dans des vues paramètrables avec une distinction entre administration, et utilisateur d'un service type cloud (vue plus simpliste). Bref il s'agit d'un produit très efficace qui commence à devenir mature, et qui a surement plus sa place aujourd'hui qu'un OpenStack qui reste une véritable usine à gaz...

Nous verrons dans un autre billet la configuration d'OpenNebula avec OpenVswitch.

Il peut être intéressant de pouvoir virtualiser à l'intérieur même d'une VM, que l'on soit adepte des scénario type Inception, des poupées russes, ou tout simplement pour tester des choses, comme les solutions logiciels de gestion de datacenter (ou autres termes fumeux, tel que cloud, private cloud, etc). Heureusement, depuis quelques temps il est possible d'activer le support de la virtualisation dans une VM avec KVM, en anglais, nested kvm.

Pour l'activer, il faut créer un fichier /etc/modprobe.d/kvm_nested.conf avec le contenu suivant:

options kvm_intel nested=1
options kvm_amd nested=1
/// 

Au prochain chargement du module kvm que vous utilisez, l'option sera prise en compte. Ne pas oublier d'activer le flag svm (pour Amd) ou vmx (pour Intel) dans la configuration de la VM (dans virt-manager, details de la VM, Processor, Configuration, CPU Features).

Dans la VM, un cat /proc/cpuinfo permet de voir le flag souhaité:

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx lm constant_tsc up arch_perfmon rep_good nopl pni vmx ssse3 cx16 sse4_1 hypervisor lahf_lm ///

En terme de performance, il ne devrait pas y avoir de soucis, cela donne bien accès aux registres CPU dédiés à la virtualisation, ce n'est pas une émulation/encapsulation.

Il peut être intéressant de pouvoir virtualiser à l'intérieur même d'une VM, que l'on soit adepte des scénario type Inception, des poupées russes, ou tout simplement pour tester des choses, comme les solutions logiciels de gestion de datacenter virtualisé (ou autres termes fumeux, tel que cloud, private cloud, etc). Heureusement, depuis quelques temps il est possible d'activer le support de la virtualisation dans une VM avec KVM, en anglais, nested kvm.

Pour l'activer, il faut créer un fichier /etc/modprobe.d/kvm_nested.conf avec le contenu suivant:

options kvm_intel nested=1
options kvm_amd nested=1

Au prochain chargement du module kvm que vous utilisez, l'option sera prise en compte. Ne pas oublier d'activer le flag svm (pour Amd) ou vmx (pour Intel) dans la configuration de la VM (dans virt-manager, details de la VM, Processor, Configuration, CPU Features).

Dans la VM, un cat /proc/cpuinfo permet de voir le flag souhaité:

flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx lm constant_tsc up arch_perfmon rep_good nopl pni __vmx__ ssse3 cx16 sse4_1 __hypervisor__ lahf_lm

En terme de performance, il ne devrait pas y avoir de soucis, cela donne bien accès aux registres CPU dédiés à la virtualisation, ce n'est pas une émulation/encapsulation.

La nouvelle version de VirtualBox est officiellement disponible depuis peu (3 jours) dans sa version 1.4.0.
Cette nouvelle release apporte énormement de changement et d'amélioration pour ces fidèles utilisateurs.

Vous apprécierez surtout la disponibilité de paquêts rpm pour Moonshine (Fedora 7) en i386|x86_64 de la version "Closed-Source" :-)" class="smiley

Lire la suite