Sie finden hier häufig gestellte Fragen zum Betrieb virtueller Server (VMs) und unseren hierfür angebotenen Dienstleistungen. (Letzte Anpassung: 06/2023)

Einsatzmöglichkeiten

Kann ich auf einer VM einen Webserver, eine Datenbank usw. installieren?

Ja. Sie können auf den VMs den gesamten technischen Betrieb für die Bereitstellung von Webservern und Datenbanken selbst abwickeln. Für besonders anspruchsvolle Konfigurationen kann zusätzlich auch ein Load-Balancer mit SSL-Offload eingesetzt werden – siehe DLK, Abs. 6.2 Serviceoption: Load Balancer (SLB).

Falls Sie sich jedoch lieber nur um Ihre eigentliche Webanwendung (Typo3, Drupal, WordPress etc.) kümmern möchten und nicht um den dafür erforderlichen technischen Basisbetrieb – u.a. Installation, Updates und Sicherheits-Patches von Betriebsumgebung, Apache, PHP, MySQL, regelmäßige Backups aller Daten sowie Zertifikate für die Verschlüsselung der Kommunikation mit Ihrem Webserver, dann könnte unser Webhosting-Angebot für Sie interessant sein.

Kann ich auf einer VM ein eigenes Active Directory (AD) betreiben?

Hier würden wir eher empfehlen, sich das vom LRZ betriebene MWN-AD anzuschauen. Für die meisten Einrichtungen lohnt sich der Aufwand für den Betrieb eines eigenen AD nicht und die Administrationsrechte für einen Teilbereich im MWN-AD wären ausreichend. Wenden Sie sich bitte an den LRZ-Servicedesk für eine weitere Beratung.

Kann ich auf einer VM einen Fileserver betreiben?

Ja. Fileservices gibt es aber auch als größtenteils kostenfreie Dienstleistung direkt vom LRZ – siehe Online-Speicher.

Kann ich auf einer VM wissenschaftliches Hochleistungsrechnen betreiben?

Im Prinzip schon, allerdings ist die Rechenleistung und der Arbeitsspeicher im Vergleich zu anderen Diensten des LRZ eher limitiert. VMs können aber sehr gut als Web-Portale (Frontends) für wissenschaftliche Applikationen eingesetzt werden – siehe Supercomputing am LRZ.

Bestellung und Abrechnung

Wer darf VMs bestellen?

Diese Dienstleistung bieten wir derzeit nur den sogenannten Nutzerklassen 1, 2 und 3 an. Hinweise zu den Nutzerklassen finden Sie im Abschnitt Preise mit Verweis auf nähere Details im DLK. Die VM-Bestellung von VMs ist an sog. LRZ-Projekte gebunden, siehe nächste Fragestellung. Zur VM-Bestellung, späteren VM-Anpassung und  Löschung ist die jeweilige Projektleitung sowie die, jedem Projekt zugeordneten sog. Master User berechtigt.

Wie beantrage ich ein LRZ-Projekt?

Beachten Sie bitte hierzu die Hinweise zur Projektbindung, die u.a. den Zugang zum Antragsformular für ein LRZ-Projekt beschreiben.

Wie bestelle ich VMs?

Beachten Sie bitte hierzu die Hinweise zur VM-Bestellung, die u.a. den Zugang zum VM-Bestellformular beschreiben.

Wie werden VMs abgerechnet?

Betriebskosten für VMs werden einmal jährlich in Rechnung gestellt. Der Abrechnungszeitraum umfasst das laufende Kalenderjahr, d.h. vom 1. Januar bis zum 31. Dezember. Die Rechnungen werden im ersten Quartal des darauffolgenden Kalenderjahrs versendet. Neben einer Einrichtungsgebühr werden die genutzten Ressourcen tagesgenau berechnet, siehe übernächste Fragestellung.

Jedem LRZ-Projekt ist eine Postadresse und optional eine davon abweichende Rechnungsadresse zugeordnet. Die Projektverantwortlichen (Projektleiter, Master-User) können den zuständigen Projektbetreuer um Adressänderungen bitten. Die Projektverantwortlichen werden regelmäßig bei der jährlich anstehenden Entscheidung über die Projektverlängerung speziell daran erinnert, die Korrektheit der Projektdaten – u.a. auch die Rechnungsanschrift – zu prüfen und ggf. zu korrigieren.

Je LRZ-Projekt ist nur eine einzige Rechnungsadresse festlegbar. Besteht der Wunsch für mehrere Rechnungsadressen, müssen entsprechend mehrere LRZ-Projekte aktiviert und die jeweiligen VMs damit verknüpft werden. Siehe hierzu auch (nochmal) den Abschnitt Projektbindung mit Hinweisen zur Einrichtung zusätzlicher Projekte.

Wenn eine Rechnung bereits erstellt wurde, ist die nachträglich geführte Kommunikation sowie Rechnungsanpassung mit hohem Aufwand verbunden:

1. Kunde muss die Rechnungsadresse korrigieren (lassen) und/oder zusätzliche Projekte mit den jeweiligen Rechnungsadressen beantragen;
2. LRZ muss Buchungsauftrag stornieren;
3. LRZ muss ggf. VMs in neue Projekte verschieben, ggf. VMs umbenennen und die VM-Nutzungsdaten in die zugehörigen Projekte migrieren;
4. LRZ muss neue Rechnungsbeiblätter mit berichtigten Rechnungsadressen erstellen;
5. LRZ muss neue Buchungsaufträge erstellen und an den Kunden zustellen.

Für den Zusatzaufwand kann eine Bearbeitungsgebühr verrechnet werden; die Höhe ist derzeit noch nicht festgelegt, wird sich aber an der Einrichtungsgebühr für VMs orientieren.

Wie kann ich mich über die aktuellen Kosten informieren?

Beachten Sie bitte hierzu die Hinweise zu den Preisen, die u.a. den Zugang zum VM-Calculator beschreiben.

Werden Betriebskosten anteilig abgerechnet?

Ja. Die Abrechnung der Betriebskosten und der Erweiterungen von vCPU, RAM und Disk erfolgt tageweise mit 365 bzw. 366 Tagen pro Jahr.

Technik

Was ist bei Linux-VMs zu beachten?

Damit die Dienstleistung 'Attended Hosting' gewährleistet werden kann, sind bestimmte Voraussetzungen notwendig. Hierzu zählen die nachfolgend aufgelisteten Systemeinstellungen, die nicht angepasst werden dürfen:

Hostname

Der Hostname, auch als Maschinenname bezeichnet, wird bei der VM-Bestellung definiert. Nach VM-Inbetriebnahme ist der Hostname in verschiedenen Instanzen registriert. Nachträgliche Änderungen wären sehr zeitaufwändig und sind deshalb nicht erlaubt! Siehe hierzu auch: Darf ich den Hostnamen meiner (Linux-)VM ändern?

Das Kommando  hostname -f  muss den vorgegebenen Fully-Qualified Domain Name (FQDN) <hostname>.<domain> ausgeben. Bei der strandardmäßigen LRZ-Dienstleistung Server-Hosting ist das FQDN-Schema <ADSOrgPrefix>-<Suffix>.srv.mwn.de vorgegeben. Im Bestellformular ist die individuelle Festlegung des <Suffix> möglich bzw. erforderlich.
→ /etc/hostname → /etc/hosts → /proc/sys/kernel/hostname

Falls abweichende, d.h. grundsätzlich beliebig viele zusätzliche Hostnamen gewünscht sind, werden diese per DNS als Host-Aliase konfiguriert. Letzteres erfolgt nach VM-Inbetriebnahme mit Kenntnis der zugeteilten statischen IPv4- und/oder IPv6-Adresse. Für DNS-Einträge sind die, jeder Domain zugeordneten Zonenverwalter zuständig. Einen Einstieg liefert die Seite DNS-Service sowie die Seite Verwendung eigener Domainnamen u.a. mit Kontaktadressen zur HM, LMU und TUM.

Netzanbindung

Die Netzanbindung wird bei der VM-Neuinstallation eingerichtet. Dabei ist die MAC-Adresse sowie die IPv4- und IPv6-Adresse für jedes Netzwerkinterface inklusiv Gateway konfiguriert. Anpassungen dürfen keinen Einfluss auf den Datentransfer von und nach "außen" haben. Abweichende oder zusätzliche, "von außen sichtbare" MAC- oder IP-Adressen sind nicht zulässig.

VM-Zugang für LRZ-Administratoren

Der VM-Zugang für LRZ-Administratoren wird bei der VM-Neuinstallation eingerichtet und von Zeit zu Zeit aktualisiert.
Ein Login auf der VM-Konsole mit lokaler Kennung vmadm muss gewährleistet sein. Zudem muss vmadm uneingeschrängte sudo-Rechte besitzen. Die Einrichtung und Aktualisierung der Funktionalität geschieht durch Installation des Softwarepakets lrz-user-vmadm.
→ /home/vmadm/ → /etc/passwd → /etc/shadow → /etc/sudoers.d/lrz-user-vmadm → /etc/ssh/sshd_config

Betriebssystem

Das Betriebssystem (OS) wird bei der VM-Bestellung ausgewählt und bis zum Ende des LRZ-Supports durch regelmäßige Software-Updates mittels LRZ-Logistik aktualisiert.
Eine Anhebung der OS-Version (OS-Upgrade), soweit vom LRZ unterstützt, ist grundsätzlich jederzeit möglich und spätestens bei Ablauf einer OS-Supportperiode notwendig. In erster Linie ist der Dienst-Administrator der jeweiligen VM für den OS-Upgrade zuständig; hierzu liefert das LRZ die passenden Hinweise, siehe Betriebssystem-Management, und bietet per Ticket-Anfrage → LRZ Servicedesk technische Unterstützung.
Falls kein OS-Upgrade mehr möglich ist, ist eine Dienstmigration auf eine neu installierte VM notwendig. Für Letztere werden keine Einrichtungsgebühren erhoben. Die Nutzung ist für einen Zeitraum von 14 Tagen kostenfrei; bei einer rechtzeitigen Dienst-Migration entstehen demnach keine Zusatzkosten.
Up- oder Downgrades auf OS-Versionen, die noch nicht oder nicht mehr vom LRZ unterstützt werden, sind nicht erlaubt; siehe auch: Kann ich mein eigenes Betriebssystem auf einer VM installieren? Ein Wechsel des Distributors, z.B. von Debian- auf Ubuntu-Linux, ist ebenfalls nicht zulässig. Für den OS-Wechsel muss eine neue VM beantragt (und die bestehende VM gelöscht) werden.

LRZ-Update

Der regelmäßige LRZ-Update v.a. zur Software-Aktualisierung muss gewährleistet sein.
Ein LRZ-Update erfolgt per Cronjob mit Ausführung lokaler Skripten.
Auf VMs mit Debian- oder Ubuntu-Linux sind die Softwarepakete lrz-base und lrz-base-vmware installiert, die u.a. die beiden Cronjobs /etc/cron.d/lrz-base und /etc/cron.d/lrz-base-automatic-reboot aktivieren, die wiederum /usr/sbin/update-debian.sh ausführen; siehe auch: Wie funktioniert der LRZ-Update bei Debian-/Ubuntu-VMs?
Auf SLES- oder openSUSE-VMs ist der Cronjob /etc/cron.d/lrz-update eingerichtet, der wiederum /usr/local/sbin/update.sh ausführt.
Zur Funktionalität der LRZ-Updates ist ein NFS-Mount des in /etc/fstab definierten NFS-Shares auf die Mountpoints /kdist/ und /ldist/ notwendig.
Für den Update von Softwarepaketen muss stets ausreichend freier Speicherplatz (auf der Systempartition) zur Verfügung stehen; mindestens 1,5 bis 2 GByte sollten es sein. Zudem muss jederzeit die Möglichkeit gegeben sein, dass die vom LRZ-Update betroffenen Verzeichnisse und Dateien angepasst, d.h. neu erstellt, bearbeitet oder gelöscht werden können.

Wichtiger Hinweis! Das regelmäßige, in der Regel automatische Einspielen sicherheitsrelevanter Updates zählt zu den wichtigsten Voraussetzungen für die Bereitstellung dieses Betriebsmodells "Attended Hosting". Falls dies nicht gewährleistet ist, behält sich das LRZ vor, die jeweilige VM ohne Vorwarnung abzuschalten. Der zuständige VM-Dienstadministrator kann die VM reaktivieren und den zugrunde liegenden Fehler beheben, sodass wieder ein regelmäßiger LRZ-Update möglich ist.

E-Mail-Versand

Der E-Mail-Versand ist durch Konfiguration der Postfix-Dateien in /etc/postfix/ voreingestellt und leitet u.a. Systemmeldungen mit Erweiterung der Absendeadresse auf root+<hostname>@<lrz-mail-relay> an die jeweiligen LRZ-Mailrelays weiter. Vorsichtige, i.d.R. nach Rücksprache mit den LRZ-Administratoren vorgenommene Anpassungen der Postfix-Konfiguration dürfen die Weiterleitungslogistik nicht beeinflussen. Sowohl Systemmeldungen (an root), als auch Meldungen an bestimmte LRZ- oder MWN-Adressen der Form <user>@[<subdomain>.]<lrz|mwn>.de, müssen die vorgenannte Absendeadresse verwenden.

Logfile-Management

Das Logfile-Management ist mittels der Software Splunk Enterprise, genauer gesagt mittels SplunkForwarder erweitert. Dieser Dienst leitet den Inhalt des System-Logs (Syslog) auf einen zentralen LRZ-Syslog-Server weiter. Für den Fall einer Kompromittierung stehen somit zusätzliche Daten zur Analyse bereit. Eine anderweitige Datenauswertung findet nicht statt. Die Konfiguration und der Dauereinsatz des SplunkForwarders darf nicht oder nur nach Rücksprache mit den LRZ-Administratoren beeinflusst werden.

Lokale Firewall

Die lokale Firewall wird bei der VM-Inbetriebnahme gemäß Ihren Vorgaben bei der VM-Bestellung für den (ersten) SSH-Zugang eingerichtet. Aktuell wird eine Konfiguration der UFW (Uncomplicated Firewall) ausgeliefert. Hinweise zur Anpassung der Filterregeln finden sich im Internet, z.B. auf der Seite: https://help.ubuntu.com/community/UFW. Es steht jedem Nutzer mit Administrationsrechten frei, beliebige Änderungen vorzunehmen – z.B. die Öffnung für zusätzliche IP-Adressen und/oder Subnetze – oder die Software durch eine Alternative zu ersetzen. Aus Sicherheitsgründen empfiehlt sich die weitgehende Reglementierung für Zugriffe von außen. Beachten Sie hierzu auch den Hinweis: SSH-Zugang auf Linux-VMs absichern.

Was ist bei Windows-VMs zu beachten?

• Windows VMs sind an das MWN-ADS angebunden. Damit ist es nicht möglich, auf den Windows-VMs des LRZ eine eigene Windows-Domäne oder MS Exchange zu betreiben.
• Windows-Updates werden gegebenfalls jeden Samstag um 6:00 Uhr installiert und bei Bedarf erfolgt ein automatischer VM-Neustart. Abweichungen davon können mit den verantwortlichen Administratoren vereinbart werden.
• Getrennte RDP-Sitzungen werden nach 12 Stunden Leerlauf automatisch getrennt. Abweichungen davon können mit den verantwortlichen Administratoren vereinbart werden.
• Die Installation von Servicepacks für das Betriebssystem erfolgt in Absprache mit dem Kunden. Servicepacks für Anwendungen müssen vom Kunden selbst installiert werden.

Welche Systemeinstellungen sind notwendig?

• Siehe Was ist bei Linux-VMs zubeachten?
• Siehe Was ist bei Windows-VMs zubeachten?

Wie groß sollte meine VM dimensioniert werden?

Das kommt auf Ihre Applikation an. Viele unserer Kunden-Systeme, z.B. Webserver, kommen bestens mit der kleinsten Konfiguration aus. Wir empfehlen daher mit einer kleinen Konfiguration zu starten und bei Bedarf mehr vCPUs, mehr RAM oder Disk hinzufügen zu lassen. Das geht sehr schnell und Sie sparen sich Kosten für ungenutzte Ressourcen.

Unter Linux kann die Load-Average ein Indikator sein: bei Werten unter 1 reicht sicher eine vCPU.

Kann ich die Ressourcen meiner VMs erweitern / vergrößern lassen?

Ja, dies ist jederzeit möglich und in aller Regel ohne Unterbrechung der Dienste (d.h. ohne OS-Shutdown) möglich:

Achtung: Wie im Abschnitt Konfigurationslimits des Artikels Server-Hosting beschrieben, darf die Gesamtgröße des virtuellen Plattenspeichers (Systemplatte plus alle Datenplatten) einer VM in Summe maximal 12 TiB betragen.

Kann ich die Ressourcen meiner VMs verringern / verkleinern lassen?

Jein, dies ist nur bei vCPU und RAM möglich und erfordert einen kurzen Shutdown der VM. Festplatten hingegen lassen sich technisch nicht mehr verkleinern:

Achtung: Aufgrund der Tatsache, dass sich Festplatten nicht mehr verkleinern lassen, sollte deren Größe mit Bedacht gewählt werden! Lieber zunächst klein beantragen und dann erst bei Bedarf erweitern lassen.

Wie funktioniert das mit der Systemplatte?

Die Systemplatte ist die virtuelle Festplatte mit dem Betriebssystem. Sie ist je nach Betriebssystem zwischenzeitlich mindestens 20 GiB groß, kann aber größer bestellt werden.
Wenn Sie Anwendungsdaten speichern möchten, empfehlen wir, eine separate virtuelle Festplatte ("Datenplatte") zu bestellen. Diese erleichtert in der Regel zukünftige Software-Upgrades, da Daten und Betriebssystem klarer getrennt sind und verhindert durch die Separierung den Ausfall des Betriebssystems bei voller Ausschöpfung des gesamten Plattenplatzes durch Anwendungsdaten. Auf die Kosten hat die Aufteilung keinen Einfluss.

Beispiel: Sie möchten einen Apache-Webserver betreiben und Ihre Daten bestehen aus den Dateien, die der Webserver ausführt oder ausliefert. In diesem Fall könnten Sie eine 20 GiB Systemplatte und eine 50 GiB Datenplatte wählen, die zum Beispiel unter /srv/www gemountet wird.

Kann ich mein eigenes Betriebssystem auf einer VM installieren?

Leider nein. Die vorbereiteten Betriebssysteme beinhalten mehrere Optimierungen, die einen gemeinsamen Betrieb mit anderen VMs auf einer Infrastruktur sicherstellen. Bei selbstinstallierten Betriebssystemen kann das LRZ diese Einstellungen nicht vornehmen und die potentiell entstehenden Kompatibilitäts-, Leistungs- und Funktionalitätsprobleme würden den Betriebsaufwand enorm steigern.

Was und wieviel ist eine virtuelle CPU (vCPU)?

Die vCPU ist das, was innerhalb einer VM als Prozessor sichtbar ist. Die erzielbare Rechenleistung entspricht maximal einem Core des Hardware-Servers – momentan Intel(R) Xeon(R) Gold 6248 CPU @ 2.50GHz. Eine VM kann derzeit mit maximal 8 vCPUs bestellt werden.

Muss ich die virtuellen CPUs mit einer Anzahl von 1,2,4,8 konfigurieren?

Nein, die Zweierpotenzen sind bei VMs nicht notwendig und eine reine Gewohnheit aus "alten Zeiten". 3 oder 5 vCPUs sind genauso gut geeignet.

Muss ich den Arbeitsspeicher (RAM) mit 1,2,4,8,... GiB konfigurieren?

Nein, die Zweierpotenzen sind bei VMs nicht notwendig und eine reine Gewohnheit aus "alten Zeiten". Größen wie 3 oder 7 GiB sind genauso gut geeignet.

Allgemeines zu VMware-Snapshots

Siehe folgende Seite: Allgemeines zu VMware Snapshots

Kann ich eigene Snapshots erstellen?

Die Erstellung und Verwaltung von Snapshots von virtuellen Servern durch Kunden wird vom LRZ nicht angeboten. Der Grund dafür ist, dass eine Wiederherstellung einer gesamten VM auf einen alten Snapshot diverse Auswirkungen hat, die die Verwaltung der Systeme deutlich erschweren.
Beispielsweise werden alle zwischenzeitlichen Änderungen an Ressourcen, wie vCPUs, RAM etc., rückgängig gemacht und auch Betriebssystem-Updates sind nicht mehr auf dem aktuellen Stand.
Wir empfehlen anstelle von Snapshots den Einsatz zusätzlicher Test-VMs, um Software-Updates und Konfigurationen vor dem Produktionseinsatz zu überprüfen.

Wie funktioniert der LRZ-Update bei Debian-/Ubuntu-VMs?

Durch einen Cronjob /etc/cron.d/lrz-base aus unserem Management-Paket lrz-base wird gemäß LRZ-Standard-Policy zweimal täglich das lokale Skript /usr/sbin/update-debian.sh ausgeführt, welches ebenfalls aus dem Management-Paket lrz-base stammt. Dieses Skript mountet den zuständigen LRZ-Installationsserver und ruft dort das "Master-Skript" chk-all-debian.sh auf. Dieses wiederum arbeitet modular verschiedene Checkskripten ab, um das LRZ-seitige Monitoring der Attended VM zu gewährleisten. Darunter befinden sich u.a. Module wie chk-dfs-debian.sh zum Überwachen der Plattenfüllstände, chk-upd-debian.sh zum Überwachen der Kernel- und Distributions-Aktualität, chk-vm.sh zum Überwachen der nötigen Anpassungen für den Betrieb unter VMware und auch chk-pkg-debian.sh, das sich um die eigentlichen Paketupdates kümmert.

Um das Rad nicht neu zu erfinden, verwenden wir im Modul chk-pkg-debian.sh den unattended-upgrades-Mechanismus, der bereits nativ in Debian vorhanden ist. Damit unattended-upgrades nicht parallel zum LRZ-Update-Mechanismus läuft, sind dessen eigene Automatismen deaktiviert. Wie eingangs beschrieben, wird der LRZ-Update-Mechanismus zweimal täglich aktiviert. Die Ergebnisse können dann in unserer Überwachung sowie den Systemmails aussagekräftig aufbereitet werden.

Was nun genau durch unattended-upgrades geupdatet wird, lässt sich unter /etc/apt/apt.conf.d/90lrz-base-unattended-upgrades einstellen. Dort wird definiert, aus welchen Repositories Updates installiert werden sollen und welche Pakete eventuell nicht angefasst werden dürfen. Diese Datei sollte mit Vorsicht behandelt werden, um nicht versehentlich wichtige Sicherheitsupdates zu deaktivieren. Falls nun Updates installiert werden, die einen Reboot erfordern – derzeit nur Kernelupdates, wird ein "Flag" namens /var/run/lrz-base-reboot-required gesetzt. Die Existenz dieses Flags wird durch einen weiteren Cronjob /etc/cron.d/lrz-base-automatic-reboot in regelmäßigen Abständen geprüft und dann der Server automatisch rebootet, falls nötig. Die Zeiten, in denen ein automatischer Reboot erfolgen darf – natürlich nur falls nötig, werden durch diesen Cronjob geregelt und können bei Bedarf angepasst werden. Von einer kompletten Deaktivierung raten wir jedoch dringend ab!

Kann ich meine bestehende VM klonen lassen, um mit möglichst wenig Eigenaufwand weitere identische Instanzen zu erhalten?

Nein, das LRZ klont keine VMs. Der Grund hierfür ist der Tatsache geschuldet, dass es sich bei VMs in der LRZ-vSphere um zentral gemanagte Systeme handelt, die nur bei der Erstinstallation noch keinerlei Identität, spezielle Einstellungen und Management-Mechanismen besitzen und daher völlig generisch angepasst werden können. Ist ein System einmal fertig eingerichtet, so besitzt dieses individuell auf diese VM-Instanz bzw. Betriebssystem-Instanz angepasste Einstellungen (Hostname, technischer DNS-Eintrag, IP-Adresse, UUID, SSH-/Host-Keys, Logging-Konfiguration, Mail-Konfiguration/-Identität und weitere Management-Mechanismen) und ist in unserem Monitoring-System registriert. Eine nachträgliche Anpassung bereits konfigurierter geklonter Systeme ist daher mit hohem Aufwand auf Systemseite verbunden und es existieren derzeit LRZ-seitig keine Automatismen, die ein solches Verfahren automatisiert ermöglichen. Wenn zusätzlich bereits anwenderseitige Änderungen, Installationen und Konfigurationen auf dem System vorgenommen wurden, erschwert dies noch zusätzlich eine generische Automatisierung, die auf alle Systeme gleichermaßen angewendet werden könnte.

Kann ich meine VM exportieren lassen, um sie z.B. in eine andere Umgebung importieren zu können?

Nein, das LRZ exportiert keine VMs. Diese sind speziell für den Betrieb in der LRZ eigenen Infrastruktur angepasst und weisen spezielle optimierte Konfigurationen (u.a. Netzwerk, Mailing, Kernel-Einstellungen, OS-spezifische Anpassungen, VMware-Container Anpassungen etc.) und Management-Mechanismen auf, sodass diese in anderen Umgebungen gar nicht ohne weiteres lauffähig wären. Wenn Sie eine Kopie Ihres Systems für andere Zwecke benötigen (z.B. eine "identische" Instanz bei einem anderen Hoster oder einem anderen Rechenzentrum zu betreiben und/oder die Original-Instanz nach Umzug löschen lassen möchten), so müssen Sie dies über althergebrachte System-Tools bewerkstelligen und Ihre Daten auf geeignetem Wege aus dem OS heraus exportieren und in ein sauber neu installiertes System der anderen Umgebung importieren.

Kann ich eine bereits bestehende VM importieren lassen?

Nein, das LRZ importiert keine VMs. Bei dem hier angebotenen Dienst handelt es sich ausschließlich um "Managed Server" im Betriebsmodell "Attended Hosting". Extern erzeugte VM-Images können (oft ohne das Wissen des Nutzers) manipuliert worden sein und stellen generell ein hohes Sicherheitsrisiko dar. Des weiteren enthalten anderweitig installierte Systeme nicht die speziell optimierten LRZ-Konfigurationen und Management-Mechnismen und sind daher nicht mit dem Betriebs- und Sicherheitskonzept vereinbar.

Darf ich den Hostnamen meiner (Linux-)VM ändern?

Nein, auf gar keinen Fall! Ihre (Linux-)VM ist über diesen Namen in unserem Management-System registriert und wird hierüber verwaltet. Durch eine Änderung verstoßen Sie gegen unsere Nutzungsbedingungen und wir müssen Ihr System außer Betrieb nehmen!

Kann ich auf meiner Linux-VM eine grafische Benutzeroberfläche installieren?

Dies ist zwar prinzipiell möglich, aber wir raten generell davon ab, eine grafische Benutzeroberfläche auf einer Linux-VM in der LRZ-vSphere zu installieren. Sollten Sie diese aus Gründen dennoch benötigen, sollten Sie dabei unbedingt drei wichtige Punkte beachten, da Sie sonst gegen unsere Nutzungsbedingungen verstoßen:

• Der VM-Zugang für LRZ-Administratoren darf dadurch auf keinen Fall behindert werden, d.h. der Systembenutzer vmadm muss sich jederzeit in die Benutzeroberfläche einloggen können.
• Nach der Beendigung der Arbeiten in der VMware-Konsole müssen alle angemeldeten User abgemeldet werden.
• Die VMware-Konsole dient lediglich als Notfallzugang (siehe "Leistungsbeschreibung") bei Störungen und darf keinesfalls zum alltäglichen Arbeiten an der Maschine verwendet werden! Es existiert zu jeder VM nur eine einzige Konsole und jede Person mit Zugriff auf die Konsole kann genau diese Sitzung sehen und voll mit ihr interagieren! Zudem ist auch die Anzahl der offenen Konsolen für die gesamte Infrastrukur technisch limitiert, d.h. dass unter Umständen keine Konsolen mehr auf anderen VMs geöffnet werden können.

Darf ich die VMware-Konsole / Webkonsole / Remote Console im vSphere Client zum alltäglichen Arbeiten am System verwenden?

Auf keinen Fall! Wie bereits in unserer Leistungsbeschreibung erwähnt, handelt es sich bei der Konsole im vSphere Client nur um einen Notfallzugang, der wunderbar zur Behebung von Störungen (insbesondere bei Netzwerk- bzw. Login-Problemen) geeignet ist. Für das alltägliche Arbeiten am installierten Betriebssystem ist sie ungeeignet und darf dafür aus folgenden Gründen nicht permanent verwendet werden:

• Es existiert zu jeder VM nur eine einzige Konsole und jede Person mit Zugriff auf die Konsole kann genau diese Sitzung sehen und voll mit ihr interagieren! Damit ist auch der VM-Zugang für LRZ-Administratoren während der Nutzung blockiert, was gegen unsere Nutzungsbedingungen verstößt! Aus diesem Grund ist es unerlässlich, nach jeder Störungsbehebung den entsprechenden Benutzer auf der Konsole wieder auszuloggen, da sonst der nächste Konsolenbenutzer eine offene und authentifizierte Sitzung vorfindet!
• Die Anzahl der offenen Konsolen für die gesamte Infrastrukur ist technisch limitiert, d.h. es können unter Umständen keine Konsolen mehr auf anderen VMs geöffnet werden.

Für die alltäglichen Arbeiten sollten daher immer die üblichen betriebssystemspezifischen Fernzugriffs-Tools wie z.B. SSH oder RDP verwendet werden.

Netzanbindung

Welche Netzanbindung haben VMs?

Einer VM stehen bis zu 25 GBit/s an Bandbreite zur Verfügung und bereits mit einer vCPU können mehrere 100 MBit/s übertragen werden. Jeder Host der Infrastruktur ist mit jeweils 100 GBit/s direkt an die Backbone des Münchner Wissenschaftsnetzes (MWN) angebunden. Der Netztraffic ist in den Betriebskosten enthalten.

Was ist der Unterschied zwischen MWN-weiten und weltweiten Netzen für VMs?

Das vom LRZ betriebene Münchner Wissenschaftsnetz (MWN) nutzt einen privaten IP-Adressbereich, der nur innerhalb des MWN, aber nicht direkt aus dem Internet erreichbar ist. Über das LRZ-VPN kann man indirekt auch aus dem Internet auf diese Server zugreifen. Weltweite Netze sind auch aus dem Internet erreichbar.

Wenn Sie nicht sicher sind, ob Ihr Server unbedingt weltweit erreichbar sein muss, empfehlen wir den Betrieb im MWN-weiten Netz. Damit wird das Risiko von Angriffen auf den Server deutlich reduziert. Ausgehende Verbindungen ins Internet sind übrigens in beiden Fällen möglich.

Kann ich mein Lehrstuhl-VLAN an eine VM anbinden, um z.B. DHCP zu nutzen?

Eine solche Konfiguration ist leider nicht möglich. Der Grund ist die Designentscheidung im Münchner Wissenschaftsnetz (MWN), dass keine VLANs über die standortübergreifende Backbone geleitet werden sollen. Daher können VMs nur die vorgegebenen VLANs – MWN-weit und Welt-weit – verwenden.

Für DHCP bietet das LRZ übrigens direkt einen DHCP-Dienst an.

Kann ich ein Zertifikat für meine VM beantragen?

Standardmäßig liefern wir VMs mit sogenannten technischen DNS-Einträgen in der Zone srv.mwn.de aus. Der jeweilige FQDN erhält somit eine Verknüpfung mit den zugehörigen IPv4- und IPv6-Adressen. Der technische DNS-Eintrag dient hauptsächlich zur Verwaltung Ihrer VM, für den technischen Zugang und für das Monitoring Ihrer VM. Sie können diesen DNS-Eintrag auch direkt für Ihre eigenen Zwecke nutzen, jedoch ist eine Ausstellung von Zertifikaten in dieser Zone nicht möglich!

Falls Ihr Dienst Zertifikate benötigt, so müssen Sie eine eigene DNS-Zone dafür verwenden. Dazu legen Sie einen CNAME Record in Ihrer Zone an und lassen diesen auf den von uns bereitgestellten technischen DNS-Eintrag verweisen. Stellen Sie sicher, dass Ihr Dienst auch auf den entsprechenden CNAME Ihrer Zone reagiert. Zusätzliche Hinweise gibt es auf folgender Seite: Server-Zertifikate. Für Nutzer der TUM und LMU gibt es auf vorgenannter Seite Links zu weiterführenden Informationen; siehe "ganz unten".

Problemlösungen

Ich kann mich nicht am VMware vSphere Webinterface anmelden.

Wenn Sie Master-User eines LRZ-Projekts sind, beachten Sie bitte den Abschnitt Projektbindung. Ein Master-User muss folgende Schritte beachten:

• Das jeweilige LRZ-Projekt wird mit Login in das IDM-Portal 2 verwaltet. Ein Master-User muss sich dort anmelden und das jeweilige Projekt auswählen.
• Sofern noch nicht vorhanden, muss die Berechtigung für den Dienst 'LRZ-vSphere' beantragt werden.
• Sofern noch nicht geschehen, muss die zu berechtigende Kennung in die dem LRZ-Projekt zugeordnete SIM-Gruppe des Dienstes 'LRZ-vSphere' (IFS_<Projektname>) als Gruppenmitglied eingetragen werden.

Wenn Sie Zugang zum VMware vSphere Webinterface für VMs eines LRZ-Projekts benötigen, für das Sie keine Master-User-Berechtigung besitzen, müssen Sie sich an den/einen zuständigen Master-User wenden. Der Master-User muss Sie gemäß der vorgenannten Schritte validieren.

Die VMware Remote Console (VMRC) lässt sich nicht öffnen.

Hinweise zur Benutzung der VM-Konsolen

Meine VMware-Konsole geht nicht – ich sehe ein "connection timed out".

Sie haben vermutlich das VMware-Browser-Plugin für die Konsole installiert. Dieses versucht sich direkt mit einem VMware-Host zu verbinden, was aus Sicherheitsgründen nicht möglich ist. Bitte entfernen Sie das VMware-Plugin – dann wird der Browser die sog. HTML5-Konsole verwenden, die im gesamten MWN uneingeschränkt funktioniert.

Eingeschränkte VM-Funktionalität wegen vollständiger Filesystembelegung.

Viele "komische" Effekte, u.a. verzögerte Logins auf VMs und dann eingeschränkte Kommando-Funktionalität, lassen sich auf eine Vollbelegung v.a. der Systempartition zurückführen. Nähere Details hierzu sind auf folgender Seite beschrieben:

Systempartition zu 100% voll

Die VM wurde vom LRZ außer Betrieb genommen.

Sofern eine der folgenden Situationen erkennbar ist, behält sich das LRZ vor, VMs außer Betrieb zu nehmen. Je nach Dringlichkeit kann die Außerbetriebnahme unmittelbar oder nach entsprechender Vorwarnung, d.h. Benachrichtigung des/der vom Kunden definierten Verantwortlichen erfolgen.

• Der Kunde bittet per Incident-Ticket um die Außerbetriebnahme;
• Die Laufzeit des zugehörigen LRZ-Projekts ist beendet; ein Antrag zur Verlängerung wurde nicht gestellt;
• Das LRZ-Projekt wurde aus bestimmten Gründen gesperrt;
• Die LRZ-Benutzungsrichtlinien sind nicht berücksichtigt/erfüllt; siehe https://www.lrz.de/wir/regelwerk/
• Eine VM-Kompromittierung, z.B. nach erfolgreich durchgeführtem Hackerangriff, ist erkennbar;
• Sicherheitsupdates, die nicht per LRZ-Automatik eingespielt werden (können), bleiben aus und es ist keine Problemlösung in Sichtweite. Gemäß LRZ-Policy müssen Sicherheitsupdates grundsätzlich binnen 7 Tagen eingespielt werden.

In der Regel werden alle VM-Verantwortlichen, d.h. sowohl die vom Kunden genannten Dienst-Administratoren, die Master-User und die Projektleitung über eine erfolgte oder (unmittelbar) bevorstehende VM-Außerbetriebnahme per E-Mail benachrichgtigt.

Nach Außerbetriebnahme besteht, sofern nicht anderweitig vereinbart, beauftragt und/oder festgelegt, eine 4-wöchige Frist bis zur (endgültigen) Löschung der jeweiligen VM. Nach Löschung einer VM ist deren Wiederherstellung nur mehr im Rahmen der Aufbewahrungszeit von Backups, sofern vorhanden, möglich. Eine Wiederherstellungsgarantie kann nicht zugesagt werden.