Who should I contact in case information or additional help is needed?
How to get access to the Compute Cloud?
If you are a user:
- You need to have an LRZ user ID in a cloud-enabled LRZ project.
- This project's master user can enable your account for the LRZ Compute Cloud.
If you are a (future) master user:
- If you do not have a LRZ project yet, you must apply for a new project and choose "Compute Cloud" as service.
- 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, and 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).
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.
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.
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 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.
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. If a floating IP address is assigned to the VM this will stay assigned and will become available when the VM is unshelved 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.
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.
|tiny||1||512 MB||for testing purposes only, most Operating Systems will not boot due to restricted resources|
|lrz.4xlarge||40||190 GB||use entire compute node|
|nvidia-v100.1||20||350 GB||use 1 GPU on a GPU node|
|nvidia-v100.2||40||700 GB||use 2 GPUs on a GPU node (use entire GPU node)|
|hugemem||184||5859.38 GB||use entire hugemem node|
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:
- You need to configure your Security Group to allow SSH connections to your VM (see section below).
- 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.
- 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.
|FreeBSD||root||First login via Console as root with empty password (press Enter). Set password using passwd command.|
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.
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 your Windows license allows you to run Windows on our hardware.
At the moment we cannot provide a comprehensive installation howto but we want to point you to some important aspects that users told us:
- You can upload an ISO containing the installation files
- 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.
- Make sure that no other (conflicting) virtualization drivers (such as Hyper-V) are installed inside your VM running in the LRZ Compute Cloud.
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.
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.
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.
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 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.
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.