Cache libvirt domain state#819
Conversation
|
PipelineRetryFailed |
|
Didn't run openqa locally, only experiment some things, start, shutdown, kill, checking Domains Widget. |
|
PipelineRetryFailed |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #819 +/- ##
==========================================
- Coverage 70.42% 70.12% -0.30%
==========================================
Files 61 61
Lines 14143 14174 +31
==========================================
- Hits 9960 9940 -20
- Misses 4183 4234 +51
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
5eff83f to
aa2e823
Compare
|
PipelineRetryFailed |
1 similar comment
|
PipelineRetryFailed |
|
Marked as draft as there still is some caching issues for the |
|
If necessary (or simpler), it's IMO okay to use cache only for |
Experimenting with cache a bit more and it's getting better, but if I don't get it to a hundred percent, will not cache the power state. |
|
From my tests, it seems to be working. My nemesis, OpenQA, should try me. Do you know a subset of tests that are interesting before joining this PR in the full run? Looking at this recent test:
Line to use after this PR is not draft anymore: |
|
I'd include also at least one of the guivm tests |
9538d21 to
6011ca3
Compare
|
PipelineRetryFailed |
|
Last CI failed on Fedora 43 to due to: So it finally reached this repo. |
|
PipelineRetryFailed |
|
openQArun TEST=system_tests_suspend,system_tests_usbproxy,system_tests_devices,system_tests_gui_tools,system_tests_guivm_gui_interactive |
OpenQA test summaryComplete test suite and dependencies: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=202606030906-devel&flavor=pull-requests Test run included the following: New failures, excluding unstableCompared to: https://openqa.qubes-os.org/tests/overview?distri=qubesos&version=4.3&build=2026050504-devel&flavor=update
Failed tests4 failures
Fixed failuresCompared to: https://openqa.qubes-os.org/tests/176874#dependencies 1 fixed
Unstable testsDetails
Performance TestsPerformance degradation:No issues Remaining performance tests:No remaining performance tests |
Seeing "Next and previous results", shows that this happened 3 days ago also, so unrelated to this PR: https://openqa.qubes-os.org/tests/182011#step/qui_widgets_update/18.
Failed recently also, and
Doesn't seem related to this PR. I will restart the failed tests. |
bf795ff to
367ae38
Compare
|
PipelineRetry |
Useful when debugging to know what's happening. I thought of logging the pretty name of the detail, but that got really big and I think it's out of scope from the Qubes OS project and in scope of the python-libvirt package.
The state changes rarely, but querying it can take a considerable blocking time, worse when looping through the state of multiple domains. For: QubesOS/qubes-issues#10569 For: QubesOS/qubes-issues#9902
These data only changes once when domain is running.
This function reimports the same information over and over and is time consuming when looping through multiple domains. Reduce listing USB devices while there is no cache from 2.8s to 0.5s.
Method 'startwith' adds considerable overhead.
Libvirt API can be quite slow on the methods for "listAllDevices" and "XMLDesc", aggravated in loops.
Assuming that hotplug is unsupported.
Decreases in ~10ms the time to create the cache.
The "get_vm_stats()" and "xs()" already check if Xen is supported.
It's not completely Xen agnostic because then it would not be possible to query stubdomains, as libvirt is not aware of them. On the other hand, non-Xen has one more API method working. When not using Xen, construct the dictionary as "xc.domain_getinfo()" would, so the info loop can consume from both inputs.
Each call was recording 1ms, now the calls are below that.
Although it doesn't help reduce the time to get the XML, as XMLDesc() is super slow, this helps cleanup the code a bit.
Skip PVH when listing attached PCI devices, as they can't possibly be there.
The state changes rarely, but querying it can take a considerable time, that is blocking, when looping through the state of multiple domains.
For: QubesOS/qubes-issues#10569
For: QubesOS/qubes-issues#9902
Didn't run openqa locally, only experiment some things:
qubed-query -e dom0 admin.vm.CurrentState QUBE