Ticket #8869 (closed defect: duplicate)

Opened 3 years ago

Last modified 17 months ago

shared folder cannot be accessed after resume from hibernate on different host

Reported by: hgkamath Owned by:
Priority: major Component: other
Version: VirtualBox 4.0.6 Keywords:
Cc: Guest type: Linux
Host type: Windows

Description (last modified by frank) (diff)

I have a machine at home (win7 64bit), and office (winxp 32bit) both running virtualbox-4.0.6 r71416 I have an external USB drive on which I had the fedora-15 x86_64, image, drive letter T:. The image also resides on T: I have configured a machine-folder which is accessible as /media/sf_T_DRIVE When I leave home, I hibernate the vmachine, and resume at work. The hibernate works, and machine can resume and access network etc. However the drive mount exists, but contents are not accessible.

Attempts to remount:

It is possible to stop processes using the drive (with fuser, kill), and unmount the drive. but remounting has not succeeded. Even on attempt to add/remove/reconfigure machine-folder.

It is possible to rmmod vboxsf, but after doing so, trying to reinit the vboxsf using modprobe will complain that it is not possible to insmod the vboxsf again. It is possible to rmmod vboxvideo, but not possible to rmmod vboxguest, (if it matters).

At this point no option but to reboot, if sf_T_DRIVE is to be regained. defeating the whole point of hibernate.

I will get more logs next time, but this is fairly reproducible.

I will capture logs when this happens again.


cometVM-2011-05-12-23-05-18.log Download (58.0 KB) - added by hgkamath 3 years ago.
Personal-2011-05-19-00-08-05.log Download (67.7 KB) - added by lbesteban 3 years ago.
Log file for the failed resume

Change History

comment:1 Changed 3 years ago by hgkamath

Same thing happens on one machine (32bit winxp), hibernate-resume

removed attribute 'automount '

I have a line in /etc/fstab to mount vbox shared folder T_DRIVE to /mnt/T_DRIVE . The mount works. but same problem after hibernate-resume.

Changed 3 years ago by hgkamath


comment:2 Changed 3 years ago by hgkamath

Logfile cometVM-2011-05-12-23-05-18.log attached

The below was repeated several times in the log 00:00:28.897 Guest Log: VbglR0HGCMInternalCall: vbglR0HGCMInternalDoCall failed. rc=-37 00:00:28.897 Guest Log: VBoxGuestCommonIOCtl: HGCM_CALL: 64 Failed. rc=-37.

comment:3 Changed 3 years ago by hgkamath

[root@comet ~]# ls /mnt/T_DRIVE
ls: cannot access /mnt/T_DRIVE: Protocol error

[root@comet ~]# lsmod | egrep -i vbox
vboxvideo 1932 1
drm 187648 2 vboxvideo
vboxsf 30902 1
vboxguest 167002 10 vboxsf

dmesg | vim -
[ 2602.504160] usb 2-1: reset full speed USB device using ohci_hcd and address 2
[ 2602.718013] PM: restore of devices complete after 705.853 msecs
[ 2602.718013] PM: Image restored successfully.
[ 2602.718013] Restarting tasks ... VbglR0HGCMInternalCall: vbglR0HGCMInternalDoCall failed. rc=-37
has several
[ 2602.773085] VbglR0HGCMInternalCall: vbglR0HGCMInternalDoCall failed. rc=-37
[ 2602.773085] VBoxGuestCommonIOCtl: HGCM_CALL: 64 Failed. rc=-37.

comment:4 Changed 3 years ago by hgkamath

The release of virtualbox-4.0.8 complicates some matters. virtualbox-4.0.8 fixes issues with fedora-15 so the 3D-accelerated mutter desktop works.

The mutter interface does not yet have hibernate option. While it is possible to hibernate with the 'pm-hibernate' command, the resume does not work. At present this is a known issue with the fedora-15 mutter release.

The hibernate needs to be tested by falling back to the gnome-panel. Need to figure out how to force the gnome-panel mode.

comment:5 Changed 3 years ago by hgkamath

Also compiled and installed the vbox 4.0.8 guest additions

To switch to gnome-panel fallback mode Click on the user menu on the top right, Select System Settings -> System Info -> Graphics and toggle the Forced Fallback Mode switch to on.

confirming that 4.0.8 still has issue

comment:6 Changed 3 years ago by lbesteban

This also happens in 4.0.8 version.

When resuming a guest with saved state if the Host is sharing USB folders to the guest machine and the USB is disconnected the guest machine fails to resume.

Changed 3 years ago by lbesteban

Log file for the failed resume

comment:7 Changed 3 years ago by hgkamath

Workaround: Copy the entire VM directory to the drive. To achieve same effect, save VM state and resume from VirtualBox Menu/Manager This is equivalent to hibernating/resume from within the VM. Shared folders, mounts and open files on them are preserved.

Need to check if this machine state saving/resuming is portable across machines.

comment:8 Changed 3 years ago by hgkamath

VM state does save/resume between Win7-64 (Home) and WinXp-32(Office) The VMstate snapshot is also saved to the USB drive as well.

I theorize, as a novice user and not developer, why shared folder does not work on hibernate/resume. The host vboxsf module communicates to host to open folder/file on host. The Host maintains state as long as communication with the vboxsf guest module is present. The guest OS Linux-64bit-fedora maintains state only wrt to the vboxsf filesystem driver. Hibernating causes the vboxsf module to go down. The on host components of shared-folder support, lose state. When machine resumes, the linux guest thinks files/seek-pointer are still open and active, but that is nolonger the case on the outside host. Unable to initialize maybe vboxsf results in protocol error. Saving VM state works because perhaps all these information is saved in the snapshot folder and restored on resuming. One way to make hibernate work, is to let the guest vboxsf save host machine state information and use that to reinitialize file open and seek states of the outside-host on initializing.

It maybe argued that the save machine state dispels with the need to hibernate.

comment:9 Changed 3 years ago by hgkamath

I tried the following
I found that the same VM works across Linux-AMD/Windows-Intel
I had to however change the shared folder path

<SharedFolder name="T_DRIVE" hostPath="T:\" writable="true" autoMount="false"/>


<SharedFolder name="T_DRIVE" hostPath="/media/mydrv01" writable="true" autoMount="false"/>


side notes:
1) glxgears caused Linux Vbox to crash.
2) The Vbox on linux was 4.0.4 from the fedora yum repo, the that on the Win7 was 4.0.8

I saved the state on the Linux machine.
On returning to windows I had to undo changes and attempt to resume
I got the following error :
Failed to open a session for virtual machine qwertyVM
cpum#1: X86_CPUID_AMD_FEATURE_ECX_CR8L is not supported by the host but has already been exposed to the guest. [ver 12: pass=final]
Result Code: E_FAIL (0x80004005)
Component: Console
Interface: IConsole {515e8e8d-f932-4d8e-9f32-79a52aead882}

*) find a way to make the VBOX state be host-machine-architecture and host-OS transparent. Maybe One way to accomplish this is to determine the minimum subset of Host Hardware information like CPUID and flags to expose to the guest.

comment:10 Changed 3 years ago by hgkamath

notes: glxgears does not crash in 4.0.12 Have machines with same hardware at home (win7) and office(winxp).

comment:11 Changed 17 months ago by frank

  • Status changed from new to closed
  • Resolution set to duplicate
  • Description modified (diff)

This is actually the same problem as #11147. Marking this one as duplicate (sorry, this one is older).

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use