Hard freeze on Centos Host system with Guest using Shared Folders

[jim.rather]

Running Centos 7.7 Host with a Windows 10 Guest using a Shared Folder. I have experienced issues in the past with Shared Folders, but in the past it only seemed to affect the Guest systems. This issue is hard to troubleshoot since the Host system freezes, I can only resolve it by unplugging the power. I have tried using the SysRq keys to no avail. In troubleshooting the issue, I have stopped all other host applications except VirtualBox and disconnected the Shared folder. For a week, I did not experience any freezing of the host the system. If I connect the Shared Folder I will randomly experience a hard freeze in a couple of hours or a couple of days.

The host system has 16GB RAM and 4 cores. I am using 4GB and 2 cores for my Windows 10 1909 guest.

I do not know how to troubleshoot this any further since the Host system hard freezes, I do not get any indications of problems in any of the host logs. It most likely freezes before documenting the problem. I welcome any tests or settings which you want me to implement in order to determine the problem or fixes.

[Socratis]

Replying to jim.rather:

I do not get any indications of problems in any of the host logs.

How about if we take a look at them as well? Actually, you were supposed to provide a VBox.log when you filed the bug. ;)

Are you doing anything "funky" on the Guest/Host when the Host freezes? For example a process with high I/O, an app that requires open files on the Host (or other special features) that may not be available in the Shared Folders implementation?

[jim.rather]

I am not doing anything funky. Both Host/Guest systems are pretty much idle. I will post my VBox.log the next time the Host freezes.

[jim.rather]

System froze last night. As I have said in previous messages this only occurs when the shared folder is connected in the Windows guest. As promised, attached the VBox.log,

[Socratis]

I "hate" to analyze VBox.logs in the Bugtracker and not in the forums, but let's give it a shot:

00:00:09.311138 File system of '/home/jrather/VirtualBox VMs/win10/win10.vmdk' is fuse

Why a .vmdk and not the suggested default .vdi? Was the VM imported maybe?

00:00:09.414161   NumCPUs           <integer> = 0x0000000000000001 (1)
00:00:12.992480 CPUM: Physical host cores: 4

Your Host has 4 cores, you can certainly afford a 2nd CPU for your Guest, your Guest is going to be running much smoother.

00:00:09.414594 [/Devices/hpet/0/Config/] (level 4)
00:00:09.414597   ICH9 <integer> = 0x0000000000000001 (1)

Any particular reason why you decided to override the template defaults, and go with an unsupported, experimental, OSX-guests-only option? Please change it back to the default PIIX3. Do not change the defaults unless you know what you're getting into.

00:00:12.995471     Host path '/media/data', map name 'data', writable, automount=false, automntpnt=, create_symlinks=false, missing=false

And we're coming to the heart of the problem. Is 'data' an external hard drive by any chance? USB perhaps? Which might have an energy policy of shutting down, or going into low-power mode? And the Host loses the connection and the Guest freaks out?

Could you try with another share, a more "permanent" one? Let's say '/home/jrather' for example?

[jim.rather]

1. I use .vmdk because this VM gets transferred offsite to a facility without connectivity. The transfer is easier if I break it out into 2G files and rsync'd it instead of a large .vdi file.
2. I lowered the guest to 1 core while troubleshooting this issue. As I stated in the original post it was set to 2.
3. I have no idea what you mean by unsupported experimental option, I thought I used the defaults. I will look into setting it to PIIX3.
4. /media/data is a hard disk, it is not USB. Specifically it is a Toshiba X300 HDWE140 4TB.

[Socratis]

1. Then why aren't you actually using the 2G-split files? What are you doing, exporting the VM? Breaking down the VMDK with a "clonemedium" procedure? Other?

2. OK, makes sense. But keep it to two, there's no known relationship with the #cores and VBoxSF.

3. Just hover over the control, read the tooltip. And no, you did not use the defaults. The defaults call for the use of the ICH9 chipset only for OSX Guests, nothing else. So, you must have manually changed it.

4. It's the path that troubles me, since Linux hosts use that "/media" folder traditionally for removable media. Anyway, can you try with another share, one that's not under "/media"?

[jim.rather]

1. I am not exporting the VM. I shutdown the VM and I rsync the VM directory to another system. If an issue occurs during the rsync, it needs to be restarted. In this case, rsync'ing multiple individual 2G .vmdk files is more efficient vs a 100G .vdi file.
2. changed back to 2.
3. I switched it to PIIX3 and will see if that resolves anything. I believe this VM initially could have been created on a Mac so it might explain the setting for ICH9. I am not sure what happens if re-started on a Mac would reset this back or not?
4. I am not sure your concern for /media/data is warranted. On CentOS systems (the VirtualBox host) removable media gets mounted on /run/media. /media/data is just a mountpoint.

[Socratis]

Replying to jim.rather:

In this case, rsync'ing multiple individual 2G .vmdk files is more efficient vs a 100G .vdi file.

Sure. But... you're not actually using the 2G-split VMDK option, you're using the single 100GB VMDK option. Not sure what exactly you're talking about, you still are using a single file that you rsync.

I believe this VM initially could have been created on a Mac so it might explain the setting for ICH9.

The ICH9 has nothing to do with the Host, it's all to do with the Guest type.

Given the VM type (Win10), the storage type (VMDK) and the ICH9 chipset, I'm inclined to believe that this was a Microsoft VM that was imported in VirtualBox.

BTW, another thing that I just noticed:

00:00:09.311138 File system of '/home/jrather/VirtualBox VMs/win10/win10.vmdk' is fuse

Why is that a FUSE filesystem? Or is it not and VirtualBox is somehow confused?

[jim.rather]

1. I assure you it is 2G .vmdk, 36 to be exact. The disk for this VM has always been this way. See attachment.
2. In reading the documentation, I think when you create a VM on a Mac it uses ICH9. Not sure it matters what the VM type or storage type is. As I said before I believe this VM was probably recreated on a Mac which would explain this. In any case, it has been set to PIIX3 for now.
3. /home/jrather/VirtualBox VMs is an mounted NTFS file system. I believe CentOS uses fuse to accomplish this.

[Socratis]

1. Ah, I see... That makes things even worse actually, this isn't the way that such a VM would have been created in VirtualBox. Just try and create a new one, see what that gets you. Can you please try to get into the VM's history? Something doesn't compute here...

2. No, you didn't read the documentation right. This (ICH9 chipset) is definitely not something that you'd get by default unless you either had an OSX Guest, or you set it up manually; there's no meaning in beating up a dead horse. Which leads me again to ask for the VM's past.

3. Your "home" is on an NTFS filesystem?!?

4. I'd like you to create a new VM and test this anew. Something is really fishy about this one.

[jim.rather]

1. This VM has been working fine for years. It has only recently had issues when the Guest uses a Shared Folder within the guest. With this particular issue, it runs fine for hours or days, but if that Shared Folder is left connected, it will freeze. I have had issues with corruption on files with Shared Folders in the past, but it never caused the host to crash. Version 6.0.6 comes to mind? There are plenty of closed bugs referencing Shared Folder issues which have been resolved in follow up releases. In any case, it would be nice to not have to disconnect the folder after i use it in the guest, but that is the reason I opened this ticket. It is the only constant that I have found when the lock up occurs.
2. You've won the argument, I already changed it to PIIX3.
3. /home/jrather is not an NTFS filesystem. /home/jrather/VirtualBox Vms is a mounted NTFS filesystem.
4. My experiences with Shared Folders in the past leads me to believe it is not a problem with the VM itself but with how Shared Folders are implemented. As I have said, it only occurs when the Shared Folder is attached so I was hoping that submitting this bug ticket would help to determine the cause of this problem so that it might somehow be fixed. In the meantime, I am going to refrain from recreating this VM, which would invariably add a lot of new variables which might not add any value. I have changed the chipset, hopefully that is the fix. If not, I will start to be diligent to disconnect the Shared Folder. Disconnecting the Shared Folder is a simpler fix than re-doing the VM. Likewise, I do not think recreating this VM will help any future versions of VirtualBox resolve this issue, even if it is a unique issue.

[jim.rather]

System hard froze again. I had the Shared Folder attached but the Chipset was PIIX3. Changing the Chipset did not solve the issue. Will keep the Shared Folder disconnected until the next release of VirtualBox, otherwise I may revert back to 6.0.4 which was working for me.