Basic Science Cloud Usage

Last modified by Administrator on Wed, 05/08/2024, 1:31 PM
Page Rating
0 Votes


The page layouts presented here may look different depending on the device used.

Logging In

Go to the Science Cloud dashboard at Enter the User Name and temporary Password sent by the COARE Team via e-mail.



After logging in, the page will be redirected to the OpenStack Dashboard. The default landing page is the project's quota overview and usage summary:


On the left-hand side portion of the page is the Navigation Bar containing different tabs for various operations: 

    •    Manage compute resources
      •    Show project quota and usage
      •    Manage instances (virtual machines)
      •    Manage volumes (virtual disks)
      •    Manage images
      •    Manage SSH key pairs
      •    List relevant API addresses
    •    Manage network resources
      •    Show a diagram of configured networks
      •    Manage project networks
      •    Manage routers
      •    Manage firewall policies and rules
      •    Manage inbound and outbound IP protocols (e.g., ICMP, TCP, UDP, etc.)
      •    Manage load balancers
      •    Manage floating (public) IP addresses
      •    Manage stack using template and environment sources
      •    List supported resource types (AWS and OpenStack)
      •    List versions of stack templates
      •    (Deprecated) Manage object storage containers
      •    Lists various information about the current system (some parts are for admins only)
    •    List all projects (for admins only)
    •    List all users (for admins only)
    •    List all user groups (for admins only)
    •    List all user roles (for admins only)

The following options become available when selecting the user settings as discussed in the next section:

    •    Modify dashboard settings
    •    Change user password

Dashboard Settings

Upon successful log in, the user's dashboard settings can be accessed by navigating to the upper right corner of the dashboard, click your username (in this example, ), then click :  


On the left portion of the screen, the options  and  will appear: 


User Settings

Here, the following dashboard settings can be changed: LanguageTimezoneItems Per Page, and Log Lines Per Instance:


Change Password

To change the user password, enter the Current password, then the New Password and Confirm new password:


We highly recommend that users change the provided temporary password upon first log in. As the description indicates, we also highly recommend that you create a strong password by using at least eight (8) characters using a combination of uppercase and lower case letters, numbers, and symbols.

Key Pair Management

Before creating any instance, it is very important to first set up key pairs as these are the way to access created instances. Key pairs are similar to SSH key pairs composed of a pair of corresponding public and private keys. Navigate to the Key Pairs section in the Dashboard by selecting    in the Navigation Bar. Two options are available:  and .

Create Key Pair

This action will generate a new SSH private key. Fill in Key Pair Name, then click :


A download prompt will automatically appear. Give the file a name with a .pem extension (such as test.pem) and download it where you can locate it later on. If for any reason you weren't able to download the file, you can click the  button:


Just make sure to download the file immediately because once you exit the "Download Key Pair" page (by clicking other links or reloading the page) this option will no longer be available. If the page is reloaded, it will change to the list of created Key Pairs:


Clicking on the Key Pair Name reveals the corresponding Public Key:


It is the Public Key that will be injected into the instance upon creation later on so that it can be accessed via SSH.

The Fingerprint information for the key is important because we can use this information to verify that the downloaded Private key corresponds to the indicated Public Key. To do this, in a Linux/Unix/MacOS terminal or Windows PowerShell, use the following command:

ssh-keygen -E md5 -lf <path/to/priv/key>

For Linux/Unix/MacOS systems, the command may run into a warning saying that the private key file is unprotected, like so:


This can be easily fixed using the following command:

chmod 400 <path/to/priv/key>


Take note of the resulting MD5 fingerprint to confirm that it matches the fingerprint indicated in the Key Pairs dashboard.

Import Key Pair

Another way of adding a Key Pair is to import a preexisting SSH key.

In your Linux/Unix/MacOS terminal or Windows PowerShell, create an SSH private and public key pair (skip this if you already have an existing SSH key pair and you wish to append the public key of that key pair).

Then, go back to the Key Pairs dashboard and click the  button to display the Import Key Pair window:


Give this key a name, paste the public key in the Public Key box, then click the  button to add the key pair under your account.

Image Management

A working Image is a very important requirement prior to creating instances as it is the source of the instance's operating system (OS) and its configuration during creation. Metadata information, such as account creation and SSH key injection, are also automatically handled by the image. Publicly-available images (i.e., images from the same or other projects that are set with Public visibility) are listed under the  tab in the Navigation Bar. Here, preconfigured images are available for use, but users may still opt to upload their image of choice as described in the OpenStack "Get images" documentation.

Create Image


Make sure to download images only from reliable sources to avoid possible security issues in the instances created.

To create an image for the project, go to the   tab in the Navigation Bar, then click the  button to display the Create Image window:


Fill up the required fields indicated by asterisks. More information on the fields are described in the OpenStack Upload and manage images documentation.

On the next page, the image's metadata may be configured:


The OpenStack Useful image properties documentation lists some image properties and their supported values which can be used to configure the image to be created. However, please note that there may be discrepancies in the properties available in the dashboard compared to that in the online documentation. In most cases, it isn't necessary to define metadata properties to the image.

Security Groups Management

Security groups control network traffic going in (ingress) and out (egress) of the instances similar to how network firewalls work. Go to the   tab in the Navigation Bar to manage your project's security groups.


The default security group contains the following network rules:


The above rules allow all outgoing (egress) network traffic to the internet (::/0 for IPv6 and for IPv4) through all ports and IP protocols. For incoming (ingress) traffic, the default security group (itself) is used, but there are no ingress rules defined in the default security group. Therefore, the default security group only allows outgoing traffic to all IPv4 and IPv6 addresses, and no incoming traffic is allowed from anywhere. This is intended by design to help secure the instance from unauthorized and malicious access. However, to be able to access the instance — for example, ping (ICMP); logging in using SSH; HTTP (port 80) and HTTPS (port 443) for web server instances; etc. — ingress traffic must be allowed. Therefore, a new security group will be created.

Create Security Group

To create a new security group, click the  button:


Give it a Name and Description. For this example, the new security group will be named minimal to allow incoming traffic for SSH (port 22) and ping (ICMP). Then, click the  button. After creation, click the  button to configure the security group's network rules. By default, all outgoing (egress) traffic are allowed in the new minimal security group like that in the default security group:


Add Rules

Click the  button to show the following window:


To allow SSH logins (via TCP port 22), select under Rule, under Remote, and type in under CIDR to allow incoming access from all IPv4 addresses. Click to add the rule. Add another SSH rule but this time set the CIDR address to ::/0 to allow incoming access from all IPv6 addresses. The CIDR addresses may be modified to allow incoming requests only from a specific IP address (e.g., equivalent to or a range of IP addresses (e.g., For more information about this notation, here is a quick overview on Understanding IP Addressing and CIDR Charts.

After creating both rules, the security group will look like this:


To be able to ping instances, the ICMP rule must also be allowed for ingress traffic. Do the same steps outlined above for SSH, but use  instead of under Rule. The minimal security group should now look like this after adding SSH and All ICMP ingress access from all IPv4 ( and IPv6 (::/0) addresses:


In the future, additional IP protocols and ports (or port ranges) may need to be opened for other applications and protocols, such as, among others:

Additional security groups with additional rules should be created to accommodate any new ports that need to be opened in your instances.

Instance Management

Create Instance

After the key pair, image, and security group are configured, the project's first instance may now be created. When creating an instance, make sure to use the least amount of resources possible (e.g., virtual CPUs, memory, disk size) first which can be gradually resized later on. It is also not advisable to create instances with large root disk sizes (e.g., more than 20 GB) for storage purposes because it will be almost impossible to recover data when the instance fails and there is no instance snapshot. Instances should only contain the bare minimum disk requirement for the operating system (OS) to run smoothly. Create and attach additional volumes instead for storage purposes.

From Image

The recommended way to create a new instance is from an image.

Go to the   tab in the Navigation Bar, then click the  button to show the Launch Instance window:


Give it an Instance Name, and keep the other settings as is (i.e., Any Availability Zone under Availability Zone, and 1 under Count). For this example, the instance name was set as test which will also become the instance's hostname later on.

Click  to configure the instance source:


Before you proceed...

If the Device Name field does not appear, reload the page in the browser.

Choose the option under Select Boot Source, then select for Create New Volume to create a new root volume for the instance. Set the Volume Size (GB) for the root volume (minimum should be 20 GB as dictated by the different flavors, to be discussed further). Set for Delete Volume on Instance Delete if you want the volume to be automatically deleted when the instance is deleted. For Device Name there are two possible options: vda or sda; the default is vda, but if this results in errors later on, then you can try setting sda instead. Select the image to use from the list of available images by clicking the button. Only one (1) image may be selected.

For this example, the image Ubuntu 20-04-focal-server-lts was used:


Click  to configure the instance flavor:


The flavor defines the instance's virtual resources, such as CPUs (VCPUs), memory (RAM), and root disk size (Root Disk). Be mindful of your project's resource quotas. Select the flavor to use from the list of available flavors by clicking the button. Only one (1) flavor may be selected.

Click  to add a network to the instance:


In the networks listed, select only either int-vlan-network (for internal users, i.e., ASTI users) or ext-vlan-network (for non-ASTI users) by clicking the button. DO NOT use either the 159-pub-network or public_v6 network as this will make the instance unreachable.

Skip the Network Ports tab and go directly to the Security Groups tab:


Here, add the minimal security group previously created by clicking the  button. Multiple security groups may be attached to a single instance. Click to proceed to the Key Pair tab:


Select the appropriate key pair by clicking the  button. Only one (1) key pair may be attached per instance. Click  to proceed to the Configuration tab:


Add any configuration script that you may have either by pasting directly into the Customization Script box or by attaching a file under Load script from a file. One useful example of a customization script is setting the root password during instance creation which may be useful later on when logging in via the instance's console.

Select Automatic for Disk Partition; if you'd like to configure the disk partition yourself, then select Manual instead. Check the Configuration Drive box to create a special partition within the instance where metadata are stored, such as the instance name (which will be used as the instance hostname), etc.

After the Configuration tab, the next tabs may be skipped. Click the  button to finally create the instance which will take the page back to the Instances tab to show that the instance is being created:


After some time, if the instance creation is successful, the Status will be changed from Build to Active:


The instance log should be inspected to confirm that the SSH key pair has been successfully appended. Click the hyperlinked Instance Name, then navigate to the Log tab to show the Instance Console Log:


You can click the  button to show the entire console log. There should be lines that look like that below saying that the authorized_keys have been updated (this is already partially visible in the screenshot above):

ci-info: ++++++++++++++++++++++++++++++++++Authorized keys from /home/ubuntu/.ssh/authorized_keys for user ubuntu+++++++++++++++++++++++++++++++++++
ci-info: +---------+-------------------------------------------------------------------------------------------------+---------+-------------------+
ci-info: | Keytype |                                       Fingerprint (sha256)                                      | Options |      Comment      |
ci-info: +---------+-------------------------------------------------------------------------------------------------+---------+-------------------+
ci-info: | ssh-rsa | 09:57:6e:59:8e:02:ff:fb:c8:a9:42:3d:29:13:6a:0f:5e:e7:39:5e:72:2b:0f:9d:b4:42:83:7b:ad:e5:1b:bc |    -    | Generated-by-Nova |
ci-info: +---------+-------------------------------------------------------------------------------------------------+---------+-------------------+

As per the OpenStack Get images guide, the default username for Ubuntu images is ubuntu, hence the key pair was appended to /home/ubuntu/.ssh/authorized_keys. For other images, such as those preconfigured by the COARE Team, the default username is indicated in the image's description. However, the SHA256 fingerprint of the key appended to the instance as indicated in the console log does not match the actual SHA256 fingerprint of the key. Please don't worry about this discrepancy as this seems to be only a bug in the current OpenStack implementation. The right key was still injected into the instance which is apparent in the successful SSH log in to the instance as discussed further.

From Instance Snapshot

Create a snapshot of your instance first as discussed further down. Then, follow the same steps above for creating an instance from an image because instance snapshots are stored as images in OpenStack. This is a good way of creating a working back up of your instance(s) which can be recreated as another instance especially when the original instance fails beyond repair and recovery.

Access the Instance

Accessing an instance after creation will depend on how the rules of its attached security group(s) is/are configured. In order to be able to access instances attached to either the int-vlan-network ( or ext-vlan-network (, connection to the appropriate COARE virtual private network (VPN) is required.

In the previously created instance, its IP address allocated under the ext-vlan-network is (see the screenshot above).


To check if the instance is indeed up and running, the ping command may be used. To ping the instance, make sure that the VPN is connected, then in your local machine's terminal:

$ ping  # change IP address accordingly

The instance will respond if the VPN is connected and if the incoming ICMP access is allowed in the instance's security groups:


However, if any of the above conditions aren't met (i.e., the VPN is not connected, incoming ICMP access is not allowed in the security goups, or both), then the instance won't be reachable:



To log in to the instance via SSH, make sure that the VPN is also connected and incoming SSH access is allowed in the instance's security groups. In your local terminal:

$ ssh -i <path/to/priv/key> <username>@  # change IP address accordingly

For the same test instance, this is how a successful SSH log in should look like:


The access transitioned from the local Inspiron-5584 machine with username demo to the remote test hostname with user ubuntu. To demonstrate that the machines are not the same, the ip -brief all (shortcut: ip -brief a) command was used on both the local and remote machines to determine their respective network intefaces/devices and their corresponding IP addresses. The above screenshot also indicates that the ubuntu user is an administrator account in the instance which is the default for all images. Thus, users are free to configure their instances up to the system level as they have root access to their instances, including but not limited to, creating additional accounts for other project members, installing various applications, etc.


In default images (i.e., images that have not yet been preconfigured), the default user is passwordless. That is why making sure that the right SSH key pair is injected into the instance is critical for access. Therefore, access via console is not yet available immediately after instance creation.

For preconfigured images, check the image description or ask the COARE Team regarding the default login credentials. For default images, a password for the default user may be set. Log in to the instance via SSH as described above (remember to connect to the appropriate VPN first), then log in as root and change the default user's password using the following commands:

ubuntu@test:~$ sudo -i
root@test:~# passwd ubuntu  # default user

The same commands are applicable for other Linux distributions as well, such as CentOS, Debian, Fedora, etc. A notification will be printed when the password is successfully set:


Console access is now possible for the default user (or any other user created in the instance) after successfully setting a password. Console access is similar to a direct log in into a physical server. To do this, keep the VPN connection active as it is necessary to access the instance's Console tab. Navigate to the instance's Console tab in the dashboard:


Click the "Click here to show only console" link to get started. This will display only the console in the entire browser window. Now enter the username and password for the user you wish to log in. After successfully logging in, it will have a similar interface when logging in via SSH:


Similarly, a password may also be set for the root user to be able to log in directly via the console:

ubuntu@test:~$ sudo -i
root@test:~# passwd

Backup Instance

Create Instance Snapshot

An instance snapshot captures the instance's state at the time the snapshot is created. This can be easily done by either clicking the  button at the rightmost portion of the instances list:


Or, by clicking the Instance Name, then clicking the same  button at the top right portion:


After clicking the aforementioned button, the Create Snapshot window will appear where the Snapshot Name should be provided:


After creating the snapshot, the page will be redirected to the  tab in the Navigation Bar. Repeatedly click any of the headers (OwnerName, Type, etc.) until all the images under the project are at the top of the list including the created snapshot:


In the    tab of the Navigation Bar under the sub-tab, a volume snapshot is also saved for the instance snapshot:


Other Instance Operations

1699193326309-147.pngOther operations may be performed on instances in the Instances dashboard:

  • Associate Floating IP: Add a floating (public) IP to an instance.
  • Attach Interface: Add a new interface/connection to a network.
  • Detach Interface: Remove a network interface/connection.
  • Edit Instance: Change the instance's name and security groups.
  • Attach Volume: Add a volume as a new disk device to the instance.
  • Detach Volume: Remove a volume from the instance. The volume contents are not affected.
  • Update Metadata: Edit the instance's metadata.
  • Edit Security Groups: Manage the security groups applied to the instance.
  • Console: View the instance console (needs VPN connection).
  • View Log: View the Instance Console Log.
  • Pause Instance: Puts the instance in a state similar to "Sleep" in personal computers.
  • Suspend Instance: Places the instance in a state similar to "Hibernate" in personal computers.
  • Shelve Instance: Shutdown the instance and store it together with associated data and resources. A snapshot is taken if the volume is not backed. Note that anything in memory of the instance (e.g., running applications, data read/write to disk, etc.) will be lost.
  • Resize Instance: Change the instance's flavor.
  • Lock Instance: Prevents deletion of the instance.
  • Unlock Instance: Allows deletion of the instance.
  • Soft Reboot Instance: Attempt a graceful shutdown and reboot of the instance similar to issuing a reboot command within the instance.
  • Hard Reboot Instance: Does not wait for a graceful shutdown similar to pressing and holding the power button of a physical machine until shutdown.
  • Shut Off Instance: Turn off the instance.
  • Rebuild Instance: Rebuild the instance from an existing image.
  • Delete Instance: Delete the instance. WARNING: This operation is not recoverable once finalized.