• Virtuelle Maschinen
  • Beantragung
  • Richtlinien
  • Batch-Beantragung
  • Anpassungen
    • Windows Server 2019

Virtuelle Maschinen

Zum Hosting von Diensten bieten wir virtualisierte Rechner an.

Beantragung

Deine Organisationseinheit muss einen ESX-Administrator benannt und eingewiesen haben.

Mail an support@ito.cit.tum.de mit dieser Antragsbox:

Zugriff: Nutzer und deren SSH-Keys können in der StrukturDB verwaltet werden. Die Änderungen sind sofort aktiv.

• CIT-Org: Zuordnung zur Organisationseinheit der CIT. VM-Name wird z. B. orgvm42.
• Kurzer Projektname: Möglichst ein bis drei Wörter, die diesen Server eindeutig bezeichnen.
  In der Verwaltungsoberfläche wird dieser Name angezeigt als orgvm42 - ${kurzer projektname} zu sehen sein. Ziel: Schnelle Übersicht über den Zweck der Maschine.
• Weitere Beschreibung des Projektes: Hier können Sie zum Beispiel schreiben, ob es sich um eine Doktorarbeit handelt oder um Infrastruktur des Lehstuhls
• Projektlaufzeit: Eine unverbindliche Angabe, die uns bei der Planung hilft. Auch unbestimmt ist gültig.
• Ansprechpartner: Zwei Personen, die mit dem Projekt und mit der Bedienung von VMware vertraut sind. Wir brauchen den zweiten Ansprechpartner, falls der erste nicht erreichbar ist.
  • Bitte CIT-Loginnamen angeben
• Hardware: Wenn weiter nichts angegeben ist, bekommt der Server 4 CPU und 4 GB RAM. Die Größe der Systemplatte ist immer 80 GiB.
  Erweiterung möglich:
  Festplattenkapazität: weitere Festplatte als Ceph RBD, welches separat vom ESX-Verwalter gesichert werden muss und nicht von der ITO gesichert wird.
  CPU: bis zu insg. 6 vCPU
  RAM: bis zu insg. 8 GB RAM

Richtlinien

Damit die vielen VMs reibungslos laufen können, müssen Regeln eingehalten werden:

• VMs im Cluster sind Dienste, also es sind keine Rechenintensiven Programme erlaubt.
• Betriebssystem aus Template der ITO (Stand Dezember 2024):
  • Ubuntu Server 24.04
  • Windows Server 2019 Datacenter
• Die ITO Systemgruppe hat für alle Server root-Zugang/Admin-Rechte. Unsere Benutzer dürfen nicht vom System entfernt werden, der SSH-Port darf nicht geändert werden.
• SSH-Login aussschließlich mit Public Keys ist ausdrücklich erlaubt.
• Um die übrigen VMs im Cluster nicht unnötig zu belasten, bitten wir um verantwortungsvollen Umgang mit den Ressourcen. Wenn alle Server gleichzeitig CPU, Netzwerk oder Disk-IO bis zum Maximum belasten würden, würde der Cluster sehr träge werden.
• Sicherheitpatches für Ubuntu oder Windows müssen regelmäßig eingespielt werden.
• Führen Sie bitte kein Release-Upgrade auf eine andere Windows-Version, einen neueren Ubuntu-Release oder ein anderes Betriebsystem durch.
• Die VMware-Tools (zur Integration des Systems in die Virtualisierungsumgebung) dürfen nicht entfernt werden.
• Für jede VM sollte jederzeit ein Ansprechpartner erreichbar sein (auch bei Urlaub, daher mindestens zwei Kontaktpersonen).

Wir empfehlen außerdem folgende optionale Maßnahmen:

• Die VMs sind zur Benutzung als Server vorgesehen. Bitte keine Desktop-Umgebung auf Linux-VMs installieren.
• Zugriffsbeschränkung durch Firewall gerne möglich (z.B. nur aus Organisationsnetz und VPN) - Verwaltung der Firewall durch Org-Admins mit Auftrag an die ITO Netzwerkgruppe
• Sehr gerne SSH-Zugriff ausschließlich mit Public Key Authentication (PasswordAuthentication no)

Batch-Beantragung

Sollten eine Reihe VMs benötigt werden, bitte eine yaml-Datei für automatische Bearbeitung einsenden:

Anpassungen

Windows Server 2019

Bitte macht kein In-Place-Update von Windows 2012 zu 2019. Gerne stellen wir euch hierfür frische VMs zur Verfügung.

In unserem Windows 2019-Image haben wir geändert:

• Firewall: File and Printer Sharing (Echo Request - ICMPv4-In + ICMPv6-In) Enable
• Server Manager - Add Roles and Features - Telnet Client
• NTP Config (in Admin-CMD Shell):
  • net stop w32time
  • w32tm /config /syncfromflags:manual /manualpeerlist:"ntp1.in.tum.de,ntp2.in.tum.de"
  • w32tm /config /reliable:yes
  • net start w32time
• SSH Server / Client:
  Settings → Apps → Apps and Features → Manage Optional Features → OpenSSH Server; Client ist bereits installiert
• Nochmal SSH (in einer Admin Shell):
  • Install-Module -Force OpenSSHUtils -Scope AllUsers
  • Set-Service -Name ssh-agent -StartupType ‘Automatic’
  • Set-Service -Name sshd -StartupType ‘Automatic’
  • Start-Service ssh-agent
  • Start-Service sshd
• LRZ Windows Updates
  Den Gruppenrichtlinieneditor ausführen: Start → gpedit.msc
  • Computer Configuration → Administrative Templates → Windows Components → Windows Update
  • "Configure Automatic Updates" → 3 - Auto download and notify for install
  • "Specify intranet Microsoft update service location" → https://sus.lrz.de als intranet update und intranet statistics server
  • "Do not connect to any Windows Update internet locations" → Enable
  • "Enable client-side targeting" → Enabled
  • Target group name: Server
• Telemetrie:
  • Group Policy Editor gpedit.msc ; wieder zu Windows Components - Data Collection and Preview Builds
  • "Allow Telemetry": Disabled
• Zusätzlich Telemetrie: Start → Settings → Privacy → Diagnostics & feedback
  • Diagnostic data: basic
  • Feedback frequency: never
• KMS Server: In einer Admin cmd-Shell
  • cscript \windows\system32\slmgr.vbs -skms kms.in.tum.de