Metacentrum Cloud Documentation
Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode Toggle Dark/Light/Auto mode


This documentation is obsolete and not maintained anymore, please use new e-INFRA CZ documentation

Frequently Asked Questions

Where I can find how to use MetaCentrum Cloud effectively?

Read our cloud best-practice tips.

What to expect from the cloud and cloud computing

Migration of Legacy Systems to Cloud Computing article gives an overview of what to expect when joining a cloud with a personal legacy application.

What are the cloud computing benefits?

The most visible cloud computing benefits are:

  • cost savings
  • online access to the cloud resources for everyone authorized
  • cloud project scalability (elasticity)
  • online cloud resource management and improved sustainability
  • security and privacy improvements
  • encouraged cloud project agility

How do I register?

Follow instructions for registering in MetaCentrum Cloud.

Where do I report a problem?

First, try searching the documentation for an answer to your problem. If that does not yield results, open a ticket with When contacting user support, always include your username (upper right corner of the web interface) and domain with active project (upper left corner of the web interface) as well as a description of your problem and/or an error message if available.

What networks I can use to access my instances?

Personal projects can allocate floating IPs from public-cesnet-78-128-250-PERSONAL. Routing is preset for this address pool. Group projects can currently allocate floating IPs from networks ending with GROUP suffix as well as private-muni-10-16-116. Furthermore, IP addresses allocated from public-muni-147-251-124-GROUP and public-muni-147-251-255-GROUP are released daily, so we encourage using only public-cesnet-78-128-251-GROUP and private-muni-10-16-116 for group projects. Follow instructions at changing the external network in order to change your public network.

Issues with network MTU (Docker, kubernetes, custom network overlays)

OpenStack compute server instances should use 1442 bytes MTU (maximum transmission unit) instead of the standard 1500 bytes MTU. The instance itself can set up the correct MTU with its counterpart via Path MTU Discovery. Docker needs MTU set up explicitly. Refer documentation for setting up 1442 MTU in Docker or Kubernetes or change the configuration with the steps below.

Changes in Docker daemon

# edit docker configuration
sudo vi /etc/docker/daemon.json

# MTU 1442 or lower
  "mtu": 1442

# then restart docker
sudo systemctl restart docker

MTU detection

You can use following bash function to detect end-to-end maximum packet size without packet fragmentation.

# detect_mtu <host>
#   measure end-to-end MTU
function detect_mtu() {
  local endpoint_host="$1"
  for i_mtu in `seq 1200 20 1500` `seq 1500 50 9000`; do
    if ping -M do -s $(( $i_mtu - 28 )) -c 5 "${endpoint_host}" >/dev/null; then
      echo "Packets of size ${i_mtu} work as expected"
      echo "Packets of size ${i_mtu} are blocked by MTU limit on the path to destination host ${endpoint_host}!"
# execute

Issues with proxy in private networks

OpenStack instances can either use public or private networks. If you are using a private network and you need to access the internet for updates etc., you can use muni proxy server This server only supports HTTP protocol, not HTTPS. To configure it you must also consider what applications will be using it because they can have their configuration files, where this information must be set. If so, you must find the particular setting and set up there mentioned proxy server with port 3128. Most applications use the following setting, which can be done by editing file /etc/environment where you need to add a line http_proxy="". And then you must either restart your machine or use the command source /etc/environment.

How many floating IPs does my group project need?

One floating IP per project should generally suffice. All OpenStack instances are deployed on top of internal OpenStack networks. These internal networks are not by default accessible from outside of OpenStack, but instances on top of the same internal network can communicate with each other.

To access the internet from an instance, or access an instance from the internet, you could allocate floating public IP per instance. Since there are not many public IP addresses available and assigning public IP to every instance is not a security best practice, both in public and private clouds these two concepts are used:

  • internet access is provided by virtual router - all new OpenStack projects are created with group-project-network internal network connected to a virtual router with public IP as a gateway. Every instance created with group-project-network can access the internet through NAT provided by its router by default.
  • accessing the instances:
  • I need to access instances by myself - best practice for accessing your instances is creating one server with floating IP called jump host and then access all other instances through this host. Simple setup:
    1. Create an instance with any Linux.
    2. Associate floating IP with this instance.
    3. Install sshuttle on your client.
    4. sshuttle -r root@jump_host_fip All your traffic to the internal OpenStack network is now tunneled through the jump host.
  • I need to serve content (e.g. web service) to other users - public and private clouds provide LBaaS (Load-Balancer-as-a-Service) service, which proxies users traffic to instances. MetaCentrum Cloud provides this service in experimental mode - documentation

In case, that these options are not suitable for your use case, you can still request multiple floating IPs.

I can’t log into OpenStack, how is that possible?

The most common reason why you can’t log into your OpenStack account is that your membership in Metacentrum has expired. To extend your membership in Metacentrum, you can visit


All the data is protected against disk failures. We are not responsible for any data loss that may occur. For now, we do not provide any means for offsite backups.

What can I do?

  • Use OpenStack Snapshots for local backup.
  • Use backup software like Borg or Restic to create an offsite incremental backup.
  • Use backup/data storage services provided by MUNI or CESNET (e. g. ).

I can’t access my cloud VMs. MetaCentrum OpenStack network security protection

Access to the MetaCentrum cloud is protected by CSIRT-MU and CSIRT-CESNET security teams.

Some interactions with allocated cloud resources may cause cloud access blockage. This is caused by the fact, that legal SSH access to a new virtual machine (VM) which is being allocated is very similar to a (SSH) brute-force attack.

A newly created VM will respond to SSH connection attempts in different ways as it moves through the setup stages:

  • A) VM is booting and network is being established. At this stage, there is no functional connection point, and connection attempts will timeout.
  • B) SSH connection is being set. At the start of its lifetime, a VM runs the cloud-init process, which enables SSH authentication with the user’s SSH key. A connection is refused, because it can’t verify the user.
  • C) Connection is finally successfull. All setup processes are finished.

When a (ssh) brute-force attack is attempted, scenario is very similar. Repeated unsuccessful (unauthorized) connections to the VM are made (resulting in connection reset or timeout). Once the attacker passes the right credentials, gets connected and logged.

Therefore, when security systems discover such suspicious series of unsuccessfull connections followed by successful one, they likely block Your IP address to the allocated cloud VMs.

Best practices for accessing cloud resources without getting blocked

The key practices helping to avoid source IP address blockage are:


As an example, consider a group of virtual machines, where at least one has access to the internet using an IPv4 or IPv6 public address, and they are connected by an internal network (e.g.

To access the first VM with a public address <public-ip-jump>:

  • Wait for the machine to enter ACTIVE state via Openstack API: openstack server show <openstack-server-id> -f json | jq -r .status.
  • After VM is in ACTIVE state try to open connection to SSH port with timeout of approx. 5 seconds and period of at least 30 seconds.

To access other VMs on the same cloud internal network (once ssh connection to 1st is established):

  • The recommended method is to create an SSH VPN using sshuttle with sshuttle -r user@<public-ip-jump>
  • Address all internal virtual servers with their internal address (CIDR and use the 1st (jump / bastion) machine with the public address as an SSH proxy.
  • Follow the same steps to connect – first wait for ACTIVE state and then try a port connection.

How to check, whether you are blocked

Run the following bash script from the machine, where you believe you got blocked (A), and also from another one located in another IP network segment (B, for instance VM in other cloud):

# Test Cloud Accessibility for a linux or Windows WSDL 2 environments
# BASH function requires following tools to be installed:
#   ip, host tracepath traceroute ping, curl, ncat, timeout, bash
# Execution example: test_cloud_access 22

function test_cloud_access() {
  local basion_vm_public_ip="$1"
  local basion_vm_public_port="${2:-22}"
  local cloud_identity_host=${}
  local timeout=60
  set -x
  cmds=("ip a" "ip -4 r l" "ip -6 r l")
  for i_cmd in "${cmds[@]}"; do
    ${i_cmd}; echo "ecode:$?";
  for i_cmd in host tracepath traceroute ping ; do
    timeout --signal=2 ${timeout} ${i_cmd} "${cloud_identity_host}"
    echo "ecode:$?"
  timeout --signal=2 ${timeout} curl -v "https://${cloud_identity_host}"
  echo "ecode:$?"
  timeout --signal=2 ${timeout} ncat -z "${basion_vm_public_ip}" "${basion_vm_public_port}"
  echo "ecode:$?"
  set +x

How to report network issue and get unblocked

If You are suspecting, that Your virtual machines are blocked, You should contact support by sending an email to the address To make things easier and resolve the issue faster, it is important to add the outputs of the bash function test_cloud_access() above, ran from both VMs (A and B).