Standardize management qube creation
12 views
Skip to first unread message
Ben Grande
Sep 4, 2025, 4:11:47 AMSep 4
to qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
This conversation is continuation of a discussion on the Ansible Proxy
PR [0] with Simon and Marek, some ideas that used here were proposed by
them also, any error in interpretation them is my own.
There are two major uses cases for management qubes:
- - `qvm-console-dispvm`: created with random disposable name, doesn't
inform which qube it is connected to [0].
- - Ansible and Salt: created with fixed name, prefixed with `disp-mgmt-`
and suffix is the qube name chopped at 31 chars [1][2], the chopping
may cause the management of two very long qube names that have the
same 31 chars prefix, to be the same. May fail the state or lead to
other unexpected occurrences. Because the name is fixed, it is not an
unnamed disposables, and therefore, doesn't benefit from preloaded
disposables.
Their creation is not standardize and there are major concerns with both
approaches, but it is not clear what a solution can be yet. It needs to
solve the following, ordered by priority (same number equals same
priority):
0. Inform which qube it is connected
0. Don't suffer from name chopping (can lead to name conflicts)
1. Uses unnamed disposables, can benefit from random names and preloaded
disposables
Proposal:
- - GUI users can be benefited if the unspoofable part of the qube window
controlled by GUI daemon mentioned the qube name the console is
connected to: `[disp1234: mgmt of sys-net]`. In the case of Ansible,
it is being created with the feature `gui=False`, meaning that no
window will be opened. The `qui-domains` will need info in the tooltip
maybe `Qube manager` will need a new field (maybe).
- - CLI users, sometimes headless setups, won't be able to differentiate
using the GUI daemon, another solution is necessary here. Maybe the
management information could be logged to qubesd as in
*disp$dispid-mgmt has admin console of sys-net*, `-mgmt` added to
disposable of disposable templates that are `management_dispvm` on the
global or per-qube level. If a feature feature/tag is added to the
qube, it could be shown on `qvm-ls`.
- - This would result in: inform slightly which qube it is connected to
for GUI and CLI users, avoids name conflicts and name chopping and can
benefit from preloaded disposables.
- From past conversations, the major opposition to my proposal is that it
only slightly informs which qube it is connected to for terminal users,
the qube name is the primary identifier. Maybe it is a trilemma, maybe
it is not and we haven't solved this puzzle (yet).
My comment on the Ansible PR and Simon's reply:
> > management_dispvm is a global and per-qube property. What if, by
> > knowing that a disposable template is the management_dispvm on the
> > global or per-qube level,
> Detecting this case by testing if the disposable template matches is a
> bad idea. This doesn't need to be exclusive.
The creation of the qube would check that property on the disposable
template, I think that part is straight forward to add the suffix
`-mgmt`. The second part is informing which qube it is connected to,
when calling the API method, `admin.vm.Console`, it would create the
tag/feature and log to qubesd which qube it connected to, and then other
tools could be informed about it also and updated with an event handler,
GUID being the edge case here.
Reference:
[0]: https://github.com/QubesOS/qubes-ansible/pull/15#discussion_r2314333818
[1]: https://github.com/QubesOS/qubes-issues/issues/9810
[2]: https://github.com/QubesOS/qubes-mgmt-salt/blob/c5a8a5ade740eff1a507a65f8b89bfc7ea9dd573/qubessalt/__init__.py#L140
[3]: https://github.com/QubesOS/qubes-ansible/blob/32e46780f96829ff61893aad3923728ff09bc7a6/plugins/strategy/qubes_proxy.py#L50
- --
Benjamin Grande
-----BEGIN PGP SIGNATURE-----
iHUEARYIAB0WIQRklnEdsUUe50UmvUUbcxS/DMyWhwUCaLlJtwAKCRAbcxS/DMyW
h3+JAQCVMI26oEv5UHQPwWV8vL3U5bgo88lX2oLKJSx6M6EH6AEA2H/kKlfKLGT/
RxlrIlyqkDIdTdRqQzkbZTIfumWvWgw=
=CxKv
-----END PGP SIGNATURE-----
Hash: SHA256
This conversation is continuation of a discussion on the Ansible Proxy
PR [0] with Simon and Marek, some ideas that used here were proposed by
them also, any error in interpretation them is my own.
There are two major uses cases for management qubes:
- - `qvm-console-dispvm`: created with random disposable name, doesn't
inform which qube it is connected to [0].
- - Ansible and Salt: created with fixed name, prefixed with `disp-mgmt-`
and suffix is the qube name chopped at 31 chars [1][2], the chopping
may cause the management of two very long qube names that have the
same 31 chars prefix, to be the same. May fail the state or lead to
other unexpected occurrences. Because the name is fixed, it is not an
unnamed disposables, and therefore, doesn't benefit from preloaded
disposables.
Their creation is not standardize and there are major concerns with both
approaches, but it is not clear what a solution can be yet. It needs to
solve the following, ordered by priority (same number equals same
priority):
0. Inform which qube it is connected
0. Don't suffer from name chopping (can lead to name conflicts)
1. Uses unnamed disposables, can benefit from random names and preloaded
disposables
Proposal:
- - GUI users can be benefited if the unspoofable part of the qube window
controlled by GUI daemon mentioned the qube name the console is
connected to: `[disp1234: mgmt of sys-net]`. In the case of Ansible,
it is being created with the feature `gui=False`, meaning that no
window will be opened. The `qui-domains` will need info in the tooltip
maybe `Qube manager` will need a new field (maybe).
- - CLI users, sometimes headless setups, won't be able to differentiate
using the GUI daemon, another solution is necessary here. Maybe the
management information could be logged to qubesd as in
*disp$dispid-mgmt has admin console of sys-net*, `-mgmt` added to
disposable of disposable templates that are `management_dispvm` on the
global or per-qube level. If a feature feature/tag is added to the
qube, it could be shown on `qvm-ls`.
- - This would result in: inform slightly which qube it is connected to
for GUI and CLI users, avoids name conflicts and name chopping and can
benefit from preloaded disposables.
- From past conversations, the major opposition to my proposal is that it
only slightly informs which qube it is connected to for terminal users,
the qube name is the primary identifier. Maybe it is a trilemma, maybe
it is not and we haven't solved this puzzle (yet).
My comment on the Ansible PR and Simon's reply:
> > management_dispvm is a global and per-qube property. What if, by
> > knowing that a disposable template is the management_dispvm on the
> > global or per-qube level,
> Detecting this case by testing if the disposable template matches is a
> bad idea. This doesn't need to be exclusive.
The creation of the qube would check that property on the disposable
template, I think that part is straight forward to add the suffix
`-mgmt`. The second part is informing which qube it is connected to,
when calling the API method, `admin.vm.Console`, it would create the
tag/feature and log to qubesd which qube it connected to, and then other
tools could be informed about it also and updated with an event handler,
GUID being the edge case here.
Reference:
[0]: https://github.com/QubesOS/qubes-ansible/pull/15#discussion_r2314333818
[1]: https://github.com/QubesOS/qubes-issues/issues/9810
[2]: https://github.com/QubesOS/qubes-mgmt-salt/blob/c5a8a5ade740eff1a507a65f8b89bfc7ea9dd573/qubessalt/__init__.py#L140
[3]: https://github.com/QubesOS/qubes-ansible/blob/32e46780f96829ff61893aad3923728ff09bc7a6/plugins/strategy/qubes_proxy.py#L50
- --
Benjamin Grande
-----BEGIN PGP SIGNATURE-----
iHUEARYIAB0WIQRklnEdsUUe50UmvUUbcxS/DMyWhwUCaLlJtwAKCRAbcxS/DMyW
h3+JAQCVMI26oEv5UHQPwWV8vL3U5bgo88lX2oLKJSx6M6EH6AEA2H/kKlfKLGT/
RxlrIlyqkDIdTdRqQzkbZTIfumWvWgw=
=CxKv
-----END PGP SIGNATURE-----
Simon Gaiser
Sep 4, 2025, 8:18:56 AMSep 4
to qubes-devel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Ben Grande, 2025-09-04 10:11 +02:00:
Good idea to move discussions here.
> [...] some ideas that used here were proposed by
what it might have implied, while not stating explicitly).
I still think that Marek's point that management qubes are sensitive and
potential user confusion with other less-sensitive disposables are a
concern to consider. Also I still think its name is the primary
identifier of a qube. But I don't think we *must* use descriptive names
for those disposable qubes. Would be nice, but there's a tradeoff with
other points, so maybe not the best option.
Beside the qvm-consolve-dispvm case, other usage of disposables also
have vastly different sensitivity/trust levels and we accept the
limitation of the non-descriptive disp${i} names there.
> 0. Don't suffer from name chopping (can lead to name conflicts)
I think handling this actual has higher priority, since handling those
conflicts is tricky and very easily leads to security relevant bugs.
But there's the option to use another naming scheme in case of over long
names, so this doesn't rule out using descriptive names by default.
BTW, it probably would be good to have some official documentation for
reserved names that are used by such auto generation schemes, since
conflicts with existing (use created) qubes are also a concern.
> 1. Uses unnamed disposables, can benefit from random names and preloaded
> disposables
>
> Proposal:
>
> - GUI users can be benefited if the unspoofable part of the qube window
> controlled by GUI daemon mentioned the qube name the console is
> connected to: `[disp1234: mgmt of sys-net]`. In the case of Ansible,
> it is being created with the feature `gui=False`, meaning that no
> window will be opened. The `qui-domains` will need info in the tooltip
> maybe `Qube manager` will need a new field (maybe).
> - CLI users, sometimes headless setups, won't be able to differentiate
> using the GUI daemon, another solution is necessary here. Maybe the
> management information could be logged to qubesd as in
> *disp$dispid-mgmt has admin console of sys-net*, `-mgmt` added to
> disposable of disposable templates that are `management_dispvm` on the
> global or per-qube level. If a feature feature/tag is added to the
> qube, it could be shown on `qvm-ls`.
> - This would result in: inform slightly which qube it is connected to
> for GUI and CLI users, avoids name conflicts and name chopping and can
> benefit from preloaded disposables.
>
> - From past conversations, the major opposition to my proposal is that it
> only slightly informs which qube it is connected to for terminal users,
> the qube name is the primary identifier. Maybe it is a trilemma, maybe
> it is not and we haven't solved this puzzle (yet).
First just for completeness options that address other points than the
preload issue:
- Use descriptive names (disp-mgmt-${name}) with a fallback for too long
names.
- Use descriptive names (disp-mgmt-${name}) and allow longer names for
those. Refuse recursion (at least at some level).
Now back to options that also address the preload issue (mostly what you
already wrote above, but a bit extended):
- Use non-descriptive names (disp${i})
- Special case display for mgmt/console case in GUI and maybe also
CLI/logs. (fixed "disp${i} mgmt for ${name}")
- Add a generic short description feature/property that is displayed
together with the name in GUI and ideally also CLI/logs.
("disp${i} (${short_desc_field})")
- Same as previous option (including sub-options), but a special naming
scheme to highlight mgmt/console use (disp-mgmg${i})
I really like the generic short description field option, especially if
it would be displayed in most cases, so would be a real addition to the
name (as opposed to be hidden behind a tool tip or similar UI).
I think this would be useful in other cases:
- Annotate other disposable by default. For example: "disp123 (created
by personal)" vs. "disp534 (created by vault)"
- Allow short (but obviously still unique) names for convenience while
having a bit longer info always displayed. Particular useful for
seldomly used qubes.
- I have a lot of temporary (but not disposable) qubes. Those are often
created in a hurry and too short lived to bother with the expensive
rename (shutdown, clone, careful remove old, updated references). So
being able to live update the short description would be really nice.
The main challenge is, I think, integrating the longer text into UI and
that it might be "too useful" and therefore overused which exacerbates
the UI problem. For example the "created by personal" immediately makes
it tempting to allow a creator qube controlled suffix for use by
qvm-open-in-dvm or similar.
> Reference:
>
> [0]: https://github.com/QubesOS/qubes-ansible/pull/15#discussion_r2314333818
> [1]: https://github.com/QubesOS/qubes-issues/issues/9810
> [2]: https://github.com/QubesOS/qubes-mgmt-salt/blob/c5a8a5ade740eff1a507a65f8b89bfc7ea9dd573/qubessalt/__init__.py#L140
> [3]: https://github.com/QubesOS/qubes-ansible/blob/32e46780f96829ff61893aad3923728ff09bc7a6/plugins/strategy/qubes_proxy.py#L50
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAmi5gxkACgkQkO9xfO/x
ly9qHQ//XA2VLTLbvrR6Zq+IM6hT+ufbB0GNEevhpDSinQ0/hL8YOmESVb0DfLQY
NFnKp8MQjDnvlrJDVTZoWKmNk4H2qIwOZCeDLz6MbVMpd5xVpxRMoi+AHXceWSLZ
Y67eIFJfTefkTvSAog0NNrsgTOzPuKiateE9tcXaW60yMjGuKZmGUTd6l8RkM51X
4sjmhCyTaXTLc+9kK30X97B5f7xJO3m19K0aHZI2Vb+EqDCyW6vS+S08PBUjrk0k
eurNhpvyF9z5AYIidxu9i/D/MDtRX4tuuZA5VIeMrA62iC85j+O3RE/1RpDLDdV1
A8UKQq3qXzhqG8X49H2lvicl4XsxiXy/Epq5UWu4+Dzj9iNbH4KmBxnuG6RZahyl
jchW4VRKBNgsNj3XChHSy1kutuXdPgDGyZ+7eqPZH4yq9nGA6Es/J8dsow3VLbJH
rBiZLEQtaxcxY6izYJjPMovU+0RJ4PP/jwsJQOtuvtLfxEuCVZPDMpmhDMoYDJhp
M8ffvakiiK93GWQJr+Vlzj0dJ3cDy63mo6X8DRUbYBrb/Kw4Ntvh2FqVaxhicpnQ
Q1Zlr4WudJKsBpxNqOOwuQuLG6SNzw4moxX+oNktshOO7ZlEm5rxt0j7aH2tzrzB
QBMFgTOu2QIYs24pD9bIuHYxEXaSurz31+ZxVV8nYFpmhwCpqMM=
=Qyjg
-----END PGP SIGNATURE-----
Hash: SHA512
Ben Grande, 2025-09-04 10:11 +02:00:
> This conversation is continuation of a discussion on the Ansible Proxy
> PR [0] with Simon and Marek, [...]
Good idea to move discussions here.
> [...] some ideas that used here were proposed by
> them also, any error in interpretation them is my own.
>
> There are two major uses cases for management qubes:
>
> - `qvm-console-dispvm`: created with random disposable name, doesn't
> inform which qube it is connected to [0].
> - Ansible and Salt: created with fixed name, prefixed with `disp-mgmt-`
> and suffix is the qube name chopped at 31 chars [1][2], the chopping
> may cause the management of two very long qube names that have the
> same 31 chars prefix, to be the same. May fail the state or lead to
> other unexpected occurrences. Because the name is fixed, it is not an
> unnamed disposables, and therefore, doesn't benefit from preloaded
> disposables.
>
> Their creation is not standardize and there are major concerns with both
> approaches, but it is not clear what a solution can be yet. It needs to
> solve the following, ordered by priority (same number equals same
> priority):
>
> 0. Inform which qube it is connected
I think I need to back-paddle a bit on my previous comment (or rather
>
> There are two major uses cases for management qubes:
>
> - `qvm-console-dispvm`: created with random disposable name, doesn't
> inform which qube it is connected to [0].
> - Ansible and Salt: created with fixed name, prefixed with `disp-mgmt-`
> and suffix is the qube name chopped at 31 chars [1][2], the chopping
> may cause the management of two very long qube names that have the
> same 31 chars prefix, to be the same. May fail the state or lead to
> other unexpected occurrences. Because the name is fixed, it is not an
> unnamed disposables, and therefore, doesn't benefit from preloaded
> disposables.
>
> Their creation is not standardize and there are major concerns with both
> approaches, but it is not clear what a solution can be yet. It needs to
> solve the following, ordered by priority (same number equals same
> priority):
>
> 0. Inform which qube it is connected
what it might have implied, while not stating explicitly).
I still think that Marek's point that management qubes are sensitive and
potential user confusion with other less-sensitive disposables are a
concern to consider. Also I still think its name is the primary
identifier of a qube. But I don't think we *must* use descriptive names
for those disposable qubes. Would be nice, but there's a tradeoff with
other points, so maybe not the best option.
Beside the qvm-consolve-dispvm case, other usage of disposables also
have vastly different sensitivity/trust levels and we accept the
limitation of the non-descriptive disp${i} names there.
> 0. Don't suffer from name chopping (can lead to name conflicts)
conflicts is tricky and very easily leads to security relevant bugs.
But there's the option to use another naming scheme in case of over long
names, so this doesn't rule out using descriptive names by default.
BTW, it probably would be good to have some official documentation for
reserved names that are used by such auto generation schemes, since
conflicts with existing (use created) qubes are also a concern.
> 1. Uses unnamed disposables, can benefit from random names and preloaded
> disposables
>
> Proposal:
>
> - GUI users can be benefited if the unspoofable part of the qube window
> controlled by GUI daemon mentioned the qube name the console is
> connected to: `[disp1234: mgmt of sys-net]`. In the case of Ansible,
> it is being created with the feature `gui=False`, meaning that no
> window will be opened. The `qui-domains` will need info in the tooltip
> maybe `Qube manager` will need a new field (maybe).
> - CLI users, sometimes headless setups, won't be able to differentiate
> using the GUI daemon, another solution is necessary here. Maybe the
> management information could be logged to qubesd as in
> *disp$dispid-mgmt has admin console of sys-net*, `-mgmt` added to
> disposable of disposable templates that are `management_dispvm` on the
> global or per-qube level. If a feature feature/tag is added to the
> qube, it could be shown on `qvm-ls`.
> - This would result in: inform slightly which qube it is connected to
> for GUI and CLI users, avoids name conflicts and name chopping and can
> benefit from preloaded disposables.
>
> - From past conversations, the major opposition to my proposal is that it
> only slightly informs which qube it is connected to for terminal users,
> the qube name is the primary identifier. Maybe it is a trilemma, maybe
> it is not and we haven't solved this puzzle (yet).
preload issue:
- Use descriptive names (disp-mgmt-${name}) with a fallback for too long
names.
- Use descriptive names (disp-mgmt-${name}) and allow longer names for
those. Refuse recursion (at least at some level).
Now back to options that also address the preload issue (mostly what you
already wrote above, but a bit extended):
- Use non-descriptive names (disp${i})
- Special case display for mgmt/console case in GUI and maybe also
CLI/logs. (fixed "disp${i} mgmt for ${name}")
- Add a generic short description feature/property that is displayed
together with the name in GUI and ideally also CLI/logs.
("disp${i} (${short_desc_field})")
- Same as previous option (including sub-options), but a special naming
scheme to highlight mgmt/console use (disp-mgmg${i})
I really like the generic short description field option, especially if
it would be displayed in most cases, so would be a real addition to the
name (as opposed to be hidden behind a tool tip or similar UI).
I think this would be useful in other cases:
- Annotate other disposable by default. For example: "disp123 (created
by personal)" vs. "disp534 (created by vault)"
- Allow short (but obviously still unique) names for convenience while
having a bit longer info always displayed. Particular useful for
seldomly used qubes.
- I have a lot of temporary (but not disposable) qubes. Those are often
created in a hurry and too short lived to bother with the expensive
rename (shutdown, clone, careful remove old, updated references). So
being able to live update the short description would be really nice.
The main challenge is, I think, integrating the longer text into UI and
that it might be "too useful" and therefore overused which exacerbates
the UI problem. For example the "created by personal" immediately makes
it tempting to allow a creator qube controlled suffix for use by
qvm-open-in-dvm or similar.
> Reference:
>
> [0]: https://github.com/QubesOS/qubes-ansible/pull/15#discussion_r2314333818
> [1]: https://github.com/QubesOS/qubes-issues/issues/9810
> [2]: https://github.com/QubesOS/qubes-mgmt-salt/blob/c5a8a5ade740eff1a507a65f8b89bfc7ea9dd573/qubessalt/__init__.py#L140
> [3]: https://github.com/QubesOS/qubes-ansible/blob/32e46780f96829ff61893aad3923728ff09bc7a6/plugins/strategy/qubes_proxy.py#L50
iQIzBAEBCgAdFiEE3E8ezGzG3N1CTQ//kO9xfO/xly8FAmi5gxkACgkQkO9xfO/x
ly9qHQ//XA2VLTLbvrR6Zq+IM6hT+ufbB0GNEevhpDSinQ0/hL8YOmESVb0DfLQY
NFnKp8MQjDnvlrJDVTZoWKmNk4H2qIwOZCeDLz6MbVMpd5xVpxRMoi+AHXceWSLZ
Y67eIFJfTefkTvSAog0NNrsgTOzPuKiateE9tcXaW60yMjGuKZmGUTd6l8RkM51X
4sjmhCyTaXTLc+9kK30X97B5f7xJO3m19K0aHZI2Vb+EqDCyW6vS+S08PBUjrk0k
eurNhpvyF9z5AYIidxu9i/D/MDtRX4tuuZA5VIeMrA62iC85j+O3RE/1RpDLDdV1
A8UKQq3qXzhqG8X49H2lvicl4XsxiXy/Epq5UWu4+Dzj9iNbH4KmBxnuG6RZahyl
jchW4VRKBNgsNj3XChHSy1kutuXdPgDGyZ+7eqPZH4yq9nGA6Es/J8dsow3VLbJH
rBiZLEQtaxcxY6izYJjPMovU+0RJ4PP/jwsJQOtuvtLfxEuCVZPDMpmhDMoYDJhp
M8ffvakiiK93GWQJr+Vlzj0dJ3cDy63mo6X8DRUbYBrb/Kw4Ntvh2FqVaxhicpnQ
Q1Zlr4WudJKsBpxNqOOwuQuLG6SNzw4moxX+oNktshOO7ZlEm5rxt0j7aH2tzrzB
QBMFgTOu2QIYs24pD9bIuHYxEXaSurz31+ZxVV8nYFpmhwCpqMM=
=Qyjg
-----END PGP SIGNATURE-----
Reply all
Reply to author
Forward
0 new messages