Opened 4 years ago
Last modified 3 years ago
#19508 new defect
VM (not) terminated with exit code 0
| Reported by: | sunrider | Owned by: | |
|---|---|---|---|
| Component: | other | Version: | VirtualBox 6.1.6 |
| Keywords: | Cc: | ||
| Guest type: | all | Host type: | Linux |
Description
Host: Ubuntu 18.04 kernel 4.15.0-96-generic #97-Ubuntu SMP Wed Apr 1 03:25:46 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Guest: any, predominantly experienced the problem with Windows guests
The problem is not willingly reproducible, but occurs on average in 1 of 20 (estimated) VM startups.
Problem description:
The VM starts correctly without any problems. While it is up and running for a considerable but variable time (experienced between 1 minute and 3 hours), the VBox Manager pops up a child window for the VM: 'Creating process for virtual machine "[machine name]" (GUI/Qt) ... (1/2)' with progress bar stuck at 0%. See attachment.
The VM continues to be operable as if nothing happens.
If nothing is done about the popup window: The VM is killed at some point in time further on without any notice. VM status in VBox Manager is "aborted" then.
If the guest operating system is shutdown ordinarily, the VM is closed and a VirtualBox Error popup window is opened "Failed to open a session for the virtual machine [machine name]." with detail "The virtual machine [machine name] has terminated unexpectedly during startup with exit code 0 (0x0)." and "Result Code: NS_ERROR_FAILURE (0x80004005)" and "Component: MachineWrap" and "Interface: Machine {[hex codes]}". See attachment.
VM log shows no obscurities. See attachment.
I suspect that the error appeared with kernel 4.15.0-96 or maybe already with kernel 4.15.0-91. The error was already present in VBox 6.1.4. I did not see it with 6.1.2 (I believe).
Attachments (3)
Change History (24)
by , 4 years ago
| Attachment: | Windows 7 64 Work1-2020-04-17-19-09-45.log added |
|---|
by , 4 years ago
| Attachment: | Screenshot from 2020-04-17 19-09-53.png added |
|---|
Second popup (VirtualBox - Error)
comment:1 by , 4 years ago
Additional information: As just experienced with an Ubuntu 18.04 guest:
If the first popup window is cancelled, i.e. first click on the red cross behind the progress bar, then close the window with the window close widget, the VBox Manager lists the VM as "Powered Off", although it is still up and running.
comment:2 by , 4 years ago
Additional Information 2: Continued from the last post:
If the still running VM is then closed with a regular operating system shutdown, the second popup window with the VirtualBox Error message appears. The VBox Manager then still lists the VM as "Powered Off", not as "Aborted".
comment:3 by , 4 years ago
Are you using Wayland or Xorg ?
I've been trying to see this error on Ubuntu 18.04.4, which is running a newer kernel and much more then the original 18.04:
Linux lserver 5.3.0-46-generic #38~18.04.1-Ubuntu SMP Tue Mar 31 04:17:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux VERSION="18.04.4 LTS (Bionic Beaver)"
And I just cannot see this behavior with Windows or Linux guests although I've been running this for days.
comment:4 by , 4 years ago
The host machine is running Xorg. Wayland is disabled as per
WaylandEnable=false
in /etc/gdm3/custom.conf
Recent observation is that the issue seems to be related to the up-time of the host and how many VMs have been started and stopped before. Meaning:
a) The longer the host has been up and running, the more likely it is to see the problem.
b) The more machines have been started and stopped before, the more likely it is to see the problem.
Although, I could not identify a stringent pattern. But I recently faced a situation where all VM starts produced the problem and the first pop-up window appeared just about 5-10 seconds after a VM start.
It is not a memory problem on the host. The host machine has 64GB RAM and even with several VMs running I never see less than 10GB of free RAM on the host.
comment:5 by , 4 years ago
please, how long running is enough and how many concurrent running VMs or VM starts you talk about. I have a 64GB test system as well, the host has been up for days and the count of concurrent VMs was 3 while the Windows VM had always been running with VM starts of approx. 20 during that time. Thanks
comment:6 by , 4 years ago
I am constantly running 4-6 VMs (Windows and Linux guests) concurrently. These take 16-20GB of RAM. When I start these serially, immediately after a reboot of the host machine, the problem does not show up for these.
I cannot give an estimate, after what time interval (after the host machine reboot) the problem is surfacing. With currently enforced home-office conditions, the host machine is running for many days without reboot.
The incident I described above, where all VM starts would produce the problem, occurred about two weeks ago: I have around 20 test VMs (Windows and Linux) that I started in series to apply the monthly OS updates and the 6.1.6 guest additions update. In that situation all the VM starts showed the problem.
I forgot to mention: When the first pop-up window of the error is closed, the VBox Manager window freezes until the related VM is stopped and the error's second pop-up window appeared and is closed. Only after that the VBox Manager window can be used again. 'Freeze' means that the VBox Manager window content does not react to mouse clicks. The window manager (or whatever component is responsible) notices that after a while and offers a forced quit, while graying out the window content. But there is no need to force it. It will behave normally again after the related VM is stopped.
comment:7 by , 4 years ago
More observations:
When the actual error was occurring, I did the following:
a) Shutdown all running VMs. Then start any VM => error shows up again.
b) Shutdown all running VMs. Close VBox Manager. Start VBox Manager again. Start any VM => error is gone
So stopping all VBox foreground processes helps. I could not test if closing just the VBox Manager window and restarting it (while VMs are kept running) would help.
Also to be noted: I have not seen the error with kernel
4.15.0-99-generic #100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
on the host machine yet. But I have not run the host machine for >24h at any time up to now. I will post another comment here when I see the problem on this kernel. Up to now it seems that the problem is gone with this kernel update.
comment:8 by , 4 years ago
Update: I have experienced the error now with host machine kernel
4.15.0-99-generic #100-Ubuntu SMP Wed Apr 22 20:32:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
after a host uptime of approximately 2 days and 22 hours.
follow-up: 11 comment:9 by , 4 years ago
After the latest occurrence of the error, I tested the following:
- Shut down the VM that was just started and "caused" the error to appear.
- Close the second error popup window from the VBox Manager, so that the VBox Manager window is responsive again.
- Close the VBox Manager.
- Restart the VBox Manager.
- Restart the same VM that "caused" the error.
Now, after 11 minutes uptime of the VM, no error is showing. (Before, it showed up within approximately 1 minute after starting the VM.)
So, it seems that a restart of the VBox Manager "solves" the problem. However, when the error shows up, the VM "causing" the error must be shut down first, because the VBox Manager window becomes unresponsive. I have not tested (and are not planning to test) whether killing the VBox Manager process would "solve" the problem.
comment:10 by , 4 years ago
I think the Component category of this ticket should now be changed to "VM control". I cannot do this myself.
comment:11 by , 4 years ago
Replying to sunrider:
After the latest occurrence of the error, I tested the following:
- Shut down the VM that was just started and "caused" the error to appear.
- Close the second error popup window from the VBox Manager, so that the VBox Manager window is responsive again.
- Close the VBox Manager.
- Restart the VBox Manager.
- Restart the same VM that "caused" the error.
It should be noted here that during the above steps multiple other VMs were running. These VMs did not cause the error to appear. They were already running for a longer time - typically started directly after the host machine boot.
Further observation in relation to the above:
After the VBox Manager has been restarted, the VMs that were kept running during the whole time, are reported as powered off by the VBox Manager. This is probably not the intended behavior. (But I cannot tell for sure, because I normally do not close the VBox Manager window. So I cannot tell what the behavior was before the problem started to appear.)
comment:14 by , 4 years ago
I am not sure whether or not the scenario described below is related to the original error or not. Maybe a separate ticket needs to be opened - maybe not. Perhaps someone can indicate that?
If the VBox Manager Window is closed while one or more VMs are running and then the VBox Manager is started again, the still running VMs are shown in the VBox Manager window as 'Powered Off'. Is this a bug or not?
The problem is: The VBox Manager then allows a VM to be started again, although it is still/already running. This of course causes data corruption on the virtual disks. I think that it should not be allowed to start a VM that is already running. Is there some mechanism implemented that is supposed to suppress such an action? If yes, why does it not work in this case - and is this then maybe related to the original error?
follow-up: 17 comment:16 by , 4 years ago
After further observation, I can refine the previous statements about the freezing of the VBox Manager window:
When a VM is started that will trigger the error, the VBox Manager window freezes immediately after the start button for the VM is clicked.
(Previously I wrote that the VBox Manager window freezes when the first error popup appears. But this is incorrect. It freezes immediately. However, this may go unnoticed, because the window of the starting VM will receive the window manager focus.)
comment:17 by , 4 years ago
Replying to sunrider:
When a VM is started that will trigger the error, the VBox Manager window freezes immediately after the start button for the VM is clicked.
Sorry, I need to correct this again. After further observation, it seems that it is indefinite whether the VBox Manager window will freeze immediately or will freeze when the first error message popup window appears (and then stay frozen when this popup window is closed). I can confirm to have observed both cases now. I could not determine (yet) under which side conditions one of the alternatives occurs.
Sample log file