FreeNX / XRDP / X11 over SSH on OpenSUSE Tumbleweed virtual guest

[RaveNBlack]

Hi All,

I need to set up some sort of remote desktop server on OpenSUSE Tumbleweed (OST). This is specific yet generic question, so a background information is needed.

I have purchased a laptop with PCIe SSD and a 4K display. I have been using Linux since Win Vista came out. Now I need to refresh my memory on Windows, but I am not ready to abandon Linux (OpenSUSE in particular). I will not go into details on my motivations and decision process, but I've settle on Windows 10 Pro Host OS and Hyper-V virtual machines.

The challenge is that Hyper-V client only gives 1280x768 resolution on OpenSUSE, and with PDI adjustment for 4K display it is unusable.
Connecting to Windows guest on hyper-v over RDP solves resolution restrictions. So I'm looking for something similar for my OST guest OS.

I've tried free offering from NoMachine. The speed is great, but unfortunately, it does not overcome resolution restrictions.
I've tried XRDP. It gives me full screen 4K (3840 x 2160) resolution, but it is slow. I've tried adjusting settings (setting max_bpp and xserverbpp to 256, bitmap_cache and bitmap_compression set to yes), but it still lags behind a bit, especially when dragging windows. I'm connecting to it using sesman-Xvnc option, as others don't seem to work at all.
For Linux to Linux connections I've used X11 forwarding over SSH, but not even sure it is possible with Windows to Linux setup?
And I also tried installing FreeNX server on OST and accessing it with NoMachine client from Windows (using SSH). It does authenticate, but then says that nomachine service is not running, although OST says that service has started.

So, I'm fishing for suggestions, tips, links to how-to's, etc. in order to have smooth OST GUI experience while running it on Hyper-V. I do not intend on using Blender or other multimedia CPU/GPU intensive applications on virtual OST.

Thank you.

[tsu2]

If you want to run X11 over SSH displaying a Windows on a Linux client, you need an X11 display manager running on Windows. Here is the top hit on a Google search
http://www.straightrunning.com/xmingnotes/

But, if you're connecting from a Linux client to a Linux Guest, then it's all Linux (the fact the Linux Guest is running in Hyper-V is irrelevant unless you have some kind of special authentication setup). Anything that should normally work in a purely physical environment should work the same when one of the Linux is deployed as a Hyper-V Guest.

Which leads me to wonder what you're doing in your described RDP connections... Is your RDP client logged into the Windows Guest (you should) or the Windows Host with the Windows Guest visible on the Host desktop (your shouldn't be doing this)?

TSU

[RaveNBlack]

If you want to run X11 over SSH displaying a Windows on a Linux client, you need an X11 display manager running on Windows. Here is the top hit on a Google search
http://www.straightrunning.com/xmingnotes/

Thank you, I'll look into this. This might be a solution.

But, if you're connecting from a Linux client to a Linux Guest, then it's all Linux (the fact the Linux Guest is running in Hyper-V is irrelevant unless you have some kind of special authentication setup). Anything that should normally work in a purely physical environment should work the same when one of the Linux is deployed as a Hyper-V Guest.

I should have stated it clearer. I have Windows 10 Pro Host. OpenSUSE is running in Hyper-V. My goal is to connect from my Win10 host into Hyper-V OpenSUSE guest.

Which leads me to wonder what you're doing in your described RDP connections... Is your RDP client logged into the Windows Guest (you should) or the Windows Host with the Windows Guest visible on the Host desktop (your shouldn't be doing this)?

TSU

I gave this an example, that solves resolution limitation. I.e. connecting from Win10 Host to Hyper-V win 7 guest over RDP (using native Win 10 RDP client) I get well performing full screen Win 7 environment. for that reason I went to XRDP, hopping it will solve my issue with Hyper-V OpenSUSE. Unfortunately, experience of connecting from Win 10 Host (native RDP client) over RDP to Hyper-V OpenSUSE guest running XRDP server is rather slow.

Since I don't really know what my options are, I'm looking for advise on how to get smooth OpenSUSE desktop experience in my setup: Win 10 Host and Hyper-V OpenSUSE guest.

[tsu2]

Thank you, I'll look into this. This might be a solution.



I should have stated it clearer. I have Windows 10 Pro Host. OpenSUSE is running in Hyper-V. My goal is to connect from my Win10 host into Hyper-V OpenSUSE guest.



I gave this an example, that solves resolution limitation. I.e. connecting from Win10 Host to Hyper-V win 7 guest over RDP (using native Win 10 RDP client) I get well performing full screen Win 7 environment. for that reason I went to XRDP, hopping it will solve my issue with Hyper-V OpenSUSE. Unfortunately, experience of connecting from Win 10 Host (native RDP client) over RDP to Hyper-V OpenSUSE guest running XRDP server is rather slow.

Since I don't really know what my options are, I'm looking for advise on how to get smooth OpenSUSE desktop experience in my setup: Win 10 Host and Hyper-V OpenSUSE guest.

IMO Linux has never really solved the remote graphics display performance issue (This isn't a specific openSUSE issue). The Windows GPU architecture is different with far longer than a decade of dedicated work designing the Windows graphics architecture, implementing things like DirectX. In this area, Linux community development of a comparable graphics architecture has fallen short (Possibly the most well known, longest known architecture is OpenGL).

This is why for the longest time you'll see recommendations to not run gaming machines as virtualized Guests, and the recommendation holds true for any high demand multimedia.
Still, if you look in the Virtualization forum, you'll see a few recent threads which are trying to push the current known boundaries on what is possible doing GPU pass through, the idea is to avoid the issues related to virtualized graphics and give the Guest direct access to hardware.

TSU

[RaveNBlack]

IMO Linux has never really solved the remote graphics display performance issue (This isn't a specific openSUSE issue). The Windows GPU architecture is different with far longer than a decade of dedicated work designing the Windows graphics architecture, implementing things like DirectX. In this area, Linux community development of a comparable graphics architecture has fallen short (Possibly the most well known, longest known architecture is OpenGL).

This is why for the longest time you'll see recommendations to not run gaming machines as virtualized Guests, and the recommendation holds true for any high demand multimedia.
Still, if you look in the Virtualization forum, you'll see a few recent threads which are trying to push the current known boundaries on what is possible doing GPU pass through, the idea is to avoid the issues related to virtualized graphics and give the Guest direct access to hardware.

TSU

Hi there. Are you saying I should abandon all hope? My intention is not to run games or do 3D modeling or things of the sort. I intend to manage my photo library (not editing, just tagging, sorting, etc.), manage my media server (NFS share), open occasion office document, that king of work. Or is simply displaying desktop in itself is "...high demand multimedia..." task?

[gogalthorp]

Hi resolutions require high bandwidth. Remember your shooting pictures of the desktop across the wires for remote. In a VM you are limited to the drivers that are available in the guest

[RaveNBlack]

Hi resolutions require high bandwidth. Remember your shooting pictures of the desktop across the wires for remote. In a VM you are limited to the drivers that are available in the guest

Hi gogalthorp, thank you for the input.
I'm not connecting over the network. I'm connecting from Win 10 Host to Hyper-V guest running on the same physical machine. I realize that RDP is designed for over the network communication and it has to be abstracted down, but it all happens in the software, I would't expect that to be a major bottleneck.

as for the drivers - I get that. The question however is, what drivers/setting do we need to use to improve the situation. I'm sure that OpenSUSE comes with Linux Integration Services built in and I refuse to believe that best it can do is 1280x768.

[gogalthorp]

My guess is that you use the Vesa driver in this case and this is the max res it supports. Unless the VM supplies a better driver (Hyper-V doubtful) you are stuck. Maybe try a different VM

[tsu2]

Hi there. Are you saying I should abandon all hope? My intention is not to run games or do 3D modeling or things of the sort. I intend to manage my photo library (not editing, just tagging, sorting, etc.), manage my media server (NFS share), open occasion office document, that king of work. Or is simply displaying desktop in itself is "...high demand multimedia..." task?

If you're photoediting stills, there should not be a problem.

If you're running video, particularly full screen then that likely would be a problem unless you have <very> capable hardware to compensate for software deficiencies.

I don't think you're using a VESA driver at the resolutions you're describing, but your described resolution is <unusually> high for a remote connection. 1280xwhatever is IMO the practical limit (or approximately such) for today's technology on Linux, I've never seen a remote Linux desktop perform at a higher resolution (maybe someone else might, but I haven't).

TSU

[RaveNBlack]

Hi gogalthorp, thank you for the input.
I'm not connecting over the network. I'm connecting from Win 10 Host to Hyper-V guest running on the same physical machine. I realize that RDP is designed for over the network communication and it has to be abstracted down, but it all happens in the software, I would't expect that to be a major bottleneck.

I've just realised how wrong I was. I'm using bridged network adapter, so my RDP traffic DOES travel to my router and back as if I was connecting to a remote server in physical network environment.

I will try to find out how Internal network adapter works in Hyper-V and see if that improves RDP experience.