Who should I contact in case information or additional help is needed?
Please note that cloud support can only help with problems related to LRZ Compute Cloud!
We are not the right persons to contact if you have problems with software you are running within your VM!
- Please check the LRZ CC documentation and FAQ for an answers, which you are already doing by reading this.
- Just try to google it. The internet knows much more about all the possible OpenStack issues than we do, though hard to find occasionally.
- If this does not help or in case you are 100% sure it is a problem of the LRZ CC please use the LRZ Service Desk and open a ticket.
What information should I provide when I contact support?
If you need to contact us (first make sure that you really need to ) please provide the following information:
- your User Name (LRZ Kennung) you use to login to the cloud
- the UUID(s) of the cloud components, i.e. VM, instance, volume, network etc. which cause the problems.
How to get access to the Compute Cloud?
If you are a user:
- We do not offer access for students that are not associated to a chair. See below.
- 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.
- This project's master user can enable your account for the LRZ Compute Cloud.
- 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:
- 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.
- 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 to LRZ:
z.Hd. LRZ-Betreuer Herrn Vasilios Kokkas
85748 Garching b. München.
- As a master user you can grant access rights to the project's users yourself.
- Within the given contingent we assigned to your project you can enabled/disable accounts in your project to use the cloud.
- 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).
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.
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 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.
Costs of using the LRZ Compute Cloud
When will LRZ start to charge money?
At the moment the usage of the Cloud infrastructure is free of charge.
We are evaluating the software we aim to use for accounting and billing. As long as you hear nothing from us there will be no charges for the usage of our cloud resources. All information regaring this topic will be distributed using our mailing list which all cloud users are subscribed to automatically as well as in the announcements section.
Who is reponsible?
From our point of view the master user of a project is responsible for assigning permissions for the LRZ compute cloud to the particular project members. Therefore the master user wil be responsible for any costs that may occur.
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 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. This quota can be adjusted to a user's need, e.g. if she/he needs to use more VMs or more CPUs per VM. In this case please contact us: cloud support team
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
|instances||4||Number of VMs|
|cores||10||Total number of CPU cores|
|volumes||4||Number of block storage volumes|
|gigabytes||200||Total size of all block storage volumes|
|snapshots||10||Total number of volume snapshots|
|floating-ips||8||Total number of floating IPs (MWN_pool and internet_pool)|
|networks||4||Total number of networks|
|subnets||4||Total number of subnets|
|key-pairs||4||Total number of public key-pairs|
|secgroups||10||Total number of security groups|
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:
|State||Resources available for other users?||Karma|
Please free resources you do not need.
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 at least 1.125 GB of memory per vCPU core used. This is reflected in the different Flavors.
Flavors define the number of vCPUs and the amount of main memory for each VM.
|Name||vCPUs||RAM||maximum CPU Overcommit||Remarks||Access|
|tiny||1||512 MB||8||for testing purposes only, most Operating Systems will not boot due to restricted resources||public|
|lrz.2xlarge||20||90 GiB||8||restricted, contact us|
|lrz.4xlarge||40||180 GiB||8||restricted, contact us|
|nvidia-v100.1||20||368 GiB||1||use 1 GPU on a GPU node||restricted, contact us|
|nvidia-v100.2||40||736 GiB||1||use 2 GPUs on a GPU node (use entire GPU node)||restricted, contact us|
|lrz.huge||24||744 GiB||1||use 1/8 of the hugemem node||restricted, contact us|
|lrz.xhuge||48||1488 GiB||1||use 1/4 of the hugemem node||restricted, contact us|
|lrz.2xhuge||96||2976 GiB||1||use 1/2 of the hugemem node||restricted, contact us|
|lrz.4xhuge||192||5952 GiB||1||use entire hugemem node||restricted, contact us|
1. The Overcommit column refers to the CPU overcommit ratio. A value X in this column means, one physical CPU processes X vCPUs. So a value of 1 basically means "no overcommitment".
2. Don't just request "more resources", this will be denied by default! Include specific CPU and memory requirements, as well as for how long you will likely need them. Our resources increasingly more limited with the size of the flavors, so check out the cloud usage dashboard: https://cc.lrz.de/lrz/cloudusagepanel/ before asking for a specific flavor. The more you request, the better your reasoning why you need them should be. Also be prepared for compromises, we cannot accommodate any request.
Can I resize a VM (add or remove ressources like cores or main memory)?
You can do that. However, you cannot freely decide which amount of cores and main memory a VM should get but you can change the flavor assigned to a VM.
Please keep in mind that VMs will be restarted during the resize process. You cannot resize a VM on the fly.
Using the web interface (GUI)
- Change to the "Compute → Instances" overview page
- Click the down arrow in the Actions column of the VM you want to resize and click "Resize Instance"
- Select the new flavor you want to assign to this VM from the "New Flavor" drop down list and click on "Resize"
- You will be returned to the Instances overview page with the VM in state "Resize/Migrate"
- Eventually it's state wil change to "Confirm or Revert Resize/Migrate". Click on the "Confirm Resize/Migrate" button in the actions column of this VM.
- After a couple of moments it's state will change to "Active" and the newly resized VM will be booted and will allow you to log in.
Using the command line tools
openstack server resize --flavor <new flavor> <vm id>This command will attach the new flavor (e.g. lrz.large) to the VM with the specified ID. Basically, it creates a new copy of the VM with the new flavor assigned.
openstack server listIs needed to keep an eye on the VM's status. The VM's state will be RESIZE and eventually change to VERIFY_RESIZE. After the VM has entered this final state, you need to carry out one more command
openstack server resize --confirm <vm id>This command confirms that the resized VM is in a working state. Thereafter the old VM will be deleted and you can use your newly resized one.
Do you use over-commitment?
Yes, when we hit the 99% mark in CPU allocation while still maintaining an average CPU usage of 13% we decided to double the RAM in our normal compute nodes and set the CPU overcommit ratio to 2 for the corresponding flavors. Please see the table above for the affected flavors.
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 created. The private key of the key pair must be presented when logging in via SSH.
Important note: This step is carried out only once - at the first time when a VM is created. If you start this VM later updated SSH keys will not be injected! If you need to inject an updated key you can create a snapshot of an existing VM and instantiate a new VM from this snapshot.
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:
Which keypair type should I use?
Short story: RSA with at least 3072 bits
|Key Algorithm||Recommended Key Length||Works out of the Box||Remarks|
|DSA||>= 3072 bit|
|ECDSA||>= 256 bit|
|RSA||>= 3072 bit|
|ED25519||>= 256 bit|
I want to use a GPU but can not see the nvidia-v100 flavors
To use a GPU you need to launch a new VM using one of the nvidia-v100 flavors. This flavors are not accessible by default. Please contact us to ask for GPU access
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:
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.
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:
- 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.
- 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
Do you create any backups?
No. If you need to backup your data you are responsible for that. You can use the LRZ backup service to do that. But you need to install and configure it manually.
Resize a VM's volume
Once in a while you may have the need for more storage space in an existing VM. How to accomplish this depends on the type of volume you need to enlarge.
If you are dealing with a volume that you attached additionally to you VM, then enlarging is rather straightforward.
- Connect to your virtual machine via SSH, and unmount the volume.
- Now login to the web interface, navigate to the volume page and detach the volume via 'Manage Attachments' in the drop down menu on the right. (Or use the CLI Client)
- Then click on 'Extend Volume' in the same drop down, and choose a new bigger size for it.
- After that you can attach the volume again via 'Manage Attachments'
- Finally adjust the partition layout of the volume if necessary from the virtual machine, and remount it.
Root volumes need special treatment, because you cannot detach them from an instance. There are two options:
Deleting the virtual machine
If you didn't choose 'Delete volume on instance delete' when creating the virtual machine, you can do the following:
- Delete the virtual machine.
- Go to the volume page, and extend the volume via the drop down 'Manage Attachments'.
- Then create a new virtual machine from this volume.
- Finally adjust the partition layout if necessary.
Using a volume snapshot
You can also leave the original volume intact and enlarge a snapshot of it:
- On the instances' overview page shelve the VM whose volume you want to extend.
- 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.
- 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.
- On the upper right corner click the "Down" button and click on "Create Snapshot", provide a name and click on "Create snapshot".
- 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".
- 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.
- 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.
- On that volume's row click on the drop down button on the right-hand side and select "Launch as Instance".
- 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.
- 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.
- Once started, you can Associate (a) Floating IP, log into your VM and continue your work.
- 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 volume or a volume snapshot
The volume must be in the state Available and have the attachment status Detached. Before you can delete volumes you need to delete any snapshots of these volumes or vice versa. Volumes cannot be deleted as long as any snapshots of the particular volumes exist. The Horizon Web GUI does not provide the possibility to list these dependencies between volumes and snapshots but you could use the following bash script to list the dependencies for your project: get_volume_dependencies.sh. Please follow this tutorial to install the command line tools.
Below you see an example of the output of that script. There are 2 volumes and one Snapshot listed. To be able to delete the snapshot you first have to delete the volume with UUID 1a0ed73b-d15a-4db2-8a84-c96953c183f0.
Despite cleared dependencies the system may still refuse to delete a volume most often due to an inconsistent state and/or attachment status in the database. An example would be a volume for which
openstack volume show VOLUME_UUID shows an attachment to an already deleted instance, or an instance for which
openstack server show SERVER_UUID does not show said attachment. In that case the state and/or attachment status have to be reset manually which requires admin privileges, so if you have this kind of problem please open a ticket and name the volume.
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:
- You cannot simply download a snapshot of a volume (it will always have a size of 0 (zero) bytes)
- You need to use the command line tools. Please follow this tutorial to install the command line tools.
In order to download an instance's volume please follow these steps:
- Create a snapshot of the instance
- Go to Volumes → Snapshots
- Click on "Create Volume" next to the snapshot you want to download
- Go to Volumes → Volumes
- Click on "Upload to Image" in the dropdown menu next to the volume you want to download
This step can take a long time. Grab a coffee and do something else until the new image has been created.
- Go to Compute → Images
- Click on the image and note its ID.
Using the command line tools you can now download the image using the openstack command:
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.
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.
Please note: you can modify the Security Groups any time. The changes take effect immediately. You do not need to restart or shelve and unshelve your VM.
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:
- 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.
- 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:
- 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.
- If you do not have a password set you need to create a new VM.
- 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.
- 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.
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
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
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
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
should be added.
Adding a second floating IP to a VM
Some use cases require to have two floating IPs attached to a VM. The following example is based on the instructions given here: https://www.thomas-krenn.com/en/wiki/Two_Default_Gateways_on_One_System and has been tested on a VM running Debian Buster.
- Create a VM and select a network interface from the MWN network, in this example this will be eth0, IP assigned via DHCP is 192.168.1.151
- Attach a floating IP from the MWN_pool to this interface to get access to it.
- Attach a second interface from the internet network to the VM, eth1, IP: 192.168.128.32/17
- Login to the VM, in the following we will change the default network setup from DHCP to static
To disable disable cloud-init's network configuration capabilities we do:
Add a second routing table
Get the current IP addresses of the two interfaces eth0 and eth1, here 192.168.1.151/17 and 192.168.128.32/17
Edit the file /etc/network/interfaces
- Reboot the VM
Attache a floating IP from the internet pool to the second interface
Can I reach my VM via a domain name?
If you have the need to make your VM accessible via a domain (and not only its IP address) you can use the default domain assigned to each floating IP address you can assign to your VMs. This domain name will be derived from the particular floating IP:
Can I register a domain name and link it to one of my VMs?
No. LRZ is not a domain registrar or reseller. Furthermore, we do not operate any name servers for cloud VMs that we need to modify for name resolution issues.
Login to the LRZ Compute Cloud
I cannot log in to the LRZ Compute Cloud
- When a project's master user granted your account access to the compute cloud it might take up to 15 minutes until your account is created in the cloud system's backend. Please give us a couple of minutes to provide you with access to the system.
- Please login to the LRZ SIM portal and ensure that …
- … your password is not too old
(At the moment the LRZ SIM system still forces users to update their passwords every $tooshorttime months.)
- … you have accepted the declaration of export control regulations ("Export-Kontrollerklärung")
You can find a button to check it in the ID Portal.
If you ask yourself "whut?" you can find more information on the website of the Federal Ministry of Education an Research (German only).
- … your nationality is set correctly.
You cannot update this information yourself but you need to contact your project's master user to update your user record.
- … your password is not too old
- In case of a functional account (Funktionskennung)
the owner of the Funktionskennung (Kennungsverantwortlicher) has to accepted the declaration of export control regulations ("Export-Kontrollerklärung").
the nationality of the Kennungsverantwortlicher is set correctly.
Common error messages
No valid host was found. There are not enough hosts available
This error message appears when you try to create a new or unselve an exising VM but there are no hosts available suitable to run your VM. Users trying to create GPU-VMs are quite familiar with this message.
When you are logged in you can visit the LRZ Dashboard to see how many resources are available for your VMs at the moment.