changement du coté libvirtd

[opentux]

hello

il y eu du changement du coté libvirt tu vérifieras pas toi même

le service devient ou va devenir déprécié je n'ai pas dans quel sens le prendre ... j'ai déjà quelque truc qui merde a l'usage comme cockpit quand j'utilise la couche de virtualisation par moment ou les services sont considéré comme legacy...

maintenant c'est virtqemud.

dans mon cas pour résoudre le problème...

j'ai desactivé tous les service libvirtd

sudo systemctl stop libvirtd.service libvirtd.socket libvirtd-ro.socket libvirtd-admin.socket
sudo systemctl disable libvirtd.service libvirtd.socket libvirtd-ro.socket libvirtd-admin.socket
sudo systemctl mask libvirtd.service libvirtd.socket libvirtd-ro.socket libvirtd-admin.socket

pour ensuite

activer les nouveaux socket virtqemud

sudo systemctl enable --now virtqemud.socket virtnetworkd.socket virtstoraged.socket

il faut evidement que le user soit dans le group libvirt a minima

et ca tourne qu'on soit sur virtmanager, gnome boxes, ou même si on utilise cockpit :)

j'utilise plusieurs techno de virtu en même temps (en fonction du taf) je n'avais pas fait gaffe que ca avait changé du coté libvirt...

[opentux]

alors pour completer apres tu en fais ce que tu en veux...

livirt a été eclaté en plein de petit service au final...
j'ai découvert plein de petite merde lié a ça... je te liste les services question tu verras ce que tu en fais ou non

sudo systemctl enable --now virtnodedevd.socket (pour gerer les node device usb pci)

mais j'ai trouvé ca aussi meme si je n'ai pas encore été emmerdé avec lol

sudo systemctl enable --now virtsecretd.socket virtnwfilterd.socket virtproxyd.socket

virtsecretd : gère les mots de passe et les clés de chiffrement (pour les disques ou le réseau).
virtnwfilterd : gère les règles de filtrage pare-feu pour les vm
virtproxyd : Agit comme un relai de compatibilité très utile pour certains clients virtuels.

[Cardiacman13]

Salut merci de me prévenir normalement j'ai fix 94cec89

[opentux]

bon a priori ca a l'air d'aller... mais a voir avec le recule j'ai du mal a saisir tout le fonctionnement de l'ensemble de ces services... pas encore le recule nécessaire on va dire

[Cardiacman13]

@opentux

Bonjour,

Je me permets de réouvrir l'issue, je voulais savoir si tu avais des nouvelles sur la meilleure façon de procéder ? Personnellement j'ai commencé à lire la doc mais tout n'est pas clair de mon côté.

[opentux]

Hello
Bon pour te faire un topo de tout ce que j'en ai compris,

Déjà sur une installation toute fraîche aucun problème ça se déroule sans problème et avec l'explication tu devrais comprendre pourquoi.

Et sur une installation déjà existante.
La c'est un peu chaotique pour rester correct 😅

Enfait libvirt est passé au modulaire

Le passage au "Modulaire"

En gros, avant, on utilisait un seul gros service monolithique, libvirtd, qui gérait absolument tout : les VMs, le réseau, le stockage. C'était l'ancienne méthode.

Maintenant, la logique a changé. On est passé sur un fonctionnement modulaire. Au lieu d'un seul bloc, t'as plusieurs petits services dédiés qui font chacun leur taf :

• virtqemud pour les VMs.
• virtnetworkd pour la partie réseau (NAT, Bridge).
• virtstoraged pour les disques.
  La petite nuance : Je n'active plus les services directement, j'active les sockets. L'idée, c'est que le service ne se lance que quand j'ouvre Virt-Manager, gnome-boxes ou Cockpit. Si tu ne les actives pas tous (notamment les logs ou le verrouillage), tu te retrouves avec des fonctions qui manquent ou des erreurs bizarres.

Pourquoi j'ai galéré sur mon installation existante ?

Sur une installation toute neuve, ça glisse. Mais sur ma machine qui tournait déjà avec l'ancien système, je me suis mangé deux gros soucis :

1. Le conflit de services :
   Mon ancien libvirtd avait laissé des fichiers de "lock" et des sockets qui traînaient. J'ai dû vraiment le désactiver et même le "mask" pour être sûr que les nouveaux services ne se marchent pas dessus.

2. Le blocage du chiffrement :
   C'est là que j'ai perdu le plus de temps. Libvirt utilise des clés et des secrets pour sécuriser les VMs (comme pour le vTPM ou les disques). Le problème, c'est que les clés générées par l'ancien service n'étaient plus acceptées par les nouveaux modules, souvent à cause d'une histoire de permissions ou de changement d'identité des services.Au final, j'ai dû carrément reset toute la partie chiffrement et les secrets. En nettoyant l'ancienne conf de zéro, j'ai forcé les nouveaux modules à régénérer des clés propres. C'est un peu radical, mais c'était le seul moyen de débloquer la situation sans passer des heures à chercher quel fichier de certificat posait problème.