qvm-run --dispvm doesn't work when invoked from dom0 #3012

rootkovska · Aug 11, 2017

Qubes OS version (e.g., `R3.2`):

4.0-rc1, latest core 4.0.5 from current-testing

Steps to reproduce the behavior:

[user@dom0 ~] $ qvm-run --dispvm -- xterm

The error message from qubesd is that dom0 has no property default_dispvm.

If I then specify e.g. fedora-25 to be used as a template, this also fails, because the template does not have dispvm_allowed property, and it doesn't seem possible to set it via qvm-prefs.
If I specify some AppVM as a template (after manually changing dispvm_allowed to True), this step works.
Unfortunately, the startup fails, Actually it seems like the DispVM starts for a second, then dies. Some relevant message might be about the Storage Pool for the dispvm (qubes_dom0/vm-dispXYZ-root-snap) "being in use"...

The error message from qubesd is that dom0 has no property default_dispvm.

This means you haven't update qubes-core-dom0: QubesOS/updates-status#176
Please update and try again (there are more fixes than just this).
Also, for GUI application I recommend updating template too, and use --service qubes.StartApp+xterm, instead of bare xterm (which use qubes.VMShell).

marmarek · Aug 11, 2017

The error message from qubesd is that dom0 has no property default_dispvm.

This means you haven't update qubes-core-dom0: QubesOS/updates-status#176
Please update and try again (there are more fixes than just this).
Also, for GUI application I recommend updating template too, and use --service qubes.StartApp+xterm, instead of bare xterm (which use qubes.VMShell).

Or maybe, you don't have default_dispvm set? If it isn't set for dom0, it defaults to global property. But maybe you don't have it set either?

marmarek · Aug 11, 2017

Or maybe, you don't have default_dispvm set? If it isn't set for dom0, it defaults to global property. But maybe you don't have it set either?

(and of course you've meant qvm-run --dispvm, not qvm-start --dispvm. I've updated description)

marmarek · Aug 11, 2017

(and of course you've meant qvm-run --dispvm, not qvm-start --dispvm. I've updated description)

@qvm-run --dispvm -- xterm:
I had also tested that yesterday afternoon and this morning with the latest updates:

This morning it did work on the 3rd try, the first two tries just resulted in qvm-run exiting without any comment and nothing happening.

I then tested qvm-run --dispvm --service qubes.StartApp+xterm which worked on the first try.

Afterwards I ran

qvm-run --dispvm fedora-25-dvm xterm
Running 'xterm' on $dispvm:fedora-25-dvm

$dispvm:fedora-25-dvm: Cannot execute qrexec-daemon!
Traceback (most recent call last):
  File "/usr/bin/qvm-run", line 9, in <module>
    load_entry_point('qubesadmin==4.0.5', 'console_scripts', 'qvm-run')()
  File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_run.py", line 235, in main
    dispvm.cleanup()
  File "/usr/lib/python3.5/site-packages/qubesadmin/vm/__init__.py", line 376, in cleanup
    self.kill()
  File "/usr/lib/python3.5/site-packages/qubesadmin/vm/__init__.py", line 118, in kill
    self.qubesd_call(self._method_dest, 'admin.vm.Kill')
  File "/usr/lib/python3.5/site-packages/qubesadmin/base.py", line 69, in qubesd_call
    payload_stream)
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 482, in qubesd_call
    return self._parse_qubesd_response(return_data)
  File "/usr/lib/python3.5/site-packages/qubesadmin/base.py", line 102, in _parse_qubesd_response
    raise exc_class(format_string, *args)
qubesadmin.exc.QubesVMNotStartedError: Domain is powered off: 'disp3011'

--> Doesn't look stable to me yet.

I also noticed a few less important bugs, but I'll create separate issues for that.

3hhh · Aug 12, 2017

@qvm-run --dispvm -- xterm:
I had also tested that yesterday afternoon and this morning with the latest updates:

This morning it did work on the 3rd try, the first two tries just resulted in qvm-run exiting without any comment and nothing happening.

I then tested qvm-run --dispvm --service qubes.StartApp+xterm which worked on the first try.

Afterwards I ran

qvm-run --dispvm fedora-25-dvm xterm
Running 'xterm' on $dispvm:fedora-25-dvm

$dispvm:fedora-25-dvm: Cannot execute qrexec-daemon!
Traceback (most recent call last):
  File "/usr/bin/qvm-run", line 9, in <module>
    load_entry_point('qubesadmin==4.0.5', 'console_scripts', 'qvm-run')()
  File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_run.py", line 235, in main
    dispvm.cleanup()
  File "/usr/lib/python3.5/site-packages/qubesadmin/vm/__init__.py", line 376, in cleanup
    self.kill()
  File "/usr/lib/python3.5/site-packages/qubesadmin/vm/__init__.py", line 118, in kill
    self.qubesd_call(self._method_dest, 'admin.vm.Kill')
  File "/usr/lib/python3.5/site-packages/qubesadmin/base.py", line 69, in qubesd_call
    payload_stream)
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 482, in qubesd_call
    return self._parse_qubesd_response(return_data)
  File "/usr/lib/python3.5/site-packages/qubesadmin/base.py", line 102, in _parse_qubesd_response
    raise exc_class(format_string, *args)
qubesadmin.exc.QubesVMNotStartedError: Domain is powered off: 'disp3011'

--> Doesn't look stable to me yet.

I also noticed a few less important bugs, but I'll create separate issues for that.

This morning it did work on the 3rd try, the first two tries just resulted in qvm-run exiting without any comment and nothing happening.

This is because qubes.VMShell service do not wait for X server startup in the VM - so, there is a race. If it starts xterm before X server, it fails. You can see that adding --pass-io option. qubes.StartApp service do wait for X server.

$dispvm:fedora-25-dvm: Cannot execute qrexec-daemon!

That's strange. Can you set debug to true on this VM and try again? You should get VM VGA output and see what's wrong with VM startup.

marmarek · Aug 12, 2017

This morning it did work on the 3rd try, the first two tries just resulted in qvm-run exiting without any comment and nothing happening.

This is because qubes.VMShell service do not wait for X server startup in the VM - so, there is a race. If it starts xterm before X server, it fails. You can see that adding --pass-io option. qubes.StartApp service do wait for X server.

$dispvm:fedora-25-dvm: Cannot execute qrexec-daemon!

That's strange. Can you set debug to true on this VM and try again? You should get VM VGA output and see what's wrong with VM startup.

Out of ten tries I only had it once so far and unfortunately debug was off then...

Now however 2/3 tries of
qvm-run -p --dispvm --service qubes.StartApp+xterm
resulted in
xterm: Xt error: Can't open display: :0
i.e. there seems to be a racing condition still. In general it might be worth making "wait for X" another command-line flag.

3hhh · Aug 12, 2017

Out of ten tries I only had it once so far and unfortunately debug was off then...

Now however 2/3 tries of
qvm-run -p --dispvm --service qubes.StartApp+xterm
resulted in
xterm: Xt error: Can't open display: :0
i.e. there seems to be a racing condition still. In general it might be worth making "wait for X" another command-line flag.

What also happened multiple times with debug = true was that I got a totally black dispVM, unable to type and not starting xterm.
In the upper left corner I get

[
_

Before I could see from the scrolling down startup messages that it got past the login.
Pass-io just shows some missing font for xterm (also happens on other occasions).

3hhh · Aug 12, 2017

What also happened multiple times with debug = true was that I got a totally black dispVM, unable to type and not starting xterm.
In the upper left corner I get

[
_

Before I could see from the scrolling down startup messages that it got past the login.
Pass-io just shows some missing font for xterm (also happens on other occasions).

What also happened multiple times with debug = true was that I got a totally black dispVM,

By default configuration in Fedora X server switch to empty tty, even if not going to use it. Simply switch back to other tty, for example with ctrl+alt+left.

Now however 2/3 tries of
qvm-run -p --dispvm --service qubes.StartApp+xterm
resulted in
xterm: Xt error: Can't open display: :0

Do you have newest qubes-core-agent there (QubesOS/updates-status#188)?

i.e. there seems to be a racing condition still. In general it might be worth making "wait for X" another command-line flag.

There is one: --gui. But normally it require calling another qrexec service before actual command. And DispVM is automatically destroyed after qrexec service call finishes... So, this option in practice works only for non-Disposable VMs.

marmarek · Aug 12, 2017

What also happened multiple times with debug = true was that I got a totally black dispVM,

By default configuration in Fedora X server switch to empty tty, even if not going to use it. Simply switch back to other tty, for example with ctrl+alt+left.

Now however 2/3 tries of
qvm-run -p --dispvm --service qubes.StartApp+xterm
resulted in
xterm: Xt error: Can't open display: :0

Do you have newest qubes-core-agent there (QubesOS/updates-status#188)?

i.e. there seems to be a racing condition still. In general it might be worth making "wait for X" another command-line flag.

There is one: --gui. But normally it require calling another qrexec service before actual command. And DispVM is automatically destroyed after qrexec service call finishes... So, this option in practice works only for non-Disposable VMs.

Do you have newest qubes-core-agent there (QubesOS/updates-status#188)?

Now I understand that previous comment...
No, I had not upgraded my template VM with the testing repo.

So now it worked 7/7 times or so without any of the aforementioned errors.

Totally my bad, sorry!

3hhh · Aug 12, 2017

Do you have newest qubes-core-agent there (QubesOS/updates-status#188)?

Now I understand that previous comment...
No, I had not upgraded my template VM with the testing repo.

So now it worked 7/7 times or so without any of the aforementioned errors.

Totally my bad, sorry!

@marmarek : qvm-run -p --dispvm --service qubes.StartApp+firefox seems to be indeed more reliable than qvm-run --dispvm -- firefox due to the waiting time for X. How can one pass arguments to the application with --service qubes.StartApp+firefox then though?

E.g. qvm-run -p --dispvm --service 'qubes.StartApp+firefox google.com' didn't work last time I tried (invalid service or something).

3hhh · Aug 18, 2017

@marmarek : qvm-run -p --dispvm --service qubes.StartApp+firefox seems to be indeed more reliable than qvm-run --dispvm -- firefox due to the waiting time for X. How can one pass arguments to the application with --service qubes.StartApp+firefox then though?

E.g. qvm-run -p --dispvm --service 'qubes.StartApp+firefox google.com' didn't work last time I tried (invalid service or something).

I still keep getting the same error about qubes_dom0/vm-disp{id}-root-snap being in used.

rootkovska · Aug 23, 2017

I still keep getting the same error about qubes_dom0/vm-disp{id}-root-snap being in used.

I still keep getting the same error about qubes_dom0/vm-disp{id}-root-snap being in used.

This problem is during DispVM cleanup, should not affect starting new DispVM.

As for qubes.StartApp - it do not allow passing an argument to application on purpose - this service is to start an application, without giving arbitrary command execution in the VM. Also, the service argument is not a command name, but a name of application (name of .desktop file in /usr/share/application, without .desktop extension - by coincidence it is the same for xterm and firefox).
The issue with original form is that qubes.VMShell service (the thing used without --service option) is not considered GUI service, so do not wait for X server startup. Unconditionally marking qubes.VMShell as GUI service IMO is a bad idea, because there are some use cases when GUI is not needed (for example downloading updates for dom0). And in Qubes 4.0 you can even choose to not start X server in a VM at all (set gui feature to false).

I see multiple possible solutions here:

Introduce another service, qubes.VMShellWithGUI, which will wait for X server startup.
Modify qvm-run tool to prepend wait for X server startup to the command, unless --nogui option is given (the command is already mangled before piping to qubes.VMShell, at least to add exit at the end).
Repurpose qubes.VMShell service to be the one with GUI, then introduce another one, for example qubes.VMShellHeadless without GUI. And carefully modify all places that use it (in practice there should be very few such places).

marmarek · Aug 25, 2017

I still keep getting the same error about qubes_dom0/vm-disp{id}-root-snap being in used.

This problem is during DispVM cleanup, should not affect starting new DispVM.

As for qubes.StartApp - it do not allow passing an argument to application on purpose - this service is to start an application, without giving arbitrary command execution in the VM. Also, the service argument is not a command name, but a name of application (name of .desktop file in /usr/share/application, without .desktop extension - by coincidence it is the same for xterm and firefox).
The issue with original form is that qubes.VMShell service (the thing used without --service option) is not considered GUI service, so do not wait for X server startup. Unconditionally marking qubes.VMShell as GUI service IMO is a bad idea, because there are some use cases when GUI is not needed (for example downloading updates for dom0). And in Qubes 4.0 you can even choose to not start X server in a VM at all (set gui feature to false).

I see multiple possible solutions here:

Introduce another service, qubes.VMShellWithGUI, which will wait for X server startup.
Modify qvm-run tool to prepend wait for X server startup to the command, unless --nogui option is given (the command is already mangled before piping to qubes.VMShell, at least to add exit at the end).
Repurpose qubes.VMShell service to be the one with GUI, then introduce another one, for example qubes.VMShellHeadless without GUI. And carefully modify all places that use it (in practice there should be very few such places).

This still doesn't work.

rootkovska · Sep 18, 2017

This still doesn't work.

What exact command have you used?

marmarek · Sep 18, 2017

What exact command have you used?

Also, see #3012 (comment) for possible solutions. Personally I like the third one.

marmarek · Sep 18, 2017

Also, see #3012 (comment) for possible solutions. Personally I like the third one.

What exact command have you used?

qvm-run --service qubes.StartApp+xterm --dispvm

(BTW, it seems the argparse doesn't accept if I specify the arguments in a different order?)

rootkovska · Sep 18, 2017

What exact command have you used?

qvm-run --service qubes.StartApp+xterm --dispvm

(BTW, it seems the argparse doesn't accept if I specify the arguments in a different order?)

qvm-run --service qubes.StartApp+xterm --dispvm

It works for me... What error have you got? Did you installed template updates (from testing)?

(BTW, it seems the argparse doesn't accept if I specify the arguments in a different order?)

Yes, argparse is more strict about ordering than previous, deprecated version (optparse).
Technically, the correct order is qvm-run --dispvm --service qubes.StartApp+xterm. --dispvm accepts optional argument - a name of base VM, so if you use qvm-run --service --dispvm qubes.StartApp+xterm, it will get qubes.StartApp+xterm as a base VM name...

marmarek · Sep 18, 2017

qvm-run --service qubes.StartApp+xterm --dispvm

It works for me... What error have you got? Did you installed template updates (from testing)?

(BTW, it seems the argparse doesn't accept if I specify the arguments in a different order?)

Yes, argparse is more strict about ordering than previous, deprecated version (optparse).
Technically, the correct order is qvm-run --dispvm --service qubes.StartApp+xterm. --dispvm accepts optional argument - a name of base VM, so if you use qvm-run --service --dispvm qubes.StartApp+xterm, it will get qubes.StartApp+xterm as a base VM name...

Interesting, it works better when you add -p option. I have no idea why, yet.

marmarek · Sep 19, 2017

Interesting, it works better when you add -p option. I have no idea why, yet.

Modify qvm-run tool to prepend wait for X server startup to the command, unless --nogui option is given (the command is already mangled before piping to qubes.VMShell, at least to add exit at the end).

Repurpose qubes.VMShell service to be the one with GUI, then introduce another one, for example qubes.VMShellHeadless without GUI. And carefully modify all places that use it (in practice there should be very few such places).

From just reading the command line help / man page, I expected that that qvm-run --gui would wait for the X session to be up before running my command.

Requiring users to be aware of qubes.VMShell* and X-related side-effects makes the command line (specifically --gui without --service) feel broken IMO.

My expectations as a user would be solution 2, or solution 3 iff --gui / --nogui controls which of qubes.VMShell / qubes.VMShellHeadless the positional command string is passed to.

jpouellet · Dec 12, 2017

Modify qvm-run tool to prepend wait for X server startup to the command, unless --nogui option is given (the command is already mangled before piping to qubes.VMShell, at least to add exit at the end).

Repurpose qubes.VMShell service to be the one with GUI, then introduce another one, for example qubes.VMShellHeadless without GUI. And carefully modify all places that use it (in practice there should be very few such places).

From just reading the command line help / man page, I expected that that qvm-run --gui would wait for the X session to be up before running my command.

Requiring users to be aware of qubes.VMShell* and X-related side-effects makes the command line (specifically --gui without --service) feel broken IMO.

My expectations as a user would be solution 2, or solution 3 iff --gui / --nogui controls which of qubes.VMShell / qubes.VMShellHeadless the positional command string is passed to.

Interesting, it works better when you add -p option. I have no idea why, yet.

Found it: it's about qrexec data connection timeout, which is 5s by default. Waiting for session is included in that timeout, so on slower machines it didn't had a chance.

marmarek · Jan 12, 2018

Interesting, it works better when you add -p option. I have no idea why, yet.

Found it: it's about qrexec data connection timeout, which is 5s by default. Waiting for session is included in that timeout, so on slower machines it didn't had a chance.

Automated announcement from builder-github

The package core-agent-linux has been pushed to the r4.0 testing repository for the CentOS centos7 template.
To test this update, please install it with the following command:

sudo yum update --enablerepo=qubes-vm-r4.0-current-testing

QubesOS/qubes-issues

Join GitHub today

qvm-run --dispvm doesn't work when invoked from dom0 #3012

Comments

rootkovska commented Aug 11, 2017 • edited by marmarek Edited 1 time marmarek edited Aug 11, 2017 (most recent)

Qubes OS version (e.g., R3.2):

Steps to reproduce the behavior:

rootkovska added bug C: core P: major labels Aug 11, 2017

rootkovska added this to the Release 4.0 milestone Aug 11, 2017

rootkovska assigned marmarek Aug 11, 2017

rootkovska changed the title from qvm-start --dispvm doesn't work when invoked from dom0 to qvm-run --dispvm doesn't work when invoked from dom0 Aug 11, 2017

This comment has been minimized.

marmarek commented Aug 11, 2017

This comment has been minimized.

marmarek commented Aug 11, 2017

This comment has been minimized.

marmarek commented Aug 11, 2017

This comment has been minimized.

3hhh commented Aug 12, 2017

This comment has been minimized.

marmarek commented Aug 12, 2017

This comment has been minimized.

3hhh commented Aug 12, 2017

This comment has been minimized.

3hhh commented Aug 12, 2017

This comment has been minimized.

marmarek commented Aug 12, 2017

This comment has been minimized.

3hhh commented Aug 12, 2017

This comment has been minimized.

3hhh commented Aug 18, 2017

This comment has been minimized.

rootkovska commented Aug 23, 2017

rootkovska referenced this issue Aug 23, 2017

This comment has been minimized.

marmarek commented Aug 25, 2017

artemist referenced this issue Aug 28, 2017

This comment has been minimized.

rootkovska commented Sep 18, 2017

This comment has been minimized.

marmarek commented Sep 18, 2017

This comment has been minimized.

marmarek commented Sep 18, 2017

This comment has been minimized.

rootkovska commented Sep 18, 2017

This comment has been minimized.

marmarek commented Sep 18, 2017

This comment has been minimized.

marmarek commented Sep 19, 2017

marmarek referenced this issue Nov 7, 2017

This comment has been minimized.

jpouellet commented Dec 12, 2017

jpouellet referenced this issue Dec 12, 2017

marmarek referenced this issue Dec 13, 2017

marmarek referenced this issue Dec 23, 2017

This comment has been minimized.

marmarek commented Jan 12, 2018

marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue Jan 12, 2018

marmarek added a commit to marmarek/qubes-core-admin-client that referenced this issue Jan 12, 2018

marmarek referenced this issue in QubesOS/qubes-core-admin-client Jan 12, 2018

rustybird added a commit to rustybird/qubes-core-admin-client that referenced this issue Jan 14, 2018

rustybird added a commit to rustybird/qubes-core-admin-client that referenced this issue Jan 14, 2018

marmarek closed this in marmarek/qubes-core-agent-linux@ce1f0af Jan 15, 2018

This comment has been minimized.

qubesos-bot commented Jan 18, 2018

qubesos-bot added the r4.0-centos7-cur-test label Jan 18, 2018

This comment has been minimized.

qubesos-bot commented Jan 18, 2018

qubesos-bot added the r4.0-fc26-cur-test label Jan 18, 2018

This comment has been minimized.

qubesos-bot commented Jan 18, 2018

qubesos-bot added the r4.0-dom0-cur-test label Jan 18, 2018

qubesos-bot referenced this issue in QubesOS/updates-status Jan 18, 2018

This comment has been minimized.

qubesos-bot commented Jan 18, 2018

qubesos-bot added the r4.0-jessie-cur-test label Jan 18, 2018

This comment has been minimized.

qubesos-bot commented Jan 18, 2018

qubesos-bot added the r4.0-stretch-cur-test label Jan 18, 2018

This comment has been minimized.

rootkovska commented Aug 11, 2017 •

edited by marmarek

Edited 1 time

marmarek edited Aug 11, 2017 (most recent)

Qubes OS version (e.g., `R3.2`):

marmarek closed this in `marmarek/qubes-core-agent-linux@ce1f0af` Jan 15, 2018