If none of the default Flavors match, please contact us for the creation of a custom Flavor.

Technically it is possible to run Windows in a VM on the 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.

All Floating IPs have a generic DNS Record. For Example 10.76.31.111 has the DNS A Record „float-10-76-31-111.cc.rrze.de“

That is possible by changing the flavor of a VM.

Please keep in mind that VMs will be restarted during the resize process. You cannot resize a VM online.

Using the web interface (GUI):

1. Change to the „Compute -> Instances“ overview page
2. Click the down arrow in the Actions column of the VM you want to resize and click „Resize Instance“
3. Select the new flavor you want to assign to this VM from the „New Flavor“ drop down list and click on „Resize“
4. You will be returned to the Instances overview page with the VM in state „Resize/Migrate“
5. 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.
6. 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:

1. openstack server resize –flavorThis command will attach the new flavor to the VM with the specified ID. Basically, it creates a new copy of the VM with the new flavor assigned. 2.

   openstack server list

   Is 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 3.

   openstack server resize --confirm

   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.

No. If you need to backup your data you are responsible for that.

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.

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

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.

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

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.
2. You need to specify the username you want to use to log in. The username depends on the operating system image you choose when launching a new instance.
3. The default SSH authentication 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.

Typically the username matches the name of the operating system.

„ubuntu“ for all Ubuntu Images

„debian“ for all Debian Images

„almalinux“ for all Alma Linux Images

and so on.

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.

Additional Volumes

If you are dealing with a volume that you attached additionally to you VM, then enlarging is rather straightforward.

1. Connect to your virtual machine via SSH, and unmount the volume.
2. 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)
3. Then click on ‚Extend Volume‘ in the same drop down, and choose a new bigger size for it.
4. After that you can attach the volume again via ‚Manage Attachments‘
5. Adjust the partition layout of the volume if necessary from the virtual machine and mount the volume again.
6. Finally enlarge the filesystem of the volume. For example in case of an xfs or ext4 filesystem use the xfs_growfs /mount/point or resize2fs /mount/point commands.

Root Volumes

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:

1. Delete the virtual machine.
2. Go to the volume page, and extend the volume via the drop down ‚Manage Attachments‚.
3. Then create a new virtual machine from this volume.
4. Finally adjust the partition layout if necessary.

Using the Cinder CLI Client

First of all you have to install the OpenStack and Cinder command line tools on your local (Linux) computer. To install the Cinder CLI on Ubuntu do ‚apt install python3-cinderclient‚.

1. Shut down the instance using the OpenStack CLI command ‚openstack server stop <INSTANCE-UUID>‘ or by using the OpenStack Web UI selecting ‚Shut Off Instance‚ in the pull down menu.
2. When the instance state has changed to shutoff, call ‚ openstack server volume list‚ and get the VOLUME_ID of the /dev/vda volume, i.e. the root volume.
3. Call ‚cinder --os-volume-api-version 3.42 extend <VOLUME_ID> <NEW_SIZE>‚ .
4. Restart the instance using Web UI or by calling ‚openstack server start <INSTANCE-UUID>‘ .
5. Finally adjust the partition layout if necessary and enlarge the filesystem, see above.

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 than one network interface in your VM, then give maximum priority (or lowest metric) to the public one, otherwise the VM won’t be reachable. As being said, if the VM has only only one 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-known Linux distributions.

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 200

should be added

auto lo
iface lo inet loopback

auto eth0
iface eht0 inet dhcp

auto eth1
iface eht1 inet dhcp
metric 200

Ubuntu 18 and later (Netplan)

version: 2
ethernets:
    ens3:
        dhcp4: true
        match:
            macaddress: fa:16:3e:30:36:0c  # MAC address of first network interface
        mtu: 1500
        set-name: ens3

    ens6:
        dhcp4: true
        dhcp4-overrides:
          route-metric: 200
        match:
            macaddress: fa:16:3e:30:36:0d  # MAC address of second network interface
        mtu: 1500
        set-name: ens6

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-, 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=200 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.

SUSE

for each interface there is a script named /etc/sysconfig/network/ifcfg-, 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.

Everyone with a valid IdM Account can login to the compute cloud with this account.

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

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.

./get_volume_dependencies.sh VOLUME: 07e56053-082a-411e-be41-747cd7004a56 (Name: )

VOLUME: 1a0ed73b-d15a-4db2-8a84-c96953c183f0 (Name: )

SNAPSHOT: c90c09b1-01e5-4a9d-b2b6-ba9187f5af6c (Name: snapshot for snapsnap) ??? VOLUME: 1a0ed73b-d15a-4db2-8a84-c96953c183f0 (Name: )

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.

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

First and foremost, please check if the Security Group you are using allows SSH traffic to the 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.

To reach a VM you need to assign a floating IP to it. 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.

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.

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.

If you need to contact us, please provide the following information:

• your User Name (IdM Account) you use to login to the cloud. (never send us any passwords!)
• the UUID(s) of the cloud components, i.e. VM, instance, volume, network etc.

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.

Default quota

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

In CC, flavors follow the SCS standards, with a few exceptions such as flavors with GPUs. For a better understanding of the naming scheme, have a look at here. If you need special flavors for your project, please do not hesitate to contact us.

We are not responsible for problems with software you are running within your VM.

1. Please check the RRZE CC User Guide and (this) FAQ for answers.
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 RRZE CC please use the E-Mail address cc-support@fau.de to open a ticket.