- This topic has 13 replies, 3 voices, and was last updated 7 years ago by
.
-
Posts
-
Hi,
Host OS: virtualized WIN server 2016 on Ret Hat (GCP)
GPU: Tesla K80 passthrough KVM
Guest OS: WIN 7 x64
There is no OpenGL on the K80, which is basically a headless display. The connection from guest to host gets estalished (checking credentials) but then there is only a blnk/black screen showing on the host. The reverse direction is working ok, i.e. connecting from the server to the workstation, showing the display of the workstation.
Due to the incorporation of NVENC I would have thought/hoped that the NM would communicate directly to the GPU though the API and thus provide the necessary hardware acceleration without going through OpenGL?
Thinking that it might be the lack of the x264 codec I purchased NoMachine AVC Pack Subscription v6, installed it, placed the license files in C:\ProgramData\NoMachine\codec\etc and restarted the NX server. But no avail, the remote screen remains blank.
What else then, or NX not suited for this scenario?
Apparently no support for NoMachine AVC Pack, except then Pay-Per-Incident$ 124.50 (€ 105.60)…
Whilst the NVIDIA smi tool can query the K80 NX does not seem to be communicating with it. Is there any way to check on the communication of NX with the GPU or VirtualGL. VirtualGL is apparently also able to communicate with GPU, as shown by their test tools
@n8v8r – free support from the developers is available in this forum – and I can confirm that it is already being looked at 😉 Please understand that the forums are handled by the developers as quickly as possible – in the time they have between handling support tickets coming from subscribed customers and their own development work.
So, if I understand, the non-working case is with NoMachine player running on the Windows 7 guest, connecting to NoMachine server running on the Windows Server 2016 (virtualized) host.
The fact NVENC encoder is available or not shouldn’t have any effect on the blank screen, but maybe there is some problem with the passed-through GPU. Please try to open the NoMachine Server preferences menu on the Windows Server host (server side of the connection), go to Performance tab, and uncheck ‘Use acceleration for display processing’.
In any case, you can send us the logs for further investigations as eplained in https://www.nomachine.com/DT07M00098. You can send to forum[at]nomachine[dot]com.
Your understanding is correct.
Tried with uncheck ‘Use acceleration for display processing’ but it does not make a difference. As mentioned in the other post VirtualGL is communicating fine with the GPU as well as the nvidia-smi tool.
Logs were already sent to that email, but I did not receive a (auto) response of whether actually been received.
Logs were already sent to that email…
The logs you sent for the other issue don’t actually contain information useful to Fra81. That doesn’t mean there is no info useful for the other topic though 🙂
What you need to ensure is that you enable debug and that you establish the connection. The logs you submitted earlier don’t show the server running, so there is no connection at all.
Some additional info, just in case:
VirtualGL tools
nettest -server
Listening on TCP port 1972nettest -client 192.168.0.3
Error in vglutil::Socket::connect–
No connection could be made because the target machine actively refused it.tcbench
Thin Client Benchmark
Click the mouse in the window that you wish to monitor …
Monitoring window 0x0003020e (NoMachine Forums – Blank on headless Tesla GPU – Mozilla Firefox)
Sample block location: 944, 508
Samples: 3001 Frames: 19 Time: 30.010020 s Frames/sec: 0.633122wglspheres (screenshot attached)
Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
Client area of window: 1240 x 900 pixels
Pixel Format of window: 3
OpenGL Renderer: GDI Generic
22.709968 frames/sec – 25.344324 Mpixels/secNVIDIA SMI tool (attached)
Attachments:
Can you force VP8 encoding and see if the problem persists? If you’re still getting a blank screen, it’s not related to codecs, and we’ll need to investigate what’s causing it elsewhere in the software.
p.s the logs you sent still didn’t include the affected session directory.
Responded by email, with a fresh set of logs, hope this time everything there. It does not seem to be a codec matter, nor a connection issue, but then I am no expert 😉
By Forums Admin: Updated info from user submitted via email with logs, useful for the topic:
With VP8 forced on the server the client does not discover the server, unless a Micrsoft RDC session is established first and the NX browser window on the server is open. Even with RDC established but NX browser window on the server closed the client keeps on reporting back “No Computers were found in your local network”. Leaving the NX browser window open and killing the RDC the client then discovers the server. Very weird but that is how it happened repeatedly and it is different than not forcing VP8.
Just for your understanding, the fist connection between client and server is through VPN initiated by the client. Then I would attempt from the client NX, or as it does not work RDC, latter also through the LAN (VPN) and not externally through the WAN. Commonly I would kill RDC prior attempting NX, to avoid interference/redundancy.
I trust I mentioned earlier that a connection from the server to the client is working.
I have scrambled the logs again, both sides attached and hope it does suffice now, from the locations:
- C:\ProgramData\NoMachine\var\log\ (aka %PROGRAMDATA%/NoMachine/var/log)
- %USERPROFILE%\.nx
, else would not know where to find what you are looking for.
The connection over VP8 has the same outcome – a black/blank screen. The client is going through with the credential handshake, then showing 2 option screens and then going blank.
Apparently no news posted here. Is it being looked into, solved. Or it simply does not with such GPU type?
After further investigation it seems that it’s not an issue of codecs (indeed logs don’t show any errors from codecs whatsoever). It appears that codecs (both H264 and VP8) are encoding a blank frame, hence the blank screen.
To allow us to check whether the frame is indeed blank and possible reasons as to why, we need you to install the package that I’ve emailed to you. It’s not a patch. Install it, enable logs as you did before, run the session, grab the logs and then zip up and send to us.
Thanks for your patience!
Closed because the user did not provide further feedback. Please notify us if you confirm that it is resolved or open a new topic if you have the same problem.