Discussion :

[tabkelm]

bonjour,

Je viens d'avoir un doute.
Je suppose que mon système hôte est un pc à 4 coeurs avec 4 threads par coeur et 8 Go de RAM
Avec VirtualBox,je lance par exemple simultanément 2 machines virtuelles configurées chacune par 1 coeur et 2 Go de RAM et 2 threads par coeur

Combien alors de RAM sur mon système hôte sera encore disponible?
(à mon avis 4 Go)

Combien alors de coeurs sur mon système hôte seront disponibles?
à mon avis 2 coeurs mais je n'en suis pas sûr !
Est-ce cela?

Combien alors de threads sur mon système hôte seront disponibles pour chaque coeur restant?


merci de votre aide

[chrtophe]

Combien alors de RAM sur mon système hôte sera encore disponible?
(à mon avis 4 Go)

oui

Au niveau des CPU, la doc est pas très claire :

You should not configure virtual machines to use more CPU cores than are available physically. This includes real cores, with no hyperthreads.

Je pense qu'il te restera 2 coeurs, Virtualbox n'a aucune option coeur phsyique/logique.

[gabriel21]

Pour la RAM, il te restera au pire 4 Go, au mieux 8 Go moins la RAM consommé par la machine 1 moins celle consommé par la machine 2. Virtualbox ne réserve pas la totalité de la RAM, mais uniquement la RAM dont il a besoin pour lui et pour les VM qui sont lancée. Par ailleurs, en cas de RAM insuffisante, l'OS de la machine physique peut décider d'envoyer sur le SWAP (Linux) ou le fichier d'échange (Windows) pour survivre. D’où le conseil de toujours garder au moins 2 Go de RAM pour OS hôte et que la RAM des VM ne doit pas dépasser RAM physique - 2Go. Pour ma part, s'il s'agit d'une machine qui ne sert pas qu'à la virtualisation, si elle fonctionne sont Windows, je conseille de laisser 4Go au Windows hôte. Cela évite les ralentissements.

Pour les threads, cela ne fonctionne pas comme la RAM, il ne s'agit pas d'une réservation du cœur d'un processeur, l'hyperviseur fait croire à l'OS virtuel qu'il a un processeur ayant 2 threads, quand l'OS invité envoie une instruction processeur et que celle ci nécessite 2 threads, l'instruction sera mise en attente au niveau du processeur physique jusqu'à ce que 2 threads soient disponible. Ce qui fait que mettre beaucoup de thread peut amener à des performances médiocres de la VM voir même sont blocage si l'hyperviseur n'arrive pas à trouver un créneau disponible. Cela impactera aussi la machine hôte. La seule règle à respecter est de ne pas dépasser le nombre total de threads pouvant être géré par le processeur physique. De toute les façons, la machine ne démarrera pas. Mais en gros si tu as 2 VM, une avec 2 threads et l'autre avec 4, potentiellement, celle à 2 ira plus vite que celle à 4, car les probabilités que 2 threads soient disponible est plus importante que 4 threads disponible.

[chrtophe]

JE te recommande de lire ceci sur la gestion mémoire par virtualBox :
https://docs.oracle.com/en/virtualiz...ory-usage.html

Il s'agit d'usage avancé, même si tu ne comptes pas les utiliser, c'est intéressant à connaitre.

[gabriel21]

Je ne savais pas que le memory ballooning était supporté par virtualbox. En même temps, je n'utilise que du VmWare ou du KVM.
Sur du VmWare, on avait du le désactiver dans certaines configurations car cela avait un impact sur les performances, et comme l'infrastructure était dimensionné comme il faut, nous n'en avions pas besoin : les machines physiques disposaient de plus de RAM que ce que demandaient les VM actives. Mais bon sur du cluster ESX, piloté par du Vsphere avec bascule automatique de certaines VM en cas de perte d'une lame (blade HP), du coup chaque lame ne dépassait pas les 70% d'utilisation. Nickel pour faire les mise à jour sans interruption de service, vu qu'il suffisait de basculer les VM sur un autre ESX pendant la maintenance.

[chrtophe]

Je ne savais pas que le memory ballooning était supporté par virtualbox.

ça n'est accessible que par le biais de vboxmanage (ligne de commande). La fusion de page peut être interessante si on exécute plusieurs VM d'un même OS.
Ca reste de l'overbooking source à problèmes.