Les performances de QEMU sont-elles (encore) à la traîne de VirtualBox et existe-t-il un moyen de les améliorer sans le support matériel + le module kvm kernel?

J'ai remarqué plusieurs articles qui affirmaient que QEMU est plus lent que VirtualBox (sans assistance matérielle), mais plusieurs ont des années, et le plus récent semble remonter à l'année dernière.

Est-il vrai que QEMU est plus lent que VirtualBox?
Si oui, pourquoi?
Existe-t-il des astuces pour combler l'écart de performances?

Certains de mes systèmes hôtes ne prennent pas en charge la virtualisation matérielle, je suis donc particulièrement intéressé par les conseils de performance qui fonctionnent sans le module du noyau.

virtualbox virtualization qemu

— Catskul
source

Réponses:

Si vous parlez de virtualisation x86 sur un hôte x86, sachez que kqemu (l'ancien module du noyau d'accélération pour qemu) est obsolète. La machine virtuelle du noyau (KVM) est "la voie à suivre" mais elle ne fonctionne que sur les hôtes Linux. L'invité peut être le système d'exploitation que vous souhaitez tant qu'il s'agit d'une architecture x86.

Cross-architecture, qemu est encore très lent; juste aujourd'hui, j'essayais le dernier qemu avec Debian MIPS64 dans l'invité .... il était utilisable depuis un terminal mais horriblement lent dans Xorg. à ma connaissance, vous ne pouvez pas utiliser les instructions d'accélération du processeur comme les tables de pages étendues ou VT-x lorsque vous effectuez une architecture croisée. Tout est émulé dans un logiciel.

Ainsi, pour la virtualisation x86 à x86, le qemu «brut» est lent, mais KVM (qui utilise qemu) est rapide. Tres rapide. Si rapide que c'est la solution de virtualisation recommandée par Red Hat pour RHEL.

VirtualBox souffle encore tout ce que qemu / kvm peut offrir en termes de performances graphiques 2d / 3d accélérées par le matériel, car kvm se concentre sur la virtualisation de serveur et virtualbox se concentre sur la virtualisation de bureau. Mais je recommanderais certainement de vérifier kvm si vous avez affaire à un serveur.

Edit: Pour vos hôtes qui n'ont aucune accélération matérielle, vous allez souffrir d'un surcoût assez important quelle que soit la solution virt que vous utilisez. Émuler des choses matérielles dans un logiciel est difficile et coûteux.

— allquixotic
source

ls $(which kvm)affiche un lien symbolique vers qemu-system-x86_64. Je suppose que c'est exactement ce dont vous parliez avec KVM en utilisant QEMU?

— Catskul

Oui, mais KVM est, comme son nom l'indique, une machine virtuelle basée sur le noyau , ce qui signifie que les tripes de l'hyperviseur sont dans le module du noyau 'kvm'. Vous pouvez le considérer comme étant similaire à l'ancien kqemu si vous le souhaitez, mais architecturalement, c'est très différent. qemu est plus une interface qu'un hyperviseur réel lorsque kvm est en fonctionnement.

— allquixotic

Oh, j'ai oublié d'ajouter: la raison pour laquelle qemu (et tout autre système de virtualisation) est si lent sans "module du noyau" (comme vous le dites; ce que vous voulez vraiment dire est "sans accélération matérielle"), c'est que certaines opérations matérielles que le les performances des invités sont très difficiles à imiter dans le logiciel. Eh bien, pas difficile en termes de manque de fiabilité ou compliqué; juste sloooooooooooooow. C'est pourquoi Intel a passé la majeure partie d'une décennie à nous donner des instructions accélérées par le matériel pour les bits de virtualisation les plus lents à la manière de VT-x et EPT. La seule solution consiste à utiliser du matériel prenant en charge ces jeux d'instructions.

— allquixotic

Y a-t-il quelque chose qui rend la virtualbox plus rapide même sans accélération matérielle?

— Catskul

Non. Sans accélération matérielle, les performances devraient être assez égales. VirtualBox peut avoir des optimisations avancées de x86 qui le rendent légèrement plus rapide dans les logiciels, ce qui serait approprié puisque virtualbox ne prend en charge que x86 en premier lieu, tandis que qemu a un champ de jeu beaucoup plus large (architectures non x86). Mais il s'agit d'un détail d'implémentation / conception qui se résumerait essentiellement à la localisation du cache, aux boucles internes optimisées, à l'assembleur codé à la main, à la mise en cache des E / S de disque côté hôte ou à d'autres astuces. Je ne sais pas dans quelle mesure vbox fait ces choses que qemu ne fait pas, mais elles ne sont pas très pertinentes ...

— allquixotic

En supposant un hôte avec un processeur capable de virtualisation (Intel VT-x, AMD SVM), exécutant Qemu sur un noyau (Linux avec KVM), il est raisonnablement rapide.

Les raisons techniques pour lesquelles Qemu est lent avec la 2D (youtube, feuille de calcul, jeux) et l'émulation 3D me sont obscures. Cependant, je peux deviner que les "pilotes vidéo" ne sont tout simplement pas assez bons - le matériel graphique du matériel n'est pas utilisé de manière optimale.

Du côté positif, un développement récent a introduit le cadre SPICE à qemu. En fait, il a quelques années et semble raisonnablement mature. Les avantages en termes de performances vidéo de l'exécution avec le pilote vidéo QXL sont énormes dans mon expérience (développement Web 2D). Je ne sais pas à quel point il se compare à Virtualbox, mais c'est certainement une amélioration. Je pense que SPICE est un incontournable pour quiconque exécute Windows dans Qemu.

Ceci est uniquement mon opinion et il convient de noter que je n'ai même jamais essayé d'exécuter une lecture 3D ou vidéo chez le client.

— Ярослав Рахматуллин
source

Si par "émulation graphique" vous faites référence à l'accélération 3D, c'est parce que les GPU ne peuvent pas être virtualisés comme les CPU. L'émulation logicielle est incroyablement lente, il existe donc aujourd'hui deux solutions: 1. Passthrough API (c'est-à-dire que les appels DirectX dans l'invité sont exécutés comme appels DirectX sur l'hôte) 2. VGA passthrough (la vraie affaire: la carte graphique entière est mise à disposition à l'invité). QEMU prend en charge # 2.

— Marcus

@Marcus Passthrough est la voie à suivre.

— Ярослав Рахматуллин