Onglet Virtualisation

L'onglet Virtualisation permet de configurer les options propres à OpenNebula.

En mode Expert il est possible de :

  • modifier le nom de la grappe OpenNebula par défaut ;

  • d'activer l'ajout de nœuds de virtualisation ;

  • modifier le port du proxy VNC ;

  • personnaliser certaines informations que l'on retrouve dans l'interface Sunstone (langue de l'interface, nommage des espaces de stockage, …) ;

  • désactiver le cache pour les images de machines virtuelles.

Configuration

La variable Activer le paramétrage par défaut adapté aux machines virtuelles EOLE permet de fixer par défaut certains paramètres (network=virtio, mode graphic=tablet/usb) à des valeurs permettant le bon fonctionnement des modules EOLE.

À partir d’EOLE 2.6.2, il est de nouveau possible de personnaliser le nom de la grappe d’hôtes par défaut.

Écran

  • 1
    Nom de la grappe OpenNebula

    Le nom de la grappe regroupe les différents hôtes fonctionnant ensemble.

Remarque

Contrairement à la fonctionnalité proposée sur EOLE 2.4, le nom de la grappe reste modifiable une fois le serveur instancié.

Attention

Si le nom de la g rappe par défaut est modifié dans l’interface Sunstone, sa valeur sera écrasée à la prochaine reconfiguration du serveur.

Configuration du moteur de base de données

OpenNebula stocke les données concernant les machines virtuelles et les comptes des utilisateurs dans une base de données.

Écran

  • 1
    Choix du moteur de base de données

    L’application peut utiliser le moteur SQLite[1] (intégré et ne nécessitant pas d’autres services, ni d’autres paramètres de configuration) ou le moteur MySQL[2] dont une instance doit être fournie à part et les paramètres de connexion renseignés dans les champs supplémentaires qui sont affichés suite à ce choix.

Écran

  • 1
    Adresse du serveur de base de données MySQL

    L’adresse permettant d’établir une connexion vers le serveur MySQL qui héberge les données d’OpenNebula

  • 2
    Port d’écoute du serveur de base de données MySQL

    Le port sur lequel le serveur MySQL attend les connexions.

  • 3
    Nom de la base de données

    Le nom de la base de données créée indépendamment et que OpenNebula utilisera pour stocker ses données.

  • 4
    Utilisateur avec les droits sur la base de données

    L’identifiant de l’utilisateur ajouté indépendamment dans MySQL avec les droits suffisants pour administrer la base de données dédiée à OpenNebula.

  • 5
    Mot de passe de l’administrateur de la base de données

    Le mot de passe du compte ayant les droits d’administration de la base de données dédiée à OpenNebula.

  • 6
    Nombre de connexions à la base de données

    Restriction du nombre de connexions concurrentes à la base de données.

Attention

Bien que des outils OpenNebula proposent la migration d'un moteur à l'autre, certaines opérations du module, comme la sauvegarde et la restauration, ne sont pas prévues pour cette migration.

Configuration des réseaux de l’orchestrateur

Les différents réseaux de l'orchestrateur peuvent être configurés au travers de l'interface Sunstone par le ou les administrateurs du serveur.

Pour faciliter la mise en production, ces différents réseaux peuvent être paramétrés dans l'interface de configuration du module.

Les réseaux virtuels peuvent être à plage d'adresse IP (réseau de type IPv4 correspondant au niveau 3 du modèle OSI) ou à plage d'adresse Ethernet (réseau de type Ethernet correspondant au niveau 2 du modèle OSI).

Pour ajouter un réseau virtuel à plage d'adresse IP cliquer sur le bouton + Nom du réseau virtuel à plage d'adresse IP et remplir les différents paramètres demandés.

Écran

  • 1
    VLAN à transporter (trunk)

    Ce champ permet de saisir un à plusieurs ID de VLAN à transporter. Dans le cas de plusieurs ID, les différentes valeurs doivent être séparées par des virgules.

Pour ajouter un réseau virtuel à plage d'adresse Ethernet cliquer sur le bouton + Nom du réseau virtuel à plage d'adresse ethernet et remplir les différents paramètres demandés.

Écran

  • 1
    Première adresse MAC

    Permet de contrôler la valeur de la première adresse MAC utilisée lors de la création des interfaces.

  • 2
    VLAN à transporter (trunk)

    Ce champ permet de saisir un à plusieurs ID de VLAN à transporter. Dans le cas de plusieurs ID, les différentes valeurs doivent être séparées par des virgules.

Les différents réseaux virtuels configurés dans l'interface de configuration du module apparaissent dans l'interface Sunstone dans la vue Réseaux Virtuels du menu Network. Leurs noms sont préfixés par CR_.

Configuration de l’orchestrateur

La configuration de l’orchestrateur permet de paramétrer des valeurs par défaut et d’activer certaines fonctionnalités utiles pour le fonctionnement des machines virtuelles

Écran

  • 1
    Activer le cache pour les images qcow2

    Le cache pour les images qcow2[3], activé par défaut, améliore les performances de la virtualisation. Toutefois les données en cache peuvent être perdues en cas de défaillance du système.

    Il est possible de désactiver le cache si une telle éventualité n’est pas tolérable.

  • 2
    Pilote vidéo par défaut

    Le pilote par défaut détermine le pilote utilisé à la création de la machine virtuelle. Le pilote par défaut est vga et peut être changé par qxl, cirrus ou std. La modification du pilote par défaut n’affecte pas les machines virtuelles déjà créées mais seulement celles qui seront créées après reconfiguration du serveur.

  • 3
    Activer la protection contre l’ARP Poisoning

    Il est possible d’activer une protection contre les attaques par ARP Poisoning[4]. Cette disposition n’est toutefois pas compatible avec les réseaux de niveau 2 et donc désactivée par défaut.

  • 4
    Utiliser des hooks personnalisés

    Le système de hooks personnalisés permet de réagir à des événements.

    Le passage à oui de cette variable donne accès à l’onglet Hooks qui permet une gestion de ce système.

Configuration des nœuds de virtualisation

Un nœud de virtualisation est une machine participant au fonctionnement des machines virtuelles en apportant des ressources au système.

Écran

  • 1
    Activer le support pour la haute disponibilité OpenNebula

    Passer cette variable à oui permet de renseigner les différents éléments d’une grappe OpenNebula pour la haute disponibilité.

    Cette option est exclusive avec l’intégration de plusieurs nœuds de virtualisation

  • 2
    Activer l’intégration de plusieurs nœuds de virtualisation

    Passer cette variable à oui permet de renseigner les différents éléments d’une grappe OpenNebula pour un fonctionnement multi-nœud.

    Cette option est exclusive avec le support pour la haute disponibilité.

  • 3
    Nombre maximum de connexions TCP simultanées maintenues avec le serveur

    Nombre au-delà duquel les demandes de connexions sont refusées par le service.

  • 4
    Nombre maximum de connexions TCP simultanées acceptées par le système d’exploitation

    Nombre de demandes de connexions supplémentaires acceptées par le système d’exploitation sans que le service ne les accepte lui-même.

  • 5
    Durée maximum d’une connexion RPC en secondes

    Le délai avant la fermeture d’une connexion sans requête.

  • 6
    Créer un fichier séparé pour les log XML-RPC

    Permet d’enregistrer les journaux d’événements relatifs aux requêtes XML-RPC dans le fichier séparé /var/log/one/one_xmlrpc.log

  • 7
    Ouvrir l’accès à l’API XML-RPC pour des IP externes

    L’accès à l’API XML-RPC est obligatoirement ouvert dans le cas d’une configuration haute disponibilité. Il est optionnel dans le cas d’une configuration multi-nœud.

  • 8
    OpenNebula node name

    Nom du nœud hébergé par le serveur.

Haute disponibilité

Le serveur courant peut-être inclus dans une grappe à des fins d’assurer une haute disponibilité.

Certains paramètres complémentaires propres à ce fonctionnement sont affichés lorsqu'on active le support pour la haute disponibilité.

Écran

  • 1
    Nom du nœud de virtualisation

    Liste des noms de domaine des nœuds de virtualisation autorisés à communiquer avec le serveur et participant à la répartition de charge.

  • 2
    Index du serveur dans la liste des nœuds de virtualisation

    L’index du serveur dans la grappe détermine son rôle : le chef a pour index 0 tandis que les autres ont des index débutant à 1.

  • 3
    Interface de communication des nœuds

    Le numéro d’interface qui relie les différents nœuds dans la nomenclature ethX.

  • 4
    Adresse IP de la VIP OpenNebula

    Adresse IP virtuelle servant à joindre le chef de la grappe OpenNebula. Cette adresse est utilisée de manière générale pour contacter la grappe.

  • 5
    Masque de sous-réseau de la VIP OpenNebula

    Masque de sous-réseau complétant l’adresse IP de la VIP.

Remarque

Pour plus d'information, consulter la section dédiée à la mise en place de la haute disponibilité OpenNebula.

Mode multi-nœuds

Un autre mode de fonctionnement possible et l’intégration avec d’autres nœuds, qui nécessitent d’être identifiés pour permettre le travail de concert.

Écran

  • 1
    Nom du nœud de virtualisation

    Liste des noms de domaine des nœuds de virtualisation autorisés à communiquer avec le serveur et participant à la répartition de charge.

  • 2
    Interface de communication des nœuds

    Le numéro d'interface qui relie les différents nœuds dans la nomenclature ethX.

Attention

Si vous disposez d'un serveur DNS il faut ajouter des entrées pour chaque nœuds, dans le cas contraire il faut renseigner le fichier /etc/hosts du module.

Attention

L'intégration du nouveau nœud se fait manuellement depuis l'orchestrateur (module Hâpy) avec la commande onehost_create_all.

Conseil

Si la fonctionnalité d'intégration de nœud n'est plus utilisée au cours de la vie du module Hâpy (suppression du dernier nœud supplémentaire) mieux vaut la désactiver pour empêcher le rattachement d'un nœud Hâpy node et ainsi sécuriser le serveur.

API XML-RPC

L’API XML-RPC est l’interface principale pour OpenNebula. Elle expose toutes les fonctionnalités du démon OpenNebula. Elle rend possible le contrôle et la gestion de toutes les ressources, machines virtuelles, réseaux virtuels, images, utilisateurs, hôtes et grappes.

L'accès à cette API peut être configuré et limité dans le cas d'une intégration avec d'autres nœuds.

Écran

  • 1
    Adresses IP/Noms DNS autorisées à utiliser l’API XML-RPC

    Liste des adresses IP ou noms de domaine permettant le filtrage des accès à l’API XML-RPC

Remarque

La documentation complète de l’API, en anglais, se trouve à l’adresse suivante :

http://docs.opennebula.io/5.12/integration/system_interfaces/api.html

Configuration de la bibliothèque de gestion des machines virtuelles

La virtualisation repose sur l’utilisation de la bibliothèque libvirt[5] qui doit accéder à différentes ressources. Cet accès est dépendant des utilisateur et groupe système utilisés.

Écran

  • 1
    Utilisateur d’exécution de la bibliothèque

    L’utilisateur avec les droits duquel la bibliothèque libvirt fonctionne.

  • 2
    Groupe d’exécution de la bibliothèque

    Le groupe avec les droits duquel la bibliothèque libvirt fonctionne.

Attention

Le changement des utilisateur et groupe d’exécution peut entraîner un dysfonctionnement des fonctionnalités de virtualisation impliquant des problèmes de droits sur les ressources.

Il est fortement déconseillé de modifier ces paramètres une fois en production.

Configuration de l'application web OpenNebula Sunstone

Sunstone[6] est une interface utilisateur pour OpenNebula.

Plusieurs variables permettent d’adapter son fonctionnement et son apparence.

Écran

  • 1
    La vue par défaut proposée aux utilisateurs

    La vue proposée à l’utilisateur est liée à l’hyperviseur dont Sunstone fait l’interface. kvm est le choix par défaut sur le module Hâpy puisque Sunstone fait l’interface avec l’hyperviseur du module. Il est également possible de basculer sur une vue vCenter ou une vue hybride adaptée à plusieurs hyperviseur.

  • 2
    Méthodes d’authentification proposées aux utilisateurs

    Par défaut, la gestion des comptes se fait localement au moyen de l’interface Sunstone. Il est toutefois possible de choisir d’autres modes d’authentification.

    Pour le moment, seul le mode supplémentaire LDAP est supporté.

    L’activation du mode supplémentaire LDAP est effectué en le sélectionnant dans la fenêtre déroulante et en paramétrant l’accès au LDAP via le nouvel onglet annuaire qui s’affichera.

  • 3
    Sécurisation des websockets pour le proxy VNC

    La sécurisation des websockets passe par l’utilisation d’un certificat et d’une clé.

  • 4
    Choix de la langue par défaut

    Sunstone est une application traduite qui laisse le choix de la langue à l’utilisateur mais permet également à l’administrateur de choisir quelle langue par défaut proposer. La liste des langues proposées (en_US, es_ES, nl_NL, …) est disponible dans le répertoire /usr/lib/one/sunsone/public/locale/languages ou dans l’interface Sunstone dans l’espace de configuration des préférences.

  • 5
    Personnalisation du logo affiché dans l’interface Sunstone

    Le logo affiché par l’interface Sunstone peut être personnalisé en plaçant l’image souhaitée dans le répertoire /usr/lib/one/sunstone/public/images/ et faisant correspondre la valeur du champ avec le nom de cette image.

  • 6
    Limite de la taille des requêtes HTTP

    Paramètre limitant la taille des requêtes permises par le serveur web, en amont de l’interface Sunstone.

AttentionDisparition de variables

Certaines variables, auparavant accessibles sur ce module, sont désormais cachées ou protégées contre toute modification.

Les variables équivalentes à Numéro de port d’écoute et Adresse IP d’écoute sont paramétrées par défaut à 9000 et 127.0.0.1 respectivement.

De même, la variable Numéro de port d’écoute du proxy VNC est forcé à 29876.

Configuration du service OpenNebula Gate (EOLE ≥ 2.8.1)

Le composant OneGate permet aux hôtes de la machine virtuelle d'obtenir et d'envoyer des informations sur la machine virtuelle depuis OpenNebula.

Les utilisateurs et les administrateurs peuvent l'utiliser pour collecter des métriques, détecter des problèmes dans leurs applications et déclencher des règles OneFlow depuis l'intérieur de la VM.

Pour les machines virtuelles qui font partie d'une application multi-VM (service OneFlow), ils peuvent également récupérer les informations du service directement à partir de OneGate et déclencher des actions pour reconfigurer le service ou transmettre des informations entre différentes VM.