virtualbox.org

first of: virtualbox is one fine CROSS OS (!) virtualization system.

what is great about it: can migrate easily between Linux and Windows hosts.

PS: update, could have been a incompatibility problem (old vbox guest additions on newer virtualbox host... until now now crashes on Debian 10 and Win 7 guests)

stability problems/vm crashes (guest: Debian 9 and Win 7 64Bit)

with this error: complete logfile attached: came from CentOS7 host with VirtualBox 5.X

because could not build the vm guest additions for Debian 10 (Debian as Guest of CentOS7) so reinstalled workstation with Debian 10 and updated to more recent Version of Virtualbox: Version 6.1.2 r135662 (Qt5.11.3)

hostnamectl ; # exact host OS
Operating System: Debian GNU/Linux 10 (buster)
Kernel: Linux 4.19.0-6-amd64
Architecture: x86-64

exact guest OS(es):

1) Debian GNU/Linux 9 (stretch)
Kernel: Linux 4.9.0-9-amd64
Architecture: x86-64

2) Win 7 Ultimate SP1 64Bit

will keep observing the behavior.

new features are nice, but at the end VirtualBox shall do ONE THING and shall DO IT WELL (UNIX philosophy) run Virtual Machines of all sorts and OS versions.

this is exactly the reason why i avoid updates like hell.

NEVER safe on software quality testing! (how does Oracle-VirtualBox-Team do software quality/use case testing?/automated/manual tests before every release?)

or: maybe the time has come to switch to

canoodler wrote: NEVER safe on software quality testing! (how does Oracle-VirtualBox-Team do software quality/use case testing?/automated/manual tests before every release?)

I'm not quite sure of the basis for that sermon? Oracle takes testing quite seriously, that's why they make VirtualBox available to people like you for free. That way their customers (which you are not) see only stable, well tested code.

If you want more stability in your VM I suggest giving it way more than 16MB of graphics RAM! Max it out to 128MB. The VirtualBox settings dialog will have been giving you warnings about this.

Also: you have assigned 100% (i.e. 2) of available host CPU cores to the VM, leaving none for the exclusive use of the host OS, which of course is running VirtualBox among other things. This can lead to instability. Unfortunately running modern 64bit OS on one core is not a good option either.

the VM just crashed again (when trying to start to connect to a vnc server via vnc client)

latest/matching guest additions installed on vm.

hostnamectl; # host
Operating System: Debian GNU/Linux 10 (buster)
Kernel: Linux 4.19.0-8-amd64
Architecture: x86-64

win 7 ultimate 64bit sp1 # guest

# dmesg on host
[51090.750760] SUPR0GipMap: fGetGipCpu=0x1b
[51091.747264] vboxdrv: 00000000596c32ba VMMR0.r0
[51092.009987] vboxdrv: 00000000f451db47 VBoxDDR0.r0
[51092.060422] VMMR0InitVM: eflags=246 fKernelFeatures=0x4 (SUPKERNELFEATURES_SMAP=0)
[53906.674250] show_signal_msg: 307 callbacks suppressed
[53906.674259] ShClipboard[1747]: segfault at 4 ip 00007f41d80381d6 sp 00007f41baa5ed00 error 4 in VBoxSharedClipboard.so[7f41d8031000+8000]
[53906.674292] Code: 41 89 c6 85 c0 78 4a 48 8d 4d c8 ba 30 75 00 00 44 89 e6 4c 89 ef e8 e9 cb ff ff 41 89 c6 85 c0 78 2f 48 8b 45 c8 48 8b 7b 08 <8b> 50 04 39 53 04 0f 46 53 04 48 8b 70 08 89 d2 e8 35 90 ff ff 48
[53944.281431] vboxdrv: 0000000070e002a9 VMMR0.r0
[53944.376652] vboxdrv: 00000000d47dc31f VBoxDDR0.r0
[53944.422019] VMMR0InitVM: eflags=246 fKernelFeatures=0x4 (SUPKERNELFEATURES_SMAP=0)
[60846.382648] ShClipboard[2298]: segfault at 4 ip 00007f793400b1d6 sp 00007f7917bd2d00 error 4 in VBoxSharedClipboard.so[7f7934004000+8000]
[60846.382668] Code: 41 89 c6 85 c0 78 4a 48 8d 4d c8 ba 30 75 00 00 44 89 e6 4c 89 ef e8 e9 cb ff ff 41 89 c6 85 c0 78 2f 48 8b 45 c8 48 8b 7b 08 <8b> 50 04 39 53 04 0f 46 53 04 48 8b 70 08 89 d2 e8 35 90 ff ff 48

# the log of the vm: PS: seems it has to do with Clipboard functionality enabled?

This has been happening to me as well on Fedora 31, and also is shared-clipboard related. It almost always happens when I copy something large (several KB or larger) on host OS and then immediately try to paste it on guest OS, and guest will abort. And I get this in the Fedora kernel log:
I finally disabled shared clipboard, which is annoying...but not as annoying as the crashes.

I think this may help explain some unexpected VM crashes that I have been having.
Host: Ubuntu 19.10, patched to date, 32Gb ram
Virtualbox: 6.1.8, current extensions installed
Guest1: Win10/1909, updates installed, guest additions installed, 12gb ram
Guest2: Ubuntu 20.04, guest additions installed, 10gb ram

Host has little to do other than running the guests
Periodically, one or other of the guests would abort, often whilst not in use.
This behaviour seems more prevalent following the recent upgrades to linux kernel (5.0.53) and VBox 6.1.8.
I face this now every few hrs with one of the machines simply aborting.

Thanks to this thread, I spot the segfault in the host regarding the shared clipboard:

May 22 09:35:14 myhost kernel: [152617.148444] ShClipboard[30667]: segfault at 4 ip 00007efde0027cdc sp 00007efdc3efdcf0 error 4 in VBoxSharedClipboard.so[7efde0020000+8000]

May 22 14:40:03 myhost kernel: [170906.135480] ShClipboard[2959]: segfault at 4 ip 00007f041846ecdc sp 00007f04184f4cf0 error 4 in VBoxSharedClipboard.so[7f0418467000+8000]

guest to guest copy/paste not far off essential for my workflow, but I will try with it disabled for now..