• [^] # Re: article avec bien trop d'erreurs ou d'inexactitudes

    Posté par . En réponse à la dépêche La virtualisation et le libre : où en est-on ?. Évalué à 3.

    XEN n'a jamais parle d'utiliser virtio
    L'article ne dit pas que XEN a parlé d'utiliser virtio, il dit seulement que cette interface permettra de mettre en commun les efforts de développement des différentes solutions. C'est comme ça que l'auteur de virtio a présenté son projet sur la liste de diffusion xen-devel d'ailleurs.

    Voir : http://archive.netbsd.se/?ml=xen-devel&a=2007-05&t=4(...)

    KVM est un hyperviseur et utilise _deja_ virtio (pas comme l'article suppose en mettant "supportera")
    L'extrait dit que KVM supportera la notion de paravirtualisation via l'interface virtio. C'est rédigé du point de vue de la disponibilité dans le kernel (cité deux fois dans l'extrait) et ces patches n'y sont pas encore intégrés. Ça a été demandé à Linus il y a 3 jours sur la LKML pour intégration dans le 2.6.26.

    Voir : http://lkml.org/lkml/2008/4/27/120

    libvirt n'est pas une couche d'abstractions permettant de s'affranchir des limitations des solutions. tout au plus une couche pour permettre de piloter les differentes solutions de facon relativement transparente
    Chez moi ça s'appelle une couche d'abstraction. Cela dit, il est clair que les auteurs auraient du détailler les limitations dont ils parlent ou supprimer cette mention.

    ESX n'etant pas un hyperviseur paravirtualise comme XEN; pas besoin de modifier l'OS pour que ca marche. (meme si ESX peut avoir des guests paravirtualises, et que xen peut faire tourner des OS non modifies a l'aide de HVM)
    Il n'est pas dit qu'ESX est un hyperviseur paravirtualisé, seulement que c'est un hyperviseur, ce qui est bien le cas.

    perte de performance genante dans le cas des "machine virtuelle complete": completement faux: l'emulation de certaines cartes relativement amicales par rapport a la virtualisation (e1000 et scsi) permet aux guests d'avoir des bonnes performances meme si on atteint pas le maximum possible avec des drivers paravirtualises.
    En gros tu dis qu'ils ont raison, sauf pour certains matériels spécifiques, et dans ce cas ce n'est de toute façon pas aussi rapide que de la paravirtualisation. Complètement faux en effet...

    le manque de mention de lguest (relativement modeste projet, mais inclus dans le kernel linux)
    Ça c'est éventuellement un oubli, mais certainement pas une erreur. Vu que tu dis toi-même que c'est un projet modeste, la raison pour laquelle ils n'en ont pas parlé semble évidente...

    virtio n'est pas un couche de "virtualisation des entrées/sorties" mais de *paravirtualisation* des entrees/sorties
    Deux lignes plus haut il est dit que virtio fournira la paravirtualisation à KVM, donc ça montre bien que ça permet de faire de la paravirtualisation et que le terme virtualisation a été employé au sens large. D'ailleurs le « draft IV » écrit par l'auteur de virtio parle également de « virtual I/O layer » et ne cite à aucun moment le terme paravirtualisation.

    Voir : http://lwn.net/Articles/240626/

    "l'émulation du processeur se faisant directement sur le processeur de la machine hôte" : contrairement aux autres systemes qui n'utilise pas les processeurs de la machine hote et utilise la magie pour fonctionner ?
    Non, contrairement aux autres systèmes qui passent par une couche intermédiaire pour traduire les instructions d'un processeur vers un autre. Mais quand on ne veut pas comprendre...

    Disclaimer : je ne bosse ni chez Citrix, ni chez VMware et je n'ai aucun lien avec les auteurs de l'article.