ansible: dom0 vs localhost target for managing qubes

[marmarek]

How to file a helpful issue

Qubes OS release

4.3

Brief summary

Current qubes_proxy strategy assumes localhost as the host to apply to dom0. But one can also specify dom0 and without qubes_proxy strategy that works.

Steps to reproduce

- hosts: dom0
  gather_facts: no
  tasks:
    - name: Create testvm
      qubesos:
        guest: testvm
        label: red
        state: present
        template: fedora-42-xfce
        properties:
          netvm: sys-firewall

Expected behavior

Create testvm.

Or maybe clearly say I should use a different name (see additional context section).

Actual behavior

Complain about dom0 not having "management_dispvm" property:

PLAY [dom0] **********************************************************************************************************************************************************************************
[ERROR]: Invalid property 'management_dispvm' of dom0
multiprocessing.pool.RemoteTraceback: 
"""
Traceback (most recent call last):
  File "/usr/lib64/python3.13/multiprocessing/pool.py", line 125, in worker
    result = (True, func(*args, **kwds))
                    ~~~~^^^^^^^^^^^^^^^
  File "/usr/share/ansible/plugins/strategy/qubes_proxy.py", line 57, in run_play_executor
    return QubesPlayExecutor(iterator, play_context).run()
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/share/ansible/plugins/strategy/qubes_proxy.py", line 411, in run
    dispvm = self._start_mgmt_disp_vm()
  File "/usr/share/ansible/plugins/strategy/qubes_proxy.py", line 390, in _start_mgmt_disp_vm
    template=self.vm.management_dispvm,
             ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/qubesadmin/base.py", line 232, in __getattr__
    property_str = self.qubesd_call(
        self._method_dest,
        self._method_prefix + 'Get',
        item,
        None)
  File "/usr/lib/python3.13/site-packages/qubesadmin/base.py", line 76, in qubesd_call
    return self.app.qubesd_call(dest, method, arg, payload,
           ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        payload_stream)
        ^^^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/qubesadmin/app.py", line 874, in qubesd_call
    return self._parse_qubesd_response(return_data)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib/python3.13/site-packages/qubesadmin/base.py", line 111, in _parse_qubesd_response
    raise exc_class(format_string, *args)
qubesadmin.exc.QubesNoSuchPropertyError: Invalid property 'management_dispvm' of dom0
"""

The above exception was the direct cause of the following exception:

qubesadmin.exc.QubesNoSuchPropertyError: Invalid property 'management_dispvm' of dom0

Additional information

TBH, I'm not sure if the expected behavior is correct. Maybe it should be only localhost? While intuitively in dom0 both names should behave the same, it isn't that obvious anymore if calling ansible from a management vm (if some future version of qubes_proxy strategy would support that case too). And in that case, I'm not sure which one is correct...

[ben-grande]

While intuitively in dom0 both names should behave the same, it isn't that obvious anymore if calling ansible from a management vm (if some future version of qubes_proxy strategy would support that case too). And in that case, I'm not sure which one is correct...

I think that specifying qube name dom0 is better for the management qube use case. Using localhost on a management qube and applying to dom0 could be confusing.

[Guiiix]

When I see a playbook with localhost as target, I read "execute the qubesos module qrexec stuff on the current host" so, for me that's not really senseless, whether from dom0 or a management VM.
OTOH, changes will be applied to dom0 so that's logical too.

We can skip the proxy when having dom0 as target host (like it is done for localhost). For qubesos module, it should work from management qubes (if relevant qubes policies are set) and from dom0. It should also work with qubes connection: for example, to run a command on dom0 from management qube. In this case the qubes connection will try to run a shell on dom0 directly from the management qube, which is not a problem because we trust dom0.

[Guiiix]

I added an exception for dom0 and patched the inventory generation to set local connection as the default for dom0.

When management vm are supported, it should work as well but it will be a bit trickier as the local connection will need to be used for qubesos module, while the qubes connection will be required for others (assuming we really want to expose VMRootShell and VMShell RPCs on dom0).