Speeding up qubesctl commands

User Support General
1

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.

2

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?

3

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
4

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.

1 Like
5

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 :frowning:

1 Like
6

It seems you are more capable then me. I jonly started the disp-vm and looked into the logs :man_shrugging:

With your benchmark:

benchmark
benchmark497×140 7.18 KB

7

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.

8

I have a plan:

  1. give whole bunch of ram to dom0
  2. set up a RAM drive
  3. create an lvm pool on it
  4. clone management template and appvm there
  5. configure them to be the default management template
  6. undo all this
  7. record 2-5 and 6 as two scripts

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.

9

Thanks, but I feel like I will spend more time trying to follow your advice than waiting for the state to apply :slight_smile:

I don’t know where the bottleneck is. It might be both…