Configuring CentOS 7, ParaView and Oracle VM VirtualBox on Windows 7

Question

I am attempting to run OpenFOAM 2.3.1 on an installation of CentOS 7, running inside a virtual machine hosted by Oracle VM VirtualBox on a Windows 7 machine. I am not trying to use any remote tunneling, SSH etc, it is all local. The exercise is proving disastrous.

startx starts bringing up the gnome interface, with the 'first time install' window. However in the virtual machine, the GUI ignores all input and effectively all I can do is kill and restart the VM. Not even Ctrl+Alt+F2 etc will switch to other terminals.

With Paraview or xhost or anything else on the command line no matter what I export the DISPLAY variable as, the result is:

xhost: unable to open display "localhost:0.0"

or

xhost: unable to open display

or whatever $DISPLAY returns.

What I would like to know is effectively what are the ways in which the system could be broken, what exactly to look for in the stack of technologies as evidence of faults, where any settings are stored, and what things may well be the key to getting this working.

• Machine operating system: Windows 7 Professional
• Virtual machine manager: Oracle VM VirtualBox Manager 5.2.18
• Virtualised operating system: CentOS 7 3.10.0-862.14.4.el7.x86_64
• OpenFOAM version: 2.3.1

Update 1:

It turns out, xterm was not installed. I have run yum install xterm on an attempt to run xinit. There is a new behaviour, a GUI window with only xterm visible. Again, no input is being accepted. I will now have to restart the machine.

Update 2:

Attempting to reinstall VBoxLinuxAdditions.run the kernel build reveals "ERROR: Kernel configuration is invalid."

Answer 1

The problem of "no input" might be as simple as not having the correct drivers for mouse installed. VirtualBox throws a bit of a curve ball here, as it might be representing the mouse to the VM as a drawing tablet device, to better handle situations like when you move the mouse cursor out of the left side of the VM console window, move it around the window and then back in the right side. A regular mouse cannot "jump" like that, but a tablet device can. I think this is handled by xorg-x11-drv-evdev RPM package.

If you don't have your X11 mouse driver in order, the mouse cursor might be stuck in its default location. If you use plain xinit, you must at least bring the mouse cursor on a window to focus it: if you can't do that, the situation might appear like all input is ignored.

The problem of Control-Alt-F1 not working might be as simple as Windows stealing all keystrokes that include Alt as menu shortcuts, so your keystroke might not even reach the VirtualBox intact, let alone the VM. With a VM, it might be easiest to establish basic networking, so that you can have a SSH connection to your VM in another window while trying to get the console X11 graphics working.

In your other question you said there is nothing in the logs - really? The main log file in X11 GUI matters would be /var/log/Xorg.0.log. If there is nothing in there, make sure your filesystem has some free space left. X11 GUI system needs to write a few tiny files when starting up the X server and a few more when starting a user session, and if it cannot do that, it will usually behave very badly.

Paraview - or any other X11 GUI application for that matter - will attempt to connect to the X server as specified by the DISPLAY variable. If there is a hostname before the colon character, this connection is established as a TCP connection into a port number that is calculated as (display number + 6000). So if you specify DISPLAY=localhost:0.0 and there is no X server listening on local TCP port 6000, it isn't going to work.

Modern Linux X servers don't generally listen on TCP ports unless you specifically enable that old-style, horribly insecure remote X11 access. You don't want to do that.

Instead, when you specify DISPLAY=:0.0 without any hostname, a UNIX socket is used to communicate with a local X server: specifically, the socket for display 0 is expected to be at /tmp/.X11-unix/X0. This is inherently protected against remote attacks and allows several local-only X11 protocol extensions which in turn allow for much more efficient graphics rendering.

xinit is the absolute lowest-level tool to start a real X11 session. As you saw, its defaults are such that it starts an absolute bare-bones-with-holes-in-them-for-lightness X11 session that is only good for diagnostics and not much else. startx is a wrapper around xinit that provides a much more meaningful user session by default: it uses whatever is configured as the default GUI desktop environment or window manager. In CentOS the default is probably GNOME... assuming you have it installed. You should have the gnome-session RPM and its dependencies installed.