Bonjour,

En redémarrant une machine qui tournait sur le kernel linux-image-6.1.0-28-amd64 et est passée en kernel
linux-image-6.1.0-32-amd64, je me suis rendu compte que le service
libvirtd retournait une erreur:

--8<------8<------8<------8<------8<------8<------8<------8<----

/ssh:proclos.tourde.home|sudo:root@proclos.tourde.home:/root $ systemctl status libvirtd
● libvirtd.service - Virtualization daemon
Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; preset: enabled)
Active: active (running) since Sun 2025-03-23 21:25:30 CET; 14min ago TriggeredBy: ● libvirtd.socket
● libvirtd-admin.socket
● libvirtd-ro.socket
Docs: man:libvirtd(8)
https://libvirt.org
Main PID: 1105 (libvirtd)
Tasks: 20 (limit: 32768)
Memory: 28.0M
CPU: 735ms
CGroup: /system.slice/libvirtd.service
└─1105 /usr/sbin/libvirtd --timeout 120

Mar 23 21:25:30 proclos systemd[1]: Starting libvirtd.service - Virtualization daemon...
Mar 23 21:25:30 proclos systemd[1]: Started libvirtd.service - Virtualization daemon.
Mar 23 21:25:30 proclos libvirtd[1105]: libvirt version: 9.0.0, package: 9.0.0-4+deb12u2 (Debian)
Mar 23 21:25:30 proclos libvirtd[1105]: hostname: proclos
Mar 23 21:25:30 proclos libvirtd[1105]: Unable to create bridge virbr0: Le paquetage n'est pas installé
Mar 23 21:25:31 proclos libvirtd[1105]: Impossible d'ouvrir /dev/kvm: Aucun fichier ou dossier de ce type

--8<------8<------8<------8<------8<------8<------8<------8<----

Après quelques rapides recherches, j'ai supposé que ça pouvait venir du kernel, et bingo c'est bien reparti avec la version -28-amd64 de
celui-ci. Du coup, j'ai quelques questions:

- Est-ce une erreur d'options de compilation, une mauvaise lecture de la
doc (laquelle ?) ou un module à charger ?
- Comment j'aurais pû anticiper cette perte de fonctionnalité ?
- Où puis-je le signaler si c'est bien une erreur ?

Je précise que c'est sur un hyperviseur Xen sous bookworm (Debian 12)

Merci d'avance pour vos réponses.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour

aucun soucis avec le dernier kernel sous bookworm mais je n'utilise pas xen

Les modules chargés:

dh@aki ~ $ lsmod |grep kvm
kvm_intel             380928  8 kvm                  1146880  1 kvm_intel irqbypass              16384  31 kvm

Le 24/03/2025 à 15:31, François TOURDE a écrit :

Bonjour,

En redémarrant une machine qui tournait sur le kernel linux-image-6.1.0-28-amd64 et est passée en kernel linux-image-6.1.0-32-amd64, je me suis rendu compte que le service
libvirtd retournait une erreur:

--8<------8<------8<------8<------8<------8<------8<------8<----

/ssh:proclos.tourde.home|sudo:root@proclos.tourde.home:/root $ systemctl status libvirtd
● libvirtd.service - Virtualization daemon
Loaded: loaded (/lib/systemd/system/libvirtd.service; enabled; preset: enabled)
Active: active (running) since Sun 2025-03-23 21:25:30 CET; 14min ago TriggeredBy: ● libvirtd.socket
● libvirtd-admin.socket
● libvirtd-ro.socket
Docs: man:libvirtd(8)
https://libvirt.org
Main PID: 1105 (libvirtd)
Tasks: 20 (limit: 32768)
Memory: 28.0M
CPU: 735ms
CGroup: /system.slice/libvirtd.service
└─1105 /usr/sbin/libvirtd --timeout 120

Mar 23 21:25:30 proclos systemd[1]: Starting libvirtd.service - Virtualization daemon...
Mar 23 21:25:30 proclos systemd[1]: Started libvirtd.service - Virtualization daemon.
Mar 23 21:25:30 proclos libvirtd[1105]: libvirt version: 9.0.0, package: 9.0.0-4+deb12u2 (Debian)
Mar 23 21:25:30 proclos libvirtd[1105]: hostname: proclos
Mar 23 21:25:30 proclos libvirtd[1105]: Unable to create bridge virbr0: Le paquetage n'est pas installé
Mar 23 21:25:31 proclos libvirtd[1105]: Impossible d'ouvrir /dev/kvm: Aucun fichier ou dossier de ce type

--8<------8<------8<------8<------8<------8<------8<------8<----

Après quelques rapides recherches, j'ai supposé que ça pouvait venir du kernel, et bingo c'est bien reparti avec la version -28-amd64 de
celui-ci. Du coup, j'ai quelques questions:

- Est-ce une erreur d'options de compilation, une mauvaise lecture de la
doc (laquelle ?) ou un module à charger ?
- Comment j'aurais pû anticiper cette perte de fonctionnalité ?
- Où puis-je le signaler si c'est bien une erreur ?

Je précise que c'est sur un hyperviseur Xen sous bookworm (Debian 12)

Merci d'avance pour vos réponses.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday 24 March 2025 15:31:46 Fran�ois TOURDE wrote:

En red�marrant une machine qui tournait sur le kernel linux-image-6.1.0-28-amd64 et est pass�e en kernel linux-image-6.1.0-32-amd64, je me suis rendu compte que le service
libvirtd retournait une erreur:

J'ai des probl�mes depuis que j'ai upgrad� mon kernel en linux-image-6.1.0-32-amd64 et linux-headers-6.1.0-32-amd64.
J'ai ce message � chaque apt install ... :
"dpkg: error processing package linux-headers-amd64 (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
linux-headers-6.1.0-32-amd64
linux-headers-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)"

Pourtant, mis � part ce bl�me, le syst�me fonctionne bien globalement.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This is a multi-part message in MIME format.
Bonjour,

Le 24/03/2025 à 17:07, ajh-valmer a écrit :

"dpkg: error processing package linux-headers-amd64 (--configure):
dependency problems - leaving unconfigured

Apparemment, les headers ont besoin d’une dépendance pour pouvoir être configurés.

Du coup, un ou plusieurs modules n’ont pas dû être compilés par dkms et ils ne doivent pas être chargés par le nouveau noyau. Globalement cela
doit fonctionner, dans les détails, peut-être un peu moins.

Chercher quel paquet manque dans les dépendances des headers (ou
pourquoi il n’a pas pu être installé) devrait te permettre d’avancer.

Bonne soirée,

Luc.

&#8203;
<!DOCTYPE html>
<html>
<head>

<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title></title>
<meta charset="utf-8">
</head>
<body>
<div class="markdown-here-wrapper">
<p
style="margin-block: 0px 16.8px; margin-bottom: 16.8px; margin-top: 0px;">Bonjour,</p>
<p
style="margin-block: 0px 16.8px; margin-bottom: 16.8px; margin-top: 0px;">Le
24/03/2025 à 17:07, ajh-valmer a écrit :</p>
<blockquote type="cite"
style="border-block-color: rgb(119, 119, 119); border-bottom-color: rgb(119, 119, 119); border-inline-color: rgb(114, 159, 207) rgb(119, 119, 119); border-inline-start: 1.73333px solid rgb(114, 159, 207); border-left: 1.73333px solid rgb(114, 159, 207);
border-right-color: rgb(119, 119, 119); border-top-color: rgb(119, 119, 119); caret-color: rgb(119, 119, 119); color: rgb(119, 119, 119); column-rule-color: rgb(119, 119, 119); margin-block: 7.5px; margin-bottom: 7.5px; margin-inline: 0px; margin-left:
0px; margin-right: 0px; margin-top: 7.5px; outline-color: rgb(119, 119, 119); padding-block: 3px; padding-bottom: 3px; padding-inline: 7.5px; padding-left: 7.5px; padding-right: 7.5px; padding-top: 3px; quotes: none; text-decoration-color: rgb(119, 119,
119); text-emphasis-color: rgb(119, 119, 119);">
<div class="external-content" id="extcontent-0" style="border-block-color: rgb(119, 119, 119); border-bottom-color: rgb(119, 119, 119); border-inline-color: rgb(119, 119, 119); border-left-color: rgb(119, 119, 119); border-right-color: rgb(119, 119, 119); border-top-color: rgb(119, 119, 119); caret-
color: rgb(119, 119, 119); color: rgb(119, 119, 119); column-rule-color: rgb(119, 119, 119); outline-color: rgb(119, 119, 119); quotes: none; text-decoration-color: rgb(119, 119, 119); text-emphasis-color: rgb(119, 119, 119);">
<pre wrap="" class="moz-quote-pre">"dpkg: error processing package linux-headers-amd64 (--configure):
dependency problems - leaving unconfigured</pre>
</div>
</blockquote>
<p
style="margin-block: 0px 16.8px; margin-bottom: 16.8px; margin-top: 0px;">Apparemment,
les headers ont besoin d’une dépendance pour pouvoir être
configurés.</p>
<p
style="margin-block: 0px 16.8px; margin-bottom: 16.8px; margin-top: 0px;">Du
coup, un ou plusieurs modules n’ont pas dû être compilés par
dkms et ils ne doivent pas être chargés par le nouveau noyau.
Globalement cela doit fonctionner, dans les détails, peut-être
un peu moins.</p>
<p
style="margin-block: 0px 16.8px; margin-bottom: 16.8px; margin-top: 0px;">Chercher
quel paquet manque dans les dépendances des headers (ou pourquoi
il n’a pas pu être installé) devrait te permettre d’avancer.</p>
<p
style="margin-block: 0px 16.8px; margin-bottom: 16.8px; margin-top: 0px;">Bonne
soirée,</p>
<p
style="margin-block: 0px 16.8px; margin-bottom: 16.8px; margin-top: 0px;">Luc.</p>
<div title="MDH:PHA+Qm9uam91ciw8YnI+PC9wPjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+TGUgMjQvMDMvMjAyNSDDoCAxNzowNywgYWpoLXZhbG1lciBhIMOpY3JpdCZuYnNwOzo8YnI+PC9kaXY+
PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOjIwMjUwMzI0MTcwNy4zNzY4NC5hamgudmFsbWVyQGZyZWUuZnIiPjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+
ImRwa2c6IGVycm9yIHByb2Nlc3NpbmcgcGFja2FnZSBsaW51eC1oZWFkZXJzLWFtZDY0ICgtLWNvbmZpZ3VyZSk6CiBkZXBlbmRlbmN5IHByb2JsZW1zIC0gbGVhdmluZyB1bmNvbmZpZ3VyZWQ8L3ByZT48L2Jsb2NrcXVvdGU+PHA+
PGJyPjwvcD48cD5BcHBhcmVtbWVudCwgbGVzIGhlYWRlcnMgb250IGJlc29pbiBkJ3VuZSBkw6lwZW5kYW5jZSBwb3VyIHBvdXZvaXIgw6p0cmUgY29uZmlndXLDqXMuPC9wPjxwPkR1IGNvdXAsIHVuIG91IHBsdXNpZXVycyBtb2R1bGVzIG4nb250IHBhcyBkw7sgw6p0cmUgY29tcGlsw6lzIHBhciBka21zIGV0IGlscyBuZSBkb2l2ZW5
0IHBhcyDDqnRyZSBjaGFyZ8OpcyBwYXIgbGUgbm91dmVhdSBub3lhdS4gR2xvYmFsZW1lbnQgY2VsYSBkb2l0IGZvbmN0aW9ubmVyLCBkYW5zIGxlcyBkw6l0YWlscywgcGV1dC3DqnRyZSB1biBwZXUgbW9pbnMuPC9wPjxwPkNoZXJjaGVyIHF1ZWwgcGFxdWV0IG1hbnF1ZSBkYW5zIGxlcyBkw6lwZW5kYW5jZXMgZGVzIGhlYWRlcnMgKG
91IHBvdXJxdW9pIGlsIG4nYSBwYXMgcHUgw6p0cmUgaW5zdGFsbMOpKSBkZXZyYWl0IHRlIHBlcm1ldHRyZSBkJ2F2YW5jZXIuPC9wPjxwPkJvbm5lIHNvaXLDqWUsPC9wPjxwPkx1Yy48L3A+PHA+
PGJyPjwvcD48ZGl2IGlkPSJncmFtbWFsZWN0ZV9tZW51X21haW5fYnV0dG9uX3NoYWRvd19ob3N0IiBzdHlsZT0id2lkdGg6IDBweDsgaGVpZ2h0OiAwcHg7Ij48L2Rpdj48dWwgY2xhc3M9ImRyb3Bkb3duLW1lbnUgdGV4dGNvbXBsZXRlLWRyb3Bkb3duIiBzdHlsZT0iZGlzcGxheTogbm9uZTsgcG9zaXRpb246IGFic29sdXRlOyB6LWl
uZGV4OiAxMDAwOyIgY29udGVudGVkaXRhYmxlPSJmYWxzZSI+PC91bD4="
aria-hidden="true"
style="font-size: 0px; padding: 0px; margin: 0px; block-size: 0px; height: 0px; inline-size: 0px; max-block-size: 0px; max-height: 0px; max-inline-size: 0px; max-width: 0px; overflow-block: hidden; overflow-inline: hidden; overflow: hidden; width: 0px;"
class="mdhr-raw">&amp;#8203;</div>
</div>
</body>
</html>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday 24 March 2025 17:07:37 ajh-valmer wrote:

On Monday 24 March 2025 15:31:46 Fran�ois TOURDE wrote:

En red�marrant une machine qui tournait sur le kernel linux-image-6.1.0-28-amd64 et est pass�e en kernel linux-image-6.1.0-32-amd64, je me suis rendu compte que le
service libvirtd retournait une erreur:

J'ai des probl�mes depuis que j'ai upgrad� mon kernel en linux-image-6.1.0-32-amd64 et linux-headers-6.1.0-32-amd64.
J'ai ce message � chaque apt install ... :
"dpkg: error processing package linux-headers-amd64 (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
linux-headers-6.1.0-32-amd64
linux-headers-amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)"
Pourtant, mis � part ce bl�me, le syst�me fonctionne bien globalement.

Je r�ponds � moi m�me.
En d�sinstallant <linux-headers-6.1.0-32-amd64>,
je n'ai plus de messages d'erreur ci-dessus sans affecter le syst�me.
Dans la foul�e, mes d�boires de carte graphique Nvidia 470,
de cl� Wifi ont disparu sur le sujet :
"upgrade Debian kernel 6.1.0-32 pas possible".
On verra lors de l'upgrade vers le prochain kernel 6.1.0-33-amd64...
Si �a peut aider lors de passage en kernel 6.1.0-32-amd64.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Bonjour,

Le 2025-03-24 23:52, ajh-valmer a écrit :

En désinstallant <linux-headers-6.1.0-32-amd64>,
je n'ai plus de messages d'erreur ci-dessus sans affecter le système.
Dans la foulée, mes déboires de carte graphique Nvidia 470,
de clé Wifi ont disparu sur le sujet :
"upgrade Debian kernel 6.1.0-32 pas possible".
On verra lors de l'upgrade vers le prochain kernel 6.1.0-33-amd64...

Les entêtes du noyau sont nécessaires pour la compilation de modules. Désinstaller les entêtes fait que les modules qui en auraient besoin ne seront
pas compilés.
Ce que tu exposes là n'est donc pas une solution puisque ça consiste à
faire en
sorte que le besoin fonctionnel qui implique des éléments techniques qui échouent
ne soit plus adressé (dit autrement : ton noyau se met à jour mais ton périphérique
ne fonctionne plus).

Si ça peut aider lors de passage en kernel 6.1.0-32-amd64.

Ce qui aurait pu aider, ça aurait été de ne pas détourner un fil de discussion qui
n'a aucun rapport pour y ramener ton problème (compilation de module
noyau de carte
wi-fi qui échoue vs. module bridge libvirt).

Sébastien

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 20171ième jour après Epoch,
NoSpam écrivait:

Bonjour

aucun soucis avec le dernier kernel sous bookworm mais je n'utilise
pas xen

Mais utilise-tu libvirtd et la notion de bridge ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Oui, virbr0 et /dev/kvm existe.

Le 25/03/2025 à 11:17, François TOURDE a écrit :

Le 20171ième jour après Epoch,
NoSpam écrivait:

Bonjour

aucun soucis avec le dernier kernel sous bookworm mais je n'utilise
pas xen

Mais utilise-tu libvirtd et la notion de bridge ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 25/03/2025 à 11:38, François TOURDE a écrit :

---8<--------8<--------8<--------8<--------8<--------8<--------8<----- /ssh:proclos.tourde.home|sudo:root@proclos.tourde.home:/root $ virsh net-start cloudNet
error: Failed to start network cloudNet
error: Unable to create bridge virbr0: Le paquetage n'est pas installé ---8<--------8<--------8<--------8<--------8<--------8<--------8<-----

Que dit brctl show ?

--
Daniel

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 20172ième jour après Epoch,
didier gaumet écrivait:

[...]

- chez moi, comme chez NoSpam, vibr0 fonctionne sans souci sous
Bookworm avec libvirt/kvm (virtmanager)

Et tu as bien une interface 'virbr0' (ou autre) dans ton ifconfig ? Avec
le kernel indiqué dans le sujet ?

- j'y connais *vraiment* *rien* mais je me demande si le message
d'erreur correspond à un pont réseau qui ne marche réellement pas ou
correspond juste à une initialisation réseau qui ne fonctionne pas à
ce moment-là, tôt lors du boot? Auquel cas réinstaller le noyau ou
régénérer l'initramfs pourrait peut-être solutionner le problème (le
/dev/kvm étant alors manquant lors des premiers étapes du boot et
pas ensuite)?

Voilà ce que me donne le démarrage manuel du réseau virtuel une fois la machine correctement bootée:

---8<--------8<--------8<--------8<--------8<--------8<--------8<----- /ssh:proclos.tourde.home|sudo:root@proclos.tourde.home:/root $ virsh net-start cloudNet
error: Failed to start network cloudNet
error: Unable to create bridge virbr0: Le paquetage n'est pas installé ---8<--------8<--------8<--------8<--------8<--------8<--------8<-----

Ré-installer -32-amd64 ou régénérer initramfs (qui l'a été lors de l'install du nouveau kernel) n'est pour le moment pas une option pour
moi. Il faut que j'attende l'été :) ... Ce serveur opère une VM qui gère entre autre mon chauffage, je n'ai pas trop envie d'expérimenter :D

Tu as un /dev/kvm ou pas?

Jamais eu de KVM sur cette machine.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 20172ième jour après Epoch,
didier gaumet écrivait:

Le 25/03/2025 à 11:38, François TOURDE a écrit :
[...]

Et tu as bien une interface 'virbr0' (ou autre) dans ton ifconfig ? Avec
le kernel indiqué dans le sujet ?

didier@hp-notebook14:~$ uname -a
Linux hp-notebook14 6.1.0-32-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.1.129-1 (2025-03-06) x86_64 GNU/Linux

didier@hp-notebook14:~$ ip addr
[...]
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state DOWN group default qlen 1000
link/ether 52:54:00:cc:c4:91 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever

Merci pour ces détails ! Il va falloir que je creuse ça un peu plus
alors. Je ne comprends pas pourquoi dans mon cas je n'ai pas ce bridge
dans le cas du noyau *-32-amd64 !

Jamais eu de KVM sur cette machine.

je suis une truffe totale sur la question de l'architecture de
virtualisation mais de ce que je comprends, il ne faut pas confondre
kvm.ko (le module Linux d'accélération de virtualisation, intégré aux sources su noyau) et "KVM" qui est en fait QEMU utilisant kvm.ko (qui
au départ a été créé par l'équipe QEMU)

Ce que je voulais dire par là, c'est que j'ai opté à l'époque pour l'utilisation de Xen au lieu de KVM. Ce sont deux mécanismes similaires
mais différents pour gérer la virtualisation.

Et je *suppose* toujours (sans aucune certitude non plus) que
lorsqu'il y a un Dom0 Xen installé par Debian (ou une autre distro
*Linux* (pas un *BSD)), Xen se sert de /dev/kvm même si aucun paquet
qemu (qemu-kvm est un paquet virtuel, il n'y a pas de paquet kvm)
n'est installé

Xen n'utilise pas /dev/kvm, voir ma réponse précédente. Encore qu'il est possible que Xen s'appuie maintenant sur des bouts de KVM qui lui est maintenant intégré dans les noyaux depuis quelques temps. Mais là ça dépasse mes compétences, et j'ai pas trop envie non plus de plonger dans
le code de Xen pour vérifier :)

[...] je sais plus où
j'ai lu ça mais Xen utiliserait (au *conditionnel*) par défaut
Openvswitch (connais pas) plutôt qu'un bridging classique.

J'ai aussi une config Xen avec openvswitch sur une autre grappe de
machines physiques, mais ce n'est pas sur ces machines que j'ai le
souci. Et Xen marche aussi bien avec openvswitch qu'avec le réseau
libvirtd ;)

Sois gentil avec moi: je parle ici de trucs que je ne comprends pas
vraiment :-)

Je suis gentil en général :D ... Sauf avec les cons présomptueux, mais
ça n'a pas du tout l'air d'être ton cas ;)

Merci en tout cas de prendre du temps pour m'aider. Je pense que je vais
rester sur l'ancienne version du noyau en attendant d'avoir les moyens
de faire des tests un peu plus fins sur une autre config.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 25/03/2025 à 15:22, François TOURDE a écrit :

[...]
didier@hp-notebook14:~$ ip addr
[...]
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue
state DOWN group default qlen 1000
link/ether 52:54:00:cc:c4:91 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever

Merci pour ces détails ! Il va falloir que je creuse ça un peu plus
alors. Je ne comprends pas pourquoi dans mon cas je n'ai pas ce bridge
dans le cas du noyau *-32-amd64 !

Dans ton qemu/networks/autostart./TON.xml as tu bien le bridge name pour
ton réseau?

<network>
  <name>route</name>
  <uuid>bla...bla</uuid>
  <forward mode='route'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='00:11:22:33:44:55'/>
  ....

[...]

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 20172ième jour après Epoch,
NoSpam écrivait:

Dans ton qemu/networks/autostart./TON.xml as tu bien le bridge name
pour ton réseau?

Oui, c'est un réseau de type persistant:

---8<------8<------8<------8<------8<------8<------8<------8<--- /ssh:proclos.tourde.home|sudo:root@proclos.tourde.home:/root $ virsh net-info cloudNet
Name: cloudNet
UUID: 3e3442c7-1645-4204-8da8-9514868952f0
Active: yes
Persistent: yes
Autostart: yes
Bridge: virbr0

/ssh:proclos.tourde.home|sudo:root@proclos.tourde.home:/root $ virsh net-dumpxml cloudNet
<network>
<name>cloudNet</name>
<uuid>3e3442c7-1645-4204-8da8-9514868952f0</uuid>
<forward mode='nat'>
<nat>
<port start='1024' end='65535'/>
</nat>
</forward>
<bridge name='virbr0' stp='on' delay='0'/>
<mac address='52:54:00:14:34:f5'/>
<ip address='192.168.56.254' netmask='255.255.255.0'>
<dhcp>
<range start='192.168.56.1' end='192.168.56.250'/>
</dhcp>
</ip>
</network>

---8<------8<------8<------8<------8<------8<------8<------8<---

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Le 20172ième jour après Epoch,
didier gaumet écrivait:

si je saisis correctement, tu n'utilises pas Xen directement mais au
travers de libvirt

Non, j'utilise libvirt uniquement pour le bridge sur Dom0, afin de faire communiquer mes VM entre elles. Et pour les VMs, j'utilise Xen
directement.

dans ton premier message c'est le daemon libvirtd qui se plaint de ne
pouvoir créer un pont virbr0 et de ne pas trouver le périphérique /dev/kvm. Les deux parties du messages sont-elles liées et dépendantes
ou sont-elles indépendantes? C'est toute la question

Elles sont indépendantes en fait. libvirt se "plaint" tout le temps de
ne pas pouvoir accéder à /dev/kvm, mais ça c'est normal et ça arrive
aussi avec le noyau *-28-amd64, J'ai posté la sortie de systemctl mais
le dernier message au sujet de kvm n'est pas révélateur.

voilà, voilà, ne pas compter sur moi pour te tirer de l'ornière, ma culture de sujet étant mincissime, je l'ai utilisée comme un pot de confitures de fin du monde, j'ai étalé le plus possible en prévision
de la pénurie ;-)

:D

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)