End-user guide: Document an issue with Virtualbox VMs

It may happen if Mesa3D desktop OpenGL driver is installed inside the VM using system-wide deployment tool as encountered in #9.

readme.md

@@ -20,7 +20,7 @@ Build instructions, if you want to replicate my builds, are available [here](htt
 
 # Installation and usage
 Before running the installer close all programs that use Mesa if any is running. After running the installer you will have access to 2 deployment options, both located in the directory you installed Mesa. Both deployment utilities have a start-over mechanism so you can do all deployments you need in one session.
-- A system-wide deployment tool. While intended for systems lacking hardware accelerated OpenGL support like virtual machines in cloud environments, it can also be used on any Windows system to replace the inbox software rendering OpenGL 1.1 driver extending OpenGL support for use cases where hardware accelerated OpenGL is not available like RDP connections.
+- A system-wide deployment tool. While intended for systems lacking hardware accelerated OpenGL support like virtual machines in cloud environments, it can also be used on any Windows system to replace the inbox software rendering OpenGL 1.1 driver extending OpenGL support for use cases where hardware accelerated OpenGL is not available like RDP connections. Due to potential issues with Virtualbox VMs running Windows it is recommended to disable 3D acceleration in such VMs if Mesa3D desktop OpenGL driver is installed inside them using the system-wide deployment tool, see [#9](https://github.com/pal1000/mesa-dist-win/issues/9).
 - A per-application deployment tool. You only need to use it for programs you didn't deploy Mesa before as the per-app deployment utility changes persist across upgrades and re-installations. The per-app deployment utility helps you save storage and makes things easier as you won't have to manually copy DLLs from Mesa installation directory as it creates symbolic links to whatever Mesa drivers you opt-in to use. This behavior ensures all programs that use Mesa use the same up-to-date version. Per-app deployment utility only asks for path to directory containing application executable, if the app is 64-bit or 32-bit and the drivers you need. 32-bit applications have their names marked in Task Manager while running. Most applications will use mesa regardless of GPU capabilities, but some applications may be smart enough to load OpenGL from system directory only. Use [Federico Dossena](https://github.com/adolfintel)'s Mesainjector to workaround this issue: [Build guide](http://fdossena.com/?p=mesa/injector_build.frag), [VMWare ThinApp capture](http://fdossena.com/mesa/MesaInjector_Capture.7z). Upgrade from 17.3.5.501-1 and older versions breaks osmesa drivers deployments made with per-app deployment tool. You'll have to redo the osmesa deployments.
 
 Since v17.0.1.391 in-place upgrade is fully supported. Since v17.0.1.391-2 S3 texture compression is supported. v17.0.4.391-1 requires uninstall of previous versions. Applications requiring OpenGL 3.2 or newer may need [OpenGL context configuration override](#opengl-context-configuration-override).

releasenotes.md

@@ -3,6 +3,8 @@
 - Workaround a pip v10.0.1 bug by nuking pip cache. The cache processing bug throws a warning that permanently changes the text color to yellow.
 ### General
 - GLES and GLAPI support.
+### End-user guide
+- Document an issue with Virtualbox VMs that may happen if Mesa3D desktop OpenGL driver is installed inside the VM using system-wide deployment tool.
 # 18.1.1.600-1
 - Updated Mesa3D to [18.1.1](https://www.mesa3d.org/relnotes/18.1.1.html).
 ### End user guide