how to start that new guiVM? Cannot see any vm named like it.
thx:)
1 Like
(moved this to a topic of its own)
1 Like
Qubes 4.1 includes salt formula to configure GUI domain. There are actually two of them:
-
qvm.sys-gui-gpu- the one using full GPU passthrough, createssys-gui-gpuVM -
qvm.sys-gui- the one using hybrid mode (X server in dom0, window manager in sys-gui)
Use it this way:
qubesctl top.enable qvm.sys-gui
qubesctl top.enable qvm.sys-gui pillar=True
qubesctl --all state.highstate
(replace qvm.sys-gui with qvm.sys-gui-gpu for the other mode)
You can read more about those modes at Qubes Architecture Next Steps: The GUI Domain | Qubes OS
Note this is still highly experimental and it is quite easy to get locked out. In case of hybrid mode, you can always switch to the text console (ctrl+alt+f2) to access dom0, but in case of GPU passthrough, you need to reboot your system with qubes.skip_autostart option added to the dom0 kernel (the line with vmlinuz in grub) - to avoid starting sys-gui-gpu and taking over the graphics card.
Also note the sys-gui-gpu formula is configured for Intel graphics specifically. In case of different graphics card, you may need to manually attach it to the sys-gui-gpu qube.
9 Likes
Thank you for ur answer. Okay I am a bit afraid to test it hehe, because GPU passthrough often ends in a unbootable vm or system for me 
and atm it is running everything really fine. And I have got nvidia cards…that makes me even more afraid of testing:D
But I like to have GPU Passthrough in one my vm’s defintely. So this should be the easiest method to try it or should I select an other one?
As soon I add the line to the grub with vmlinuz again then gui-vm will be disabled again and my system should work again if there is any problem after enabling the gui-vm?
And adding one those commands a dom0 terminal should show me the gui-vm, shouldn’t it?
Just to have your system started again - yes, that kernel option is enough. To roll back to the GUI in dom0, you may also need to switch default-guivm property back to dom0, and disable sys-gui (or sys-gui-gpu) autostart.
2 Likes
How much performance impact does this new gui-vm impart over dom0 based gui? Anyone?
What I tried now:
run your 3 steps with qubesctl top.enable qvm-sys-gui-gpu
qubesctl top.enable qvm-sys-gui-gpu pillar=True
qubestctl --all state.highstate
And the last step I just got one error with code 1 for sys-firewall, but think that shouldn’t be the problem and my system is working and didn’t crashed;) Now I have got 1 sys-gui-gpu as a Vm in the qubes-manager. But they didn’t boot automatically at system start and I need to run it first.
I don’t know why that vm is based on my fedora-33-xfce template ,because I don’t have selected this one as my main in the global settings, but if that bringst not some problems then it is wayne weather vm the gui-gpu is running. How do u mean to attach the nvidia cards to the vm? Just in the Qubes-Manager under Devices and add the pci /pcie of my two nvidia 980m cards to it or I need to do it other way?
thank you again for ur great help
edit: starting the vm first works but immeditately shutdown again with the error no such file or directory /usr/bin/qubes-input-trigger-dom0 --all --dom0 failed with erno2 -is that because I haven’t attached the nvidia cards to the vm now?
Before using the 2nd way I disabled the sys-gui-gpu running qubesctl top.disable qvm.sys-gui and then started with
2nd method enable sys-gui not sys-gui-gpu . That is working after rebooting the system the vm starts in a green state and just was a error 20 at the last step running qubesctl --all state.highstate sys-gui but that shouldn’t be a real error and be problem. But I have to read the documentation again and much more detailed, because now I don’t know if already my vm’s have gpu passthrough or I need to add my video cards or sth like that first;)
And this vm is based on my fedora-33-xfce template,too but I don’t select it, but like I said if that is working then the template is wayne for me.
Of course if anyone is trying it,too u need to run all these commands with sudo or u will get permission denied;) And I am not logged of from my system;) Maybe that new is still experimental and not highly experimental and don’t be too afraid to try it 
1 Like
I just tried it myself on 4.1 and the qubectl top.enable qvm.sys-gui command(s) didn’t create any VM. qubectl --all state.highstate also hangs. Any idea what could be wrong or where to check to see what might have gone wrong with the VM?
qubectl top.enable qvm.sys-gui gave me a response that sys-gui was enabled.
2 Likes
sudo qubesctl top.enable qvm.sys-gui
sudo qubesctl top.enable qvm.sys-gui pillar=True
sudo qubesctl --all state.highstate (that step needs some time for me until it was finished)
and every command in a dom0 terminal. Like @marmarek explained in the first post creates a sys-gui vm in the qubes manager for me with 3 running services: - guivm-gui-agent ; dummy-psu dummy-backlight and the vm starts after rebooting.
I first tried it with the sys-gui-gpu vm and that created the sys-gui-gpu vm qubes ,too but that vm don’t start at my system (think because of the nvidia cards) But maybe it works because I first tried this method
qubesctl top.enable qvm-sys-gui-gpu ; qubesctl top.enable qvm.sys-gui-gpu pillar=True and qubesctl --all state.highstate and then I disable the sys-gui-gpu because it is not working with sudo qubesctl top.disable qvm-sys-gui-gpu and then started the steps for the qvm-sys-gui. But I don’t know if that is the problem. Another thing could be that u have to update dom0 from the curent-testing repo first?! But , sorry I think that will not help u much.
And I don’t know exactly if it is working at my system completely. Just the vm is running without an error, but I don’t what to do now;)
Another point is that I have installed the fedora-33-xfce template from the itl repo, but since a few days it should be in the testing or stable repo as well and if I run any of these two commands, then it creates the sys-gui or sys-gui-gpu vm based on that fedora-33-xfce template. Maybe that is a good compatible template for the new gui-vm’s. And of course run all the 3 commands, not only the last one, then reboot ur system and the vm should be here. But these are only guess of me and I hope I can help anyway
I now noticed that the commands also created a vm “test” based on that xfce-33 template. If I run firefox or a terminal in that qube it is working and it don’t see a error. Here is already an other thread about the sys-gui, perhaps u will find ur answer there.
Next steps. I logged out from lightdm / plasma session and logged in to the gui-domain. It starts ,but there is no network, no qubes manager and some more things not working, but from an usual xfce session the sys-gui vm runs with a green state and most things are working, but I don’t know if that changes anything at my system?!
Edit: If I attach with qvm-prefs my-vm guivm sys-gui then the vm’ starts from dom0, but I am not able to start a app like terminal, firefox and else. It just is loading and nothing starts. Do u know why ?
1 Like
Cross referencing similar issue-
1 Like
Here is my error message if I try to start the sys-gui-gpu vm.
And if I try to change the dom0 of any appvm to sys-gui (without gpu) then everyhting is starting and has a green state but I cannot open any apps, terminal and else. Maybe I try to install sys-gui based on fedora-32-xfce template again and not the fed-33-xfce.
Can I just delete the sys-gui qube and then start the commands again after I installed fed-32-xfce ,make it default and then sys-gui should be installed on fed-32-xfce or?
Maybe people that cannot install it on fedora-32-xfce try it with the fedora-33-xfce template available in the itl testing repo and as I think it already has switched to stable, too but I don’t know.
sudo qubes-dom0-upate --enablerepo=qubes-template-itl-testing qubes-template-fedora-33-xfce will definitely install it I have based my main appvm’s on it and could not notice much problems only with those with the sys-gui vm’s.
update: deleting sys-gui from the qubes manager and running the 3 /4 commands again creates a new sys-gui and everything is working like before. But I Installed the fedora-32-xfce and set it as default and sys-gui even is installed at the fedora-33-xfce template . I don’t know why and maybe that is problem because apps don’t run and sys-gui-gpu is not starting, too. I will be very happy and thankful for help here.
@rasta
Did you have a look at this thread?
I didn’t try things out since then so I don’t know about improvements or anything else but at least back then I could start the guiVMSession and start apps the way described in the linked thread above.
I didn’t experiment with sys-gui-gpu yet because I read that it was tested to work with intel rather than AMD. I have a dedicated gpu so I will try this in the future.
1 Like
Yes I already did it. I can log in to sys-gui from the display manager or with the command. that it is working, but setting qvm-prefs sys-gui in for a vm as a guivm ,then there no app is starting. And I am trying it from dom0 and there I read that it is working for a few people. Now is weekend again hehe and I will try it and research again for a solution, but if not no problem and I just have to wait a bit until it becomes more stable:) And I have got a nvidia ,too and think that sys-gui-gpu is much more difficult to get working because of that, u are right thank you for every help .
For me it works the same as before. I have to open an app from the drop down menu of said VM (for example: libreofficeWriter in the VM office [that has been added via: qvm-prefs office guivm sys-gui] or via CLI in dom0.
It does not work via the drop-down menu in sys-gui. There are no apps in these menus.
Okay @rasta I tried sys-gui-gpu and had the same error message you had.
When running
sudo qubesctl --all state.highstate
there is an error with the package
dummy-psu-dom0
which fails to install. So in the end there is the message
DOM0 configuration failed, not continuing
Maybe the error message might have something to do with this package?
1 Like
There is a error in sys-gui-gpu config file. Line 14:
It says:
dummy-psu-dom0:
pkg.installed:
https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/sys-gui-gpu.sls
When you look at this file sys-gui: Line 13
dummy-psu-sender:
pkg.installed:
https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/qvm/sys-gui.sls
So you need to change your sys-gui-gpu SLS file.
This file you can found at this location:
/srv/formulas/base/virtual-machines-formula/qvm/default/sys-gui-gpu.sls
After you change this config file and compile your new VM, you will receive new error:
file or directory qubes-input-trigger not found.
I am waiting here for progress.
After reading your Post 10 times again and again, I am still not sure if I get it right.
So…
Note this is still highly experimental and it is quite easy to get locked out. In case of hybrid mode, you can always switch to the text console (ctrl+alt+f2) to access dom0
I get this, no problem
but in case of GPU passthrough, you need to reboot your system with
qubes.skip_autostartoption added to the dom0 kernel (the line with vmlinuz in grub) - to avoid starting sys-gui-gpu and taking over the graphics card.
This part I do not get.
What do you want to say?
I have to add this line to my /etc/default/grub ?
I know how to add it.
What confuses me is you part:
to avoid starting sys-gui-gpu and taking over the graphics card.
What?
Please, explain this.
Thank you very much.
1 Like
this is same error which I get when I compile VM.
2 Likes
I don’t get that part with the grub-line ,too. I need to add this line that sys-gui-gpu and maybe then it is working or I need that line to repair my system if it is not working anymore ? Don*t know if it is right to start the sys-gui-gpu from dom0 only .Think the gpu have to be loaded at booting and we need to add this line first, but I really don’t know it!
1 Like
What happen ? Were you able to make everything work normally ?
2 Likes