Original post of genma.Votez pour ce billet sur Planet Libre.

Xen Orchestra est une interface web qui s'appuie sur xapi pour piloter un serveur Xen. Il est possible créer des VMs, les monitorer, faire des snapshot, attacher des SR et gérer des ACL pour les utilisateurs autorisés à se connecter à la console. Étant très intéressé par la virtualisation et Xen, j'ai testé cette solution et je dois dire que je suis plutôt impressionné.

Xen c'est quoi ? Et Xapi ?

Bon, si vous lisez l'article, c'est que vous connaissez probablement tout ça :)

Xen est une plateforme de virtualisation, un hyperviseur qui repose beaucoup sur la paravirtualisation. Là où la plupart des hyperviseurs émulent des machines virtuelles (cpu, disque, bios...), Xen fonctionne différemment et va se présenter comme une surcouche entre le matériel et les systèmes invités. Pas d'émulation, les systèmes invités tournent directement sur le vrai matériel, mais passent par Xen pour les accès. En gros, c'est comme un switch qui gère l'accès au hardware et isole les systèmes invités. Ce procédé est très avantageux en terme de performances mais a l'inconvénient de nécessiter des systèmes invités conçus pour fonctionner avec Xen (ce qui exclue notamment Windows !). Pour palier à cela, Xen est capable d'émuler du matériel et fonctionner ainsi comme un hyperviseur classique (VMware, KVM...).

Néanmoins, la paravirtualisation complète n'est plus aussi intéressante de nos jours car les processeurs sont puissants et intègrent des instructions pour gérer la virtualisation. Donc la virtualisation complète est aussi rapide voire plus que la paravirtualisation. Xen a donc évolué et permet de "mélanger" différents modes de fonctionnement. Il est ainsi possible d'utiliser la virtualisation complète (avec instructions CPU) pour le système et de faire appel à la paravirtualisation pour les périphériques, on a ainsi le meilleur des deux technologies. Tout ceci est récapitulé dans l'excellente documentation de Xen.org : Virtualization Spectrum - Xen.

Pour piloter Xen il existe différents outils comme xl ou libvirt mais également xapi qui est utilisé pour Xen Orchestra. Pourquoi ? Parce que xapi est stable, mature, et surtout conçu pour fonctionner en cluster (avec d'autres serveurs Xen mais également du stockage déporté - SR). La page Choice of Toolstacks liste les différentes solutions et leurs avantages / inconvénients. xapi est au coeur de XenServer (solution commerciale Citrix) + XenCenter (interface graphique pour Windows similaire à vsphere).

Xen Orchestra (XO) est une interface web capable de se connecter à XenServer, ou tout serveur Xen fonctionnant avec xapi et remplacer ainsi la console XenCenter limitée à Windows. XO est écrit en nodejs et peut être installé n'importe où, sur le serveur Xen ou non, car la connexion à xapi se fait par l'intermédiaire du réseau.

Maintenant que nous connaissons un peu mieux Xen et XO, voyons un peu à quoi ressemble le tout !

Installation de Xen Orchestra

Pour tester Xen Orchestra, j'ai créé en virtuel une mini infrastructure :

• Deux XenServer (pour tester un cluster).
• Une VM Debian dans Virtualbox puis installation de XO.
• Une seconde VM Debian dans Virtualbox et création d'un iSCSI target (pour faire un SR) - non détaillé, voir cette page.

L'installation de XenServer est directe et simple, il suffit de booter sur l'ISO et suivre les étapes. L'installation de Xen Orchestra sur Debian s'est révélée en revanche un peu plus compliquée. La documentation liste toutes les étapes, en revanche il faut absolument utiliser n pour installer la version 0.10.36 de nodejs. N'essayez pas de prendre la version des dépôts ou installer la 0.12, XO n'est pas compatible. La bonne méthode d'installation de nodejs est :

curl -o /usr/local/bin/n https://raw.githubusercontent.com/visionmedia/n/master/bin/n
chmod +x /usr/local/bin/n
n 0.10.36

Suivez le reste des étapes, c'est à dire la récupération des sources xo-server puis xo-web, l'installation des dépendances et la modification (simple) du fichier de configuration. Si tout se passe bien, Xen Orchestra doit fonctionner.

Découverte

Enfin ! Après avoir bataillé contre (ou avec, comme disait Coluche) Nodejs, voici enfin Xen Orchestra !

L'interface est... adaptée aux tablettes. Sur PC, c'est un peu déroutant. Tous les éléments sont énormes (même avec un écran 1920x1080 je dois scroller), peu intuitifs, et pas vraiment organisés. Mon cerveau de sysadmin s'attendait plutôt à une arborescence listant les pool, serveurs, SR, VMs, comme sur XenCenter ou vSphere. Xen Orchestra utilise un design moderne mais un peu agaçant à mon sens.

Xen Orchestra reconnait les pool (ensemble de serveurs Xen + Storage repositories) mais ne semble pas encore en mesure de les gérer. Je l'ai donc fait directement sur le second XenServer (connexion au pool du premier) :

Xen Orchestra voit maintenant notre pool composé de deux serveurs Xen. Tentons maintenant d'ajouter un SR (Storage repository) de type iSCSI :

Après avoir saisi l'adresse de l'hôte, Xen Orchestra détecte et liste tout seul les target iSCSI et les LUN disponibles. Intéressant non ? Et ça marche. Voici donc notre Cluster, composé de deux serveurs Xen et d'un SR iSCSI vus par Xen Orchestra :

Comme les éléments graphiques sont trop gros (merci l'interface tablette !), la capture d'écran ne montre pas tout car il faut scroller, mais tout est là. Passons à la création d'une VM :

On retrouve exactement les mêmes élements que sous XenCenter : choix d'un template, source d'installation, quantité de ram / vcpu, interface réseau, SR... voilà donc un excellent point puisque rien ne manque.

La console distante n'est pas oubliée et fonctionne en prime sans flash. On peut également voir la console du serveur Xen (dom0) comme pour XenCenter :

Voilà donc encore une fois un excellent point ! Jetons maintenant un oeil aux ACL :

Plutôt clair non ? Il est possible d'accorder ou non l'accès a un pool ou à certains éléments pour un utilisateur. Peut-être est-ce trop basique à l'heure actuelle, mais nul doute que cela va évoluer !

Conclusion

Mon impression de Xen Orchestra est plutôt positive, car même s'il existe quelques bugs ils portent sur l'interface et n'empêchent pas le système de fonctionner (contrairement à virt-manager qui m'a déjà fait complètement planter un hyperviseur, plusieurs fois !). De plus si le but est de remplacer la console XenCenter, XenOrchestra est clairement sur la bonne voie. Carton rouge cependant pour le look "tablette+4K" de l'interface que je n'aime pas du tout.

Original post of Maniatux.Votez pour ce billet sur Planet Libre.

[EN] Make A Wi-fi Webcam From An Old Android Phone - instructables

android DIY obsolescence

antistress : Recycler un vieux smartphone android en moniteur distant pour webcam... via bloguelinux.ca [1]

[1] http://www.bloguelinux.ca/emission-78-du-5-mars-2015-zigonner-avec-ca/

---

Original post of Planet Libre.Votez pour ce billet sur Planet Libre.

gnome-mpv est une interface graphique en Gtk+ pour lecteur multimédia mpv, qui se trouve être lui-même un fork de MPlayer (dont le développement ne semble plus très actif ces derniers temps).

Au niveau des apports de cette nouvelle version, malheureusement dépourvue de notes de version officielles, un épluchage en règle des différents commits depuis la précédente version, semble indiquer l’implémentation des Client-Side Decorations (CSD), avec néanmoins la possibilité de les désactiver pour revenir à un menu plus traditionnel; l’ajout d’une option pour désactiver le thème sombre; la possibilité de glisser-déposer des éléments sur la liste de lecture. Et pour finir, le support de l’internationalisation, même si aucune traduction française n’est pour le moment disponible.

Original post of Okki.Votez pour ce billet sur Planet Libre.

 

Christian Schaller a publié un billet de blog le mois dernier, où l’on apprenait que les spécifications de l’UEFI 2.5, dont les premières cartes mères équipées devraient sortir d’ici la fin de l’année, autoriseraient la mise à jour du micrologiciel depuis n’importe quel système d’exploitation supportant ces nouvelles spécifications ; ce qui sera le cas de Linux. On apprend d’ailleurs que Red Hat possède un représentant au sein du groupe de travail UEFI. C’est une bonne chose de constater que l’industrie ne se contente plus désormais du simple avis de Microsoft.

Avec Richard Hughes, qui est en charge du développement de Logiciels et de la spécification AppData, et qui a également publié un billet à ce sujet, ils auraient travaillé avec Microsoft et différents constructeurs pour voir ce qui serait le plus simple. Apparemment, on se dirigerait vers une archive CAB qui contiendrait, en plus du micrologiciel lui-même, un fichier .INF qui préciserait un certain nombre d’informations telles que l’ID du matériel attendu par le micrologiciel, le nom du fabriquant, la liste des modifications apportées…

Certains constructeurs, favorables à Linux, devraient également fournir un fichier AppStream. Le but étant, à terme, de pouvoir effectuer la mise à jour directement depuis le gestionnaire de logiciels, comme pour n’importe quel autre programme. Chez Red Hat, la mise à jour ne s’effectuera par contre que lors du prochain boot système, mais j’ignore s’il s’agit d’une limitation technique, ou d’une simple précaution de leur part, pour éviter de potentiels problèmes.

Pour l’intégration au sein du système de packages des différentes distributions, ça semble pour le moment plus confus. Dans le cas de micrologiciels dont la redistribution serait autorisée, Red Hat prévoit de créer des RPM pour ces derniers (les autres distributions pourront bien évidemment faire de même). Mais dans le cas de conditions plus restrictives, ils pensent pour le moment à une simple notification à l’utilisateur de l’existence d’une telle mise à jour, tout en lui indiquant où il pourra la télécharger.

Original post of Okki.Votez pour ce billet sur Planet Libre.