-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Frequent VM startup failures - R4rc2 #3221
Comments
Issue #3125 regards 'libxenlight' errors which I'm not seeing. Also, this startup problem occurs with regular appVMs as much as network-providing or device-mapped VMs. So if sys-net and sys-firewall are running OK, an appVM that uses sys-firewall (or no netvm at all) may still fail to start. |
There is an emerging pattern (and workaround) to what I'm experiencing: On boot, sys-net will usually start but sys-firewall or VPN (these both connect to sys-net) will fail, and any appVMs that use these proxyVMs will also fail. Non-connected appVMs may or may not start at this point. If I keep re-trying different VMs, I may get sys-firewall or VPN to run but downstream appVMs can't access the net. However, if I shut down sys-net along with all the other VMs, I can then start VMs with much more reliability: I can start an appVM, and then sys-net and VPN or sys-firewall will start and run properly. A memory management issue may be related to this... I have noticed sometimes appVMs lose the ability to acquire more RAM despite plenty available, resulting in the appVM swapping heavily when demand increases. But it may be the case when I re-start sys-net like above, the new VM instances retain their ability to gain (and relinquish) RAM; that is how my system is behaving now. |
I've not experienced any of the other issues you described, but that memory management issue happened to me a few times and I've not managed to reliably replicate it yet. Although, now that I think about it, |
I also have problems with
If I try to connect USB controller after boot and then start
Not sure if this is related. This behavior didn't appear on R4-rc1. |
Same here...
Even if sys-firewall does start successfully, I have similar issues with AppVMs (with no pci devices) connected to sys-firewall. |
How much memory does the system have? Try adjusting initial memory (increase it), or maxmem (decrease it). |
The above comment is to check relation to #2853 |
sys-firewall: 600MB initial, 1GiB max As tasket mentioned, the issue seems to affect VMs downstream from sys-firewall. If I change my AppVM's netvm from sys-firewall to none, it starts always. If I change it back, startup fails most of the time. |
Ok, so this is something different. |
Having same issiue but starting a VM multiple times doesn't help |
@marmarek One trick that has worked over the last 2 days: |
Also, overall system RAM is 8GB. |
After qubes-dom0-update, VMs now start consistently for me (whereas before, startup would fail half the time). |
I'm having similar good luck for the last 24 hrs. since the update, but I'm still keeping my fingers crossed. :) |
Qubes OS version:
R4rc2
Affected TemplateVMs:
fedora-25
debian-8
Steps to reproduce the behavior:
Start any VM using these templates.
Expected behavior:
VM starts and responds to commands.
Actual behavior:
Desktop notification that VM is starting, but there is relatively little disk activity and the VM menu widget shows a busy indicator for that VM until a minute later when the VM disappears.
This happens close to 50% of the time.
General notes:
Trying to start the VM over and over can get the VM running.
Discussion thread here:
https://groups.google.com/d/msgid/qubes-users/g5tLp_yA2-jvKvSkZmQyCEJU50NS6aWb7m1Dmezb6d1y2loGsi-fh1pSgK5Jk2ovnwECfmVVAym11iFX7CbaAdGvX_iKZWOvKzzAF4eEcsE%3D%40protonmail.com
Related issues:
The text was updated successfully, but these errors were encountered: