Petites brèves : Phonon 4.5 et Xen 4.1

Posté par  . Modéré par Benoît Sibaud. Licence CC By‑SA.
Étiquettes :
24
28
mar.
2011
Technologie

Xen 4.1

Xen , la solution de virtualisation et de paravirtualisation, est sorti en version 4.1. Cette version apporte la gestion de plus de 255 processeurs et des grandes pages mémoires de 2 Mio et 1 Gio. Les instructions AVX pour les processeurs x86 sont aussi prises en charge, et un nouvel ordonnanceur, plus performant dans les opérations à faible latence (comme le réseau), fait son apparition.

La paravirtualisation est un moyen pour avoir une ou plusieurs machines virtuelles bien distinctes de l’hôte (par exemple, une machine Solaris et une machine FreeBSD sur un hôte Linux). Cependant, il faut que ces systèmes virtuels soient préparés à être virtualisés pour que la paravirtualisation fonctionne ; ceci empêche d’utiliser n’importe quel système de virtualisation, tels que KVM ou VirtualBox.

Phonon 4.5

Cette nouvelle version apporte la prise en charge de Zeitgeist, ce qui permet de journaliser les lectures de contenus multimédia, et l’API gère les boutons des menus [DVD]. Les widgets de Phonon sont désormais disponibles dans Qt Designer, ce qui permet de l’utiliser très facilement et de créer un lecteur vidéo en 30 secondes.

Pour rappel, Phonon est une couche d’abstraction qui facilite la lecture de contenus multimédia. Le but n’est pas de fournir une liste exhaustive de fonctionnalités pour le traitement vidéo ou audio, mais de permettre à chaque application de facilement jouer un son ou une animation.

Aller plus loin

  • # Dépêche très intéressante

    Posté par  . Évalué à 9.

    Ce que j’adore sur Linuxfr c’est l’éventail de gens et de sujets abordés. Parler à la fois de philosophie, de physique théorique poussée et d’informatique grand public dans le même paragraphe : je dis chapeau !

  • # Xen et systèmes virtualisés

    Posté par  (site web personnel) . Évalué à 1.

    Sur les systèmes modernes (technologies VT d'Intel ou AMD-V de chez AMD), Xen est capable de faire tourner "n'importe quel système d'exploitation" (au moins des choses comme Windows XP chose)(mode HVM) Cette feature aurait disparu de Xen 4.x ?

    • [^] # Re: Xen et systèmes virtualisés

      Posté par  . Évalué à 2.

      It was not a feature but a bug.

    • [^] # Re: Xen et systèmes virtualisés

      Posté par  . Évalué à 3.

      Non bien sûr, c'est pour ça qu'il est écrit virtualisation et paravirtualisation

      « 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

  • # Homonymies

    Posté par  (site web personnel) . Évalué à 10.

    La page de wikipedia phonon, citée dans l'article est fort intéressante mais le concerne pas ce sujet. Le lien de phonon sur wikipedia est Phonon (KDE)

    De la même façon, il fait passer par la page Zeitgeist (Homonymies) pour connaître la signification de ce mot.

    Il y a quelques soucis avec la syntaxe de ce wiki :

    • Les raccourcis [[Zeitgeist (Homonymies)]] et [[Phonon (KDE)]] ne fonctionnent pas mais Phonon fonctionne.
    • Pour faire apparaître les liens Phonon (KDE) et Zeitgeist_(homonymie) il a fallu remplacer la dernière parenthèse par %29 (son code hexadécimal).

    Bon courage Nono, il te reste encore de quoi t'occuper !

  • # pourquoi empêche?

    Posté par  . Évalué à 5.

    ceci empêche d’utiliser n’importe quel système de virtualisation, tels que KVM ou VirtualBox.

    Je ne comprends pas cette phrase : je ne vois pas en quoi ça empêche d'utiliser VirtualBox ou KVM, je dirais plutôt que cette approche est différente de celle de KVM et VirtualBox, qui tous deux virtualisent l'intégralité du système, alors que Xen nécessite une modification des noyaux des OS invités et hébergeur.

    Quant au mot "empêche", c'est de toute manière généralement le cas : les fonctions de "nested virtualization" (virtualisation imbriquée) sont assez peu testée, et rarement conseillées.

    • [^] # Re: pourquoi empêche?

      Posté par  . Évalué à 3.

      Je ne comprend pas non plus pourquoi cette phrase a été changée.

      « 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: pourquoi empêche?

      Posté par  . Évalué à 3.

      Je crois qu'il veut dire que si tu es sur un noyau XEN, tu ne pourras plus utiliser KVM, je sais pas ce qu'il se passe, mais on dirait que KVM n'a plus accès aux extensions de virtualisation quand on le lance depuis un noyau XEN (en dom0)

  • # Phonon, PulseAudio, Alsa... et leurs copains

    Posté par  (site web personnel) . Évalué à 3.

    Le système de son de Linux a considérablement évolué en à peine plus de dix ans.
    Au début, c'était OSS Open Sound System issu des machines SUN, remplacé par ALSA. On y a ajouté PulseAudio et Phonon ainsi que JACK et les différents mixers... Je ne cite pas les pilotes des cartes audio qui peuvent être aussi nombreux qu'un évêque peut en bénir.

    J'aimerais bien comprendre comment tout cela peut fonctionner ensemble. Cela me permettrait de participer activement à la recherche des bugs sur une de mes machines équipée d'une carte audio performante en plus du chip embarqué sur la carte mère.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 3.

      Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Phonon, PulseAudio, Alsa... et leurs copains

      Posté par  . Évalué à 5.

      J'aimerais bien comprendre comment tout cela peut fonctionner ensemble.

      C'est bien le problème en fait...

    • [^] # Re: Phonon, PulseAudio, Alsa... et leurs copains

      Posté par  . Évalué à 3.

      Tu mélanges un peu quand même. Phonon se veut au dessus de tout ça, c'est un framework pour pouvoir utiliser facilement xine ou gstreamer. D'ailleurs, ça fait aussi la vidéo et pas seulement le son. Et Phonon peut utiliser Alsa, OSS, Pulseaudio ou Jack.

      « 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: Phonon, PulseAudio, Alsa... et leurs copains

        Posté par  (site web personnel) . Évalué à -1.

        Tu es gentil, mais ça ne me permet toujours pas d'avoir du son avec VLC ou Totem ou Dragon alors que j'en ai avec audacity et mplayer : mplayer -ao alsa:device=pluginhw=1 cantique.wav
        J'ai une carte son Midiman delta 44 (en plus du son intégré sur la carte mère).

        • [^] # Re: Phonon, PulseAudio, Alsa... et leurs copains

          Posté par  . Évalué à 4.

          Je ne vois toujours pas le rapport avec Phonon.

          « 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

  • # drôle de formulation

    Posté par  (site web personnel) . Évalué à 10.

    Je trouve étrange cet argument :

    il faut que ces systèmes virtuels soient préparés à être virtualisés pour que la paravirtualisation; ceci empêche d’utiliser n’importe quel système de virtualisation, tels que KVM ou VirtualBox.

    Xen sait aussi exploiter les extensions de virtualisation pour virtualiser du code non modifié, mais surtout, ce que ne fait pas KVM et consorts, c'est de virtualiser du code modifié.
    On pourrait plutôt écrire :

    En préparant les systèmes virtuels à la paravirtualisation; ceci permet aussi de virtualiser quand les autres systèmes de virtualisation ne peuvent fonctionner, tels KVM ou VirtualBox.

    Alors oui, au final, depuis une machine virtuelle Xen, on ne peut plus bénéficier de KVM, tout comme depuis une machine virtuelle KVM, on ne peut plus non plus lancer virtualbox et bénéficier d'une virtualisation complète...

    Là où il y aurai une différence, c'est une différence d'usage : Xen n'est PAS linux, donc lorsqu'on utilise Xen, l'interface de contrôle (virsh du projet libvirt ou xm des xen-tools) tourne déjà dans un linux virtualisé :

                      __ xm (ou virsh)
       __ Dom0 __|
Xen __|          |__ applis
      |
      |__ DomU1 __ applis
      |
      |__ DomU2 __ applis

    Ainsi, quand on utilise Xen, il n'est donc plus possible à Qemu d'exploiter KVM, puisque nous sommes déjà dans une machine virtuelle.

    Avec KVM, l'interface de contrôle n'est pas dans une machine virtuelle :

                   __ virsh
Linux (KVM) __|
              |__ applis
              |
              |__ Qemu0 __ applis
              |
              |__ Qemu1 __ applis
              |
              |__ autre emulateur qui exploite kvm __ aplis

    Pour administrer des machines virtuelles qui exploitent KVM, on utilise communément virt-manager (gui) ou virsh (cli), ces mêmes outils sont également exploitables avec Xen. Au niveau "expérience utilisateur" de l'admin, KVM en soit n'apporte rien par rapport à Xen si on a un processeur avec extension vmx/svm, l'inverse est vrai aussi, au niveau "expérience utilisateur" de l'admin, Xen en soit n'apporte rien par rapport à KVM si on a un processeur avec extension vmx/svm. Par contre, sans ces extensions, seul Xen fonctionne.

    Ce qui est très pratique avec KVM, c'est que puisque le Linux qui fournit l'interface d'admin n'est pas virtualisé, on peut exploiter directement le matériel comme une carte graphique ou une carte son. Ainsi, on installe Ubuntu sur son portable, et à coté de d'un jeu vidéo qui va exploiter des ressources matérielles non virtualisable (par exemple Xonotic), on peut faire tourner une vm avec une carte vidéo générique émulée et des applis bureautiques.

    De plus, avec KVM, la séquence de démarrage est plus simple, qu'on veuille virtualiser ou non on a BIOS -> GRUB2 -> Linux alors que avec Xen il faut BIOS -> GRUB2 -> Xen -> Linux Si on souhaite faire de la virtualisation pour s'amuser, KVM c'est mieux

    Si on souhaite faire de la virtualisation en prod', KVM et Xen se valeront¹. KVM est sous les projecteurs et est la solution d'avenir, les solutions basées sur KVM seront meilleures parce que tout simplement c'est là que ça pousse. Pour le moment, Xen est le choix historique et donc le choix de la robustesse et de la stabilité.

    Par exemple si aujourd'hui vous voulez virtualiser sérieusement avec Debian Squeeze... J'ai été moi-même confronté à ce problème : je voulais que mes machines virtuelles soient endormies à l'extinction de la machine physique, que leur état soit conservé et qu'elles soient réveillées au démarrage. Par contre, si la machine physique est éteinte par accident (coupure EDF plus longue que l'onduleur :/ ) les scripts d'extinctions ne feront pas leur travail, et aucune machine virtuelle ne sera redémarrée lorsque le courant reviendra, ce qui est très gênant.

    Pour avoir les deux comportements, réveil de machines virtuelles endormies ET démarrage de machines virtuelles dans le cas d'un état indéterminé, les versions fournies dans Squeeze sont incomplètes, avec Xen il faudra ajouter une dépendance obsolète pas très critique de Lenny (python-xml), alors que pour KVM il faudra remplacer le paquet libvirt-bin (le coeur de l'outil, très critique) par celui du dépôt expérimental (qui paniquait à l'endormissement quand j'ai essayé). Entre un paquet non maintenu qui fontionne, et un paquet expérimental, le choix est fait.

    Si vous n'avez pas de processeur avec extension de virtualisation (et que vous n'avez aucune raison de renouveler votre parc), Xen est le seul choix, ce n'est pas un inconvénient pour Xen.

    Les technos sont mutuellement exclusives, ça n'a rien de notable et je trouve étrange de présenter comme inconvénient quelque chose d'évident et de normal.

    ¹ Probablement qu'avec Red-Hat on peut parler au présent.

    ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: drôle de formulation

      Posté par  . Évalué à 3.

      Si vous n'avez pas de processeur avec extension de virtualisation (et que vous n'avez aucune raison de renouveler votre parc), Xen est le seul choix, ce n'est pas un inconvénient pour Xen.

      Ou on peut utiliser openvz, vserver ou lxc. Pratique pour une maquette, ou une plate-forme d'administration ou d'outils voir même pour de la production "best effort". Avec un avantage indéniable de faire des économies en cpu/mémoire.

      (Bon ce n'est pas de la "vraie" virtualisation et c'est (GNU)/Linux only, mais ca vaut le détour surtout quand on ne veut pas renouveler son parc).

      • [^] # Re: drôle de formulation

        Posté par  . Évalué à 3.

        (Bon ce n'est pas de la "vraie" virtualisation et c'est (GNU)/Linux only, mais ca vaut le détour surtout quand on ne veut pas renouveler son parc)

        Il n'y a pas de vraie virtualisation! (À supposer dès lors qu'il y en ait une «fausse»?)

        Seulement des technologies de virtualisation appropriées ou pas en termes d'efficacité. J'ai toujours été contre le principe même de la virtualisation complète (VMWare, KVM, etc) si l'hôte et l'invité sont des environnements GNU/Linux, auquel cas, Virtuozzo ou OpenVZ sont bien plus indiqués. Le gaspillage en ressources est considérable en virtualisation complète; il est limité dans le cas de Virtuozzo/OpenVZ et les performances quasi natives.

        Par contre, lorsqu'il s'agit de virtualiser des systèmes invités propriétaires sur un hôte GNU/Linux, là, en effet, le choix est restreint et c'est la virtualisation complète qui doit être retenue. (Je ne tiens pas compte des autres formes de virtualisations pour OS propriétaires comme ThinApp.)

      • [^] # Re: drôle de formulation

        Posté par  (site web personnel) . Évalué à 8.

        oui :) et il y a les jails chez BSD je crois.

        Les seuls cas où j'ai besoin d'un processeur avec extension ce sont les systèmes propriétaires et les systèmes expérimentaux/confidentiels. Dans le premier cas parce que l'on n'en a pas le contrôle, dans le second cas parce que les petites ressources font qu'il y a d'autres priorité que de gérer Xen (par exemple).

        Si je voulais virtualiser un Windows (par exemple), si j'ai des doutes à propos des droits que me laisse le CLUF pour virtualiser, je n'ai pas de doute quant à la non-modification.

        Pour tester un Haiku ou un ReactOS, je ne vais pas attendre le support de Xen, je comprends que ce n'est pas une priorité.
        Quoique... je crois avoir lu dans un journal ou une news Debian que pour Hurd le support de Xen avait beaucoup aidé le développement (au moins de la distrib), car cela permettait de faire des machines de tests/build/toussa plus facilement.

        Pour ce qui est de la vraie/fausse virtualisation, ce qui compte c'est de rendre un vrai service. Si le cahier des charges stipule qu'il faut une indépendance au matériel et pouvoir déplacer les systèmes sur différentes machines, et que ces systèmes sont des systèmes libres, que la solution soit vserver, xen ou kvm/qemu, le service est rendu. Après c'est de l'idéologie ou du troll, avec le risque de choisir le moyen pour le moyen.

        Récemment sur Linuxfr quelqu'un avait leaké (via GCU) http://www.nbs-system.com/blog/xen-facts/ , j'étais moi-même arrivé aux mêmes conclusions. Au final même un serveurs qui a vocation d'être seul sur une machine physique est virtualisé. Si besoin est je peux maquetter une machine virtuelle à coté en lui vampirisant quelques ressources. Dans l'urgence je pourrais le déplacer plus tard très facilement, même sur la première machine venue. Il suffit de booter sur une clé usb avec Xen dessus, et d'avoir accès à une quelconque copie du serveur. Un tel confort mérite bien quelques cycles CPU en moins. Le cahier des charges est rempli et après Xen, KVM ou Vserver, c'est affectif.

        Il y aura toujours des vserverophobes, des kvmophobes ou des xenophobes !

        ce commentaire est sous licence cc by 4 et précédentes

    • [^] # Re: drôle de formulation

      Posté par  . Évalué à 2.

      Encore une fois, j'ai bien écrit que Xen fait de la virtualisation et de la paravirtualisation. J'ai uniquement expliquer la paravirtualisation parce que c'est souvent le point le plus nébuleux alors que la virtualisation simple est souvent connnue par la majorité des visiteurs de ce site.

      « 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: drôle de formulation

      Posté par  . Évalué à 3.

      Si on souhaite faire de la virtualisation en prod', KVM et Xen se valeront¹. KVM est sous les projecteurs et est la solution d'avenir, les solutions basées sur KVM seront meilleures parce que tout simplement c'est là que ça pousse. Pour le moment, Xen est le choix historique et donc le choix de la robustesse et de la stabilité.>

      Je dirais même plus, se "Si on souhaite faire de la virtualisation en prod, KVM et Xen se vaudront"...

    • [^] # Re: drôle de formulation

      Posté par  . Évalué à 5.

      si la machine physique est éteinte par accident (coupure EDF plus longue que l'onduleur :/ )

      Euh, ça c'est un exemple étrange: il me semble qu'on peut superviser un onduleur (sauf ceux bas de gamme) pour déclencher une action quand il arrive en bout de batterie..

      Mais oui, la loi de Murphy étant ce qu'elle est, une extinction non-programmée ça peut toujours arriver..

      • [^] # Re: drôle de formulation

        Posté par  (site web personnel) . Évalué à 4.

        De fait, j'ai déjà vu des onduleurs couper court en affichant 15min restante. Dans le même genre de comportement inattendu j'ai aussi vu un onduleur s'éteindre après retour du courant, ayant déclenché sa propre procédure d'extinction avant retour du courant, et ayant mit plusieurs minutes à s'éteindre (!).

        Après dans les logs ça fait joli : 

        N   - onduleur : coupure secteur
N+1 - onduleur : batterie basse, extinction en cours
N+2 - onduleur : retour secteur
N+3 - ping     : onduleur ne repond plus

        Il y a des serveurs avec alims redondantes, une sur onduleur et une sur le secteur, mais ça ne protège pas de ce genre de situation de compétition, en fait le serveur s'éteindrait comme s'est éteint l'onduleur, alors que le courant est revenu, le halt ayant été déjà invoqué.

        N   - onduleur : coupure secteur
N+1 - serveur  : coupure secteur
N+2 - onduleur : batterie basse, extinction en cours
N+3 - serveur  : extinction en cours
N+4 - onduleur : retour secteur
N+5 - serveur  : retour secteur
N+6 - serveur  : coupure onduleur
N+7 - ping     : onduleur ne repond plus
N+8 - ping     : serveur ne repond plus

        Murphy est un vieil ami... ;)

        ce commentaire est sous licence cc by 4 et précédentes

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.