Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I just received my new Thinkpad E545 and would love to set up a new virtual machine for development. After creating the appliance and adding the #! iso for installation, I tried to start up the machine and I get the following error:
Failed to open a session for the virtual machine CrunchBang.
AMD-V is disabled in the BIOS (or by the host OS). (VERR_SVM_DISABLED).
Result Code: E_FAIL (0x80004005)
Component: Console
Interface: IConsole {8ab7c520-2442-4b66-8d74-4ff1e195d2b6}
I did some searching and found this thread (https://askubuntu.com/questions/118006/amd-v-is-not-enable-in-virtualbox-in-amd-apu) and followed the advice about enabling virtualization in my bios, but I still get the same results from virtualbox, even after re-installing. After enabling virtualization in the bios, the acceleration tab in vbox is still not available (greyed-out and un-clickable).
Screenshot: http://i.imgur.com/ev3Ty53.png
Relevant laptop specs:
Processor AMD A10-5750M Accelerated Processor (2.5GHz to 3.5GHz, 4MB Cache, 1600MHz) with Radeon HD 8650G Graphics
Operating System Windows 8 64
Operating System Language Windows 8 64 English
Display 15.6W HD AntiGlare, Midnight Black
Graphics AMD Radeon HD 8570M 2GB Discrete Graphics
Memory 16GB PC3-12800 DDR3L SDRAM 1600MHz SODIMM
Keyboard Keyboard with Number Pad - US English
Camera 720p HD Camera
Hard Drive 320GB Hard Disk Drive, 5400rpm
Optical Device DVD Recordable 8x Max Dual Layer
Sorry, that I am so late, but at least someone else will be able to use my advice.
In the latest version of BIOS for this model (have the same one) they mixed up the setting: ENABLING amd-v DISABLES it.
Or this could be some bug of VirtualBox as stated above, however this worked for me.
I've just discovered that having hyper-V installed seems to prevent certain virtualisation features (such as 64 bit) being available to virtualbox. Switching hyper-V off (via add/remove windows features) fixed this for me.
Judging by a sudden spike in forum posts and Stack Overflow questions about this precise error code (VERR_SVM_DISABLED) starting right about when 4.3 came out, I'm willing to bet that this is a legitimate bug in 4.3.
I've triple-checked my BIOS settings and AMD-V is enabled...but I'm still seeing this error in 4.3.10. I never had this problem on 4.2.18.
And this bug report might be good additional reading: https://www.virtualbox.org/ticket/12049
You can simply change the Virtal machine from 64-bit to 32-bit
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I'm trying to download whonix on my computer but I get 2 errors:
First Error: "The memory could not be written",
Second Error: "Failed to open a session for the virtual machine"
and then it says aborted.
First Error
SecondError
I have no idea what to do, I tried to:
Reinstall VirtualBox
Write in cmd: "sfc /scannow"
Install oldest versions of VirtualBox
Write custom size in virtual Memory(Control Panel->System and Security->System->Advanced system settings->(Performance)settings->Advanced->Change->Custom size)
Updates VirtualBox+Windows+Whonix+Drives
Enabled Intel Virtualization Technology(in BIOS->CPU Configuration)
Deactivate the 3d acceleration but I have no idea how
and nothing works :(
If it helps I have:
Operating system: Windows 10 Pro
Processor: Intel(R) Core(TM) i7-8700 CPU # 3.20GHz 3.20 GHz
Graphics Card: GTX 1080
Installed RAM: 32.0 GB
System type: 64-bit operating system, x64-based processor
Hope someone could help me!
I had the same problem
solution: VirtualBox → Settings → Storage → Type: AHCI → OK
it worked for me
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
The community reviewed whether to reopen this question 5 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
OpenGL and Windows Remote don't play along nicely.
Solutions for this are dependent on the use case and answers are fragmented across the vast depths of the net.
This is a write-up I wish existed when I started researching this, both for coders and non-coders.
Problem:
A RDP session of Windows does not expose the graphics card, at least not directly. For instance you cannot change the desktop resolution and GraphicsCard drivers usually just disable their setting menus. Starting a OpenGL context higher than v1.1 fails because of this. The, especially in support IRCs, often suggested "Don't use WindowsRemote" is unfortunately not an option for many. In many corporate environments Windows Remote is a constantly used tool and an app has to work there as well.
Non-Coder workarounds
You can start the OpenGL program, allowing it to see the graphics card, create an opengl context and then connect via WindowsRemote. This always works, as Windows remote just transfers the window content. This can be accomplished by:
A batch script, that closes the session and starts the program, allowing you to connect to the program already running. (Source)
Using VNC or other to remote into the machine, start the program and then switch to Windows Remote. (Simple VNC programm, also with a portable client)
Coder workarounds
(Only for OpenGL ES)Translate OpenGL to DirectX. DirectX works under Windows Remote flawselly and even has a Software rendering fallback built into DX11 if something fails.
Use the ANGLE Project to do this at run-time. This is what QT officially suggests you do and how Chrome and Firefox implement WebGL. (Source)
Switch to software rendering as a fall back. Some CAD software like 3dsMax does this for instance:
Under SDL2 you can use SDL_CreateSoftwareRenderer (Source)
Under GLFW version 3.3 will release OSMesa (Mesa's off screen rendering), in the mean time you can build the Github version with -DGLFW_USE_OSMESA=TRUE, but I personally still struggle to get that running (Source)
Directly use Mesa's LLVM pipe for a fast OpenGL implementation. (Source)
Misc:
Use OpenGL 1.1: Windows has a built in implementation of OpenGL 1.1 and
earlier. Some game engines have a built in fall back to this and thus
work under Windows Remote.
Apparently there is a middle-ware, that allows for even OpenGL 4 over Windows Remote, but it's part of a bigger package and is a commercial solution. (Source)
Any other solutions or corrections are greatly appreciated.
[10] Nvidia -> https://www.khronos.org/news/permalink/nvidia-provides-opengl-accelerated-remote-desktop-for-geforce-5e88fc2035e342.98417181
According to this article it seems that now RDP handles newer versions of Direct3D and OpenGL on Windows 10 and Windows Server 2016, but by default it is disabled by Group Policy.
I suppose that for performance reasons, using a hardware graphics card is disabled, and RDP uses a software-emulated graphics card driver that provides only some baseline features.
I stumbled upon this problem when trying to run Ultimaker CURA over standard Remote Desktop from a Windows 10 client to a Windows 10 host. Cura shouted "cannot initialize OpenGL 2.0 context". I also noticed that Repetier Host's "preview" window runs terribly slow, and Repetier detects only an OpenGL 1.1 card. Pretty much fits the "only baseline features" description.
By running gpedit.msc then navigating to
Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment
and changing the value of
Use hardware graphics adapters for all Remote Desktop Services sessions
I was able to successfully run Ultimaker CURA via with no issues, and Repetier-Host now displays OpenGL 4.6, and everything finally runs fast as it should.
Note from genpfault:
As usual, this Policy is kept in the HKLM registry group in
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Set REG_DWORD:bEnumerateHWBeforeSW to 1 to turn ON using GPUs in RDP.
OpenGL works great by RDP with professional Nvidia cards without anything like virtual machines and RemoteFX. For Quadro (Quadro 4000 tested) you need driver 377.xx. For M60 you can use the same driver. If you want to use last driver with M60, you have to change the driver mode to WDDM mode (see c:\Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.1.pdf). It is possible that there are some problems with licensing in this last case.
Some people recommend using "tscon.exe" if you can: https://stackoverflow.com/a/45723167/32453 or using a scheduler to do it on native hardware: https://stackoverflow.com/a/41839102/32453 or creating a group policy:
https://community.esri.com/thread/225251-enabling-gpu-rendering-on-windows-server-2016-windows-10-rdp
maybe copy opengl32.dll (or opengl64.dll) to your executable's dir: https://blender.stackexchange.com/a/73014 and newer version of the dll: https://fdossena.com/?p=mesa/index.frag
Remote Desktop and OpenGL does not play very well. When you connect to a Windows box the OpenGL Driver is unloaded and you end up with software emulation of OpenGL.
When you disconnect from the Windows box the OpenGL driver is not reloaded. This causes issues when you are running tests on the machine as you have to physically login to the machine to reset the drivers.
The solution I ended up using was to:
Disable Remote Desktop.
Delete all other software for remote desktop access. Because if it's used for logging in remotely the current set of drivers loaded may be messed up.
Install NoMachine
NoMachine is my personal favourite (when it does not play up) for a number of reasons:
Hardware acceleration of compression (video of desktop).
Works on Windows and Linux.
Works well on low-bandwidth connections especially if the client and server have the necessary hardware for compression of the data stream.
On Linux you get your desktop as you last left it when you were sitting in front of the machine.
On Windows it does not affect OpenGL.
currently free for personal and commercial use. Do check the licence in case it's changed.
When NoMachine plays up it hogs the CPU but this happens rarely. It is however in active development
Others to consider:
TurboVNC
TightVNC
TeamViewer - only free for personal use.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 6 years ago.
Improve this question
I run a X server on a Windows 7 machine with OpenGL 4.4. From there I ssh -Y to a remote machine where I start an OpenGL application. (for what it matters, the network connection is very fast, I have turned off compression and use arcfour,blowfish-cbc ciphers for speed)
glxgears runs, but not very smoothly. Reports it is doing 6000+ FPS though.
However, matlab fails to use hardware OpenGL rendering. I read the docs and they mention it requires OpenGL version 2.1. When I run glxinfo in the ssh terminal, it tells me:
GLX version: 1.4
OpenGL version string: 1.4 (4.4.0 - Build 10.18.15.4279)
I don't know the technical details of GLX, but does this mean that the OpenGL version supported over SSH is limited to 1.4? I understand that the latest version of GLX is quite old, compared to the progress of OpenGL.
I run a X server on a Windows 7 machine with OpenGL 4.4
The first problem start with this. A X11 server on Windows is just another program running there and ultimately is going to turn X11 commands into Win32 GDI calls. X11 itself does not "know" OpenGL, that's why there's the GLX extension. And GLX is an interesting beast and the X11 servers for windows all implement only a very basic baseline of OpenGL commands to support the essentials.
But that's only half of your problem…
From there I ssh -Y to a remote machine where I start an OpenGL application.
Doing this kind of thing always invokes indirect rendering where all commands have to be sent as a GLX opcode command stream. And unfortunately (for you) GLX opcodes have been specified only up to OpenGL-2.1, but full GLX support is mandatory only for up to OpenGL-1.4. OpenGL-1.5 introduced vertex buffer objects, which add quite a lot of complications for an indirect rendering contexts, so GLX may implementations opt not to support it for indirect rendering.
For Linux at least the proprietary NVidia drivers and client libraries have full indirect OpenGL-2.1 support. But the X11 server you're running on Windows, and likely the client library don't.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
I have a whitebox dual CPU home server running ESXi 5.5.
I have loaded the server up with a bunch of VM's for learning Microsoft SCCM. I noticed that as soon as one of the guests gets under load, the host will crash with the attached photo (apologies for the quality). Could this be due to a dying CPU? I have noticed that one of the CPU's runs quite a bit hotter than the other.
Usually with CPU overheating the machine would shut down first, however if the temperature inside the case is too hot, something else might be getting affected (e..g memory or video display circuitry).
If you want to diagnose overheating, I can suggest placing a vacuum cleaner hose over the air vent, this will draw much more air than your regular fans. If the system stays up under load with the vacuum cleaner attached, it will be an overheating problem.
Not a programming issue, so I'll close this off and note the resolution I found incase anyone else has the same issue.
Looks like this was a known issue under ESXi 5.X that has to do with the E1000 and E1000e virtual network adapter as per the lines:
#BlueScreen: #PF Exception 14 in world wwww:WorldName IP 0xnnnnnnnn addr 0x0
PTEs:0xnnnnnnnn;0xnnnnnnnn;0x0;
0xnnnnnnnn:[0xnnnnnnnn]E1000PollRxRing#vmkernel#nover+0xdb9
0xnnnnnnnn:[0xnnnnnnnn]E1000DevRx#vmkernel#nover+0x18a
0xnnnnnnnn:[0xnnnnnnnn]IOChain_Resume#vmkernel#nover+0x247
0xnnnnnnnn:[0xnnnnnnnn]PortOutput#vmkernel#nover+0xe3
0xnnnnnnnn:[0xnnnnnnnn]EtherswitchForwardLeafPortsQuick##+0xd6
0xnnnnnnnn:[0xnnnnnnnn]EtherswitchPortDispatch##+0x13bb
0xnnnnnnnn:[0xnnnnnnnn]Port_InputResume#vmkernel#nover+0x146
0xnnnnnnnn:[0xnnnnnnnn]Port_Input_Committed#vmkernel#nover+0x29
0xnnnnnnnn:[0xnnnnnnnn]E1000DevAsyncTx#vmkernel#nover+0x190
0xnnnnnnnn:[0xnnnnnnnn]NetWorldletPerVMCB#vmkernel#nover+0xae
0xnnnnnnnn:[0xnnnnnnnn]WorldletProcessQueue#vmkernel#nover+0x486
Simply remove any adapters using E1000/e and replace with VMXNET3.
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2059053
I have a Kubuntu 12.10 64bit as host and CentOS 6 32bit as guest system on VMware player 5 on a Dell Latitude E6510.
Despite the installation of VMware tools, the clipboard exchange is not working.
I use a very similar guest system within VirtualBox and there cliboard exchange works fine.
Has someone experienced the same with a configuration similar to mine?
And is it possible, that the guest system causes the problem instead of the player?
I've found thaht suspending and then re-playing the VM will re-enable clipboard exchange.
Clipboard exchange will then work both between VMs and the Host machine as well as between VMs themselves.
(VMWare Player 5.0, Windows 7)
After having installed several constellations like that, I experienced, that in general it works, I can exchange the clipboard in both ways and even the desktop size adapts to the size of the VM window, but still from time to time having a situation, where it doesn't work and also heard of many other people who experienced that.
So, if someone can enlighten me on that point, I'll be happy, but I'm closing my question hereby.