OpenGL Warning: requesting to create context with already allocated id

[jasonic]

Just a data point: Under VirtualBox VM 6.0.0 r127442 linux.amd64, my Windows guest vm failed to start just now.

Log attached.

Trying to start it a second time, it worked as usual. I never saw a failure like this under VirtualBox 5.2.

thanks .. Jason

[socratis]

Please edit your message, remove the chunks of the log that you have attached, ZIP and attach the whole log.

1. Partial logs are not that useful
2. Logs should be posted as zipped attachments, it helps save a (virtual) tree or two

[jasonic]

done

[socratis]

Trying to start it a second time, it worked as usual.

So, it was a one-time of? No need to worry too much, but since you included the VBox.log, let's take a look...

00:00:00.797611 File system of '/media/jharrop/1c1b7be8-0e86-4e57-bc96-534503465f27/VMs/M6600.vmdk' is unknown

Where did you get this VM from? It looks like an imported VMDK (located in an external HD?) for which you created a VM around it, no?

00:00:01.245751 Changing the VM state from 'CREATED' to 'LOADING'
00:00:01.245953 SSM: File header: Format 2.0, VirtualBox Version 6.0.0 r127442, 64-bit host, cbGCPhys=8, cbGCPtr=8
00:00:01.248107 VUSB: Detached 'HidMouse' from port 1 on RootHub#0
00:00:01.248134 SSM: Saved state info:

If that's the VM log that gave you the problem, the saved state restore might have been the source of your error. There have been several reports with saved state restorations with 6.0.0, even from within the same version. Take a look at the Known Issues in the "Discuss the 6.0.0 release".

Other than that, I don't see anything obviously wrong with the VM, and since this was a one-of, I wouldn't worry too much...

[jasonic]

Thanks. I've started and stopped it several times - each successfully - over the last couple of days.

But the last time I tried to start it, it took forever to restore (say 30 mins, instead of 10 secs) during which the host computer appeared frozen, and then, when the VM finally looked like it had started, it (and the host) was frozen. Had to power off the host

I've extracted some stuff from the logs which show it was 42 mins before I gave up and turned off the host (complete log is attached):

Code: Select all

00:00:00.915263 VirtualBox VM 6.0.0 r127442 linux.amd64 (Dec 26 2018 21:56:59) release log
00:01:47.326628 TM: cTSCTicksPerSecond=0xb88935b2 (3 095 999 922) enmTSCMode=1 (VirtTscEmulated) (state load)
00:03:43.448997 Shared clipboard: Starting shared clipboard thread
00:03:44.082444 VMMDev: Guest Additions information report: Interface = 0x00010004 osType = 0x0003B100 (Windows 10, 64-bit)
00:08:17.701558 OpenGL Info: Render SPU: GL_VENDOR:   NVIDIA Corporation
00:20:13.094952 OpenGL Info: Render SPU: GL_VENDOR:   NVIDIA Corporation
00:32:29.756292 OpenGL Warning: cleaning gl error (0x500), ignoring.. (1 out of 5) ..
00:33:03.974330 GUI: UIMachineLogicNormal::sltCheckForRequestedVisualStateType: Requested-state=0, Machine-state=5
00:33:28.601391 VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be unresponsive. Last heartbeat received 5 seconds ago
00:33:56.134996 TM: Giving up catch-up attempt at a 60 464 606 017 ns lag; new total: 60 464 606 017 ns
00:34:57.300417 TM: Giving up catch-up attempt at a 60 879 276 981 ns lag; new total: 121 343 882 998 ns
00:35:58.778972 TM: Giving up catch-up attempt at a 61 645 210 939 ns lag; new total: 182 989 093 937 ns
00:36:59.347334 TM: Giving up catch-up attempt at a 60 771 771 473 ns lag; new total: 243 760 865 410 ns
00:38:00.135435 TM: Giving up catch-up attempt at a 60 779 276 125 ns lag; new total: 304 540 141 535 ns
00:39:00.334825 TM: Giving up catch-up attempt at a 60 146 081 373 ns lag; new total: 364 686 222 908 ns
00:40:01.188087 TM: Giving up catch-up attempt at a 60 957 853 539 ns lag; new total: 425 644 076 447 ns
00:41:02.662039 TM: Giving up catch-up attempt at a 61 319 731 693 ns lag; new total: 486 963 808 140 ns
00:42:04.323273 TM: Giving up catch-up attempt at a 61 659 739 530 ns lag; new total: 548 623 547 670 ns

In answer to your earlier question:

Where did you get this VM from? It looks like an imported VMDK (located in an external HD?) for which you created a VM around it, no?

This was the main hard drive in a Windows laptop which I virtualized 18 months ago (when Windows forced updates made Windows intolerable as a development environment). As mentioned, it worked with 100% reliability until VB 6.

Apart from using VB 6, 2 things have changed which might have caused this failure:

• Microsoft recently did a forced update in the guest KB4480966 2019-01 Cumulative Update (but it did boot successfully since)
• I've been compiling some large native images (graalvm) on the host, and I suspect this might mess somehow with host RAM state (64GB installed, I don't think I was out of mem)

After rebooting the host, the VM started OK (it was now in an off state), so this is a relief.

[socratis]

But the last time I tried to start it, it took forever to restore

The only obvious difference that I saw between the two logs is the amount of available memory on your host on the failed attempt:

00:00:00.915315 Host RAM: 64344MB (62.8GB) total, 7536MB (7.3GB) available
00:00:01.448654 RamSize   <integer> = 0x00000001acf00000 (7 196 377 088, 6 863 MB, 6.7 GB)
00:00:01.448833 VRamSize <integer> = 0x0000000010000000 (268 435 456, 256 MB)

7536 available - (6863 RAM + 256 VRAM) = 417 MB left for your host. Not enough... I can see the host start swapping like crazy, putting a strain to each and every process, even maybe killing your host. You should keep an eye at all times on your hosts resources, you don't want to run out. Or something is going to hit the fan...