Opened 12 years ago
Closed 8 years ago
#11136 closed defect (fixed)
VirtualBox GUI should (optionally?) not die and get the VM into "aborted" state after errors with X11 server
| Reported by: | Jim Klimov | Owned by: | |
|---|---|---|---|
| Component: | GUI | Version: | VirtualBox 4.2.0 |
| Keywords: | Cc: | ||
| Guest type: | other | Host type: | Solaris |
Description
VirtualBox GUI for interactive VMs has a couple of problematic cases when it can not interact with the X server:
1) If the X server does not have some capabilities (or perhaps access permissions) needed by the VirtualBox GUI client, the VM becomes "aborted", even if it was being resumed from a "saved" state. For example, starting VBoxSDL on older X-servers can cause this.
I believe the VM should remain (or technically roll back to?) "saved" in this case so it can be properly started by other GUI clients or as a headless service - from the same state as it was saved into.
2) If the X server is closed, the VirtualBox GUI dies and aborts the VM. (Also some proper OS signals do that, like SIGTERM - but this I can work around by setting traps in a calling script.)
At the moment I am expanding http://vboxsvc.sf.net functionality to gracefully cover the proper lifecycle of "interactive" VMs, and this wrapper script can already issue "savestate" or "poweroff" commands (as instructed by user) to VirtualBox when the controlling terminal is closed - such as during an X server teardown. Unfortunately, the VirtualBox process dies by this time due to disconnection from X.
I propose adding a new option for the VirtualBox GUI programs to leave the VM in some running or paused state (possibly with a configurable timeout) suitable for further "savestate", "acpipowerbutton" or "poweroff" even if its GUI can not display anything anymore, so that it can be gracefully suspended or turned off by external logic such as my wrapper script.
I tested that I can "savestate" and "poweroff" a paused VM, however I can only issue "acpipowerbutton" to a running VM.
Essentially, it would suffice that with this option in place a VM with lost X connection should instantly become "headless" in effect, perhaps in the same state it was previously.
This is fixed now with the introduction of detached mode which makes it possible to attach/detach the GUI from a running VM process.