Bonjour,
La nouvelle version du noyau (5.10.0.16)aggrave encore plus le problème.
Pour l’instant je démarre sur le noyau 5.10.0.14 lorsque je veux utiliser mes VM.
Bon courage à tous linux c’est gratuit (heureusement) et moi j’ai le temps je suis retraité.
Même problème sous Devuan Ceres, avec noyau 5.18 !
Bonjour
C’est un peu comme dans certains couples :
est-ce que c’est ce noyau qui est incompatible avec virtualbox ?
ou bien est-ce virtualbox qui est incompatible avec ce noyau ?
Quoiqu’il en soit, chacun peut décider à tester les versions de test depuis le site virtualbox :
Soit la dernière version 6.1, soit la dernière snapshot.
Pour ma part, j’arrive à faire tourner des machines virtuelles sur ce noyau, je pense que le problème vient de VirtualBox.
Je n’utilise pas virtualbox, mais qemu/km avec virt-manager
et aussi en ligne de commande(s) avec virsh,
et je n’ai toujours rencontré aucun problème avec mes machines virtuelles
alors que :
michel@debbull:~$ uname -a
Linux debbull 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64 GNU/Linux
michel@debbull:~$
2 J'aime
Bonjour,
@Almtesh et @MicP est-il possible d’utiliser qemu ou KVM en utilisant les disques virtuels de Virtualbox a savoir les « .vdi » et les « .vmdk » bref changer de logiciel mais conserver l’existant.
Si Gnome boxes peux le faire je dirais oui ^^
J’avais utilisé ces lignes de commandes il y a quelques années,
et ça avait fonctionné.
qemu-img convert -f vdi -O qcow2 fichier.vdi fichier.qcow2
qemu-img convert -f vmdk -O qcow2 fichier.vmdk fichier.qcow2
Voir :
man qemu-img
1 J'aime
Bonjour,
J’ai rencontré le même problème après la mise à jour du kernel en version 5.10.0-16-amd64, le problème ne vient pas de virtualnox mais du noyau, il y a eu une régression du nouveau kernel par rapport au kernel 5.10.0-14-amd64.
En fait virtualbox lui-même fonctionne parfaitement mais ce sont les VM qui se crashent au démarrage laissant croire que le problème viendrait d’un problème hardware de la machine exécutant l’hyperviseur, de même l’installation de nouvelles VM que ce soit en Windows ou Linux se crashe aussi de manière aléatoire.
Moi j’ai choisi de réinstaller le kernel 5.10.0-14-amd64 et d’en faire le kernel par défaut en attendant que les dev corrigent le problème et tout fonctionne parfaitement maintenant.
Ci-dessous les actions réalisées :
- installation du kernel et des headers correspondants :
apt install linux-image-5.10.0-14-amd64 linux-headers-5.10.0-14-amd64
- Modification du fichier /etc/default/grub pour démarrer sur le kernel 5.10.0-14-amd64
Dans mon cas c’est le kernel qui se trouve en cinquième position dans le menu « menuentry » du fichier /boot/grub/grub.cf comme le système commence sa numérotation par 0 donc c’est le kernel en position 4
vi /etc/default/grub modification de la ligne ci-dessous:
GRUB_DEFAULT="1>4" (Les " "sont importants)
Mise à jour de grub :
update-grub
- Figeage des packages « linux-image-5.10.0-14-amd64 linux-headers-5.10.0-14-amd64 linux-headers-5.10.0-14-common » pour empêcher que le système les met à jour:
apt-mark hold linux-image-5.10.0-14-amd64 linux-headers-5.10.0-14-amd64 linux-headers-5.10.0-14-common
Quand le problème sera résolu il faudra remplacer "hold’ par « unhold » dans la commande pour libérer ces packages et les permettre de se me à jour.
Dans mon cas tout fonctionne parfaitement maintenant.
Willy
Je n’utilise pas VirtualBox, mais je n’ai rencontré aucun problème en utilisant toutes les différentes versions du noyau jusqu’à la version actuelle (5.10.0-16-amd64) incluse
pour faire tourner mes machines virtuelles avec qemu/kvm
1 J'aime
Pour compléter mon message précédent :
J’utilise debian 11 (bullseye) <=> version stable
michel@debbull:~$ cat /etc/apt/sources.list
# Type URI Distribution Catégories
deb https://deb.debian.org/debian/ bullseye main contrib non-free
deb-src https://deb.debian.org/debian/ bullseye main contrib non-free
deb https://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb-src https://deb.debian.org/debian/ bullseye-updates main contrib non-free
deb https://security.debian.org/debian-security bullseye-security main contrib non-free
deb-src https://security.debian.org/debian-security bullseye-security main contrib non-free
michel@debbull:~$
michel@debbull:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 11 (bullseye)
Release: 11
Codename: bullseye
michel@debbull:~$
michel@debbull:~$ uname -a
Linux debbull 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64 GNU/Linux
michel@debbull:~$
Voir aussi la page suivante : KVM - Debian Wiki
dans laquelle on trouvera un lien vers : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=794466
Bonsoir,
la nouvelle version de virtualbox semble régler le problème.
Passer sur KVM QEMU m’intéresse, mais il semble qu’il faille convertir les disque virtualbox. Or, mes disques virtuel sont tous défini avec une taille qui augmente automatiquement en fonction des besoins. Est-ce possible avec KVM et QEMU lors de la conversion? ou seront-ils figés a la taille physique actuel?
1 J'aime
Oui, le format de fichier .qcow2 que j’ai proposé a une taille qui augmente automatiquement en fonction des besoins