Another guest stuck in VBOX_E_INVALID_VM_STATE

Discussions related to using VirtualBox on Linux hosts.
Post Reply
rbarak
Posts: 52
Joined: 25. Sep 2018, 20:43

Another guest stuck in VBOX_E_INVALID_VM_STATE

Post by rbarak »

I had another CentOS 7 guest that became unresponsive, and it's /home file system was mounted RO by the OS.
Further investigation revealed that it was in VBOX_E_INVALID_VM_STATE.
So, I brought it back to normal operation with VBoxManage startvm "guest-name" --type emergencystop.
I'm attaching the relevant log (see 00:08:34.497610 therein).

Is it possible to determine why the guest got into the VBOX_E_INVALID_VM_STATE?
Attachments
VBox.log.2.tar.gz
VBox.log.2
(29.52 KiB) Downloaded 10 times
mpack
Site Moderator
Posts: 39134
Joined: 4. Sep 2008, 17:09
Primary OS: MS Windows 10
VBox Version: PUEL
Guest OSses: Mostly XP

Re: Another guest stuck in VBOX_E_INVALID_VM_STATE

Post by mpack »

I notice that the VM is located on a raid array. Is that over a network connection?
00:08:15.501474 PDMR3Suspend: 24 963 185 ns run time
00:08:15.501491 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
00:08:15.501500 Console: Machine state changed to 'Paused'
00:08:23.052784 VMMDevNotifyGuest: fAddEvents=0x2 ignored because enmVMState=15
00:08:34.497567 GUI: Request to close active machine-window.
00:08:34.497610 ERROR [COM]: aRC=VBOX_E_INVALID_VM_STATE (0x80bb0002) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={Invalid machine state Paused when checking if the guest entered the ACPI mode)}, preserve=false aResultDetail=0
00:08:44.516945 GUI: Request for close-action to save VM state.
00:08:44.516960 GUI: Passing request to save VM state from machine-logic to UI session.
00:08:44.517156 Console: Machine state changed to 'Saving'
00:08:44.520949 Changing the VM state from 'SUSPENDED' to 'SAVING'
That request to close the machine window, was that you? Was it because of the slow execution?

Running a VM over a network connection may be slower, but I don't know how much slower. This is not the same as executing a VM in its own processor in the cloud. In your scenario there needs to be constant glitch free comms between control PC and VM drives in order to prevent the latter from being corrupted. Hopefully you aren't trying to share drives either with live VMs.

Other things that will make it slower and more fragile are: only 1 core allocated, and only 16MB of graphics RAM (increase to 2 and 128MB respectively).

Since you located the VM to a raid drive I expected you must have chosen a huge VM drive, but my calculations show it's only about 50GB. Can you really not afford to run that locally?
rbarak
Posts: 52
Joined: 25. Sep 2018, 20:43

Re: Another guest stuck in VBOX_E_INVALID_VM_STATE

Post by rbarak »

mpack wrote:I notice that the VM is located on a raid array. Is that over a network connection?
No, the VirtualBox uses a RAID10 for its storage, but the only network connection is me connecting to the VM guest over ssh (with X11 forwarding enabled).
00:08:15.501474 PDMR3Suspend: 24 963 185 ns run time
00:08:15.501491 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
00:08:15.501500 Console: Machine state changed to 'Paused'
00:08:23.052784 VMMDevNotifyGuest: fAddEvents=0x2 ignored because enmVMState=15
00:08:34.497567 GUI: Request to close active machine-window.
00:08:34.497610 ERROR [COM]: aRC=VBOX_E_INVALID_VM_STATE (0x80bb0002) aIID={872da645-4a9b-1727-bee2-5585105b9eed} aComponent={ConsoleWrap} aText={Invalid machine state Paused when checking if the guest entered the ACPI mode)}, preserve=false aResultDetail=0
00:08:44.516945 GUI: Request for close-action to save VM state.
00:08:44.516960 GUI: Passing request to save VM state from machine-logic to UI session.
00:08:44.517156 Console: Machine state changed to 'Saving'
00:08:44.520949 Changing the VM state from 'SUSPENDED' to 'SAVING'
mpack wrote:That request to close the machine window, was that you?
Yes.
mpack wrote:Was it because of the slow execution?
It was because of complete unresponsiveness.
mpack wrote:Running a VM over a network connection may be slower, but I don't know how much slower. This is not the same as executing a VM in its own processor in the cloud. In your scenario there needs to be constant glitch free comms between control PC and VM drives in order to prevent the latter from being corrupted. Hopefully you aren't trying to share drives either with live VMs.
I haven't.
mpack wrote:Other things that will make it slower and more fragile are: only 1 core allocated, and only 16MB of graphics RAM (increase to 2 and 128MB respectively).
Okay, thanks for the suggestions: I'll implement them.
mpack wrote:Since you located the VM to a raid drive I expected you must have chosen a huge VM drive, but my calculations show it's only about 50GB. Can you really not afford to run that locally?
The VM guest is run off of a VirtualBox dedicated server, which has a few VM guests running/stopped.
Post Reply