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.

« Pour finir j'ai aussi dû activer une poignée d'autres services plus spécifiques, mais qui sont indispensables si tu veux pas que ça coince :

virtsecretd : Celui-là, c'est le cœur de mes emmerdes sur le chiffrement. C'est lui qui gère tous les secrets, les mots de passe de disques et les clés. Si tu ne l'actives pas, ou s'il essaie de lire les vieux secrets de l'ancienne install, ta VM ne démarrera jamais. C'est pour ça que j'ai fini par tout raser pour qu'il reparte sur des bases saines.

virtnodedevd : Je me suis fait avoir aussi avec celui-là. Il sert à détecter le matos physique. Sans lui, tu oublies le passthrough USB ou PCI. Il est aussi très lié aux permissions, donc s'il n'est pas d'équerre avec le service des secrets, ça bloque.

virtnwfilterd : Il gère les filtres réseau. C'est surtout utile quand je fais du bridge pour éviter que le trafic des VMs ne foute le bazar sur le réseau physique ou ne fasse n'importe quoi avec les IPs.

virtproxyd : C'est un peu le "standardiste". C'est lui qui fait le pont entre mon Virt-Manager et tous les petits services que je viens de te citer.
Au final, ce que j'ai retenu :

Sur une installation qui a déjà vécu, faut pas chercher à faire dans le détail. J'ai balancé une boucle pour activer tous les sockets d'un coup (qemu, network, storage, nodedev, secret, nwfilter, proxy, log, lock).
C'est vraiment en faisant ça, et en nettoyant les vieux fichiers de conf qui traînaient dans /etc/libvirt/, que j'ai enfin récupéré un système stable. Si tu restes sur l'ancien modèle, tu vas forcément tomber sur un conflit de droits à un moment donné. »

Après pour être honnête. J'ai même galéré à me rappeler tout les éléments qui ont déconné... Au passage en modulaire...

J'ai voulu le faire sur une ancienne installation pour comprendre.

Ça me servira dans mon taf plus tard quand des solutions comme nutanix, proxmox, unraid ou même dans le monde rhel... Seront à la même version de libvirt

Mais il va me falloir un peu de temps pour bien maîtriser le sujet, pour que ça devienne des habitudes de mon côté... Je ne suis pas si vieux mais je suis moins efficace qu'à une époque... Donc une distribution comme la arch depuis des années est un lab permanent pour moi... Qui permet mine de rien, quelques temps plus tard (des fois longtemps) de croiser en monde serveur les changements croisé et testé sur la arch (et pourquoi la arch, car elle suit quasiment Tous les standards du marché...)
Bref mais là je m'égare du sujet...