Skip to content

3. Create and Manage Virtual Instances

2.1 Instances

An Instance is a virtual machine (VM) that runs inside ScienceCloud. When you start a new instance it is never automatically deleted, so we kindly ask you to terminate the instance whenever it's not needed anymore in order to free up resources from the system.

To start an instance, you have to choose:

We define quotas on a per-project basis, and you check whether you are under quota on the web interface when you try to start a new instance. However, being within your quota does not guarantee access, as it might be possible that during peak periods ScienceCloud will not have enough resources to start your instance even though you are well under your quota.

You can also refer to the following official OpenStack documentation on how to manage your instances:

IMPORTANT: Whenever you terminate an instance, its root disk is deleted (i.e., it is permanently gone). To save your data, please:

  • Save your important data on an external storage device (e.g., your laptop or external hard drive).
  • Use a Cinder volume to store your data.
  • Make a snapshot of the root volume of you instance (e.g., make an instance snapshot).

2.2 Images

On ScienceCloud you don't have to install the operating system when you start a new virtual machine. Instead, we provide bootable disks ready to use so that within one minute you can log in to your new instance. These prepared disks are called images, and they are basically files containing bootable virtual disks. We provide a basic selection of images (i.e., operating system varieties), but you can also create your own and upload it to the cloud.

IMPORTANT: Whenever you terminate an instance, its root disk as well as ALL of your customizations are deleted. The base image, however, is never deleted.

Get more information about ScienceCloud Supported Images here.

How to upload and manage images you create:

  • Upload an image

    • Note: When uploading an image, we STRONGLY recommend to convert it to RAW format. Because of the storage backend system we are using, this disk format is the preferred format for the following reasons:

      • Instances are faster to startup.
      • Creating a snapshot is faster and uses much less space.
      • Creating a volume from an image is faster and uses less space.

  • Create a new image from a running instance

    • Note: Some of the images already present are quite basic images that you can run and customize. In order to make your customizations persist, you have to create a new image from a running instance. This is called a snapshot.

      A snapshot is an image created from the virtual disk of a running instance. However, to create a consistent snapshot you need to ensure that no file writes are performed on the filesystem while you create the snapshot. Furthermore, all dirty data, metadata, and log information must be flushed on the device before snapshotting.

      The following procedure ensures creation of a consistent snapshot:

      • Log in on the virtual machine and become root (use the sudo su command).
      • Run the sync command.
      • If you have any Cinder volume mounted, run fsfreeze -f <PATH> for each of them (where <path> is the directory path in the filesystem). For instance, if you mounted the cinder volume /dev/vdb to /data, run the fsfreeze -f /data command.
      • Run the fsfreeze -f / && sleep 120 && fsfreeze -u / command. This will freeze the root filesystem, wait for 120 seconds, and unfreeze it again. It is important to run the command as a single line because while the root filesystem is frozen you will not be able to issue any additional commands. Adjust the sleep time of 120 to the number of seconds needed to create the snapshot. If 120 is not enough, just increase it.
      • If you have any Cinder volume mounted, unfreeze it with the fsfreeze -u <PATH> command.

      Now login to the web interface https://cloud.s3it.uzh.ch:

      • Click on Instances from the Compute dropdown menu.
      • Locate the instance of interest on the table, then click on the Create Snapshot button corresponding to the instance you want to create a snapshot of.
      • Select a snapshot name and click on the Create snapshot button to finalize the process.

      The snapshot will be visible in the Images & Snapshots link on the left panel, and it can then be used to create new instances.

      Check this blog post for further information on how to perform consistent snapshots in OpenStack.

  • Update an image

  • Delete an image

2.3 Flavors

A virtual machine flavor describes the size and kind of resources that will be allocated in a virtual machine. It is basically a combination of the number of CPUs and the amount of RAM composing your virtual machine, plus the flavor "type".

A flavor type is a group of flavors that have common features, but vary only in the size. For example the ratio between the number of virtual CPUs (henceforth: vCPU) and the RAM amount can vary between each flavor type, but is always the same for flavors of the same kind.

Common features are:

  • the ratio between the number of virtual CPUs and the amount of RAM (in GB)
  • the processor model
  • the ratio between the number of vCPUs and physical CPUs (e.g., there could be 2 vCPUs that are shared on 1 physical core)
  • the allocation of a certain number of GPU devices
  • vCPU cost

Flavors are statically mapped to a specific hypervisor type (a hypervisor is a virtual machine monitoring system), so each different group of flavors will run only on a specific set of hypervisors, and the CPU type seen from within the virtual machine does not change.

"*-hpcv3" flavors

Intended for intensive calculations, the VMs created with this kind of flavor will run on the newest hardware we put in production.

They feature all the CPU flags available on the AMD "Rome" processor family, and all the CPU flags are exposed to the virtual machines. This flavor uses an AMD EPYC 7702 Hypervisor CPU and features 100GB of default storage on the root disk.

The Simultaneous Multithreading feature is disabled on these physical hypervisors, so that each thread corresponds to a physical core, and each vCPU is mapped to a thread running exclusively on a single physical core.

Name vCPUs RAM
1cpu-4ram-hpcv3 1 4 GB
2cpu-8ram-hpcv3 2 8 GB
4cpu-16ram-hpcv3 4 16 GB
8cpu-32ram-hpcv3 8 32 GB
16cpu-64ram-hpcv3 16 64 GB
32cpu-128ram-hpcv3 32 128 GB

"*-hpcv2-lmem" flavors

These are virtual machine suited for intensive calculation, as the HPC ones, except with 2 key differences:

  • They run on the Intel "Skylake" processors, and all of the CPU feature flags are directly exposed in the virtual machines.
  • They have a 1:8 vCPU:GB_of_RAM ratio.

With this kind of flavor you can run calculations that require up to 8GB of RAM per vCPU (as opposed to the 4GB limit on "hpc" and "hpcv3" flavors).

You can make use of the full set of Xeon Gold (Skylake) CPU flags to run a highly optimized binary; e.g., for programs compiled using the avx512 features. This flavor uses a Intel Xeon Gold 6126 Hypervisor CPU and features 100GB of default storage on the root disk.

Hyper-threading (Intel's Simultaneous Multithreading proprietary implementation) is enabled on the hypervisors hosting this flavor type.

Name vCPUs RAM
8cpu-64ram-hpcv2-lmem 8 64 GB
16cpu-128ram-hpcv2-lmem 16 128 GB
32cpu-256ram-hpcv2-lmem 32 256 GB

"*-server" flavors

These are intended for services that do not run CPU-intensive applications because VMs started with these flavors might share the same physical core.

Each physical core has 2 threads, as Hyper-threading (Intel's Simultaneous Multithreading proprietary implementation) is enabled on these CPUs, and each physical thread can be shared with up to 4 vCPUs.

These machines will perform well enough when used to run applications that do not require a steady-over-time heavy CPU load; for example: websites, file servers, authentication and proxy servers, backup servers, etc. This flavor uses the Intel Xeon E5-2640 v3 Hypervisor CPU and features 100GB of default storage on the root disk.

Backup is possible either via snapshots or via the Backup Systems managed directly by ZI.

Name vCPUs RAM
1cpu-1ram-server 1 512 MB
2cpu-2ram-server 2 2040 MB
4cpu-4ram-server 4 4080 MB
8cpu-8ram-server 8 7680 MB

"*-gpu*" flavors

These are intended for GPU computations. They are made of a normal "hpcv2" or "hpcv3" flavor plus a GPU device.

See detailed information on the GPU related ScienceCloud page.

Flavor Availability Report

An updated list of the number per type of public flavors available for creation can be found on the ScienceCloud flavor availability report (requires internal network or VPN).

2.4 Networks

In ScienceCloud, we provide different options to give network connectivity to your VM. These are explained in more detail on the Networking Options page.

Name IP Network Description When it should should be used...
uzh-only 172.23.0.0/16 Private network, routable only within the UZH network Most computational use cases, when you only need to access your VM to run computational workloads.

Also for services that need to be accessed by UZH clients only.
public 130.60.24.0/24 Public network For services that need to be contacted from the internet, including public data repositories like OpenBIS or MOOCs (like OpenEdX).

You don't attach your VM directly to this network; instead, you have to create a private network and a router then associate a Floating IP to it.