tl;dr: The libvirt version in the above logs is libvirt-5.4.0 (and libglib-2.56.4) ; and libvirt developers suggest that there are some fixes in this area in the upstream libvirt 6.7.0; and it might potentially also be fixed in libvirt-6.1.0 (or higher).
Long
----
Talking to Michal from the upstream libvirt team, this sounds like a libvirt bug. To quote him from IRC:
"When we [libvirt] start a guest and open its [QEMU] monitor we put the FD into our event loop. And whenever QEMU emits an event, a handler is called. But in this instance the handler was called over and over. On the other hand, there were some issues in glib's event loop once we [libvirt] switched to that."
So the preferred order of testing libvirt versions (based on what's available):
- try libvirt-6.9.0; if not
- try libvirt-6.7.0; if not
- try libvirt-6.1.0
tl;dr: The libvirt version in the above logs is libvirt-5.4.0 (and libglib-2.56.4) ; and libvirt developers suggest that there are some fixes in this area in the upstream libvirt 6.7.0; and it might potentially also be fixed in libvirt-6.1.0 (or higher).
Long
----
Talking to Michal from the upstream libvirt team, this sounds like a libvirt bug. To quote him from IRC:
"When we [libvirt] start a guest and open its [QEMU] monitor we put the FD into our event loop. And whenever QEMU emits an event, a handler is called. But in this instance the handler was called over and over. On the other hand, there were some issues in glib's event loop once we [libvirt] switched to that."
So the preferred order of testing libvirt versions (based on what's available):
- try libvirt-6.9.0; if not
- try libvirt-6.7.0; if not
- try libvirt-6.1.0