Virtual Machines

For projects whose requirements cannot be met by the existing IT services, virtual machines (VMs) can be provided by the FB3 on a Proxmox cluster (as long as resources are available).

If you need a VM, please send an email to serviceinformatik.uni-bremen.de. The email should include the following information:

Contact persons for the VM
- Note: When the contact persons for a VM change, please remember to inform us about this, so e.g. reminders about expiring VMs go to the right people.
Name of the project/workgroup
Required resources (number of CPU cores, RAM, disk space)
- Note: Please provide sensible/realistic values here. We have limited resources, and especially RAM and disk space cannot simply be overbooked for stability reasons. A "more is better" approach to resource allocation is inappropriate here. If it turns out later that more resources are required, VMs can be resized.
Desired hostname ($NAME.informatik.uni-bremen.de)
Desired operating system (examples)
- Debian
- Ubuntu
- Alma/Rocky/CentOS Stream
One or more public SSH keys
If the project is conducted in a workgroup with its own IP address range which the VM should be in, the VLAN and IP address
Expected usage duration for the VM (expiration date)
Firewall rules, if desired
- Note: When no firewall is configured for a VM, it is accessible globally from anywhere.

Available operating systems

Any Linux distribution for which a cloud image with cloud-init is available can generally be offered.

Windows can also be used in principle; however, we do not provide any licenses. It is essential to ensure that licenses are obtained that are suitable for the intended use and for virtual machines. In particular, for Windows Server versions, it must be noted that, in addition to the OS license, licenses/subscriptions for CPU cores are also required.

Accessing virtual Machines

VMs are generally accessed via SSH. Additionally, there is a web interface through which the VMs can be managed (start, stop, access to the console, boot from ISOs), where you can log in with your account after activation.

The technical staff does not set up its own access to hosted virtual machines but can execute any commands with root privileges via the qemu-guest-agent installed in the guest system if necessary, allowing to e.g. reset passwords in case of being locked out.

Usage duration / expiration date

The expiration date primarily serves to avoid orphaned VMs and can be extended as many times as needed. An automatic warning email is sent to all contact persons 30 days before a VM expires. After a VM has expired, it is shut down and retained for at least one week before being deleted.

Notes on Operating VMs

The technical staff does not perform maintenance on the guest systems of provided VMs. Users of the VMs must ensure their secure operation themselves.

This includes, among other things:

Regularly installing updates.
- For VMs that are operated long-term, this may also include upgrades to a new version of the operating system, especially if there are no longer security updates available for the installed version.
Securing services running on the VM against unauthorized access.
- Use of Strong Authentication Methods (For example, it is recommended to allow access via SSH only through public key authentication).
- Services that do not need to be accessible from the outside should only listen on localhost or a socket.
- Alternatively, a firewall can be configured within the guest system, or by technical staff at the virtualization cluster level (e.g. to restrict access to the campus network).

Maintenance and outages

Maintenance work and outages that affect the availability of VMs are announced on the status page for FB3 services.

Virtual machines can usually be moved between the nodes of the Proxmox cluster without downtime, allowing them to continue running during maintenance, e.g. when nodes are rebooted after applying updates.

Backup

All virtual machines are backed up every day at around 23:00. Backups are retained for 14 days.

If commands need to be executed before or after the backup, e.g. to dump a database, you can create and make executable the files /opt/pve/preBackup.sh and/or /opt/pve/postBackup.sh. If they exist, they will be executed before/after the backup by the qemu-guest-agent in the guest system.