Setting several AppVMs to start on boot causes only one random VM to autostart #2666
Comments
|
This isn't my experience. I regularly open 9 or 10 qubes on start-up without problems. Almost all of those are based on minimal (or mini) templates, but not all. I dont have huge amounts RAM, but a reasonable processor and SSD. Even on laptop with regularHD I could start 5 or 6 |
|
I have 32GB of RAM and an nvme SSD so I doubt it's caused by my spec. |
|
Does those network connected VMs use default NetVM? Default NetVM is specifically started before other VMs to avoid race condition you are experiencing. |
|
All VMs use the default sys-firewall VM. Although I just checked, under Global settings I had sys-net set as default NetVM and not sys-firewall which was probably the cause of this issue. This however leads me to a question, why is it even possible to set sys-net as default NetVM (aside from "users are free to shoot themselves in the foot if they want to") ? |
|
Because it's also valid setting, in some cases. |
|
Fair enough. Is the race condition something that is going to be worked on or can I close this one out? |
marmarek
added
the
T: bug
|
@andrewdavidwong Confirmed this issue still arises in 3.2 milestone |
While libvirt handle locking itself, there is also Qubes-specific
startup part. Especially starting qrexec-daemon and waiting until
qrexec-agent connect to it. When someone will attempt to start VM the
second time (or simply assume it's already running) - qrexec will not be
connected yet and the operation will fail. Solve the problem by wrapping
the whole vm.start() function with a lock, including a check if VM is
running and waiting for qrexec.
Also, do not throw exception if VM is already running.
This way, after a call to vm.start(), VM will be started with qrexec
connected - regardless of who really started it.
Note that, it will not solve the situation when someone check if VM is
running manually, like:
if not vm.is_running():
yield from vm.start()
Such code should be changed to simply:
yield from vm.start()
Fixes QubesOS/qubes-issues#2001
Fixes QubesOS/qubes-issues#2666
While libvirt handle locking itself, there is also Qubes-specific
startup part. Especially starting qrexec-daemon and waiting until
qrexec-agent connect to it. When someone will attempt to start VM the
second time (or simply assume it's already running) - qrexec will not be
connected yet and the operation will fail. Solve the problem by wrapping
the whole vm.start() function with a lock, including a check if VM is
running and waiting for qrexec.
Also, do not throw exception if VM is already running.
This way, after a call to vm.start(), VM will be started with qrexec
connected - regardless of who really started it.
Note that, it will not solve the situation when someone check if VM is
running manually, like:
if not vm.is_running():
yield from vm.start()
Such code should be changed to simply:
yield from vm.start()
Fixes QubesOS/qubes-issues#2001
Fixes QubesOS/qubes-issues#2666
While libvirt handle locking itself, there is also Qubes-specific
startup part. Especially starting qrexec-daemon and waiting until
qrexec-agent connect to it. When someone will attempt to start VM the
second time (or simply assume it's already running) - qrexec will not be
connected yet and the operation will fail. Solve the problem by wrapping
the whole vm.start() function with a lock, including a check if VM is
running and waiting for qrexec.
Also, do not throw exception if VM is already running.
This way, after a call to vm.start(), VM will be started with qrexec
connected - regardless of who really started it.
Note that, it will not solve the situation when someone check if VM is
running manually, like:
if not vm.is_running():
yield from vm.start()
Such code should be changed to simply:
yield from vm.start()
Fixes QubesOS/qubes-issues#2001
Fixes QubesOS/qubes-issues#2666
|
Automated announcement from builder-github The package |
Qubes OS version (e.g.,
R3.2):3.2
Affected TemplateVMs (e.g.,
fedora-23, if applicable):fedora-24, possibly others
Expected behavior:
All AppVMs set to autostart actually autostart.
Actual behavior:
Network disconnected AppVM and one random network connected AppVM autostart correctly. The rest needs to be manually started.
Steps to reproduce the behavior:
General notes:
I can provide whichever logs are needed just tell me which ones.
Related issues:
The text was updated successfully, but these errors were encountered: