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. We do not offer access for students that are not associated to a chair.
  2. You need to have an "LRZ Kennung" (user ID) in a cloud-enabled LRZ project.
  3. 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. You need to send it via snail-mail to the LRZ:
        z.Hd. LRZ-Betreuer Herrn Vasilios Kokkas
        Boltzmannstraße 1
        85748 Garching b. München
  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?

Accounts that are assigned to cloud-enabled LRZ projects can be used to access the cloud. Accounts that are managed by TUM or LMU can not be used to access the LRZ Compute Cloud!

More information on how to apply for a new project can be found on this page.

More information on how to get accounts can be found here.

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).

Information for Master Users

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.

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

Shelve/Shut Off 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 but free resources to other users. This function was called UNDEPLOY (and RESUME) in the old cloud system and it is called Shelve / Unshelve Instance in OpenStack.

Shelving a VM means that this machine is orderly shut off and the resources consumed are freed. The IP and MAC addresses of the network interfaces as well as floating IP addresses 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.

The cloud also offers to Shut Off a VM. This means that the VM will be shut off but the resources stay assigned to this VM and will not become available for other users. There might be rare cases in which this behavior makes sense but I cannot remember one single case. However, if you have VMs in state shut off for at least 2 days you will receive a notification emails until you resume or shelve the VMs.

The differences between shelved and shut off VMs is as follows:

StateResources available for other users?Karma

Please free resources you do not need.

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

Resize a VM's volume

Once in a while you may have the need for more storage space in an existing VM. The obvious thing to do would be to just resize the volume. Unfortunately, this is not possible. The solution is to create a snapshot and create a new volume from this snapshot.

Please note that you can extend the size of the volume but you cannot decrease its size.

  1. On the instances' overview page shelve the VM whose volume you want to extend.
  2. On the instances' overview page click on the name of the particular instance you want to extend. At the bottom of the newly opened page you will find the section "Volumes Attached" listing all the volumes attached to this particular machine.
  3. Click on the volume that is too small. The Volume's overview page will open. You will see the details of this image including its size.
  4. On the upper right corner click the "Down" button and click on "Create Snapshot", provide a name and click on "Create snapshot".
  5. The Snapshots overview page will open and you will find the newly created snapshot in this list. Next to your new snapshot click on "Create Volume".
  6. A new form opens that allows you to provide a volume name and to modify the size of this new volume. Just change the size of the volume to create to a size that fits your needs. Please not that the volume size cannot be less than the snapshot size.
  7. The Volumes overview page will open and you can see the newly created volume in that list. Make sure that the Volume is bootable. You can click on "Edit Volume" to change this setting.
  8. On that volume's row click on the drop down button on the right-hand side and select "Launch as Instance".
  9. It seems that there is a bug in the user interface. In the "Source" tab you need to manually set "Select Boot Source" to Volume and select the resized volume you created earlier.
  10. Configure the VM to create as needed. Do not forget to add your "Key Pair" and make sure that the "Security Groups" are configured correctly! If you want support that guides you through the entire VM creation process have a look at our tutorial.
  11. Once started, you can Associate (a) Floating IP, log into your VM and continue your work.
  12. To prevent your quota to be consumed by unused VMs, volumes and snapshots, you should clean up after yourself: Delete the old VM, the unused volume(s) and the intermediate snapshot.

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.

Data Science Storage (DSS)

A Data Science Storage (DSS) container can be used to store huge datasets and to make them available for VMs you are running in the LRZ Compute Cloud without the need to copy data into your VMs and exceeding your storage quota.

If want to access a DSS container from a VM you should follow the instructions in Section "Using DSS via Compute Cloud and VMware" of the DSS documentation for users. It is noteworthy that a Floating IP will be associated to your user account until you explicitly return it to the floating IP pool. Hence you can rely on the fact that no other user can assign this particular IP to a VM unless you explicitly free this IP.


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 need a static IP for my VM

To reach a VM you need to assign a floating IP to it (more information on that can be found in this tutorial, step 13 ff.). Floating IPs have some remarkable characteristics:

  1. Once you select a floating IP from the pool this IP stays assigned to you until you return it to the pool.
    This is very helpful if you want to register this IP with remote services (such as NFS exports), because until you explicitly return it to the pool you can be sure that this IP is only used by you.
  2. Once you assign a floating IP to a particular VM this IP stays assigned to it even if you shelve your VM.
    This ensures that a VM will use the same IP even if you shelve it inbetween. To free the floating IP you need to explicitly disassociate it or delete the VM. It also allows to provide a service to the MWN (or to the public) with a "static" IP.

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.

A cloud user described the following procedure that he successfully used to migrate an existing VM from the old cloud to the new system:

Prerequisite: * you have a volume reachable by SSHFS or NFS, should be at LRZ
                (e.g. Linux Cluster Scratch, DSS)
              * VM with root FS only on vda

Steps:        * remount root FS read-only (mount -o remount,ro -f /)
              * mount external volume e.g. by sshfs into /mnt
              * dd if=/dev/vda of=/mnt/my-image.img
              * mount the volume on my desktop (SSHFS) and import image in
                OpenStack by web interface

                as an alternative I also managed to create a volume (empty)
                and dd my vda content onto it using a VM (reverse process w/r/t
                above), but then I didn't try if the volume can actually be
                made into a successfully starting image...

  • No labels