Page tree
Skip to end of metadata
Go to start of metadata

Who should I contact in case information or additional help is needed?

Please send any question to, also referred to as service administrator in this document. Alternatively, you can use the LRZ Service Desk and open a ticket.

How to get access to the Compute Cloud?


If you are a user:

  1. You need to have an LRZ user ID in a cloud-enabled LRZ project.
  2. This project's master user can enable your account for the LRZ Compute Cloud.

If you are a (future) master user:

  1. If you already have an existing project, you can simply contact us, provide us with some information what you want to do with the cloud and apply for access permissions.
  2. If you do not have a LRZ project yet, you must apply for a new project and choose "Compute Cloud" as service.
  3. As a master user you can grant access rights to the project's users yourself.

However, the following sections will give you a more detailed overview of this process:

Which accounts can be enabled for the Compute Cloud?

The LRZ Compute Cloud strongly relies on the LRZ user administration system, which you may know via its web user interface, the LRZ ID Portal. A key prerequisite to use an account to access the LRZ Compute Cloud is that it is part of a project (also called group) managed by LRZ (though it can belong to another institution). Internal projects created for staff members of the institutions we serve (LMU, TUM, FH, ...) are not suitable. The very practical reason is that all the accounts belonging to these projects are known to us, but they are members of a "catch-all" container, so completely opaque. The consequence of this situation is that the entire network security isolation concept is ineffective. If your account is imported "as is", then your VMs would share network connectivity with VMs belonging to other cloud users completely unrelated to you (since you are all members of the same "catch-all" group, as explained before). In fact, decisions on whether VMs are allowed to reach each other depend on the group of the owners. Moreover, budget and resource limits are assigned on a group basis. Again, you would find yourself competing for resources with unrelated researchers.

When requesting access, please feel free to suggest the account you would like to use, but if we verify that the situation explained above applies (i.e., membership in a non-LRZ project), then we kindly ask you to apply for a new project. The whole procedure is rather easy, it consists of filling in a form (Antrag auf ein LRZ-Projekt) that should be returned to your "Betreuer", printed on A4 paper, and with of all required fields completed, especially date and signature. The information requested is quite straightforward, it consists of:

  • the personal data of the master user, to whom the possibility to create new accounts (or close old ones) is delegated. She/he will be the link between LRZ and the members of the new group;
  • the desired service (in our case, the LRZ Compute Cloud: check "other" and add "Compute Cloud");
  • the signature of the head of your institution.

In other words, creating a new project is like creating a new Unix or Windows group. The only difference is that this process should be started by the user and not by us (the service administrators). All in all, we are going to authorize the master user to perform some administrative tasks, so a sort of preliminary vetting procedure is required.

All cloud accounts are added to a mailing list which is used to announce new features, scheduled downtimes, maintenances, and problems affecting our infrastructure. Moreover, it is an important tool for use to get in touch with all people we are currently serving. The number of messages is rather limited, nonetheless, please be aware that we can not remove an email address while the associated account is still cloud enabled. The only way to be excluded from the mailing list is to remove the account from the cloud platform.

Last but not least, an ordered (and consistent) user management approach is necessary for detailed accounting, statistics collection, and automatic procedures. Please do not ask to import accounts belonging to projects that are not cloud enabled, since this would create an exception.

I already have an account, how can I get access to the cloud?

Supposing that the account is suitable for the usage with the LRZ Compute Cloud (namely, it is part of a LRZ project), there are 2 requisites to be finally able to log in:

  • a valid password
  • the LRZ Compute Cloud Platform flag

Please note that both requirements have to be fulfilled in order to get access, however they're independent. In other words, it does not matter the order in which the two operations (change the password, assign the flag) are carried out, especially because two different subjects are involved).

Password management

This is the LRZ Compute Cloud account's password, it is up to the account's owner to

  • change the initial password (Startpasswort) received by the master user;
  • renew the password periodically, according to the LRZ policies.

In case the password has been forgotten, it can always be reset by the master user to an initial password, which has then to be updated. Please be also aware that the initial password (Startpasswort) grants no access.

The tool for password management is the LRZ ID Portal. Log in using your known password (the initial one is of course valid) and

  • on the left panel click on the Self Services button, if present;
  • always on the left pane, under Account (Kennung), click on modify password (Passwort aendern);
  • on the right part of the screen, a list of accounts owned by the user are shown. Please check that the status of the account meant to be used on the LRZ Compute Cloud reads valid (gueltig), otherwise click on the Select (Waehlen) button. A new page will open, in order to let you change the current password. Please type the old one (once) and the new one (twice), then click on Modify password (Passwort aendern).

LRZ Compute Cloud platform

A user account is able to access the LRZ Compute Cloud if it has been assigned to the corresponding platform. This can be done by the master user. The master user should connect to the LRZ ID Portal and

  • on the left panel click on the Master User Services (Master User Dienste) button, if present;
  • always on the left pane, under Project (Projekt), click on view / modify (anzeigen/bearbeiten);
  • on the right part of the screen, a list of projects managed by the master user are shown. Please click on the Select (Waehlen) button near the name of the project enabled for the cloud.

Something similar to the following picture should appear at the bottom of the page, or click on List of accounts (Kennungliste) on the top right corner of the page.

ID Portal project kontingen

Each project is assigned an Account Quota (Kontingent), i.e., the maximum number of account of the project (blue square in the previous picture). Cloud projects are also given a Cloud Quota (Cloud Kontingent), i.e., the maximum number of accounts that can be assigned to the cloud platform (yellow square in the previous picture). The master user should verify that the cloud quota is present and there are enough free tokens. If it is not the case, please contact us.

In the upper part of the page, the list of accounts and available platform is reported, as per the following screenshot.

ID Portal user platform

As suggested by the description, just put a X in the LRZ Cloud column (for each account that should be given access) and save it.

Important note: the LRZ Compute Cloud front-end and the ID Portal are synchronized every 15 minutes. After the account's activation please wait about a quarter of a hour before trying to login. If there are still problems, please contact us , do not try to remove the account or the flag and create it again. Moreover, as already specified, it is not important that the initial password is changed before or after the flag is assigned. The important thing is that the account has the flag and a valid password at login time.

How to use the LRZ Compute Cloud


A quota is a limit on resources to prevent that a single user can block too many resources at once and to have resources available for other users on the cloud, i.e. the default quota that is initially assigned to a user is not sufficient to spawn a GPU VM.

This quota can be adjusted to a user's need, e.g. if she/he need to use VMs with GPUs for machine learning or visualization tasks.

Default quota

The default quota for new LRZ Compute Cloud users will be set to the values shown in the table below. In case you need more you have to contact us: cloud support team

instances4Number of VMs
cores10Total number of CPU cores
volumes4Number of block storage volumes
gigabytes200Total size of all block storage volumes 
snapshots10Total number of volume snapshots
floating-ips8Total number of floating IPs (MWN_pool and internet_pool)
subnets2Total number of subnets

Shut down/undeploy/shelve VMs you do not need at the moment

It is important to understand that our (physical) resources are limited. Please do not run idle VMs and free resources for other users. This function was called UNDEPLOY (and RESUME) in the old cloud system and is called Shelve/Unshelve in OpenStack.

Shelving a VM means that this machine is shut down and the resources consumed are freed. The IP and MAC addresses of the network interfaces as well as floating IP address assigned to the VM will stay assigned and will become available when the VM is unshelved again in a later point in time. However, the number of CPUs, RAM and disks are counted in the quota of the particular user. If you need to free up your quota you must delete existing VMs.

Virtual Machines

Can I have a VM with x vCPUs and y GB of RAM?

Probably yes, but: There is a fixed ratio between CPUs and RAM for the compute nodes. Each VM running on a standard compute node will get 4.75 GB of memory per CPU core used. This is reflected in the different Flavors.


Flavors define the number of CPUs and the amount of main memory for each VM.

tiny1512 MBfor testing purposes only, most Operating Systems will not boot due to restricted resourcespublic
lrz.small14.75 GiBuse 1/40 compute nodepublic
lrz.medium29.5 GiBuse 1/20 compute nodepublic
lrz.large419 GiBuse 1/10 compute nodepublic
lrz.xlarge1047.5 GiBuse 1/4 compute nodepublic
lrz.2xlarge2095 GiBuse 1/2 compute noderestricted, contact us
lrz.4xlarge40190 GiBuse entire compute noderestricted, contact us
nvidia-v100.120350 GiBuse 1 GPU on a GPU noderestricted, contact us
nvidia-v100.240700 GiBuse 2 GPUs on a GPU node (use entire GPU node)restricted, contact us
lrz.huge24744 GiBuse 1/8 of the hugemem noderestricted, contact us
lrz.xhuge481488 GiBuse 1/4 of the hugemem noderestricted, contact us
lrz.2xhuge962976 GiBuse 1/2 of the  hugemem noderestricted, contact us
lrz.4xhuge1925952 GiBuse entire hugemem noderestricted, contact us

How can I log in to my VMs?

The default way to log into your VMs is via SSH. There are 2 necessary steps you need to complete:

  1. You need to configure your Security Group to allow SSH connections to your VM (see section below).
  2. You need to specify the username you want to use to log in. The username depends on the operating system image you choosed when launching a new instance.
  3. The default SSH authenication method is SSH Key-based authentication. You need to provide a SSH key pair during the instantiation of a VM. The public key of this key pair will be injected into the VM when it is screated. The private key of the key pair must be presented when logging in via SSH.

What is the correct username to log into my VM?

The default username you need to provide when logging in to your VM depends on the operating system image you choose.

Operating SystemUsernamePasswordRemarks
SSH-key only

SSH-key only

SSH-key only
First login via Console as root with empty password (press Enter). Set password using passwd command.
SSH-key only
SSH-key only

We provide information regarding the login information in the description field of each image. You can access this information by clicking on the image you are interested in the Images tab. The description field can be found in the Custom Properties section. As an example, the following figure shows the Description of an Ubuntu-based Operating System image:

I want to use a GPU but my quota is too small

To use a GPU you need to launch a new VM using one of the nvidia-v100 flavors. This means that you need a quota of at least 20 CPUs.

Please contact us to ask for a raise of your CPU quota.

How can I import an own disk image?

When logged in, you can go to Project > Compute > Images and click on "Create Image". From there you can select the image file you want to upload to our cloud.

Please note that you are only allowed to upload images in raw format at the moment.

If you want to upload images in qcow2 you need to convert this image to raw before uploading it. This can be done with the qcow-img command that you can install on your workstation or in a virtual machine on our cloud. (smile)

$ qemu-img convert -f qcow2 -O raw image.qcow2 image.img

Can I install Microsoft Windows in a VM?

Technically it is possible to run Windows in a VM on the LRZ Compute Cloud. Before you start you must make sure that you own an appropriate license and that your Windows license allows you to run Windows virtualized on our hardware. Because of licensing issues, Windows Server operating systems must not be run in the LRZ Compute Cloud.

At the moment we cannot provide a comprehensive installation howto but we want to point you to some important aspects that users told us:

  1. You can upload an ISO containing the installation files
  2. A user ran into the problem that a VM's volume was write-protected after fresh Windows installation. He could circumvent this by preparing a Windows-VM on his workstation, installing the latest VirtIO drivers for Windows and uploading this volume to our cloud.
  3. Make sure that no other (conflicting) virtualization drivers (such as Hyper-V) are installed inside your VM running in the LRZ Compute Cloud.
  4. One user succeeded building the image outside of OpenStack:

Needless to say: if you use a commercial product, like Windows, you need to have a license for it!

Volumes and images

I cannot delete old volumes

Before you can delete volumes you need to delete any snapshots of these volumes. Volumes cannot be deleted as long as old snapshots of the particular volumes exist.

I cannot delete an image

As long as there exists a volume, which has been created based on the image, you can not delete the image.


Security Groups

The concept of security groups is used to prevent unwanted and malicious network traffic from or to the machines. It can be seen as an external (outside of the VM itself) firewall that can be fully configured by the user.

It is worth noting that the default security group does not even allow incoming SSH connections! If you want to access your VMs via SSH you need to add a corresponding rule to the security group you want to use first. Please refer to our tutorial to learn how to add a rule to a security group.

If you run into problems regarding network connectivity of your VMs security groups are a good place to start debugging your problems. (wink)

I cannot reach my VM via SSH

First and foremost, please check if the Security Group you are using allows SSH traffic to the VM.

That said, we experienced problems with the network connectivity after we changed the network settings in our July 2019 mainenance window. The problem is that the MAC address of the virtual network card has changed but Ubuntu stores the MAC in the netplan configuration and will not update the MAC automatically. As a result, the network interface will not come up. There are 2 possible ways to recover such an VM:

  1. If you have set a password for your user you can use the NoVNC console from within the OpenStack dashboard to log into the VM and reconfigure netplan's configuration file located in /etc/netplan/50-cloud-init.yaml. More information on this topic can be found here.
  2. If you do not have a password set you need to create a new VM.
    1. As default value, a volume will be kept even if its VM is deleted. In this case, you can delete the VM, go to the Volumes overview page and select "Launch as instance" from the particular volume's dropdown menu.
    2. If you are unsure, you can create a snapshot of your (running) VM, go to Volumes → Snapshots and select "Launch as Instance" from the particular snapshot's dropdown menu.

Once the VM is ready, you should be able to log in via SSH.

Existing users

Are there any differences between the new (OpenStack) and the old (OpenNebula) cloud?

Plenty. The major difference is that we now use OpenStack instead of OpenNebula. This change does not only affects the software we use to realize our cloud offering but it does also comes with different concepts the users need to understand.

  • Budget
    At the moment there is not budget system comparable to the budget system of the OpenNebula cloud. At the moment we think about how to implement a comparable system.
  • Flavors
    Flavors define the assignment of resources to each VM. In difference to OpenNebula, OpenStacks does not let you choose the number of virtual CPUs and the amount of memory independently. This prevents fragmentation on the nodes or situations that one VM consumes all CPUs of a node but only 4 GB of RAM.
  • Quota
    In both clouds we use a quota system to prevents the cloud resources to be blocked completely by few users. However, since a quota was assigned to a group of users belonging to the same project in the old cloud, we now assign quota directly to the particular users. This is the reason why we cannot simply assign the quota from the old cloud to the accounts in the new cloud system. If you (as a user) needs an increased quota please contact us directly.
  • Security Groups
    Wile OpenNebula VMs are not located behind a firewall and the user is responsible to block malicious and unwanted network traffic on the OS level, OpenStack incorporates the concept of security groups. These security groups define a set or rules to allow or reject network traffic. By default, not even SSH is allowed in the default security group. The user needs to manually add a rule to access her VMs via SSH first. If you have problems in terms of reaching your VMs, security groups are a good place to look first.

Is there a migration path from the old cloud to the new one?

Unfortunately there is no migration path to the new cloud but there are some best practices to get your software to your new VMs.

  • No labels