Each time I’m trying to troubleshoot some salt states, I end up spending too much time waiting for the management qube to open. Is there a way to keep the management qube open or anything that might help to get a faster execution?
Note: I’m aware of preloaded disposables.
I got the debian 13 minimal template in use. It takes about 4s to boot with 2 cores assigned.
Your text reads to me, as if you wait like 20s+ for an execution?
Mine is base on debian-13-xfce.
I’m bad at benchmarking:
$ time sudo qubesctl --skip-dom0 --show-output --targets default-dvm state.apply test-echo saltenv=user
default-dvm:
----------
ID: echo "test"
Function: cmd.run
Result: True
Comment: Command "echo "test"" run
Started: 11:30:03.496253
Duration: 14.314 ms
Changes:
----------
pid:
1372
retcode:
0
stderr:
stdout:
test
Summary for default-dvm
------------
Succeeded: 1 (changed=1)
Failed: 0
------------
Total states run: 1
Total run time: 14.314 ms
real 0m53.314s
user 0m0.015s
sys 0m0.031s
The disposable (even if preloaded) takes a lot of time to run:
$ time qvm-run --dispvm default-mgmt-dvm "echo test"
Running 'echo test' on @dispvm:default-mgmt-dvm
real 0m34.531s
user 0m0.144s
sys 0m0.045s
Unfortunately, can’t preload disposables for Salt or Ansible.
https://mail-archive.com/qubes-devel@googlegroups.com/msg05635.html
The VMs you have preloaded on defaullt-mgmt-dvm only serve for Management Console, which is used by qvm-console-dispvm.
Ideally, Ansible and Salt would use preloaded disposables.
If you ask why the documentation mentions Salt and Ansible, it was because I hoped it was fixed by the time the documentation was merged
You may remove it 
It seems you are more capable then me. I jonly started the disp-vm and looked into the logs 
With your benchmark:
A partial workaround might be to manually start the related disp-mgmt-<QUBE> and the target as soon as the previous qubesctl command is done, it takes me ~25 seconds instead of 50.
I have a plan:
Something like this should work per this guide (excluding persistency parts, of course)
Qube preloading is a mistake.
p.s. 34 seconds is slow! Is this a storage or cpu bottleneck for you? My idea is useless if cpu is the limitation
p.p.s. I don’t like my plan no more, it permanently takes away significant chunk of memory from the system. It might be okay for people with a lot of memory though, especially if they run minimal templates. Qube preloading is fine.
Thanks, but I feel like I will spend more time trying to follow your advice than waiting for the state to apply 
I don’t know where the bottleneck is. It might be both…
Hi, I would like to admit that I have nerdsniped myself there. I’ve ran some tests:
Test is:
time sudo qubesctl --skip-dom0 --show-output --targets vmname cmd.run 'echo test'
Test results:
real 0m42.831s
user 0m1.777s
sys 0m1.012s
real 0m48.739s
user 0m1.958s
sys 0m0.920s
real 0m27.355s
user 0m1.711s
sys 0m0.828s
real 0m31.327s
user 0m1.694s
sys 0m0.745s
And here is what I consider more notable test:
time qvm-start fast-mgmt-dvm)real 0m5.891s
user 0m0.041s
sys 0m0.016s
time qvm-start default-mgmt-dvm)real 0m7.072s
user 0m0.037s
sys 0m0.024s
The obvious conclusion is that performance boost is very limited. My setup is quite haphazard, it might be possible to optimize by a lot. For this test it’s just zram drive with file qubes pool driver. Giving more cores to my qubes at this point might notably improve the speed.
Actually interesting conclusion is that management dvm itself is quite fast overall, there aren’t much performance to gain even if you make its startup literally instant. Speeding up boot time of the managed qube is more valuable.
Another idea I have is to try to optimize qube-starting algorithm of qubesctl. As is it is just starting qubes one by one, it doesn’t even start management qube - managed qube pair at the same time.
Low hanging fruit is to make a wrapper around qubesctl that simply pre-runs qvm-start for all targeted qubes (but respects max-concurrency)
As far as I understand the Linux kernel’s LRU cache, giving enough RAM to dom0 and preloading the files of the VMs with vmtouch or plain old cat ... >/dev/null should achieve virtually the same thing.
As such, if your management/AppVMs’ template is the same as for your other, currently running qubes, I believe you’ll see better performance due to caching than if the template was different.
It doesn’t seem to have an effect (although I haven’t tested it that well, it’s just in the ball park of starting from nvme)
Perhaps xen kernel isn’t using stuff cached by dom0 kernel?