Advanced Features

The following guide will introduce you to advanced features available in MetaCentrum Cloud. For basic instructions on how to start a virtual machine instance, see Quick Start.

Virtual Networks

MetaCentrum Cloud offers software-defined networking as one of its services. Users have the ability to create their own networks and subnets, connect them with routers, and set up tiered network topologies.


  • Basic understanding of routing
  • Basic understanding of TCP/IP

For details, refer to the official documentation.

Create Network

  1. Go to Project > Network > Networks, click on Create Network.

  2. Choose name and click Next.

  3. In the subnet tab, choose a subnet name. In Network Address Source, select Allocate Network Addres from a pool. In Address pool select any of the available pools. Click Next.

  4. Click Create. Do not change any other options.

  5. Go to Project > Network > Network Topology, review your newly created network topology.

Create Router

  1. Go to Project > Network > Routers, click on the Create Router button.

  2. Choose a name. Select External Network and click Create Router.

    Please, remember that your will have to allocate floating IP addresses in the selected External Network for all instances using this router as a gateway.
  3. Go to Project > Network > Network Topology, the newly create router should be now present.

  4. Click on the router icon, select Add Interface.

  5. Choose the previously created network/subnet from the drop-down menu. Click Submit.

  6. The router is now attached to an external network.

    Routers can also be used to route traffic between internal networks. This is an advanced topic not covered in this guide.


The OpenStack orchestration service can be used to deploy and manage complex virtual topologies as single entities, including basic auto-scaling and self-healing.

This feature is provided as is and configuration is entirely the responsibility of the user.

For details, refer to the official documentation.

Image upload

We don't support uploading own images by default. MetaCentrum Cloud images are optimized for running in the cloud and we recommend users to customize them instead of building own images from scratch. If you need upload custom image, please contact user support for appropriate permissions.

Instructions for uploading custom image:

  1. Upload only images in RAW format (not qcow2, vmdk, etc.).

  2. Upload is supported only through OpenStack CLI with Application Credentials.

  3. Each image needs to contain metadata:


    Following needs to be setup correctly (consult official documentation) or instances won't start:

    os_type=linux # example
    os_distro=ubuntu # example
  4. Images should contain cloud-init, qemu-guest-agent and grow-part tools

  5. OpenStack will resize instance after start. Image shouldn't contain any empty partitions or free space

Image sharing between projects

Image sharing allows you to share your image between different projects and then it is possible to launch instances from that image in those projects with other collaborators etc. As mentioned in section about CLI, you will need to use your OpenStack credentials from openrc or cloud.yaml file.

Then to share an image you need to know it's ID, which you can find with command:

openstack image show <name_of_image>

where name_of_image is name of image you want to share.

After that you will also have to know ID of project you want to share your image with. If you do not know ID of that project you can use following command, which can help you find it:

openstack project list | grep <name_of_other_project>

where <name_of_project> is name of other project. It's ID will show up in first column.

Now all with necessary IDs you can now share your image. First you need to set an attribute of image to shared by following command:

openstack image set --shared <image_ID>

And now you can share it with your project by typing this command:

openstack image add project <image_ID> <ID_of_other_project>

where ID_of_other_project is ID of project you want to share image with.

Now you can check if user of other project accepted your image by command:

openstack image member list <image_ID>

If the other user did not accepted your image yet, status column will contain value: pending.

Accepting shared image

To accept shared image you need to know <image_ID> of image that other person wants to share with you. To accept shared image to your project you need to use following command:

openstack image set --accept <image_ID>

You can then verify that by listing your images:

openstack image list | grep <image_ID>

Unshare shared image

As owner of the shared image, you can check all projects that have access to the shared image by following command:

openstack image member list <image_ID>

When you find <ID_project_to_unshare> of project, you can cancel access of that project to shared image by command:

openstack image remove project <image ID> <ID_project_to_unshare>

Add SWAP file to instance

By default VMs after creation do not have SWAP partition. If you need to add a SWAP file to your system you can download and run script that create SWAP file on your VM.

Local SSDs

Default MetaCentrum Cloud storage is implemented via CEPH storage cluster deployed on top of HDDs. This configuration should be sufficient for most cases. For instances, that requires high throughput and IOPS, it is possible to utilize hypervizor local SSDs. Requirements for instances on hypervizor local SSD:

  • instances can be deployed only via API (CLI, Ansible, Terraform ...), instances deployed via web gui (Horizon) will always use CEPH for it's storage
  • supported only by flavors with ssd-ephem suffix (e.g. hpc.4core-16ram-ssd-ephem)
  • instances can be rebooted without prior notice or you can be required to delete them
  • you can request them, when asking for new project, or for existing project on


LBaaS (Load Balancer as a service) provides user with load balancing service, that can be fully managed via OpenStack API (some basic tasks are supported by GUI). Core benefits:

  • creation and management of load balancer resources can be easily automatized via API, or existing tools like Ansible or Terraform
  • applications can be easily scaled by starting up more OpenStack instances and registering them into the load balancer
  • public IPv4 addresses saving - you can deploy one load balancer with one public IP and serve multiple services on multiple pools of instances by TCP/UDP port or L7 policies

This feature is provided as is and configuration is entirely the responsibility of the user.

Official documentation for LBaaS (Octavia) service -

results matching ""

    No results matching ""