IRB Vir­tu­al Ma­chine 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 who would like to request VM, please ask your Advisor to request one for you on your behalf.

 

Form with recommended default values:

The fields printed in bold are required.

  • Hostname:
  • Use Case:
  • CPUs: 2
  • RAM: 4 GB
  • Additional Storage (on top of Base Storage ): 0 GB
  • Operating System: IRB Debian
  • AdminC UPB Username:
  • TechC UPB Username:
  • TechC phone number: none
  • Duration: 15 Months
  • Firewall Whitelist: none
  • Firewall Purpose: none
  • Backups: none
  • Docker: none
  • Additional Requests: none

 

Detailed explanation

  • Purpose of the VM
    • For what do you need the VM?
    • Must be a specific reason.
  • Hostname
    • Please choose an appropriate name for the VM
    • The VM will be reachable under <VM-Name>.cs.uni-paderborn.de
  • Required Resources
    • Default resources:
      • 2 CPU
      • 4 GB RAM
      • 64 GB Disk (Base storage)
    • In many cases, the basic storage is enough, but we can give you additional storage, usually mounted under /data, if you require more.
    • Further allocations are only provided if the purpose of the VM requires it.
  • Operating System
    • The VMs use an up-to-date version of Debian per default, which we update, maintain and administrate.
    • Users of our version of Debian are reminded for required reboots after updates and the VMs automatically update, if not in use.
    • 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.
    • Tip: We recommend systemd-inhibit to temporarily prevent reboots.
    • Our version of Debian ships with TLS-certificates.
    • 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.
  • Person of Contact
    • Administrative (AdminC) — carries responsibility for the VM; must be a permanent employee
      • UPB-Account (required)
      • preferred UPB-E-Mail (optional)
      • working group (optional)
    • Technical (TechC) — takes care of technical administration of the VM (OS, services, upgrades); only if different from the AdminC; may be a student
      • UPB-Account (required)
      • preferred UPB-E-Mail (optional)
      • Telephone Number (only for Emergencies: hacked VM, etc; recommended, but not required)
    • Technical Abuse (AbuseC) — contacted for reporting potential malicious use; only if different from the TechC; may be a student
      • UPB-Account (required)
      • preferred UPB-E-Mail (optional)
      • Telephone Number (only for Emergencies: hacked VM, etc; recommended, but not required)
  • 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: 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. In addition, please provide an AbuseC (see above).

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.