New install – what do I need

[stanj]

I will enable the debug by setting SessionLogLevel 7 and try a connection again and send the info.

 

No journal filess…….

$ journalctl -f | grep -i kde

No journal files were found.

[stanj]

I have emailed the log files

 

Stan

[graywolf]

It seems original issue again:

It looks like your X server started but it is not fully functional because no screen is attached to the video out.

Did you repeat the steps to configure Xorg for headless use?

[stanj]

The xorg looks to be the same file that was generated for headless last time. I see the below in the file that was not in the original.

Section “Screen”

Identifier     “Screen0”

Device         “Device0”

Monitor        “Monitor0”

DefaultDepth    24

Option         “AllowEmptyInitialConfiguration” “True”

SubSection     “Display”

Virtual     1920 1200

Depth       24

EndSubSection

EndSection

[stanj]

I rebooted the VM and was able to connect NoMachine to the VM.

it is real slow moving around and even opening KDE desktop settings takes forever

I used putty to ssh into the VM and see that a process called nxnode.bin is showing 101.7 CPU%?

[graywolf]

Would you collect new server and client logs for this problem?

1. Increase log level and turn automatic cleanup off:

sudo /etc/NX/nxserver --debug --enable all

2. Reproduce the problem

3. Collect server logs:

sudo /etc/NX/nxserver --debug --collect (NoMachine-log-.zip will be created).

4. Collect logs from the client host (zip the folder %USERPROFILE%\.nx).

[stanj]

I sent the log files via email.

CPU on the VM still shows 102.0% for nxnode.bin

 

 

[graywolf]

I see that NoMachine launched a virtual display as its attempts to probe the X server failed. The virtual display runs in a process nxnode.bin, likely the one consuming the CPU.

By the way, I understand you want to use the video card, so falling back to the virtual display is not an option. Investigating the high CPU usage by nxnode.bin looks futile, in such a situation.

It seems that most part of the problems are due to the headless configuration. Would it be possible for you attaching a display to the output of the video card, restoring xorg.conf, restarting Gdm, restarting NoMachine, and trying to see what happens?

[stanj]

The first goal is to see if the VM will boot with the video card.

The NVIDIA M6000 card is currently set in the VM with PCI device to pass-through.

The VM has 21 vCPUS and 64 GB or RAM

I recall that we connected a display monitor to the video card last summer.  We could not get the display to show anything.  That is when I contacted NVIDA support and they  provided info that in order to see the display and run graphics, one of two options was needed: 1-Horizon View, 2-some form of a viewer (VNC or NoMachine)

What would the  attaching a display to the output of the video card, restoring xorg.conf, restarting Gdm, restarting NoMachine,  accomplish?

Is there some other option beside headless ?

[graywolf]

Likely your video card changed to standby state if no display is attached. Search for errors in /var/log/Xorg.0.log.

Attaching a display would help to find out if the X server is correctly configured. I’d expect to see the guest X server output shown on the attached display.

Should things work fine with a display attached it could be replaced by a fake display dongle.

[stanj]

I connected a display to the M6000 card HDMI port and the display says “No Signal”

I see no errors in the /var/log/Xorg.0.log (below are the last few entries after connecting NoMachine

 

[1238442.646] AUDIT: Thu Feb 28 03:33:28 2019: 2143: client 7 connected from local host ( uid=42 gid=42 pid=2628 )

Auth name: MIT-MAGIC-COOKIE-1 ID: 569

[1238442.648] AUDIT: Thu Feb 28 03:33:28 2019: 2143: client 7 disconnected

[1290233.422] (–) NVIDIA(GPU-0): CNC HDMI (DFP-0): connected

[1290233.422] (–) NVIDIA(GPU-0): CNC HDMI (DFP-0): Internal TMDS

[1290233.423] (–) NVIDIA(GPU-0): CNC HDMI (DFP-0): 600.0 MHz maximum pixel clock

[1290233.423] (–) NVIDIA(GPU-0):

[1290234.340] (–) NVIDIA(GPU-0): CNC HDMI (DFP-0): connected

[1290234.340] (–) NVIDIA(GPU-0): CNC HDMI (DFP-0): Internal TMDS

[1290234.340] (–) NVIDIA(GPU-0): CNC HDMI (DFP-0): 600.0 MHz maximum pixel clock

[1290234.340] (–) NVIDIA(GPU-0):

[1290234.401] (–) NVIDIA(GPU-0): CNC HDMI (DFP-0): connected

[1290234.401] (–) NVIDIA(GPU-0): CNC HDMI (DFP-0): Internal TMDS

[1290234.401] (–) NVIDIA(GPU-0): CNC HDMI (DFP-0): 600.0 MHz maximum pixel clock

[1290234.401] (–) NVIDIA(GPU-0):

[1290258.339] (–) NVIDIA(GPU-0): DFP-0: disconnected

[1290258.339] (–) NVIDIA(GPU-0): DFP-0: Internal TMDS

[1290258.339] (–) NVIDIA(GPU-0): DFP-0: 600.0 MHz maximum pixel clock

[1290258.339] (–) NVIDIA(GPU-0):

[1290258.344] (–) NVIDIA(GPU-0): DFP-0: disconnected

[1290258.344] (–) NVIDIA(GPU-0): DFP-0: Internal TMDS

[1290258.344] (–) NVIDIA(GPU-0): DFP-0: 600.0 MHz maximum pixel clock

[1290258.344] (–) NVIDIA(GPU-0):

 

 

[graywolf]

The Xorg log shows a video out has been staying connected for a while. It is possible the passthrough is not working as expected, although no problem is reported. For example, look at this compatibility list:

Compatibility Guide – Shared Pass-Through Graphics

It seems that hypervisors provide passthrough for a limited set of video cards.

[stanj]

I will have to take a look

I have been side tracked with other work…

According to NVIDIA support and VMware the M6000 card is on the comparability list.

I will check again.

[stanj]

This is using dedicated PCI pass through with an M6000 Quadro GPU

I will have to reconnect with NVIDIA as they verified using Horizon View or a VNC Viewer or NoMachine would work

 

[graywolf]

It is possible that compatibility list is out of date as I didn’t find the card.

[Author]

Posts