eRSA Services Transition

The closure of eRSA prompted ITDS to establish an eRSA transition project team. This team is focused on ensuring that our researchers continue to have access to eRSA Virtual Machines (VMs) and stored data.

What has happened so far

In November 2018, eRSA’s board advised us that it would close in the first half of 2019. Early in 2019 eRSA advised the University that there would be no IT support beyond March. This identified a need for us to implement short-term solutions for our researchers’ data and compute needs. Throughout this period, we engaged with Intersect to conduct a discovery of our eRSA compute.

The Discovery phase of transitioning from the eRSA infrastructure to Intersect was completed. Thank you to those of you who provided us with relevant information and engaged in the testing processes. Intersect has presented their transition and support proposal to the university and DRI has committed to working with Intersect moving forward. The proposal from Intersect includes us having a dedicated eResearch Analyst to provide support to you and bridge the gap between our organisations. The plan is that this analyst will be employed before the end of the year.

During September and October we will be moving those of you that have confirmed you need us to move your eRSA compute and storage into Intersect. We will contact the key contacts of the compute and storage to confirm that the proposed times to move are suitable, as there will be some scheduled outages throughout the move.

Reference group

A reference group, which consists of around 10 eRSA users, has been established to provide the project team with specific research advice and support the project to make your transition to the new solution smooth. Some of our reference group members have been involved in testing and trialling our ongoing solution with Intersect.

How you will know when you will be impacted…

We are working directly with the nominated key contact of the VM or data share, who will liaise with the owner and their teams to schedule an appropriate time for the move. The key contact will provide us with the details of the people who need to be given access to the VMs and data share at Intersect. There is also a link to the transition schedule below.

How the move will work…

There are a few processes that we are going to follow for the transition, so we’ll send the key contacts a more detailed email that is specific to their compute and storage. But in a nutshell, where there is a VM being copied over as it is, there may be a 2 day shutdown where it will not be able to be accessed. A VM that is going to be rebuilt from scratch will not be impacted by downtime. For data shares, Intersect will start copying it over in the background and when the moving day comes, no-one will be able to access it until any changes that have been made since Intersect has last copied it are also copied over. Hopefully this is restricted to a few hours, but we won’t know until the day.

Contacts throughout transition and project period

If you have any information to share or ask of us in relation to the transition, you can email us at or call John Harpas (our project manager) on 8313 5303.

We’ll communicate with you when the time comes to engage directly with Intersect for all ongoing support.

For all other IT support needs you can continue to contact For any technology issues that require urgent attention please contact the ITDS Service Desk on 08 8313 3000.

Click through these tabs to read further information relevant to you

If you have either a VM or data stores moving to Intersect, we will send the key contact an email with details of a shared folder in Box where we can share any information such as other users who access your compute or access keys for the move into the Intersect infrastructure. Your key contact is either the owner of the VM or data store, or a person they have nominated.

How do you keep updated with the move…

The project team will update this page regularly as we have more information.

Overall Schedule:

We'll be updating the overall schedule as we work through the transition so you can keep an eye on the progress as dates may change. When it is your time to move, we will contact our key contacts directly to confirm dates.

Virtual Machines:

You can click on the VM schedule to keep an eye on the timing of the upcoming outages that may affect you. But remember this document will continue to be updated throughout the transition.

Data / Shares:

You can click on the share schedule to keep an eye on the timing of the upcoming times that the data will be copied over to Intersect. This will give you an indication on when you will transition over to Intersect.

We need you.

If you have a VM or data store moving to intersect, please make sure:

  • You have reviewed and completed the relevant parts of the checklist (a link to the checklist will be emailed to you). This is where you can provide us with information such as a public ssh key, other users, etc
  • You have confirmed your availability to engage with us at the start of the testing timeslot to work through access with Intersect and then test and verify that your compute at Intersect is up and running successfully. If there is any need to change the date, contact us asap at email
  • After you have spent time reviewing and testing your data or VM, please send us a confirmation email to confirm that your new location at Intersect is up and running successfully.

Impacts on others

We are working directly with the key contact of the data and VMs, with little contact with other users. If you are our key contact and you know of other researchers or students that you have given access to either your data or VM, you’ll need to let them know about your outage, and let us know what impacts the transition will have on them. In addition, if you would like us to retain their access after the transition, please let us know via or the email address that Giacinta has or will send you.

Once you have transitioned, you may find some of the information on the Intersect pages are of interest to you.

Intersect refers to things with some slightly different names to us. Here are a couple of things you may want to know about. We'll update this list as the project progresses:

Space = storage. Intersect has various ‘space’ offerings that you’ll hear about. The main terms that you will come across are:

  • DeepSpace for your archived data. DeepSpace is a low cost storage solution for researchers requiring long-term networked data storage. Three synced copies of your data are stored on tape and disk at two different locations, so you can be confident of integrity and security.
  • SpaceShuttle is a storage solution that securely transfers, stores, manages and shares large amounts of active research data. Data is read, written, copied or moved over the Internet at maximum speed using the most efficient transmission technology available. SpaceShuttle uses a combination of disk and tape with two copies stored on tape so you can be confident of its integrity. (Check out
  • SpaceVault - SpaceVault is used in conjunction with SpaceShuttle to offer an extra level of security over your data, especially when shared with others. SpaceVault enables restoration of your data to an earlier point in time.

Time = VMs (our virtual machines). Intersect has various time offerings. Ours is under the CloudTime umbrella which offers a range of Openstack cloud deployment models, including private, public, and community offerings. The main term you will come across is:

  • OwnTime - which supports several operating systems, a range of virtual configurations, and provides a large number of pre-built images that can be used as the basis for your own Virtual Machines (VMs), without having to configure the entire system.

Hosted VM - means Intersect does all the system admin such as patching and adding and removing users

Self-managed VM - means the Researcher gets "sudo" access and needs to initiate their own patching requirements and add and remove users

Sudo - allows users to run programs with the security privileges of another user, by default the superuser

VM relocate

This means your VM will be copied and moved as it is to Intersect infrastructure.

Benchmark Validation

Intersect suggests you conduct a short test by running a job prior to the move. You can do it now, or if you have a recent one, you can choose to use that as a benchmark. After the move, you will be asked to run the exact same job to ensure that all is working well in the new infrastructure.

SSH public key

Intersect require an SSH public key for you and all users who access your VM. Click this link if you need information about how to generate this key:

Please save your public key file name starting with your first name followed by your last name with no space, eg JohnSmith.

Prior to your moving day you'll need to provide your key contact with your public key, so that they can save it in their Box folder. Without this we cannot give you access to the VM.

Stop using it

Intersect needs you to ensure you are not running any jobs on the days we have scheduled you to move. Any jobs you have running leading into the move will be stopped. You will no longer have access to the eRSA VM from the nominated days.

We will send your key contact a meeting request following the moving days. This is where the key contact will commence the benchmark validation and we will assist to resolve any issues relating to logging in, or working with your machine. We need confirmation that the test in the new environment has been successful.

VM rebuild

This means that the key contact will be given a new VM to install software and set up as required.

A VM that is going to be rebuilt from scratch will not be impacted by downtime. Once the key contact validates that their VM has been successfully rebuilt, the access to the eRSA VM will cease.


In order to have access to space using Aspera GUI, every researcher needs to log in to using UofA credentials. This step will enable Intersect to add you to the right space.

Copying in the background

Around the time of your moving day, Intersect will start taking a copy of your data in the background. Through this process, you can continue accessing it as you currently do through the eRSA infrastructure.

Stop using it

On your moving day, you will not be able to access your data. Intersect needs this drive to be inactive so that they can capture the final version of your data. Once this is done, you no longer have access to the eRSA storage, but will access your data from its new home in Intersect. You’ll need to contact any researcher that also accesses your data to ensure they are aware of the shut down, and the new way of accessing the data.


Folders in Intersect can be set up with restricted access. We can set this up if you let us know your requirements.

Accessing Shares (pre and post migration)

Here are some links to access your data shares:

● Generate SSH key

● Data transfer using SFTP

● Data transfer using

 Accessing Space from my VM

A key part of our membership with Intersect is the services of an on-site eResearch Analyst. This analyst will work within DRI and will be your key support person for any issues or requests relating to your Intersect data or VM's. They have not been employed yet, but we will let you know when they join our University team.

Intersect have given us some support links: 

How to log out/log in

1. Go to, then click on your name on the top right corner, finally click Sign out. 

2. After that, click again on it should ask you to log in again.

How to sign in from an incognito window

1. Open an incognito window, If you are using Google Chrome, please press:

  • SHIFT+CMD+N for Mac Laptop or 
  • CNTRL+SHIF+N  for Windows machines.

2. After that, sign in again by clicking on any of the links, for instance