This applies from 7th October 2021.

On the first Thursday of each month, security and feature updates are applied to the CentOS Linux VDI systems.

This takes place sometime after 19:30 UK local time (and only after the Windows VDI updates have finished).

Examples of the updates applied are non-critical security updates, new software, and necessary reconfiguration to allow features to still work.

In general, software is not upgraded unless necessary and unless patches have been released by official upstream maintainers (CentOS, or ECMWF, for example).

Change of hostname

After the session you will need to log in again using graphical access (Horizon client or browser) and note the hostname, which may have changed, for future SSH connections.

If you try to log in using your old system hostname without the graphical step, it might work, because you will connect to someone else's VDI session!

Long-running processes

If you wish to have long-running processes for more than one month (for example an ecFlow server), then we have better alternatives to CentOS VDI.

Dedicated ecFlow servers can be instantiated for you, on request. For other cases, please use the Support Portal to ask for advice.

As part of the Bologna End-User Operating Model, the CentOS VDI is a graphical presentation layer for HPC resources in the data centre, and not intended for long-running processes or compute work.

10 Comments

  1. Hello, is it possible to have a tool similar to 'ws_of' that would say what is the current hostname of the assigned VDI? Example:

    # vdi_of sycs
    
    lx-vdi-001
    1. Yes, but no.

      If the user has logged into the Linux VDI pool in Horizon, then yes, because I can create a script that finds out which VM (if any) is assigned to a specific user.

      But otherwise, no, because nobody will have a VM assigned to them unless they have logged in.

      Have in mind that we overprovision. We don't have a VM up and running waiting for every user entitled to log into it. They're created instantly when an user logs into it and destroyed upon logout..

  2. Hi all, how long is the disruption to the VDI Linux sessions?

    1. Hello. This is the first time that I'm going to do it in an entirely new way, but it shouldn't take more than 5 minutes. Most likely even less than that, but the data I have at this moment comes from a much smaller testing pool, so I don't know for sure yet.

      Basically, I will prepare the master image so at the next logon you will get the new release, then I'll force a log out from all the running VMs.

    2. To be more accurate, the entire process is likely to take more than five minutes, but the disruption of the service shouldn't take that long.

      Basically, it goes as follows: At 19:20, the new base image is set to replace all the existing VMs, but not all will be dealt with at the same time, and it's impossible to predict the exact moment yours will be targeted.

      At some moment after 19:20 all VMs that have NOT running sessions will be shut down and upgraded automatically. All VMs with running sessions will display a message box to the user saying that in 10 minutes the VM is going to be shut down for maintenance. After those 10 minutes have passed, your session will be logged off, your VM shut down. You should be able to login right away because there'll be spares with the new image ready to go.

      Hope this helps.

      1. Thanks a lot for the info!

        1. Anytime. We may change this in the upcoming months to minimise disruption if we find a good way to do so. Maybe something similar to the Windows updates that can be deferred for a couple of days before the reboot is enforced

  3. On the new redhat system at least (never looked on centos) I can't find any kind of session manager which will save all my windows/apps so I can quickly restore my setup over multiple workspaces after a reboot. Is anything like this available, or could be made available?

    1. I'm looking into this, yes. If you know of a good extension or app that can achieve this in Gnome please let me know so I can consider it

    2. This one looks interesting:

      https://github.com/johannesjo/gnome-shell-extension-window-session-manager

      However, not being an RPM in a standard repository would make its maintenance harder, and we're trying to run away from everything that is not in a repo (the only exemption, for now, is ecflow)