Save State stuck at 0% since recent update (Arch Linux, Vbox 7.0.16r162802)

[hans.werner]

Problem Description

Since last update a week ago (or so) I can not save the win11 state (running -> save). However, I can save the state of all other machines (Linux, Win Server 2003, 2008, 12 etc). When I am saving it does not matter, e.g. during guest reboot or after running the guest a few min or anything else. It is just stuck at 0%. Logs and Debug are NOT showing any information (except SUSPENDING -> SUSPENDED -> SAVING) Cloning the machine, reverting to previous snapshots, making more disk space on host or things like that, and then trying to save the current state does not work either. Exporting and Reimporting does not work either.

uname -a

-> Linux 6.8.7-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Wed, 17 Apr 2024 x86_64 GNU/Linux

cat /etc/os*

-> arch/rolling

vbox --version

-> 7.0.16r162802

Tried solutions:

• Reset to old save state and restore (doesn't fix anything)
• Deleting old save state (doesn't fix anything)
• cleaned up disk space (122 GB available, 40 GB vdi sizes) && Resizing HDD/Medium (vboxmanage modifyhd/medium win11.vdi --resize <size in mb> -> does not help)
• Full Machine Export/Reimport (Appliance)
• Deleting all snapshots and nvram file (or moving them out of the folder and resetting the state -> no success)
• full device reboot
• full device update

Once the saving process is started, it is unstoppable, except by forcefully terminating it e.g. by running sudo kill -9 $(pgrep -i vbox && pgrep -i virtualbox)

BTW: Log file does not indicate anything special but it is attached.

Possible related Reddit:

​https://www.reddit.com/r/virtualbox/comments/1ce1tut/virtualbox_7016_fedora_40_hangs_at_0_when_taking/

/Edit:

Problem seems prevalent in version 7.0.18-1 (host-dkms, vbox and guest-utils)

/Edit2:

Affected Version(s): All versions above 7.0.14 (so .16 and .18)

Temp fix:

• downgrade

Workaround by Oracle:

a workaround is to configure the VM to use a USB 3.0 (xHCI) controller

UPDATE 08.07.2024 18:00BT: Temporary solution:

• https://www.virtualbox.org/download/testcase/VirtualBox-7.0.19-163782-Linux_amd64.run (Linux amd64 testbuild v. 7.0.19)

[hans.werner]

I did a pacman -Syuuu and general update and saw this:

• virtualbox-guest-iso-7.0.18-1
• virtualbox-host-dkms-7.0.18-1

I'll test it now, looks promising.

/EDIT: Never mind, it's still broken.

pacman -Q | grep virtualbox

• virtualbox 7.0.18-1
• virtualbox-guest-iso 7.0.18-1
• virtualbox-host-dkms 7.0.18-1

and

00:01:35.613975 PDMR3Suspend: 2 714 444 ns run time

00:01:35.613986 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'

00:01:35.613998 Console: Machine state changed to 'Paused'

00:01:36.538584 GUI: Request for close-action to save VM state.

00:01:36.538600 GUI: Saving VM state..

00:01:36.544810 Console: Machine state changed to 'Saving'

00:01:36.545387 Changing the VM state from 'SUSPENDED' to 'SAVING'

-- after that no log --

[hans.werner]

Interestingly, it works after killing it (see above) as long Win 11 is not loaded, see ss below. Maybe a bug in Guest Additions? Too much memory to save? IDK - Logs are telling NOTHING.

[hans.werner]

added hint regarding 7.0.18-1

[hans.werner]

I tried ​https://superuser.com/questions/623989/virtual-box-stuck-at-starting-virtual-machine-0 - no success. Also, I've played around with the settings (disable Network, other Media, CPU setttings, Mem settings, enabled/disabled AMD-V/intel-x etc

[hans.werner]

Tried full reinstall (paket purge, files purge etc) using pacman -R $(pacman -Q | grep -i virtualbox) and pacman -S virtualbox -> does NOT work.

[hans.werner]

I tried it with a fully fresh Tiny11 and it worked out of the box. I tried to figure out whether the shrinking and growing of disk sizes is a problem. Turns out: It's not a or the problem! There is no possibility to debug this, as there is no increase log level option (tried the wiki instructions for it) and there are no error messages in the log. So it seems without further instructions by Oracle we can not find out more about that.

Not sure if EFI plays a significant role in this.

[tpeterson]

I am seeing this problem also for a Windows XP guest on Windows 11 host. It started for me with 7.0.18 (updated from 7.0.14) and it persists in the test version 7.0.19.

[hans.werner]

With Tiny11 it worked until now, after I've installed everything (in the guest) and ran Windows Update (shortly before the whole machine got stuck when it was running!)

Now it's again stuck in the save state at 0%

• Might it be the missing KB5036980???
• OR is it the mapped network drive?

No clues in the logs

00:01:53.321212 GUI: UISession::sltAdditionsChange: GA state really changed, notifying listeners
00:01:53.321446 GUI: UIMachineViewNormal::adjustGuestScreenSize: Adjust guest-screen size if necessary
00:01:53.321528 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners
00:01:53.321534 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=1, Machine-state=6
00:01:53.321554 GUI: UISession::sltAdditionsChange: GA state change event came, notifying listeners
00:01:53.321559 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=1, Machine-state=6
00:02:12.170204 VMMDev: Guest Log: Shared Clipboard: WM_CLIPBOARDUPDATE failed with VERR_ACCESS_DENIED
00:02:39.408595 Console: Machine state changed to 'OnlineSnapshotting'
00:02:39.429124 Saving state of VM, reason 'Snapshot'
00:02:39.429176 Changing the VM state from 'RUNNING' to 'SUSPENDING'
00:02:39.433766 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:02:40.400456 PDMR3Suspend: 971 230 656 ns run time
00:02:40.400471 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
00:02:40.400781 Changing the VM state from 'SUSPENDED' to 'SAVING'
00:04:13.173796 SSM: Cancelled pending operation
00:06:25.454237 GUI: UIMachineView::sltPerformGuestResize: Omitting to send size-hint 1279x959 to guest-screen 0 because frame-buffer is already of the same size.
00:06:25.482005 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:06:26.916666 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:06:50.302280 GUI: UIMediumEnumerator: Medium-enumeration finished!
00:06:51.257090 VMMDevNotifyGuest: fAddEvents=0x80 ignored because enmVMState=18

Seemingly something changed in vbox making it overall really unstable! :O How did that even pass Software testing?

[hans.werner]

RonSMeyer1 gave me an important hint, thus saved my ass! Leading to a temp fix via downgrade!

Temp Fix (run as root):

/usr/bin/rcvboxdrv stop
kill -9 $(pgrep -i vbox && pgrep -i virtualbox);
wget "https://download.virtualbox.org/virtualbox/7.0.10/VirtualBox-7.0.10-158379-Linux_amd64.run" 
chmod u+x VirtualBox-7.0.10-158379-Linux_amd64.run
./VirtualBox-7.0.10-158379-Linux_amd64.run
usermod -a -G vboxusers hostuser

The old version can be found by using the https://www.virtualbox.org/wiki/Download_Old_Builds_7_0 page (just type "Vbox 7.0 old version" in ur fav search eninge). Then "all distributions" on your selected version in this case 7.0.10.

His post: ​https://forums.virtualbox.org/viewtopic.php?t=111508#p548057

I recommend to use 7.0.14, I tested it and it works. 7.0.16 has the "stuck in 0% saving state" bug!

[hans.werner]

Repost in 7.0.18 related bugs, as it's applying to all above 7.0.14! https://www.virtualbox.org/ticket/22071

[sideral]

This issue also occurs on OpenSUSE Leap 15.5, with both 7.0.16 and 7.0.18. Using the distro kernel 5.14.21-150500.55.59-default.

[paulson]

Thanks for the report. There is no need for separate tickets for different VirtualBox versions so I've closed #22071 as a duplicate of this ticket. It looks like a regression in the USB OHCI support was introduced in VirtualBox 7.0.16 which thus affects VMs configured to use either a USB 1.1 or USB 2.0 controller. Rather than downgrading a workaround is to configure the VM to use a USB 3.0 (xHCI) controller.

[sideral]

I can confirm that this workaround appears to work.

[hans.werner]

Replying to paulson:

Thanks for the report. There is no need for separate tickets

Thank you very much. I mean if nobody sees it and nobody replies to it after multiple days, except users panicking why their VMs are suddenly have stopped working and Oracle and the VBox Team is silent...

Also the SEO of the bug tracker is so crappy that I decided to post it separately, to link the affected versions and to make google index it properly, as well as giving users' the opportunity to see and read it, nobody looks into the old versions in a bug tracker under normal circumstances.

It looks like a regression in the USB OHCI support was introduced in VirtualBox 7.0.16 which thus affects VMs configured to use either a USB 1.1 or USB 2.0 controller.

What I do not get: why playing around with a feature that works fine in the first place ? Did anyone test this before rolling it out? I am sorry if I sound frustrated or angered but this is just the reality for me as an user.

Rather than downgrading a workaround is to configure the VM to use a USB 3.0 (xHCI) controller.

Does not that only work with your vbox extension pack ?

As far as I know, there is no option for USB 3.0 by default. I even tried playing around with the USB Controller (enabling, disabling, switching between the availabe options) in my first runs, which did not work. But maybe it works now idk.

Lessons learned: I will not trust new versions of vbox for now. They just break things and suck performance for such "features", causing unnecessary efforts.

A nice warning popup for the users' would be nice, when their machine can be possibly affected by this issue. Or a auto-fix deployed by VBox.

[hans.werner]

Replying to sideral:

I can confirm that this workaround appears to work.

The downgrade or the USB 3.0 switch?

[abruenin]

I had the same problem in my environment (Win11 host, Win10 guest). I can confirm, that setting USB Controller to USB 3.0 solved this for me

[paulson]

We've pushed a fix for this issue to the Testbuilds and would appreciate feedback on its efficacy from users who have run into this. You can download a 7.0.x build or development snapshot corresponding to your host OS to try it out. There is no need to update the Guest Additions or the Extension Pack (the latter should be the 7.0.18 one if you're on Windows host, older ones wouldn't work). If users could let us know here if the Testbuilds addresses the issue described here for VMs configured with an OHCI USB controller that would be much appreciated.

Also to answer the question above: xHCI/USB 3.0 support is included by default in VirtualBox 7.0 and thus the Extension Pack is no longer required for xHCI support.

[homersp]

Having the same issue here running 7.0.18-162988. Can confirm that switching to USB 3.0 controller seems to fix it. I also tried the latest test build (7.0.x revision 163377) with USB 2.0 controller, and it does seem to be fixed there as well.

[AaronC81]

Another +1 for the workaround mentioned here - VirtualBox 7.0.18 r162988, Windows 10 guest and host, with the guest originally using the USB 1.1 controller. Switching to USB 3.0 resolved the issue.

[jsible]

Replying to paulson:

We've pushed a fix for this issue to the Testbuilds and would appreciate feedback on its efficacy from users who have run into this. You can download a 7.0.x build or development snapshot corresponding to your host OS to try it out. There is no need to update the Guest Additions or the Extension Pack (the latter should be the 7.0.18 one if you're on Windows host, older ones wouldn't work). If users could let us know here if the Testbuilds addresses the issue described here for VMs configured with an OHCI USB controller that would be much appreciated.

Also to answer the question above: xHCI/USB 3.0 support is included by default in VirtualBox 7.0 and thus the Extension Pack is no longer required for xHCI support.

I ran into this on 7.0.18-162988, and I can confirm that upgrading to the 7.0.19-163426 testbuild fixed it for me, without having to change any settings.

[hans.werner]

I've js tested the 7.0.19-163426 test build, seems to work.