Ubuntu-fr

men-go

[Résolu] Virtualbox: durée excessive lors des communications VM-hôte

Bonjour,

N'étant pas un spécialiste réseau, je me suis installé il y a quelque temps un petit réseau virtuel comprenant deux VM routeurs (Debian stretch) et six VM Ubuntu. Cela m'a permis d'appréhender Virtualbox et combler quelques lacunes puisque dans mon petit réseau j'utilise les trois types d'adresses IP publiques.

Tout ceci fonctionnait correctement jusqu'au moment où il a fallu passer de Ubuntu 18.04 à 20.04. Non pas que les systèmes se plantent, mais on dirait qu'il existe un goulet d'étranglement dans la communication entre les VM et le système hôte. Cela se traduit par une lenteur désespérante lorsqu'on boote deux ou trois VM en même temps. Idem lors des mises à jour système des VM, la durée du décompactage des paquets est multipliée par 15 ou 20.

D'après ce que j'ai pu constater, la rupture s'est faite avec Virtualbox V6 et le noyau Linux 5.3. A titre d'exemple, pas de problème avec comme hôte Ubuntu 18.04 et un noyau 4.15 mais les mêmes ralentissements avec Ubuntu 18.04 et un noyau 5.4.

J'installe Virtualbox comme d'habitude, mais il faut croire qu'il doit me manquer une définition (au niveau noyau ?):

sudo apt install virtualbox virtualbox-dkms virtualbox-ext-pack virtualbox-guest-additions-iso virtualbox-qt virtualbox-source

Le problème existe quelque soit le noyau:
Noyau 20.04 upgradé:
linux-headers-generic, linux-headers-5.4.0-70, linux-headers-5.4.0-70-generic, linux-modules-extra-5.4.0-70-generic, linux-image-generic, linux-image-5.4.0-70-generic, linux-modules-5.4.0-70-generic, linux-base, linux-generic, linux-signed-generic, linux-firmware

Noyau 20.04 installé:
linux-base, linux-headers-5.8.0-48-generic, linux-headers-generic-hwe-20.04, linux-hwe-5.8-headers-5.8.0-48,
linux-generic-hwe-20.04, linux-image-5.8.0-48-generic, linux-image-generic-hwe-20.04, linux-modules-5.8.0-48-generic, linux-modules-extra-5.8.0-48-generic, linux-firmware                               

Étant donné qu'en l'état c'est quasiment inexploitable, je pense que ce problème a dû être résolu, c'est pourquoi je vous remercie par avance de l'aide que vous pouvez m'apporter.

Dernière modification par men-go (Le 19/05/2021, à 11:52)

Beta Pictoris

Re : [Résolu] Virtualbox: durée excessive lors des communications VM-hôte

Tes vms sont installées sur un disque ssd  ?

Il est peut-être temps de passer sous qemu (ex kvm) ? : https://www.phoronix.com/scan.php?page= … -kvm&num=2

Dernière modification par Beta Pictoris (Le 11/04/2021, à 19:19)

men-go

Re : [Résolu] Virtualbox: durée excessive lors des communications VM-hôte

@ Beta Pictoris

Merci pour ta réponse.

Non mes VMs ne sont pas sur SSD, j'ai de mauvais souvenirs de ce composant (j'ai plus confiance avec des HDD avec cache où si panne il y a  on arrive à récupérer des choses alors qu'avec un SSD on ne récupère rien). Ceci étant, pour une même VM sur le même HDD et une mise à jour système d'environ 500Mo je passe d'une durée entre 5 et 6 minutes à plus de 1h30.

Il est vrai qu'en parallèle j'étudie une solution de rechange et je ne manquerai pas d'étudier celle que tu me proposes.

men-go

Re : [Résolu] Virtualbox: durée excessive lors des communications VM-hôte

Bonjour,

J'ai testé (survolé) Proxmox, Xen et Qemu. Résultats en résumé: je cherche à avoir des machines virtuelles qui sont l'équivalent de PC modernes (écran rectangulaire et non carré, disque(s) avec formatage GPT et boot UEFI) et les systèmes d'exploitation qui vont avec. Jusqu'à présent je n'ai trouvé ceci que dans VirtualBox. LVM est certainement utile dans des configurations (très) ambitieuses, ce qui est loin d'être mon cas.

J'ai donc trouvé une solution provisoire qui consiste en gros à cloner sur un disque USB au format GPT les différentes partitions systèmes de mes VM, à faire les mises à jour sur une machine réelle et à recloner dans l'autre sens. Comme je n'ai pas encore assez de recul et sachant que le premier clonage ne sera pas fait systématiquement je pense pouvoir diviser le temps des mises à jour au moins par 3.

J'ai fait un certain nombre de tests qui n'ont évidemment rien donné et je ne vois toujours pas pourquoi la virtualisation a une telle incidence sur le décompactage des paquets. En tout cas ça m'aiderait beaucoup de simplement savoir si d'autres ont le même problème. Merci d'avance.

men-go

Re : [Résolu] Virtualbox: durée excessive lors des communications VM-hôte

Bonjour,

Il y a quelques jours j'ai dû booter un système USB sur une VM monodisque pour y apporter des modifications. Ce système USB n'avait pas été mis à jour et je m'attendais à ce que ça le fasse en pratiquement une heure. Or pour environ 500 Mo de MAJ ça a duré une douzaine de minutes ce qui, pour un USB3 est relativement correct. Comme il n'y a aucune addition VB à ce système, j'ai cloné l'équivalent sur un disque VBI et relancé les MAJ et là ça a été catastrophique comme d'habitude.

VirtualBox gère plusieurs types de conteneurs et jusqu'à présent j'ai privilégié le leur (VBI). Mais comme sur un USB3 ça allait presque 10 fois plus vite, j'ai décidé de tester les autres conteneurs. J'ai commencé par HDD: durée environ 2 fois USB3. Puis VMDK (the popular and open VMDK container format that is used by many other virtualization products, such as VMware). Et là bingo ! En fait les temps d'exécution sont quasiment 3 fois plus rapides que ceux que j'avais avant la survenue du problème.

Après quelques tests, j'ai recopié (par la fonction ad'hoc de VirtualBox, ~4mn pour 20Go) tous mes VBI en VMDK, ce qui résolu même les performances de lancement des machines virtuelles.

Avant de clore ce chapitre je voudrais laisser un petit souvenir à ceux qui se sont intéressés à mon problème. Comme vous, je faisais souvent du "sudo" et j'en ai eu marre des ampoules au doigts et des trous dans le clavier à force d'entrer mon mot de passe. C'est pourquoi j'ai écrit un petit script que j'ai appelé "supa" (‘su’ pour administrateur) basé sur «/etc/sudoers.d».

Prenons comme exemple un système avec 3 utilisateurs: ulysse, aristote et zsecadm. ulysse est l'administrateur principal, aristote est un simple utilisateur et zsecadm l'administrateur de secours. Tous ces utilisateurs ont le même groupe principal, celui d'ulysse. Le fichier à placer dans «/etc/sudoers.d» aura la physionomie suivante:

%ulysse ALL=(ALL) NOPASSWD: /usr/local/bin/mnfsu
ulysse ALL=(ALL) NOPASSWD: /sbin/shutdown,/usr/local/sbin/supa,/usr/local/sbin/rmount
zsecadm ALL=(ALL) NOPASSWD: /sbin/shutdown,/usr/local/sbin/supa,/usr/local/sbin/rmount
# eof

Dans la première ligne on indique que pour le groupe ulysse (%ulysse) on est dispensé d'entrer son mot de passe pour l'application «/usr/local/bin/mnfsu». On comprend facilement la signification des 2 dernières lignes.

Le script «supa» est:

#!/bin/bash
#men-go: supa
#
USAGE="#
#
# supa [@#PROF] [nx] ”script_name” ”arguments1_de_script_name” ”arguments2”
#
# Exécute en mode root ”script_name arguments_de_script_name” avec ’exec’ ou
# sans (nx) et éventuellement ajout/modification de l'environnement par PROF.
#14/07/2017⇔102(S)###########################################################
#"; [ "$1" = "-h" -o "$1" = "--help" ] && { echo -n "$USAGE ";ls -l --time-style=+%Y/%m/%d-%H:%M:%S $0; exit 2;}
[ $UID -ne 0 ] && { sudo -H "$0" "$1" "$2" "$3" "$4" "$5"; exit $?;}
#________________
#
PROF=": "; [ "${1:0:2}" = "@#" ] && { PROF=".  ${1#@#}"; shift;}
export HOME="/home/$SUDO_USER"; [ -f .profile ] && .  .profile
$PROF

[ "$1" = "nx" ] && { bash -c "$2 $3 $4"; exit $?;} || exec bash -c "$1 $2 $3"

[ $UID -ne 0 ]…: si $UID et différent de 0, on réexécute via sudo le script (sudo -H "$0"…)
Suivent ensuite les commandes de gestion de l'environnement avec les fichiers «.profile» et éventuellement "@#PROF" PROF étant le chemin d'un fichier profile qui sera préfixé par "@#" pour être certain de la nature du fichier.

La dernière ligne est l'exécution sous root de l'application indiquée en argument de «supa». À noter toutefois que contrairement à sudo, le nombre d'arguments de supa est limité. Le fait qu'à la fin, la commande est interprétée par bash voudra dire que pour certaines applications, il faudra donner les arguments sous forme de chaîne(s) et donc jongler avec les doubles quotes. Ex:

supa update-initramfs -u
supa grub-install "--directory=/usr/lib/grub/x86_64-efi --efi-directory=/boot/efi --target=x86_64-efi --boot-directory=/boot"
supa useradd "-lmU -c Invité -d /tmp/invité -s /bin/bash -u 1099 invité"; supa "passwd -d invité"

Comme on ne donne pas son mot de passe, on peut aussi exécuter des applications graphiques avec Alt-F2:
supa gparted
supa synaptic

Idem pour certains lanceurs (.desktop) comme nautilus ou nemo sous root:
Exec=supa "pkexec nemo /usr/local"
Exec=supa "pkexec nautilus /usr/local"

Enfin certains scripts utilisateur s'exécutent sous root avec la séquence par exemple:

#!/bin/bash
#men-go: clnaptx
#
USAGE="#
# clnaptx  [-c|C|n] lDATA [LSYS] [RELN] [ARCH]
#
# -c|C|n	-c: Création de la structure “cache APT“ (dft: clean). -C: Création
# 		de la structure et recopie /var/cache/apt/archives/*.deb du volume LSYS
# 		-n: Clean inconditionnel de la structure «\$lDATA/apt-c\$ARCH_\$RELN»
# lDATA	Label volume/répertoire ([/media/]) cible du (nouveau) cache APT
# LSYS		Label volume système cible
# RELN		Nom de la release d'Ubuntu (dft: actuelle)
# ARCH		Architecture (64 ou 32 bits. Dft: 64)
#
# Si ! ‘-c&-C’, nettoie un cache APT (clean) externe (non pointé par /var/cache/apt).
#26/04/2016⇔105(S)#####################################################################
#";. ifhelp
[ $UID -ne 0 ] && { supa "$0" "\"$1\" \"$2\" \"$3\" \"$4\" \"$5\""; exit $?;}
startend "" "$*"
…
…

«ifhelp» est un petit fichier équivalent à la première commande de «supa», ‘startend’ est une fonction spécifique. Si on exécute “clnatpx -h[|--help]”, on affiche $USAGE et on s'arrête. Sinon lorsque on entre ‘clnatpx ……’, l'exécution se passe en 2 temps
1) BASH va créer un processus normal
2) Si $UID -ne 0, «supa» va créer un second processus en mode root avec le même script (supa "$0"). Dans ce second processus UID sera 0, on passera le test et donc l'exécution va commencer à ‘startend "" "$*"’ (si on est déjà en mode root, ce second processus n'est pas créé)

Bien faire attention à ce que la totalité des arguments sont bien passés au second processus. La sécurité du système va dépendre du fichier placé dans «/etc/sudoers.d», donc à utiliser avec parcimonie.

Depuis je n'ai plus de problème aux doigts et mes claviers sont comme neufs.