`qvm.present` not creating

User Support
1

SOLUTION: have - match: nodegroup

Anyone else getting nothing out of qvm.present on qubes 4.1.2, please?

Happens to any VM I try to create, but I can successfully run states in targets other than dom0.

VM creation states that are failing with no error message are like:

# arbeit/create-vms.sls
# user: dom0:

arbeit:
  qvm.present:
    - name: arbeit
    - template: debian-workspace
    - label: blue
    - mem: 3000
    - vcpus: 2

arbeit-prefs:
  qvm.prefs:
    - name: arbeit
    - memory: 300
    - maxmemory: 3000
    - netvm: sys-firewall

# TODO have storage defined as pref/script to change it

The top file:

# tops/arbeit.top

user:
  dom0:
    - arbeit.create-vms
#  arbeit:
#    - arbeit.init-vms
#    - firefox.configure-debian

Directories are symlinked to /srv/user_salt/. And:

# /srv/user_salt/top.sls
user:
  '*':
    - locale

I am running with 16GB ram.
I have tried with no success:

  • striping the qvm.prefs from the sls
2

Works for me.

How are you running the state?

3

sudo qubesctl —target=dom0 state.highstate

Also:

sudo qubesctl state.highstate

4

In /srv/user_salt/test/create.top:

user:
  dom0:
    - match: nodegroup
    - test.create

In /srv/user_salt/test/create.sls:

qvm-present-id:
  qvm.present:
    - name: builder_test
    - template: template-builder
    - label: purple

[root@dom0 test]# qubesctl top.enabled
local:
    ----------
    user:
        - /srv/salt/_tops/user/test.create.top
    base:
        - /srv/salt/_tops/base/topd.top
[root@dom0 test]# qubesctl  --show-output state.apply
local:
----------
          ID: topd-always-passes
    Function: test.succeed_without_changes
        Name: foo
      Result: True
     Comment: Success!
     Started: 02:19:02.162577
    Duration: 0.651 ms
     Changes:   
----------
          ID: qvm-present-id
    Function: qvm.present
        Name: builder_test
      Result: True
     Comment: /usr/bin/qvm-create builder_test --class=AppVM --template=template-builder --label=purple None
     Started: 02:19:02.194596
    Duration: 3982.308 ms
     Changes:   

Summary for local
------------
Succeeded: 2
Failed:    0
------------
5

This is probably what @unman meant (maybe not, their post might have been truncated?): have you enabled the top file?

6

Maybe not,indeed.
Why is anything being touched within code blocks? This looks like a
major bug to me.

What I wrote was as below.
As you can see, the top file is enabled, and state.apply results in
the qube being created.

[quote]
[root@dom0 test]# qubesctl top.enabled

local:

7

Looks like this was indeed the case. I have now edited your post and replaced the issue. I’ll flag this on meta.discourse.org. I guess their parser only cares about what it thinks is a character separator. In this case the ----- in salt output seems to cause the error.

Let’s continue this discussion in Discourse truncating saltstack output on email replies

1 Like
8

A post was split to a new topic: Discourse truncating saltstack output on email replies

9

Thank you @unman, I added - match: nodegroup and it worked.

I’m new to salt and qubes, I followed in a bit chaotic manner the documentation and excellent setp-by-setp available (linked from the forum), but it got me to the following warnings (I might have skipped some initial config):

1. not able to run qubesctl without sudo

# qubesctl top.enabled
[WARNING ] Failed to open log file, do you have permission to write to /var/log/salt/minion?
[CRITICAL] Specified ext_pillar interface qvm_prefs is unavailable
Cannot write to process directory. Do you have permission to write to /var/cache/salt/minion/proc/20231220091327803815 ?
DOM0 configuration failed, not continuing

2. always get warning on top_file_merging_strategy

# sudo qubesctl state.highstate # or state.apply
[WARNING ] top_file_merging_strategy is set to 'merge' and multiple top files were found. Merging order is not deterministic, it may be desirable to either set top_file_merging_strategy to 'same' or use the 'env_order' configuration parameter to specify the merging order.
local:
...
10

This one is solved here:

1 Like
11

I’m also new to salt and I don’t understand why match: nodegroup is required here ?

1 Like
12

I also can’t figure out when adding match: nodegroup in .top files is beneficial or not. I’ve been searching the QubesOS forums, and seen lots of examples of .top files with and without it…

1 Like
13

It’s needed for dom0 because in the Qubes configuration dom0 is the name
of a nodegroup - the other default nodegroup is vm - defined as not dom0.
You can see this in /etc/salt/minion.d/f_defaults.conf

I never presume to speak for the Qubes team. When I comment in the Forum I speak for myself.
2 Likes