Virtualbox VM gets aborted if the X dies

devsk · Post by **devsk** » 6. Aug 2008, 22:22

Hi,

First post here.

If X dies unexpectedly, why does the VM die with it? Technically, it can still keep running. This is major loss because it forces fsck/chkdsk on next boot of the guest.

I am using the binary distribution of virtualbox-1.6.2.

Post by **stefan.becker** » 6. Aug 2008, 23:28

Why does word crash, if Windows crash?

Probably because its a windows application?!

You can start Guests with the Hosts using CLI Tools and connect to Guest via RDP/VNC. Then you dont have the Problem.

devsk · Post by **devsk** » 7. Aug 2008, 00:00

The window which has the VM running in it, will close because X that was serving that window died unexpectedly. The VM inside that window aborts and needs a restart.

The VM itself should not be windows application. only the display of the VM should be. May be they are tied together for a reason, but I don't understand that part.

Post by **TerryE** » 7. Aug 2008, 01:24

devsk, have a look the Forum Posting Guide for help in framing Qs. Also use postreply to reply to a post and quote to pick up a specific quote to replay against. There's no point in quoting the entire post. It just makes it difficult for others to follow.

Kitsune · Post by **Kitsune** » 7. Aug 2008, 19:58

I believe devsk is asking is for the the VirtualBox window in X to not be in the same process as the actual VM thats running, to simply be a front end (kinda like the way stefan mentioned).

I think a better solution to the problem would probably be to have VirtualBox attempt to save the guests' state if it loses its connection to the X server. Assuming the X server doesn't explode too badly, this should be possible.

Post by **Sasquatch** » 7. Aug 2008, 20:58

Well, the problem is is that X is the 'parent' of the VB process. If the 'parent' dies, so does it's 'children', else they become 'zombies'. Just like what Stefan said, the starting process is tied to the X process. You can run VB from a command line by switching to a virtual terminal (TTY) so it runs outside X, then connect to the VM using RDP, VNC or any other remote control software.

For the explanation of 'parents', 'children' and 'zombies', please see:
http://en.wikipedia.org/wiki/Zombie_process
http://en.wikipedia.org/wiki/Parent_process
http://en.wikipedia.org/wiki/Child_process

devsk · Post by **devsk** » 8. Aug 2008, 02:19

Well, the problem is is that X is the 'parent' of the VB process.

you are kidding right? A parent is the process which does 'fork()' to spawn a child process. X doesn't do a spawn of VB processes. Its the shell running under xterm/konsole/g-t that does it. And the rest of the processes are spawned (whether as detached daemons e.g svc process, or as direct children) by that process.

In this case VB processes are more of a client to the X server. And clients can detect server death. VB code can detect that its connection with X has terminated and it needs to save the VM state before dying. There are examples of many processes which exit cleanly after their connection with X abruptly dies. Of course, if the code has hard coded throwing of a dialog saying "saving state", that's going to fall flat as well.

See, I am not that noob....

Starting VM from CLI outside of X and then doing RDP into it, is a good workaround but not the solution.

Another option is that VB can do what vmware-server does. Decouple the console and the VM completely.

Post by **TerryE** » 8. Aug 2008, 03:14

OK, where stdout is going? Or did you do a

nohup VBoxHeadless -s yourVM -p port 1>someRDPlog 2>&1 &

No your stdout is almost certainly connected to a gd served virtual device. You say

"VB code can detect that its connection with X has terminated and it needs to save the VM state before dying"

whilst what you should say is that "the VB code could potentially include detection of its stdout/stderr connection type and could establish an exit handler to detect if this device terminates and save the VM state before dying". This an enhancement request, because VB doesn't do that today. Write it up, register it with the Bugtrack system, and file it.

Look, something is pretty wrong with your system if X is crashing. This isn't a sort of high demand request. If you don't want this to crater your VM then run as I suggest above and connect to it with RDP. That way you can still shut it down cleanly through VBoxManage.