Une introduction à l'interface web pour Xen a déjà été réalisée ici-même.
Après plusieurs mois de gestation, voici donc la version 3.7 de Xen Orchestra, qui est -entre autres- une interface web pour gérer ses serveurs Xen (XenServer ou Xen avec la toolstack XAPI).
Celle-ci apporte de nombreuses nouveautés, aussi bien sur les fonctionnalités classiques que l'on peut attendre d'un outil d'administration, mais aussi d'autres qui commencent à ouvrir des possibilités de délégation de ressources (machines virtuelles).
Pour rappel, XenServer est une distrubution « clef en main » basée sur une CentOS, avec Xen et sa XAPI configurée. Cette API est très complète et souvent méconnue en terme de fonctionnalités, car originalement exposée via XenCenter, un outil de gestion en .NET qui ne fonctionne que sous Windows.
Plus d'infos en seconde partie de cette depeche.
Nouveautés
Délégation de ressources
Première étape dans la délégation de ressource, et sous la forte pression de la communauté, car de loin la plus attendue et demandée. L'objectif est simple, il existe deux types d'utilisateurs :
- les administrateurs, qui peuvent tout voir et tout faire
- les utilisateurs, qui ne voient rien par défaut et auxquels il faut attribuer des objets (machines virtuelles, stockages etc.)
Très utile pour déléguer à votre équipe de développeurs la possibilité d'accéder à la console, redémarrer, faire des instantanés et revenir en arrière etc.
Le processus est simplifié au maximum, comme le montre cette vidéo, avec l'utilisateur "john" qui ne peut voir que sa machine attribuée :
Bien entendu, l'étape suivante est une connexion à un annuaire (OpenLDAP, AD ou autre LDAP) et la gestion d'ensemble de personnes (groupes) et de permissions (rôles).
Migration à chaud
de machines virtuelles sans stockage partagé
La migration à chaud classique est connue : deux hôtes ayant un disque partagé (NFS ou iSCSI) peuvent s'échanger des machines virtuelles, il n'y a que la mémoire vive à déplacer entre eux.
Mais la XAPI permet de faire mieux : déplacer à chaud les disques sous-jacents de la machine virtuelle, puis la RAM, le tout sans interruption ! Le fameux Xen Storage Motion qui permet de littéralement promener votre machine où bon vous semble, sans être limité par des ressources partagées.
Dans Xen Orchestra, la manipulation est triviale : migrer la machine virtuelle sur l'hôte de votre choix. Si jamais le système détecte qu'il n'y a pas de stockage partagé, il vous propose de migrer le disque avec. C'est tout !
de disques
Cette fonctionnalité est aujourd'hui exposée et très simple à utiliser : sur la vue de votre la machine virtuelle, éditez les disques, et changez sur quel Storage ils se trouvent.
Exemple concret : votre machine virtuelle possède un disque qui est attaché à un SAN iSCSI. Vous souhaitez migrer vers un nouveau SAN plus rapide (à base de SSD par exemple), mais sans arrêter celle-ci. Eh bien, sélectionnez le nouveau SAN dans le menu déroulant des stockages disponibles pour cette machine, et le tour est joué !
Exemple en vidéo d'une migration d'un disque sur un stockage distant en iSCSI vers le stockage local de la machine (un SSD) :
Ajouter des stockages
Cette fonctionnalité n'était pas présente dans les versions précédentes de Xen Orchestra. Dorénavant, vous pouvez ajouter des Storage Repositories depuis l'interface web. Le système détecte si ces stockages ont servi par le passé pour stocker des machines virtuelles au format de XenServer : le cas échéant, vous n'avez plus qu'à le rattacher sans le formater. Vidéo de démonstration
Gestion des consoles virtuelles en HTTPS
Un gros travail a été réalisé pour remédier à certaines limitations inhérentes aux consoles virtuelles dans XenServer. Pour cela, a été implémenté un système de proxy, qui non seulement est plus sécurisé, mais permet aussi de résoudre des limitations à cause d'un NAT ou de certains pare-feu.
Affichage des tâches actives
Cet ajout permet de savoir exactement quelles sont les tâches en cours sur votre infrastructure : migration, copie de disques, importations etc. avec leur progression respective. Un grand pas en avant en terme de confort d'utilisation. Ces tâches sont visibles dans la barre de navigation, elles sont donc accessibles à tout moment sur toutes les vues.
Divers
D'autres fonctionnalités mineures sont aussi de la partie, comme :
- l'ajout de Suspend/Resume pour les machines virtuelles (comme une hibernation)
- divers changements d'interface pour une meilleure convialité
- plus d'informations importantes remontées
- et d'autres encore.
L'article original (en anglais) est plus détaillé.
Téléchargement
Comme d'habitude, deux solutions :
- utiliser XOA, une machine virtuelle avec Xen Orchestra installé dedans, au format XVA (que l'on peut importer directement dans la XAPI, soit via XenCenter, la ligne de commande XE ou encore une version précédente de Xen Orchestra), disponible sur le site du projet Xen Orchestra
- ou l'installer manuellement via les dépôts Git du projet : l'un pour la partie serveur du logiciel, xo-server, et l'autre xo-web pour la partie… web !
Aller plus loin
- Site officiel (501 clics)
- Le dépôt principal sur GitHub (122 clics)
- Article officiel pour la 3.7 (45 clics)
- Forum (27 clics)
# Téléchargement
Posté par Sytoka Modon (site web personnel) . Évalué à 8.
Personnellement, mon habitude, c'est 'apt-get install' ;-)
Il y a encore des personnes qui monte et gère elle même leur serveur. L'intégration dans les distributions est donc un plus surtout pour un projet qui vise les couches bases.
A par cela, ça a l'air très bien !
[^] # Re: Téléchargement
Posté par claudex . Évalué à 3.
En même temps,
apt-get, c'est un peu mort pour Xen https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740517« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Téléchargement
Posté par Plam . Évalué à 2.
Eh oui, malheureusement, la XAPI c'est déjà pas la fête à installer sur Debian. C'est pour ça qu'on vise -à court terme- un public qui a déjà une stack installée de leur côté.
Après, si le succès est au rendez-vous, on aura plus de moyens et donc potentiellement à consacrer à la création d'un paquet.
C'est d'ailleurs pour cette raison qu'on a crée l'appliance : c'est une Debian avec XO dedans. On automatise autant que possible ceci dit (pour info, on les build avec Salt Stack)
[^] # Re: Téléchargement
Posté par mazarini . Évalué à 2.
Avec Jessie, on a perdu xm et xapi. Heureusement xl a évolué et permet de conserver une vm qui reboote.
[^] # Re: Téléchargement
Posté par Kioob (site web personnel) . Évalué à 1.
La «perte» d'xm n'est toutefois pas lié à Debian : ça a tout simplement été retiré de Xen 4.4.
alf.life
[^] # Re: Téléchargement
Posté par Plam . Évalué à 3.
Exactement : toute la partie xend est passée deprecated depuis un petit bout de temps, il n'y a que récemment que ça a été complètement retiré.
Quant à la XAPI, il y a un gros travail qui est mené par ses développeurs pour la rendre moins chiante à installer, mais c'est assez récent (moins d'un an).
Reste donc XL, qui est très légère (par design), et si l'on souhaite une API minimale, il faut le couple libvirt+xl.
Problème : les fonctionnalités de la libvirt avec Xen sont très très très (très) loin derrière la XAPI. Le plus grave étant le manque de support des événements, qui obligerai à installer un programme tiers sur les hôtes pour avoir le même résultat qu'avec la XAPI.
Or on souhaite éviter ça au maximum, donc pas le choix, c'est la XAPI qui nous sert à communiquer avec les hôtes !
[^] # Re: Téléchargement
Posté par mazarini . Évalué à 1.
Effectivement Debian n'y est pour rien dans l'abandon d'xm. Quand je me suis rendu compte qu'il me restait qu'xl, j'ai eu peur car mon essai précédent n'avait pas été concluant.
xl convient bien à mes besoins maintenant. Le démarrage auto a été intégré et les domU continuent comme si rien ne s'était passé en cas de reboot de la dom0.
J'ai voulu essayer virt-manager, pas pu voir mes domU. Un point à creuser…
# Bien mais
Posté par MTux . Évalué à 4.
Dommage qu'il soit nécessaire de fournir un e-mail + nom de société pour pouvoir télécharger Xen Orchestra.
[^] # Re: Bien mais
Posté par Plam . Évalué à 2.
Le nom de société n'est pas obligatoire. Et si tu ne souhaites pas laisser ton email, tu peux l'installer à partir des sources :)
# Deuxième question
Posté par MTux . Évalué à 3.
Je suis perdu.
Sur github il est écrit :
Bon jusqu'ici d'accord.
Mais ensuite :
Quoi ??? Je comprends plus rien. Ça veut dire qu'il faut déjà avoir un Xen fonctionnel avec xapi et même Xencenter ? Mais je croyais que le but de l'appliance c'était de tout avoir clés en main !
De plus comment c'est possible de faire fonctionner Orchestra si on ne l'installe pas sur le Dom0 ???
[^] # Re: Deuxième question
Posté par Plam . Évalué à 2.
Alors voici quelques précisions :)
1/ Pour l'appliance, oui, il faut avoir un XenServer fonctionnel quelque part. Sans cela, tester Xen Orchestra n'a aucun sens : on le connecterai sur quoi pour voir les VM, les hôtes etc ?
2/ XOA ne « s'installe » pas sur le Dom0, il s'importe puis est crée en tant que machine virtuelle. Ensuite, il est aussi possible de l'installer depuis les sources directement, pour le mettre sur du « bare-metal » ou sur un poste client.
Les deux modes de diffusion sont corrélés à notre public :
Voilà j'espère que c'est plus clair \o_
[^] # Re: Deuxième question
Posté par MTux . Évalué à 3.
Ben c'est pas clés en main s'il faut se taper l'install de XenServer.
Ensuite si Orchestra peut piloter des VM, il doit être Dom0, je comprends même pas comment ça peut marcher en DomU.
[^] # Re: Deuxième question
Posté par Plam . Évalué à 1. Dernière modification le 08 mars 2015 à 17:17.
Clef en main pour des utilisateurs de XenServer. À aucun moment on ne fournit un hyperviseur !
Et non, Xen Orchestra n'est pas sur le Dom0, à aucun moment (d'ailleurs il est déconseillé de modifier le Dom0 d'un XenServer).
Il n'y a aucun agent à installer sur les hôtes, car Xen Orchestra se connecte à l'API de XenServer (la XAPI).
Voici un schéma pour y voir plus clair :
D'où le fait que Xen Orchestra peut s'installer n'importe où (ton poste actuel, via XOA ou un server physique). La seule condition c'est de pouvoir joindre la XAPI de ton serveur cible.
Maintenant je suppose que tu comprends pourquoi c'est inutile de fournir XOA si tu n'as pas le moindre serveur Xen à ajouter dans Xen Orchestra ;)
[^] # Re: Deuxième question
Posté par MTux . Évalué à 2.
Merci.
Je vais pouvoir tester ça :)
[^] # Re: Deuxième question
Posté par Plam . Évalué à 1.
\o/ Hésite pas à faire signe si tu as le moindre soucis ! (sur notre forum par exemple)
[^] # Re: Deuxième question
Posté par MTux . Évalué à 1.
Désolé de pousser un coup de gueule, mais nodejs ça me sort par les trous de nez.
Les développeurs semblent s'éclater avec, mais quand il faut installer une appli en partant de zéro c'est l'enfer avec les versions, npm qui compile plein de machins et échoue 1 fois sur 2, et des scripts d'init maison à faire…
# Install
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Ça tombe bien cette news, j'avais commencé à tester la version précédente, il y a quelques jours. Il ne semble qu'il n'y ait pas grand monde qui travaille dans ce sens sur xapi donc merci et bravo. L'interface est simple, fonctionnelle, on en attend pas plus.
Par contre les ACL chez moi n'ont pas du tout la gueule de ce qui est présenté dans la vidéo. J'ai deux zones de saisies vides affichant {{$select:placeholder}} ce qui ne me semble pas très explicite. De plus, il s'emble que la possibilité de créer des utilisateurs readOnly ait disparue. Peut-on gérer cela avec les ACL ?
Enfin il semble que la doc d'installation de xo-web ne soit plus à jour. D'après ce que j'ai compris, il faut faire un npm run build à la place du ./gulp --production
[^] # Re: Install
Posté par Plam . Évalué à 1.
On a intégré les changements dans Master que ce week-end donc idéalement il faudrait que tu vérifies que tu es bien à jour sur les deux dépôts :)
Et forcément il y a un petit décalage avec la doc, je suis justement dessus pour la mettre à jour.
[…]
Je viens de terminer : https://github.com/vatesfr/xo/blob/master/doc/installation/manual_installation.md
[^] # Re: Install
Posté par Joris Dedieu (site web personnel) . Évalué à 2.
Je suis en 328ade2f0a77026d0bde2388574a6f1c2ec7cfa0 sur xo-web et en 34e8f57f7d8785b67d53eac38b5bd296cf7b35c2 sur xo-server
j'imagine bien :)
[^] # Re: Install
Posté par Plam . Évalué à 1.
Alors t'es à jour :)
De mon côté c'est OK avec Master, je vois bien la même chose que dans la vidéo.
Tu peux tenter de supprimer ton dossier
distdansxo-webet de relancer unnpm run build. Rafraîchit bien ton navigateur aussi.# quel est la logique de
Posté par Albert_ . Évalué à 3. Dernière modification le 09 mars 2015 à 14:59.
Vu que Xen est un truc unix? Franchement c'est une logique un peu … particuliere!
[^] # Re: quel est la logique de
Posté par Plam . Évalué à 3. Dernière modification le 09 mars 2015 à 15:08.
La raison est historique !
Revenons en 2007, Citrix à besoin de maîtriser toute la pile, sachant que leur produit phare c'est la virtualisation… du poste de travail. Ils ont donc racheté XenSource (la société fondée par le créateur de Xen), pour être capable de se « reposer » sur un hyperviseur qui n'est pas chez un concurrent (à l'époque : VMWare).
Les liens entre Citrix et Microsoft sont très forts, alors pourquoi pas HyperV ? À l'époque, il était vraiment pas au niveau.
Bref, les voilà avec une solution 100% à eux : il faut donc pousser Xen chez le client. Problème : leurs clients sont 100% Microsoft, et ils n'y connaissent RIEN en Unix/Linux/etc.
D'où XenServer, une distro « clef en main » (aucun paramétrage à faire) et une API vraiment complète pour être dirigée depuis un soft qui s'installe sur le poste du client : XenCenter.
Tada ! Voilà pour ce qui semble être bizarre mais qui répond au besoin de l'époque. Ça explique pourquoi la XAPI peut tout faire (ou presque) contrairement à certaines autres API de virtu.
[^] # Re: quel est la logique de
Posté par Albert_ . Évalué à 2.
Merci de l'explication. En effet ceci explique cela, je ne comprenais pas la logique maintenant oui.
[^] # Re: quel est la logique de
Posté par mazarini . Évalué à 1.
Disons plutôt que les clients ont des serveurs unix pour leur intranet, leurs bases de données… et des postes de travail windows pour leurs employés.
# XO pour du XCP
Posté par madko (site web personnel) . Évalué à 1.
Est-ce que XO peut piloter des serveurs XCP?
[^] # Re: XO pour du XCP
Posté par Plam . Évalué à 2. Dernière modification le 09 mars 2015 à 18:19.
Tout à fait, même si XCP n'est plus à jour et est aujourd'hui remplacé par XenServer (car Open Source depuis Juin 2013), c'était exactement le même principe : Xen + XAPI sur une CentOS.
edit : ceci dit, je conseillerai quand même de migrer, car XCP n'est plus maintenu et donc potentiellement troué de partout à l'heure actuelle.
[^] # Re: XO pour du XCP
Posté par madko (site web personnel) . Évalué à 1.
J'avoue que je me replonge que depuis peu dans Xen que j'avais delaissé à l'époque de Citrix. J'ai donc du mal à m'y retrouver… Je laisse tomber XCP et me concentre sur XenServer. Merci pour l'info.
Est-il possible de faire de la haute dispo de VM avec XO? Où il faut payer un abonnement?
[^] # Re: XO pour du XCP
Posté par Plam . Évalué à 2.
J'ai écrit un guide là dessus : https://xen-orchestra.com/blog/xenserver-and-vm-high-availability/
Juste une case à cocher sur la VM à protéger une fois configuré dans le Pool. C'est XenServer qui gère la haute-dispo des machines, et c'est expliqué de quelle manière :)
Cette fonctionnalité est disponible dans XOA en version gratuite !
[^] # Re: XO pour du XCP
Posté par madko (site web personnel) . Évalué à 0.
Dur de s'y retrouver quand même car sur https://xen-orchestra.com/#/pricing ici le HA est payant. C'est un autre HA? Je vais retenter mais avec XOA appliance quand je click sur add to pool ça ne fait rien.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.