running Mc-V on a remote machine

[kbedka1]

I recall in discussions at SSEC that the Mc-V development group there had figured out a solution to run Mc-V on a remote machine that does not have a display or graphics card. Colleagues here would like to mimic this setup here. Could someone provide the recipe that will help make this work for us?

[barryr]

Hi Kris,
I forwarded your question to the McV developers in hope that someone in that area can give a better answer. In the meantime, I'll simply note that the only related info I'm aware of are the short blurbs about using xvfb in the McV User's Guide at http://www.ssec.wisc.edu/mcidas/doc/mcv ... index.html and in slides 7 and 8 of the McIDAS-V Technical Issues talk at the 2009 MUG Meeting (PDF and PPT links at http://www.ssec.wisc.edu/mcidas/mug_mee ... tions.html).

Barry

[kbedka1]

Thanks, a lot of this description seems to be related to running scripts remotely. Instead of having to pay to upgrade every user's OS here to run the latest java and Mc-V, we thought that we might be able to do this upgrade on one centralized machine and everyone else could connect into it and use Mc-V remotely. Would this be possible?

We understand that performance would be slower, but it would still give the casual user some experience in using Mc-V and if they were convinced that it would benefit their work, we could then commit financially to give them the capability to use it on their local machine.

[davep]

Hi Kris,

This is a complicated subject and requires a pretty lengthy reply... so here it goes!

One of the big benefits of using McIDAS-V for visualization lies in its use of today's powerful graphics cards. Java3D requires quite a lot of horsepower to create the displays you see, and unlike McIDAS-X it does not directly use the X11 Window System protocol (which is what gives McX its "export DISPLAY=" functionality). Java3D uses OpenGL, which cannot--except under very special circumstances using special drivers--export its display over the network.

There are ways of using Java3D/OpenGL without requiring special graphics hardware on the processing machine (using the Mesa software library--resulting in degraded 3D performance), and this is how we recommend running background scripts on servers without 3D cards. It is also possible to create a "virtual X11 Server" that is not connected to a physical display, but exists in memory on the server. The utility for doing this is called "Xvfb" (for "X11 Virtual Frame Buffer") and can usually be installed using package managers on the server or by compiling from source (see your system admin).

The following assumes that you have Xvfb running on the server, using either Mesa OpenGL libraries or a 3D graphics card with up-to-date drivers:

While the components of the individual display cannot usually be exported, the actual pixels that are being drawn in the virtual framebuffer can. There is a protocol known as "VNC" (for "Virtual Network Computing") that basically takes a picture of your entire desktop and sends it over the network to a VNC viewer on a remote machine. This is inefficient and incurs a lot of overhead for compressing/decompressing the image, but it does work. If you have VNC installed on your server, you would then be able to view and interact with the Xvfb virtual desktop that is running McIDAS-V.

It is also important to remember that McIDAS-V's displays require significantly more memory than McIDAS-X displays. In McIDAS-V you are viewing the actual data, not an 8-bit flat "picture" representation as in McX. For this reason McV by default will attempt to use 80% of available system memory for the Java heap size. You can easily lower the maximum memory usage by running the McIDAS-V Configuration Manager, but you will be further limiting the amount of data that can be imported. Running multiple instances of McV on the same machine is an exercise in memory management, and each running instance will have a maximum of M/N mb memory available, where M is the total system memory and N is the number of McV instances (also leaving some for the OS and other running programs).

Summary:

In short--while it is possible to use a remote McIDAS-V display--there are very specific technical requirements, the performance will be degraded, and it does not scale well to multiple users on the same server.

[kbedka1]

Thanks Dave, this is very informative and useful. I have passed this information on to management...

[jayh]

This posts contains comments from a systems programmer and a user who runs McIDAS-V in the background.

Here are the comments from the systems programmer:

Running any X11 display through VNC *should* work, as VNC exports the entire display's pixels--as opposed to exporting your DISPLAY variable, which just sends the X11 protocol calls over the network--so as long as the frame buffer supports Java3D you should be able to virtualize a McV session (which Xvfb ought to do if built correctly; it needs to be able to connect to things like the graphics drivers and possibly Mesa3D). We don't explicitly support any configuration because they are so dependent on the hardware+software setup.

He also provided the script below, which he said he wrote years ago and "had some logic in it that would do some rudimentary tests to guess if Xvfb would work, and to direct the user in connecting to it". It is provided as-is, with no guarantees that it will work as issued.

Code: Select all

    #!/bin/sh

    # Make sure we are running in the right environment
    if [ -z "${HOME}" ]; then
            echo "HOME is not set"
            exit 1
    fi

    # Displays to try
    DISPLAYS="3 4 5 6 7 8 9"

    # Resoluion to try
    RESOLUTION="1600x1200"

    # Location of Xvfb binary
    XVFB_BIN=/usr/bin/Xvfb
    if [ ! -f "${XVFB_BIN}" ]; then
            XVFB_BIN=`which Xvfb 2>/dev/null`
            if [ -z "${XVFB_BIN}" ]; then
                    echo "Could not find Xvfb" >&2
                    exit 1
            fi
    fi

    # Try to start Xvfb on given displays
    XVFB_PID=
    for XVFB_DISPLAY in ${DISPLAYS}; do

            ${XVFB_BIN} :${XVFB_DISPLAY} -screen 0 ${RESOLUTION}x24 +extension GLX -ac >/dev/null 2>&1 &
            XVFB_PID=$!
            sleep 1

            /bin/ps -p ${XVFB_PID} >/dev/null 2>&1
            if [ $? -ne 0 ]; then
                    continue
            fi

            break

    done

    # If we couldn't start Xvfb, error out
    /bin/ps -p ${XVFB_PID} >/dev/null 2>&1
    if [ $? -ne 0 ]; then
            echo "Could not start Xvfb" >&2
            exit 1
    fi

    echo "Started Xvfb on display :${XVFB_DISPLAY}"
    echo "  runMcV -nooneinstance $@"

    trap "kill ${XVFB_PID}; exit" INT TERM

    # Start McV on Xvfb
    export DISPLAY=:${XVFB_DISPLAY}
    cd ${HOME}/McIDAS-V-System && ./runMcV -nooneinstance $@

    # Stop Xvfb
    kill ${XVFB_PID} >/dev/null 2>&1
    sleep 1

Here are the comments from a user who runs McIDAS-V in the background:

This worked on some machines in the past, but I found that recently, I have had to use vnc. I really struggled to start/stop and access vnc servers consistently. Therefore, I keep a vncserver running on a specific display, export to that display, then run McIDAS-V. The steps seems simpler, but the caveat is that I have to check occasionally to make sure the specific vncservers are running. If they are not running, then I try to start on the same display number. My script looks like this:

Code: Select all

    #!/bin/bash

    # this script checks to make sure that 1,2,4 vncservers are still running....not sure what to do if they are not.
    # there has been an issue with the vncserver improperly leaving locks and not being able to start again.

    source  ~/code/goesrImg/scripts/in_array.sh

    #exclude vnc displays which are currently active from displays list
    declare -a vncserver_displays
    active_vnc_displays=`vncserver -list | sed -n '/^:/p' | awk '{print $1}' | sed 's/://'`

    # check display 1
    function check_display {

        in_array active_vnc_displays $vnc_display

        if [ $? -ne 0 ]
        then
            echo "{$0}:  VNC Display ${vnc_display} is not active"
            vncserver :${vnc_display}
        fi

    }

    for vnc_display in "$@"
    do
        check_display vnc_display
    done

    exit

where in_array is somebody else’s code, but pretty straight-forward…and I am not sure why I source it rather than just putting the function inline.

Code: Select all

    #!/bin/bash
    # function to check if value is in array called by in_array <array_name> <value>
    # example:
    #   declare -a vpsservers=("vps1" "vps2" "vps3" "vps4" "vps6");
    #   in_array vpsservers vps3 && echo "found" || echo "not found"
    #   in_array vpsservers vps5 && echo "found" || echo "not found"

    # From:  https://raymii.org/s/snippets/Bash_Bits_Check_If_Item_Is_In_Array.html  (Bash Bits:  Checking if item is in array
    in_array() {
        local haystack=${1}[@]
        local needle=${2}
        for i in ${!haystack}; do
            if [[ ${i} == ${needle} ]]; then
                return 0
            fi
        done
        return 1
    }

In my scripts, I then call specific vnc servers. This is not ideal, but it has worked for me without building up too many vnc sessions, allowed me to access vnc session for which I have permission.

If the Xvfb route works, [the system programmer’s] script [above] worked very well for me. If it does not, then vnc might be the way to go, though I am not sure the way I have set it up is the best way, it is just what has worked for me.

[joleenf]

The vnc script above is just dealing with the running of the vnc servers. To run a McIDAS-V script using the vnc virtual display, make sure the bash shell is exported to the number of the vnc display, then run the script. This is similar to what is done inline for the Xvfb script.

Code: Select all

#!/bin/bash

# set up paths (if not already done)
test -n "$mcv_path" || export mcv_path=${HOME}/McIDAS-V-System
test -n "$script_path" || export script_path=${HOME}/scripts

# export to running vnc display
export DISPLAY=:4

# run the mcidas-v script
sh $mcv_path/runMcV -script $script_path/myScript.py

Joleen