IRB Virtual Machine Cluster

The IRB manages a Virtual Machine (VM) Cluster running VMware vSphere.

Our cluster contains 16 nodes with 64 Cores apiece and provides almost 3 THz of CPU capacity, 32 TB of Memory, and around 900 TB of SAN Disk Space for more than 500 Virtual Machines.

13 of the nodes are equipped with two NVIDIA H100 GPUs each.

You may request a new VM via Email to irb-linux-support[at]uni-paderborn.de

The IRB requires a steadily available point of contact for each VM, so requests for new ones can only be made by permanent employees of the Computer Science Department. If you are a student and would like to request VM, please ask your Advisor to request one for you on your behalf.

Your email must contain the following information about the VM:

  • Purpose of the Host
  • Hostname
    • The default domain is cs.uni-paderborn.de
  • Required Resources
    • Default Resources are
      • 2 CPU
      • 4 GB RAM
      • 30 GB Disk Space (Base) + 0 GB (Data)
    • The base disk space will suffice for many use cases. We recommend requesting an additional disk for Data storage starting at 10GB of application data.
    • Please justify your requests for any resources exceeding these defaults.
  • Operating System
    • Our managed systems consist of the most recent Version of Debian.
    • By default, we remind the administrator on required reboots after updates. If the server must not be rebooted with other servers, for example in a Cluster, or must not be automated reboot at all, please tell us.
    • We can start the Installation for (some) other OS types, but do not manage these. Especially we don't offer services like backup, certificates or support for them.
  • Persons of Contact
    • Administrative (AdminC) — carries responsibility for the VM; required to be a permanent employee
      • Name
      • IMT Account
      • E-Mail
      • Fachgruppe
    • Technical (TechC) — takes care of technical administration of the VM (OS, services, upgrades); only if different from the AdminC; can be a student
      • Name
      • IMT Account
      • E-Mail
      • Telephone Number (only for Emergencies: hacked VM, etc.)
  • Duration of Use
    • Default: 15 Months
    • The AdminC will be notified three months before each expiration date and will be able to extend the lifetime of the VM for up to a year each time.
  • Optional: Firewall Whitelist
    • Port(s) and protocol(s) (TCP/UDP)
    • The IMT firewall denies all uni-external access to VMs by default. Any global firewall rule must be reasoned to the IRB.
  • Optional: Backups
    • Should we make backups of your VM? Please note that continually changing data cannot be safely backed up. Instead, please dump/snapshot this data to disk and inform us of the list of directories containing the continually changing source data, so that we may exclude these directories from our backups and only include your dumps/snapshots.
    • These daily backups are encrypted and hosted at the RWTH Aachen.
  • Optional: DFN X509 Certificate
    • Default expiry: 1 year after issuance
    • Allows seting up HTTPS on webservers
  • Optional: Docker
    • If you intend to use docker, please let us know so we can provide an optimized VM configuration that avoids several common problems.
  • Optional: Any other special requirements

If you'd like, we can also discuss the individual needs of your application so that we can provide a VM that's tailored to your use case.

If you are planning to scan the internet with this VM you need to pay attention to the notes from the IMT regarding network scans and also says this in the VM request.

The TechC of your VM (and any other users you request) will be granted access to the VM Administration Console via vSphere, which allows accessing the VM's graphical console and functions such as shutting the system down, power cycling and rebooting.

The vCenter server can be reached via https://vmc.cs.uni-paderborn.de. Use your standard IMT credentials to log in.

Backup

The VMs are stored in our Storage Attached Network (SAN).

All SAN components are redundant, managed, and fault tolerant, so data loss due to hardware failure is very improbable, but not impossible. Of course, hardware is only one possible source of error. We strongly recommend a dedicated external backup solution for VM systems.

Warning: You are wholly responsible for ensuring your data is backed up.

A useful, production-ready backup system is IBM Spectrum Protect (formerly Tivoli), which the Paderborn University uses to store backups on the RWTH Aachen's servers. Further information regarding this service is available from the IMT, which manages this service.

Archiving

All Data we hold regarding your VM will be deleted at most 1 year after expiration of your VM, or upon request.

Please note that our VMs are unsuitable for long-term archiving of your data. Please make use of the RWTH Aachen's dedicated archive services instead.

Securing your VM

Our VMs are outfitted with a public IP Address, and are connected to the Internet.

It is imperative that you keep your VMs up-to-date, secure and monitored.

We recommend setting up automatic updates, a firewall, being conservative with permissions, and disabling password authentication (use public keys instead). Please contact us if you need help with this.

You are fully responsible for Virtual Machines you administer.

VMware Tools/Upgrades of the virtual Hardware

We require installation of a system service within VMs for keeping VMware tools up to date and secure to allow orderly communication with the VMs over vSphere, and to ensure stability of our VMware cluster.

An installation guide for these tools is available from VMware here (pdf).

Warning: If the VMware Tools are not installed or problems occur due to out-of-date virtual hardware, then the VM may be shut down during maintenance.

Lifetime of ISOs, Snapshots, and other Disk Images

Mounted ISOs complicate internal shuffling of VMs between cluster servers, which can severely impact the performance of your VM. In addition, snapshotting VMs with mounted ISOs creates a hard dependency on these, only resolvable via deletion of the affected snapshot, which drastically reduces the flexibility of these snapshots.

ISOs should only be mounted briefly, and no snapshots should be made of a VM with a mounted ISO.

We reserve the right to forcibly unmount ISOs or delete such snapshots if these impede necessary cluster management operation.