Installation et mise en œuvre du module Hâpy

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

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.

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

Le port sur lequel le serveur MySQL attend les connexions.

Le nom de la base de données créée indépendamment et que OpenNebula utilisera pour stocker ses 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.

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

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

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.

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

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.

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.

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.

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.

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.

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

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é.

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

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.

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

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

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.

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

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

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.

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

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.

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

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

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

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

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

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

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.

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.

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

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.

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.

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