Erreur QEMU arprès hard reboot

Support Debian
#1

J’ai dû installer une VM windows sur ma machine professionnelle Debian 10 et j’ai commencé à paramétrer ce Windows 10.

Après une pause le PC sous Debian n’a pas voulu sortir d’hibernation (la swap est trop petite semble-t’il) et j’ai donc dû rebooter à l’arrache (bouton « power »)…

Il semblerait que la VM (ou bien Qemu ?) n’aie pas aimé puisque en lançant virt-manager j’ai l’erreur "network not working"¹.
Quand je veux tester avec Aqemu j’ai l’erreur "qemu-system-x86_64: -hda Windows 10: Block node is read-only ".

Un ls -l sur le répertoire où est le fichier de la VM me montre qu’il n’est plus propriété de mon utilisateur mais de libvirt-qemu

Un chown permet de régler le problème et de démarrer la machine avec aqemu (sans réseau) et les options de virt-manager permettent de redémarrer sous virt-manager avec le réseau, mais ensuite le fichier machine redevient propriété de libvirt-qemu.

Bizarre autant qu’étrange…

C’est paramétrable ce comportement ?

¹ Ou à peu près, je n’ai pas noté sur le moment.

#2

Ah ben aujourd’hui après redémarrage c’est encore mieux, la machine est propriété de root…
On dirait l’histoire courte des débuts de Maltaite et Desberg, « Maman est aléatoire ».

#3

Bizarre, je crois qu’il n’y a aucun binaire de qemu qui soit en suid root. Vérifie les droits des binaires, parce que changer le propriétaire et surtout le faire devenir root revient à contourner le noyau… Aurais tu lancé une fois la machine en root?

#4

Non, je l’ai toujours lancée en graphique pour l’instant, donc forcément pas en root.

Les binaires dans /usr/bin/ ?
Tout ce que je vois (qemu*, aqemu, virt-manager) ont

-rwxr-xr-x root root

Ce qui me paraît normal…

#5

Bon, si tu remets le propriétaire normal de la machine virtuelle (donc du ou des disques) et que tu relances la machine virtuelle en tant que ce propriétaire, est ce que le phénomène se reproduit?

Sinon pour le block node une explication serait que la partition VFAT EFI du disque virtuel soit en vrac. Lorsque la partition est en vrac, elle se remonte souvent en RO (cas de linux par exemple). Dans ce cas, tu peux essayer de la vérifier par fsck, c’est un systeme de fichier vfat standard. Profites en pour vérifier le systeme NTFS de la partition de windows10

#6

Ben les deux premières fois que j’ai testé, oui.
Là je n’ai pas vraiment accès à la machine hôte.

Comment je fais un fsck sur la partition du disque virtuel ?
Le seul vfat que je voie avec mount | grep vfat est la partition EFI du disque principal (physique).

Mais comme le « block node » n’apparaît que lorsque je n’ai pas les droits sur le fichier de la VM, je ne pense pas que le problème soit au niveau de la partition du disque virtuel.

#7

Ah, exact, dans ce cas c’est normal, qemu n’a pas les droits d’écriture sur le fichier ce qui donne ce message d’erreur. Le souci est donc cette histoire de changement de possesseur. Comme j’ai du mal à imaginer une faille telle qu’un «non-root» puisse mettre le propriétaire d’un fichier en root, il faut regarder toute la chaine d’execution de lancement de cette machine virtuelle. Il faudarait que tu remettes le propriétaire normal puis que tu lances la machine virtuelle en regardant régulièrement quand le propriétaire change, je ne vois que ça comme méthode.
Tu peux éventuellement regarder du coté de dnotify pour intercepter le changement de propriétaire mais je ne connais pas trop cet outil…

#8

Aah je suis bête, je viens de voir (en tentant de lancer virt-manager sur un autre PC qui a été installé le même jour avec la même clé) que virt-manager me répond « System policy prevents management of local virtualized systems » et me demande le mot de passe root.
Donc je suppose que j’ai bien lancé la VM en root sans m’en rendre compte la première fois que j’ai lancé virt-manager…

#9

J’ai copié la VM sur l’autre machine donc mais en tentant de l’ouvrir avec Aqemu (pour éviter le problème de droits avec virt-manager) je ne trouve aucune option pour importer une machine sur Aqemu ?
Et le canard me donne également de la doc pour importer depuis Aqemu, mais rien pour importer dans Aqemu…

#10

Bon ben en fait il faut ajouter l’utilisateur au groupe libvirt ET au groupe kvm pour ne pas avoir à démarrer virt-manager en root…

Mais par contre le propriétaire devient toujours libvirt-qemu lorsque l’on lance la VM avec virt-manager, ce qui va re-poser des problèmes en démarrant avec Aqemu je suppose.

#11

Bon, ben entre une machine réinstallée et la découverte des groupe, tu n’as pas perdu ta journée, c’est toujours ça…

#12

Enfin je connais les groupes, j’avais juste pas pigé qu’il fallait ajouter l’utilisateur aux deux.

Et pour info si d’autres ont le même souci, virt-manager ne démarre pas le réseau virtuel par défaut.
Il faut soit le démarrer à la main (Edition ==> Détails de la Connexions ==> Réseaux virtuels) soit cocher l’option « démarrage automatique : au démarrage » dans le même onglet.

Par contre je ne comprends toujours pas pourquoi libvirt-manager devient propriétaire de ma machine à chaque fois que je la lance ?

#13

C’est ce que je voulais dire. Il y a de même les groupes vboxusers que l’on découvre qd on n’y est pas…