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

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

  1. Please check the LRZ CC documentation and FAQ for an  answers, which you are already doing by reading this.
  2. Just try to google it. The internet knows much more about all the possible OpenStack issues than we do, though hard to find occasionally.
  3. If this does not help or in case you are 100% sure it is a problem of the LRZ CC please send an email to cloud-admin@lrz.de or  use the LRZ Service Desk and open a ticket.

How to get access to the Compute Cloud?

tl;dr

If you are a user:

  1. We do not offer access for students that are not associated to a chair. See below.
  2. You need to have an "LRZ Kennung" (user ID) in a cloud-enabled LRZ project.
    If your user ID belongs to a project that is maintained by LRZ but not cloud enabled yet, you might ask the project's master user(s) to contact LRZ and ask to activate this project for the compute cloud.
  3. This project's master user can enable your account for the LRZ Compute Cloud.
  4. It might take some minutes to synchronize your new permissions with the cloud system. You can not log in until your permissions have been synchronized with the cloud system. After your account's permissions have been synchronized you will receive emails providing further information on how to use the 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/public mail service (wink) to LRZ:
        Leibniz-Rechenzentrum
        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.
    1. Within the given contingent we assigned to your project you can enabled/disable accounts in your project to use the cloud.
    2. Once the new permissions have been synchronized with the Cloud system the accounts will receive emails providing further information.

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 am a student, can I use the Compute Cloud?

We cannot offer access to the compute cloud for every individual student.

If you belong to a chair or research group that has a LRZ project that is or can be enabled to use the compute cloud please ask one of this project's master user to create a new account in this project for you and enable it for cloud usage.

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

Funktionskennungen (functional accounts)

If you want to share access to VMs (and the management tasks) between different individual users, a project's master user can create a functional account that is allowed to be shared between different normal users. In many cases it makes sense that a research group runs their virtual resources using a functional account instead of the researchers' personal accounts.

From an OpenStack perspective there is no difference between a functional account and a normal account.

Quota

Quota limits will be assigned on a per-user basis.

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

QuotaLimitComment
instances4Number of VMs
cores10Total number of CPU cores
ram-1unlimited
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
SHELVEyes+1
SHUTOFFno-1

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

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

NamevCPUsRAMRemarksAccess
tiny1512 MBfor testing purposes only, most Operating Systems will not boot due to restricted resourcespublic
lrz.small14.5 GiBuse 1/40 compute nodepublic
lrz.medium29 GiBuse 1/20 compute nodepublic
lrz.large418 GiBuse 1/10 compute nodepublic
lrz.xlarge1045 GiBuse 1/4 compute nodepublic
lrz.2xlarge2090 GiBuse 1/2 compute noderestricted, contact us
lrz.4xlarge40180 GiBuse entire compute noderestricted, contact us
nvidia-v100.120368 GiBuse 1 GPU on a GPU noderestricted, contact us
nvidia-v100.240736 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
CentOScentos
SSH-key only
cirroscirrosgocubsgo
Debiandebian

SSH-key only

Fedorafedora
SSH-key only
FreeBSDroot
First login via Console as root with empty password (press Enter). Set password using passwd command.
openSUSEopensuse
SSH-key only
Ubuntuubuntu
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.

The virtual GPU causes problems when using a GUI in my VM

A user ran into a problem when he wanted to access the Gnome settings menu of the virtual Cirrus Logic GD 5446 GPU (this is used as the default GPU by qemu) under Ubuntu. The solution was to change the emulation of the GPU to a different model. The current problems could be solved by using "qxl" as hw_video_model in the image metadata.

To change the hw_video_model using our Cloud web interface, go to Compute → Images and ans select "Update Metadata" from the particular image's dropdown menu. From the left list choose "libvrit Driver Options for Images" → "Video model" and click the + button right next to it to add it to the image's metadata. Now choose "hw_video_model" in the right list and select one of the options from its dropdown menu.

You can also use the command line tools to set the hw_video_model metadata option. To select qxl you can simply type:

$ openstack image set {image name or ID} --property hw_video_model=qxl

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: https://superuser.openstack.org/articles/how-to-deploy-windows-on-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 a volumes

The volume must be in the state Available. Before you can delete volumes you need to delete any snapshots of these volumes. Volumes cannot be deleted as long as any 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.

Download an image/a volume

In order to download a volume, e.g. because you want to save a backup or want to use this volume in a different environment, you will face several limitations:

  1. You cannot simply download a snapshot of a volume (it will always have a size of 0 (zero) bytes)
  2. You need to use the command line tools. Please folllow this tutorial to install the command line tools.

In order to download an instance's volume please follow these steps:

  1. Create a snapshot of the instance
  2. Go to Volumes → Snapshots
  3. Click on "Create Volume" next to the snapshot you want to download
  4. Go to Volumes → Volumes
  5. Click on "Upload to Image" in the dropdown menu next to the volume you want to download
    (warning) This step can take a long time. Grab a coffee and do something else until the new image has been created.
  6. Go to Compute → Images
  7. Click on the image and note its ID.
  8. Using the command line tools you can now download the image using the openstack command:

    openstack image save --file myimage.raw <Image ID>

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.

Networking

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.

How to add a second (third, ...) network interface to a VM

By default a VM has only one network interface and the DHCP assignment works out of the box. With two or more interfaces, there's a problem. Every interface tries to set the default route, but there can be only one. So, the first interface to be set up wins, and it's not given that it is the first one specified in the template. The solution consists in specifying the priority, or metric, of the interfaces. Each one sets the default gateway given by the DHCP but with a different priority.

If you plan to have more then one network interface in your VM, then give maximum priority (or lowest metric) to the public one, otherwise the VM won't be reachable. If you don't specify anything, then the priority is maximum and the metric is the minimum. If the VM has only network card, then there is no need to specify a metric.

Now, some details on how to configure the network card of a VM. We consider here some well-know Linux distributions.

SUSE

for each interface there is a script named /etc/sysconfig/network/ifcfg-<if name>, such as ifcfg-eth0, ifcfg-eth1 and so on. The content should be

DEVICE=eth0 #this is an example, change to eth1 in ifcfg-eth1 ...
STARTMODE=auto
BOOTPROTO=dhcp4
DHCLIENT_PRIMARY_DEVICE=yes

The value of the DEVICE directive should be adapted accordingly (i.e., eth1) while DHCLIENT_PRIMARY_DEVICE should be changed to no, then save the new file in a consistent way, i.e., ifcfg-eth1.

Remember: the device attached to the public network needs DHCLIENT_PRIMARY_DEVICE=yes, for all the others it should be set to no.

Fedora, CentOS and derivatives

The approach is very similar to SUSE. For each interface there is a script located in /etc/sysconfig/network-scripts, named ifcfg-<inteface name>, such as /etc/sysconfig/network-scripts/ifcfg-eth0 and so on.

The content should be

DEVICE=eth0
BOOTPROTO=dhcp
ONBOOT=yes

For every other interface, the DEVICE and the file name should be adapted, while the parameter METRIC=1 should be added. METRIC increases for every new interface. A higher metric means a decreasing priority of the route associated to that interface. The public interface has to be the one without the METRIC parameter, that is the one whose default route is the preferred.

Debian, Ubuntu and derivatives

Debian and Ubuntu have only one file, /etc/network/interfaces. A typical example is

auto lo
iface lo inet loopback
auto eth0
iface eht0 inet dhcp

It is obvious that the loopback interface and eth0 are brought up automatically at boot (auto) and then configured.

For each additional interface, the auto statement, the iface definition, and the entry

metric 1

should be added.

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