The documentation for sys-gui isn’t very comprehensive, and many of my questions remain unanswered on the forum. So I’ll just share my thoughts and questions:
What are the benefits of sys-gui?
What are the downsides or important considerations when using sys-gui?
Quoting the first two sentences from the documentation:
On this page, we describe how to set up a GUI domain . In all the cases, the base underlying TemplateVM used is Fedora with XFCE flavor to match current desktop choice in dom0. That can be adapted very easily for other desktops and templates.
Some follow-up questions:
Is it possible to use debian or debian-minimal as template for sys-gui? If so, which packages are required?
What’s the recommended way to set up sys-gui - using the standard Saltstack states, creating a custom setup, or something else? More specifically, what do experienced Qubes users typically do?
What are the pros and cons of sys-gui compared to sys-gui-gpu? The documentation mentions that only Intel iGPUs (i assume that iGPU is meant and not a “real” Intel GPU because as of my knowledge the first Intel GPU came only recently?) are supported by default, so I’m curious what distinguishes the two?
2 Likes
It has been some time since the last design post about Qubes. There have been some big changes happened, and it took us a little while to find people best suited to write these articles. But, as you can see, the victims volunteers have been found....
opened 05:08PM - 08 Mar 15 UTC
closed 12:29AM - 07 Feb 23 UTC
C: core
C: gui-virtualization
P: major
release notes
security
C: gui-domain
meta-issue
**Reported by joanna on 27 Apr 2014 12:32 UTC**
- Allow to "kiosk" the GUI doma… in reasonably for corporate applications
- Allow to use "whatever" OS as GUI domain (e.g. Windows) -- we just need gui-daemon ported to that OS
- Potentially requires "qubesd" (discussed elsewhere) (#853)
- Requires vm-to-vm vchan for GUI protocol (#2619)
Migrated-From: https://wiki.qubes-os.org/ticket/833
Subtasks:
- [ ] give GUI domain control over the whole screen - either with GPU passthrough (#2618), or another qubes-gui connection (similar to https://github.com/QubesOS/qubes-issues/issues/833#issuecomment-277015652)
- [ ] configure GUI domain environment - window manager, system settings, etc (#4186)
- [ ] various startup scripts and configuration - get actual desktop environment started in GUI domain (and only there), pass connection information to other domains etc
- [ ] menu handling - redirect menu related qrexec services to GUI domain, trigger menu updates on relevant events (qube creation etc)
- [ ] implement (opt-in) debug access to dom0 shell (maybe just qubes.VMShell, or something more elaborate with real pty access)
- [ ] collect and implement missing Admin API calls (GUI domain elements assuming direct dom0 access)
- [ ] get installer setup all the above
sys-gui is in its alpha stage, so expect some bugs, including lacking documentation:
opened 02:30PM - 05 Jun 23 UTC
C: doc
P: default
[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/)
#… ## Qubes OS release
### Brief summary
In the documentation on creating a [gui domain](https://www.qubes-os.org/doc/gui-domain/) there is inadaquate information on how `sys-gui` and `sys-gui-gpu` is to be used, and how to troubleshoot issues. I understand it is a work in progress, but am speaking in terms of improving the documentation.
These questions should be touched upon.
- Is passing a GPU to sys-gui-gpu safe, or does is still posses the same security risks?
- How to execute dom0 commands while in sys-gui-gpu?
- What software is meant to be installed in sys-gui? Additionally, are there qube packages that are specific to the gui domain we need to be aware of? This may be important if users decide to install different desktop environments or qube dep packages get removed.
- How to deal with empty application menu?
- How to deal with empty device menu (qui-devices)?
- Troubleshoot tip on using 'qubes.skip_autostart' but also having to manually execute 'qui-*' services when wanting to run as dom0.
This point should also be raised.
The salt script may not set `default_guivm` to sys-gui* but remain set to dom0, likewise the key `guivm` must also be set to sys-gui*, otherwise they won't show up in the GUI domain.
### Expected behavior
Prior to explaining how to create sys-gui*, there should be greater explanation and context how the GUI domain is to be used.
### Actual behavior
Documentation gives brief explanation on what sys-gui is and how to create it, but not how to use it.
opened 01:21AM - 06 Aug 18 UTC
C: gui-domain
P: default
Configure graphical system in GUI domain (for GUI/Admin domain split), including… required qrexec services:
- [ ] multi-display handling, including dynamic configuration (specifically in fallback case without real GPU passthrough)
- [x] power reporting (battery, AC)
- [ ] RPC for managing dom0 powerstate (shutdown, restart, etc.)
- [ ] screen locker - choose one; if applicable - prevent vt switch
- [ ] disable "new login" feature
- [x] Debian packaging for current only dom0 (Fedora) components (e.g. manager, artwork, desktop-linux-xfce4*)
- [ ] touchpad configuration, and various other input devices configuration that isn't passed through GUI protocol / input proxy
opened 12:03AM - 17 Jun 21 UTC
C: doc
P: default
**Qubes OS version (if applicable)**
R4.1
**Affected component(s) or f… unctionality (if applicable)**
gui, documentation
**Brief summary**
Document everything needed to test new GUI VM feature. Some hints at https://qubes-os.discourse.group/t/how-to-enable-the-new-gui-vm/2631/3
**Relevant [documentation](https://www.qubes-os.org/doc/) you've consulted**
https://www.qubes-os.org/doc/gui-configuration/
https://www.qubes-os.org/news/2020/03/18/gui-domain/
**Related, [non-duplicate](https://www.qubes-os.org/doc/reporting-bugs/#new-issues-should-not-be-duplicates-of-existing-issues) issues**
#833
opened 01:19PM - 05 Sep 23 UTC
C: doc
C: gui-domain
P: default
Quote https://www.qubes-os.org/news/2020/03/18/gui-domain/#the-compromise-soluti… on
> The compromise solution
This can cause a lot of confusion.
I can follow your train of thought in the blog post.
1. best solution - [`GPU passthrough: the perfect-world desktop solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#virtual-server-the-perfect-remote-solution)
2. next best solution - [`Virtual server: the perfect remote solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#gpu-passthrough-the-perfect-world-desktop-solution)
3. third best solution - [`The compromise solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#the-compromise-solution)
But this is far too complex for users to property contextualize. The problem is, the word `compromise` (also meaning "I got hacked") is very close to `compromised`. The `compromise` here implies "less secure". And yes, it might be "less secure".
The fallacious interpretation is "then better don't use it". Less secure than what? Less secure than not using GUI domain at all? No.
What the real ordering from best to worst security is, as far as I understand is the following:
1. best solution - Qubes [`GPU passthrough: the perfect-world desktop solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#virtual-server-the-perfect-remote-solution)
2. next best solution - Qubes [`Virtual server: the perfect remote solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#gpu-passthrough-the-perfect-world-desktop-solution)
3. third best solution - Qubes [`The compromise solution`](https://www.qubes-os.org/news/2020/03/18/gui-domain/#the-compromise-solution)
4. fourth best solution - Qubes without GUI domain
5. non-Qubes
This also seems weird `compromise solution` is used in the following context:
Quote https://www.qubes-os.org/doc/gui-domain/
> Here, we describe how to setup sys-gui that we call hybrid mode or referenced as a compromise solution in [GUI domain](https://www.qubes-os.org/news/2020/03/18/gui-domain/#the-compromise-solution).
The next source of confusion exaggerating this issue is the word `passthrough` which is easily understood and already tagged as a negative word in this context. This is because quote [](https://www.qubes-os.org/doc/how-to-use-pci-devices/).
> Attaching a PCI device to a qube has serious security implications.
PCI passthrough and GPU passthrough are historically have often been usability features. Not security features.
Using PCI passthrough has been used as a compromise to make certain devices work Or GPU passthrough might be useful for graphically intense applications such as gaming.
However, using passthrough of devices to a dedicated VMs `sys-gui` / `sys-audio` is a security feature, not a usability feature.
Qubes documentation is very technical but it lacks contextualization of the very essentials for laymen. These are easy to add. I can send some pull requests.
Instead of `compromise` I would suggest words such as `reasonable` or `feasible`. The `compromise solution` could be renamed to the `hybrid solution`.
Please correct me if my understanding is wrong.
opened 03:12AM - 28 Feb 24 UTC
C: gui-domain
P: default
C: GPU acceleration
sys-gui should have GPU acceleration enabled by default. It is often highly pri… vileged, in which case there is no security risks of doing so. Even when it is not highly privileged, the performance benefits are much more likely to outweigh the risks here than they are for AppVMs.
6 Likes
phceac
April 15, 2025, 2:52am
3
I cannot give any useful answers, but I did have a little “play” with sys-gui, which has sat untouched for weeks,
Fresh 4.2.4 Qubes-os install
I used Salt, according to “docs”, but did not note which docs.
I had to install Xephyr in Dom0
I noted to be sure to log in to Dom0 on a text virtual console (e.g. ctrl-alt-F2), to allow to use qvm-run to kill screensaver in sys-gui when it locks (because password was not initialised there).
I was pleased to be isolated from Dom0, and could create new AppVMs running in sys-gui.
Dom0 admin was all via text VC or logout/login.
Next task was to set a user password in sys-gui, but progress stopped, mainly because I wanted to use Salt to do my setting-up, but I was confused by the documentation/intro docs.
I was hoping to find a way to run multiple gui-domains, each serving a different group of AppVMs on a different VC.
My final goal was a cleaner alternative to putting different work/project/personal “compartments” on different workspaces inside a single X server, which quickly falls apart. That is: use VC switch to change compartment.
I hope to see some good replies to your questions from people who actually know what they are doing…
My next step is to read all those useful-looking links from @fsflover !
2 Likes
Thanks to both of you for your answers
1 Like
barto
April 15, 2025, 7:59am
5
Note that on certain hardware (like older Lenovo laptops) it is impossible to get the sys-gui construct running in a usable way - because the screen brightness is stuck to “minimum”.
absent
April 15, 2025, 8:18am
6
Is it known which lenovo laptops are not supported? T480, T430?
barto
April 15, 2025, 9:02am
7
I tried on a T480 - no success. There are several threads, from 2020-2024, on this forum, detailing different levels of success with sys-gui.
1 Like
absent
April 15, 2025, 9:14am
8
Did you try it on 4.3 alpha?
