Creating standalone qube from commandline

User Support
#1

I am trying to set up a proper saltstack conf and I’m stuck on creating a standalone qube.

First off all it seems like the docs are slightly incorrect because they claim you control the type through the type keyword however class is the only thing that works for me.

Secondly when I create a standalone class it causes an error, when I investigate this and run the command manually I get the same error.

qvm-create qube-name --class=standalone --label=red results in
app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details.
There are no details beyond there being a “protocol error”.

I’m somewhat suspecting that the error has to do with the fact that I am not specifying what file system the qube should have. Normally when you create a standalone qube through the GUI you select another qube to copy. I can’t see any obvious argument which does that, template doesn’t. I suspect it might be the --root-copy-from but I don’t know how to get a filesystem as a file in the appropriate format.

Furthermore I don’t know how to specify root-copy-from in my saltstack conf.

#2

Instead of doing:

<statename>:
    qvm.present:
        - name: <appvm name>
        - template: <template name>
        - label:  <color>

like you would for an AppVm (or disposable, or disposable template which is really an appVM), do this:

<statename>:
    qvm.clone:
        - name: <your new template name>
        - source: <the template you want to copy into your new template>

The key differences are you’re doing a qvm.clone, not a qvm.present, and instead of a template, you have a source (the clone-ee).

#3

If I do that then won’t the cloned VM be a template VM rather than a standalone VM? Is there a way to achieve what you accomplish via the GUI when creating a standalone?

#4

That’s a very good question, and I have to apologize for losing sight of the fact that you were talking about a standalone.

It’s possible that if “source” is a standalone, then you can use this method and the new qube will be too. (Nothing limits clones to templates.) I’m not in a position to try that experiment, though. If you are trying to clone a standalone, please try it and see what happens.

#5

You are reading that wrong - that section refers to keywords in the
pillar, distinct from use in your own modules and states.

Check out qvm-create --help which will lead you to qvm-create --help-classes
What you want is qvm-create --class=StandaloneVM --label=red --template=TEMPLATE....... QUBE-NAME

In salt, you would use:

create_standalone:
  qvm.present:
    - name: QUBE-NAME
    - template: TEMPLATE
    - label: red
    - flags:
      - standalone

Like this:

copy_filesystem:
  qvm.present:
    - name: QUBE-NAME
    - label: red
    - root-copy-from: PATH
1 Like
#6

This seems to be what I’m looking for, however I’m getting a invalid property 'template' of salt-standalone when using the following configuration. Note that I’m not getting that error for salt-no-netvm. Any idea why? Are there any other comments on how I should do my configuration?

{% set fedora_app_vms = [
  {
    'name': 'salt-standalone',
    'label': 'red',
    'template': 'fedora-36',
    'type': 'standalone'
  },
  {
    'name': 'salt-no-netvm',
    'label': 'blue',
    'template': 'debian-11',
    'netvm': 'none'
  },
] %}

{% for vm in fedora_app_vms %}
Check if {{ vm.name }} exists:
  cmd.run:
    - name: qvm-check {{ vm.name }} || echo "__QUBE_NOT_FOUND__"
    - shell: /bin/bash
    - output: qube_exists_result
    - changes_dict: {'qube_exists_result': '{{ vm.name }}'}

Create {{ vm.name }}:
  qvm.present:
    - name: {{ vm.name }}
    - label: {{ vm.label }}
    - mem: 2000
    - vcpus: 4
    {% if 'template' in vm %}
    - template: {{ vm.template }}
    {% endif %}
    {% if 'type' in vm and vm.type == 'standalone' %}
    - flags:
      - standalone
    {% endif %}

Configure {{ vm.name }}:
  qvm.prefs:
    - name: {{ vm.name }}
    {% if 'netvm' in vm %}
    - netvm: {{ vm.netvm }}
    {% endif %}
    - onchanges:
      - cmd: Check if {{ vm.name}} exists
{% endfor %}

I’ve never used saltstack before and I realized that there were some qubes specific macros in the standard qubes configurations, is it good practice to use those?

Is there any place I can read more about which flags are available?

#7

There are indeed qubes specific macros, but I think you should get the
basics first before hand.
There is good documentation at qubes-mgmt-salt-dom0-qvm/README.rst at master · QubesOS/qubes-mgmt-salt-dom0-qvm · GitHub
and of course, the source code under /srv/salt
Use the salt forms instead of calling external programs - qvm.exists,
for example, instead of a call to qvm-check.

I never presume to speak for the Qubes team. When I comment in the Forum or in the mailing lists I speak for myself.
#8

A suggestion: that github info is a lot more complete than what’s in the qubes-os.org documentation page. (I did not know, for instance, that you could do qvm.features until just now; I was writing calls to qvm-features.) Could that info possibly make its way onto that page?

#9

It is directly linked from the Qubes introduction page.

#10

There is a link at the bottom of this page: Salt (management software) | Qubes OS but every link there is to the salt official site. I really think that link should be near where the (subset) of qubes-specific sets is discussed, with an explanation to the effect that the link points to a complete list; what’s shown here is just a set of examples. Otherwise one gets the impression that’s a complete listing. (At least one does, if one is SteveC.)

#11

Let me redo that post; the first sentence was just a bodge (I would edit, but unman is an email user).

There is a link at the bottom of this page: Salt (management software) | Qubes OS but every link in the main text of the page is to the salt official site.

I really think that link at the bottom of the page should be near where the (subset) of qubes-specific sets is discussed, with an explanation to the effect that the link points to a complete list; what’s shown here is just a set of examples. Otherwise one gets the impression that’s a complete listing. (At least one does, if one is SteveC.) Basically “additional reading” implies it’s optional; in this case it’s a vital reference for anyone doing salt.

#12

The salt pages definitely need work.