Some situations make VirtualBox think a session on a powered-off vm is being openned/closed and a full system restart is required

[gbuonfiglio]

I was creating a new vm using the CLI (VBoxManage) instead of the GUI (VirtualBox) and I mistyped the "ostype". VBoxManage hanged and I hit CTRL-C to stop it. When I try to issue anything for this new vm I got:

[!] FAILED calling virtualBox->OpenSession(session, uuid) at line 3206[[BR]] [!] Primary RC = 0x80070005
[!] Full error info present: true , basic error info present: true
[!] Result Code = 0x80070005
[!] Text = A session for the machine 'w2kad1' is currently open (or being closed)
[!] Component = Machine, Interface: IMachine, {0332de0e-ce75-461f-8c6f-0fa42616404a}
[!] Callee = IVirtualBox, {d1a2295c-d257-4a4c-a9a6-843d87db6f45}

This is really annoying because when this happens I need to shutdown every vm and kill VBoxSVC. If I kill VBoxSVC the vms continue to work but I cannot manage them.

[Achim Hasenmueller]

Please paste the full command line that lead to the hang (i.e. the one with the mistyped ostype).

[gbuonfiglio]

The command was:

VBoxManage modifyvm w2kad1 -ostype "Windows 2000" -memory 200MB -acpi on -boot1 dvd -boot2 disk -hda w2kad1.vdi -dvd d9753baf-e8b4-4427-0ca4-653af89d5317 -nic1 hostif -cableconnected1 on -hostifdev1 tap6 -audio none -clipboard bidirectional -vrdp on -vrdpport 45156 -vrdpauthtype null -usb off

The output was:

VirtualBox Command Line Management Interface Version 1.4.0
(C) 2005-2007 innotek GmbH
All rights reserved.

[!] FAILED calling virtualBox->GetGuestOSType(ostype, guestOSType.asOutParam()) at line 3221[[BR]] [!] Primary RC = 0x80070057
[!] Full error info present: true , basic error info present: true
[!] Result Code = 0x80070057
[!] Text = 'Windows 2000' is not a valid Guest OS type
[!] Component = VirtualBox, Interface: IVirtualBox, {d1a2295c-d257-4a4c-a9a6-843d87db6f45}
[!] Callee = IVirtualBox, {d1a2295c-d257-4a4c-a9a6-843d87db6f45}
error: Invalid guest OS type 'Windows 2000'

Then it hangs... But.... I've seen other situations where it happens but I did not take any notes on that. It seens like after some failure VBoxSVC looses the vm status and it never recovers from this, requiring a restart of it and its managed vms. So I would say this status management needs some reinforcement as a simple failure in VBoxManage results in loosing the ability to use that vm.

[gbuonfiglio]

Another situation is shutdown a windows 2000 vm. After it closes you cannot start it anymore with the same error reported in this ticket.

[Frank Mehnert]

I think this has something todo with a bug we fixed recently (crashes of VBoxSVC on shutdown). If possible please retry with the current svn or retry with VirtualBox 1.4.2 when released.

[mattcornell]

I usually screw up the state of the machine by going to start it up without the -vrdp option and then trying to ctrl-c out of it in time. You can find the defunct VirtualBox process. Caution this is a heavy hammer and is presented only as an alternative to the system restart described in the bug title - there's almost always a way to avoid a system restart in linux.

 ps -ef | grep Virtu
machines  3761     1  0 Nov19 ?        00:00:01 /opt/VirtualBox-1.4.0/VBoxXPCOMIPCD
machines  3765     1  0 Nov19 ?        00:00:05 /opt/VirtualBox-1.4.0/VBoxSVC --automate
machines 19548  3765  0 10:32 ?        00:00:00 [VirtualBox] <defunct>
machines@mox:~/.VirtualBox/Machines/propt$ kill -9 3765
machines@mox:~/.VirtualBox/Machines/propt$ ps -ef | grep Virtu
machines  3761     1  0 Nov19 ?        00:00:01 /opt/VirtualBox-1.4.0/VBoxXPCOMIPCD
machines 24568 17657  0 10:55 pts/5    00:00:00 grep Virtu
machines@mox:~/.VirtualBox/Machines/propt$

[Frank Mehnert]

This might be fixed in the SVN. If you are able to compile the SVN version, please check if the problem is gone.

[Frank Mehnert]

Please reopen if still relevant.

[James Lucas]

I am reopening this because it still is relevant. Seems to be a locking issue by VBoxSVC that doesn't recover/ clear session+locks if one of the VBoxManage or VBoxHeadless processes crash.

I am seeing this happen often on a Virtual Box 1.6.4 installation on RHEL5u2. Sometime a VBoxManage process hangs (usually a modifyvm call) and needs to be kill with a kill (or CTRL-C), however I have seen it if a machine aborts and the VBoxHeadless process is left running (which needs to be killed)

After this the VM can't be powered on or modified because it has an Open Session. I can confirm that there are no running processes that are using this vm. I can see that VBoxSVC has a lock on the vm files.

The only method to get back and running is to shut down all other vms on the host and wait for VBoxSVC to shutdown. Then the machine can be started again. Is there any way to recover from these open session issues. It is painful that if one vm has a issue then all others must be shutdown before you can recover from the issue.

Nothing is logged in the VBox.log files (noticed this when I had a issue when creating a new VM. Couldn't power it on because a modifyvm got stuck. Kill process and tried to start but no go.

[!] FAILED calling virtualBox->OpenSession(session, uuid) at line 4339!
[!] Primary RC  = E_ACCESSDENIED (0x80070005) - Access denied
[!] Full error info present: true , basic error info present: true 
[!] Result Code = E_ACCESSDENIED (0x80070005) - Access denied
[!] Text        = A session for the machine '1016' is currently open (or being closed)
[!] Component   = Machine, Interface: IMachine, {f95c0793-7737-49a1-85d9-6da81097173b}
[!] Callee      = IVirtualBox, {2d3b9ea7-25f5-4f07-a8e1-7dd7e0dcf667}

[noname42]

I can confirm that this happens to me a lot when just testing 2.0.4 as well. Without notice VBoxManage hangs, or a server running using VBoxHeadless ends up in the aborted-state and is inaccessible.

The machines are in all cases still running and are reachable via SSH.

This is a 2.0.4-installation on Ubuntu Intrepid Server 64bit, and it seems to happen regardless of running 64bit guests or 32bit guests and regardless of hwvirtex being enabled or not.

It's pretty much making it impossible to actually use VBox in any sensible and reliable setup as it seems right now.

Everything matches the descriptions above, where SVC simply doesn't see the VM anymore and everything has to be restarted (or at least savestate+resume for the still available VMs) for it to function again.

[James Lucas]

This bug is still present in 2.0.6

[ein]

This bug is present in OSE and not-OSE versions I've testing - from 1.6.2 to 2.0.6 (I don't test newer versions yet). In my situation I have Windows XP SP3 on VM. My VM start/stop script:

#!/bin/sh # # /etc/rc.d/rc.vbox-m01 # # Start/stop vbox virtual machine # Last modified: 03.01.09

case "$1" in

'start' )

echo "Start M-01 VM." VBoxHeadless -s WindowsXPpro.ac04.m-01 & echo "Virtual Machine M-01 Started."

;;

'stop')

echo "Stop M01 VM." /opt/vbox/VBoxManage -nologo controlvm WindowsXPpro.ac04.m-01 savestate echo "Virtual Machine M-01 Stopped." ;;

'state')

VBoxManage showvminfo WindowsXPpro.ac04.m-01 ;;

*)

echo "usage $0 start|stop|state" ;;

esac

After some time when I want to stop VM (suspend like in the above script) I have got this error:

[!] FAILED calling virtualBox->OpenExistingSession (session, uuid) at line 5710[[BR]] [!] Primary RC = E_ACCESSDENIED (0x80070005) - Access denied
[!] Full error info present: true , basic error info present: true
[!] Result Code = E_ACCESSDENIED (0x80070005) - Access denied
[!] Text = The machine 'WindowsXPpro.ac04.m-01' does not have an open session
[!] Component = Machine, Interface: IMachine, {1e509de4-d96c-4f44-8b94-860194f710ac}
[!] Callee = IVirtualBox, {557a07bc-e6ae-4520-a361-4a8493199137}

I can only kill all VBox processes (VBoxSVC, VBoxHeadless and XPCOMIPCD) and after that VM start just fine. I noticed this hapen after 5-10 uptime days and the VM guest system is still runing. After next few days 4-5 guest VM hangs and only kill all vbox processes helps. The logs are also clear.

Host: OS Slacware 12.1, Linux 2.6.24.5-smp #2 SMP Wed Apr 30 13:41:38 CDT 2008 i686 AMD Athlon(tm) XP 2400+ AuthenticAMD GNU/Linux

I going to test 2.1.2 or 2.1.4 and I'll send the results.

Best regards. e.

[sunlover]

ein, please test with 2.1.4. It includes a number of related fixes.

[ein]

2.1.2 results (18h uptime), after comamnd:

/opt/vbox/VBoxManage -nologo controlvm WindowsXPpro.ac04.m-01 savestate

[!] FAILED calling a->virtualBox->OpenExistingSession (a->session, uuid) at line 2784!
[!] Primary RC  = VBOX_E_INVALID_SESSION_STATE (0x80BB000B) - Current session state prohibits operation
[!] Full error info present: true , basic error info present: true
[!] Result Code = VBOX_E_INVALID_SESSION_STATE (0x80BB000B) - Current session state prohibits operation
[!] Text        = The machine 'WindowsXPpro.ac04.m-01' does not have an open session
[!] Component   = Machine, Interface: IMachine, {ea6fb7ea-1993-4642-b113-f29eb39e0df0}
[!] Callee      = IVirtualBox, {339abca2-f47a-4302-87f5-7bc324e6bbde}

I'm going to install and test 2.1.4 in a few next days.

Best regards. e.

[ein]

I forgot to mention that I have VBox on 2 PCs so this exclude hardware problem. On both the problem existed with older versions of VirtualBox than 2.1.4.

I've testing VBox 2.1.4 and after 4 days of uptime the problem seems to be resolved but I'll still testing.

PS. I have VBox with Windows XP SP3 on guest and it stops after stopping system or restarting (windows action for example from start menu). Do somebody know this issue? I had more details if You need.

Best regards, e.

[ein]

Resolved.

[harmscon]

I just had this problem on a Debian etch system with VirtualBox 2.1.4. It's a standard system. I start the VM using:

$ nohup VBoxHeadless -s wiki-dev -v off &

From within the VM, I shut it down with 'init 0'. Once the system had shutdown, VirtualBox interface showed the system as Powered Off and session closing. VBoxManage controlvm wiki-dev poweroff returned the error shown above. I had to kill all VBox processes to restore sanity.

I haven't been able to reproduce the problem during some testing today but I wouldn't call this issue resolved.

[hajma]

CCing myself (why don't you guys have the voting feature implemented?)

[sorin]

I have the same issue with VBOX_E_INVALID_SESSION_STATE on VirtualBox 2.2.2 running on Linux (fc9) +1 for this and another +1 for adding voting instead adding not-so-useful comments.

[Frank Mehnert]

There were some related fixes in later releases (not sure which exact release). Could you check if the problem persists with VBox 3.0.2?

[Frank Mehnert]

No response, closing.