rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=134435155 eln: https://koji.fedoraproject.org/koji/taskinfo?taskID=134434490 Traceback (most recent call last): File "/builddir/build/BUILD/qemu-10.0.2-build/qemu-10.0.2/python/qemu/machine/machine.py", line 448, in launch self._launch() ~~~~~~~~~~~~^^ File "/builddir/build/BUILD/qemu-10.0.2-build/qemu-10.0.2/python/qemu/machine/machine.py", line 475, in _launch self._pre_launch() ~~~~~~~~~~~~~~~~^^ File "/builddir/build/BUILD/qemu-10.0.2-build/qemu-10.0.2/python/qemu/machine/machine.py", line 349, in _pre_launch self._qmp_connection = QEMUMonitorProtocol( ~~~~~~~~~~~~~~~~~~~^ sock_or_addr, ^^^^^^^^^^^^^ server=bool(self._monitor_address), ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ nickname=self._name ^^^^^^^^^^^^^^^^^^^ ) ^ File "/builddir/build/BUILD/qemu-10.0.2-build/qemu-10.0.2/python/qemu/qmp/legacy.py", line 89, in __init__ self._aloop = asyncio.get_event_loop() ~~~~~~~~~~~~~~~~~~~~~~^^ File "/usr/lib64/python3.14/asyncio/events.py", line 718, in get_event_loop raise RuntimeError('There is no current event loop in thread %r.' % threading.current_thread().name) RuntimeError: There is no current event loop in thread 'MainThread'. The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/builddir/build/BUILD/qemu-10.0.2-build/qemu-10.0.2/tests/functional/test_x86_cpu_model_versions.py", line 267, in test_4_0 self.vm.launch() ~~~~~~~~~~~~~~^^ File "/builddir/build/BUILD/qemu-10.0.2-build/qemu-10.0.2/python/qemu/machine/machine.py", line 461, in launch raise VMLaunchFailure( ...<3 lines>... ) from exc qemu.machine.machine.VMLaunchFailure: RuntimeError: There is no current event loop in thread 'MainThread'. Command: Output: None Reproducible: Always
https://docs.python.org/3.14/whatsnew/3.14.html#id7 > Removed implicit creation of event loop by asyncio.get_event_loop(). It now raises a RuntimeError if there is no current event loop. https://github.com/python/cpython/issues/126353
This is now blocking a stoname bump in libcbor. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/5CO7XNDVNYEQPREU4U2GCYNPII2WK2YT/ Please, respond.
I don't see any upstream fix yet. Can you suggest a fix? I'm neither an expert in Python asyncio nor in QMP. The code in python/qemu/qmp/legacy.py doesn't exactly match any of the suggestions in the Python docs.
I'd try replacing: self._aloop = asyncio.get_event_loop() With: try: self._aloop = asyncio.get_event_loop() except RuntimeError: self._aloop = asyncio.new_event_loop() This should effectively revert to the behavior of Python < 3.14, as get_event_loop used to return a new event loop when there was no current event loop.
What puzzles me is why we've never seen any deprecation warnings with python < 3.13, because if we were triggering the fallback 'create a new loop' code previously, we should have seen warnings. This makes me wonder if we've got further problems than just the headline event loop issue.
OK I reproduced this locally and implemented the fix as suggested by Miro above.
> What puzzles me is why we've never seen any deprecation warnings with python < 3.13 I am not sure the warning would propagate through the tests.
Fedora build: https://koji.fedoraproject.org/koji/taskinfo?taskID=134838089 Upstream patch: https://www.mail-archive.com/qemu-devel@nongnu.org/msg1127519.html
(In reply to Daniel Berrangé from comment #5) > What puzzles me is why we've never seen any deprecation warnings with python > < 3.13, because if we were triggering the fallback 'create a new loop' code > previously, we should have seen warnings. This makes me wonder if we've got > further problems than just the headline event loop issue. Urgh, python only emits warnings if triggered *directly* by the __main__ module, so any usage from imports never shows warnings. This is spectacularly unhelpful at alerting people to usage of deprecated features :-(
New Fedora build: https://koji.fedoraproject.org/koji/taskinfo?taskID=134838848
This failed to build on i686 with what might be a random failure. I will retry the build when all the other arches have finished. 54/310 qemu:qtest+qtest-arm / qtest-arm/aspeed_smc-test ERROR 43.15s killed by signal 6 SIGABRT
It also failed on ppc64 with a test timeout. Here is a new build (unmodified): https://koji.fedoraproject.org/koji/taskinfo?taskID=134842457
The ppc64 test failure was on 'test-replication' which normally takes only 2 seconds, so a 60 second timeout is a clear hang. I notice upstream there is report that this test causes 'tsan' thread safety warning, so further looks like a bug. I've filed this to track it: https://gitlab.com/qemu-project/qemu/-/issues/3035
I cherry picked another patch from upstream to improve the stability of a test that failed on x86_64 (thanks Dan!) New build: https://koji.fedoraproject.org/koji/taskinfo?taskID=134842989
I added a further patch to increase the test-replication timeout, for: https://gitlab.com/qemu-project/qemu/-/issues/3035 New build: https://koji.fedoraproject.org/koji/taskinfo?taskID=134845860
Finally fixed in Rawhide - qemu-10.0.2-5.fc43
Thank you.
For c10s (for merging back to ELN): https://gitlab.com/redhat/centos-stream/rpms/qemu-kvm/-/merge_requests/237