Univention Bugzilla – Bug 20341
Zuordnung: UVMMd, Sessionbroker, Node-Gruppen, Server
Last modified: 2012-03-29 07:53:20 CEST
+++ This bug was initially created as a clone of Bug #18192 +++ (In reply to Bug #18192 comment #4) > Ok, eine Option wäre also den uvmm-node.py Listener aus > univention-virtual-machine-manager-node-common auch auf Sessionbroker-Hosts zu > verwenden. uvmm-node-common macht derzeit einiges, was für den Session Broker nicht notwendig/erwünscht ist: 1. uvmm/managers pflegen, d.h. Xen/Kvm-Hosts hinzufügen entfernen, sobald diese im LDAP registriert werden 2. Dadurch wird /etc/libvirt/libvirtd.conf neu generiert 3. Danach wird libvirtd (univention-virtual-machine-manager-node-common) neu gestartet 4. Legt ggf. die Gruppe "UVMM Nodes" an. 5. Fügt den Rechner der Gruppe "UVMM Nodes" hinzu 6. Stellt libvirt unter die Kontrolle von runit. Was derzeit noch sowohl in UVMM alsauch in DVS fehlt ist eine Zuordnung von UVMMds, Sessionbrokern, Gruppen und Virtualisierungsservern: 1. Wie findet ein UVMMd seine Virtualisierungsserver? Derzeit: LDAP-Suche nach (univentionService=(XEN|KVM) Host) Hintergrund: Hier fehlt definitiv die Möglichkeit, einen UVMMd nur mit den Rechnern der (z.B.) Entwicklung zu haben. (Bug #19532) 2. Wie werden Virtualisierungsserver in UVMMd ggf. gruppiert? Todo (Bug #19171) 3. Von welchen UVMMds läßt sich ein Virtualisierungsservern verwalten? Derzeit: LDAP-Suche nach (univentionService=Virtual Machine Manager) bzw. UCR-Variable "uvmm/managers". Hintergrund: Derzeit muß man die UCR-Variable anpassen, die aber weiterhin vom Listener um neue Rechner erweitert wird. 4. Welche UVMMds verwendet der DVS Session Broker? Derzeit: lokaler UVMMd oder UCR-Variable "uvmm/managers" Hintergrund: wünschenswert ist eine flexible aber fehlertolerante Möglichkeit 5. Welchen Session Broker verwendet ein Client? Derzeit: DNS-Service-Record _dvs_sessionbroker._tcp Hintergrund: Reicht das aus, um für verschiedene Zweigstellen unterschiedliche Session-Broker zu verwenden? 6. Wie Beschränkung man den Session Broker auf eine (Teil-)Gruppe von Virtualisierungsservern innerhalb eines UVMMds? Todo Hintergrund: Es läuft nur ein einziger UVMMd, der die Server der Entwickler aber auch Endanwender verwaltet. Neue Instanzen sollen aber nur auf den Servern für die Endanwender erzeugt werden können, sprich: Im UMC-Modul wird nur ein Teil aller dem UVMMd bekannten Server angeboten. Soll sowas unterstützt werden oder muß man dann dafür auf einem zweiten Rechner einen eigenen UVMMd installieren, der eben nur die User-Server sieht?
Anforderungen: 1. Zuordnung von Servern in 0..1 Gruppen: Innerhalb dieser Gruppe müssen alle Server aufeinander zugreifen können, damit Migration funktioniert. (Bug #19828) 2. Managen von 1..n Gruppen: Server werden nach Gruppen sortiert im UVMM angezeigt. (Bug #19171) 3. Muß auch ohne verfügbares LDAP funktionieren. 4. Wissen muß global verfügbar sein: UVMM soll nur die erlaubten Hosts anzeigen (Bug #19532), Server müssen ihren UVMM kennen. 5. Sollte Out-of-the-Box sinnvoll funktionieren Anmerkungen: Zu 1. Ist mehr als eine Gruppe pro Server, d.h. überlappende Gruppen sinnvoll? - sonst tauchen Server ggf. mehrfach im UVMM auf ? neue Server standardmäßig in "UVMM Nodes" Gruppe, müssen dann verschoben werden. + ermöglicht Migration von Instanzen zwischen unterschiedlicher Gruppen (Dev, Support, Produktiv) bei Überlast, Failover, Backup, Tests, Rollout Zu 3. Auf Servern pflegt bereits ein Listener die UCR-Variable uvmm/managers. Für UVMM ist auch ein Listener für die Reduzierung der Anfragen (Bug #19319) notwendig, der die Daten dann lokal als Fallback vorhalten kann. Zu 4. Derzeit zeigt UVMM Server als nicht verfügbar an, die lokal so umkonfiguriert wurden, daß sie sich nicht von diesem UVMMd verwalten lassen. Umsetzung: * Unix-Gruppen mit bereits existierender LDAP-Schema-Erweiterung aus (40univention-virtual-machine-manager-schema): univention-directory-manager settings/extended_attribute ... \ »···--position "cn=UVMM,cn=custom attributes,cn=univention,$ldap_base" \ »···--set objectClass="univentionVirtualMachineGroupOC" \ »···--set ldapMapping="univentionVirtualMachineGroup" \ »···--set name="UVMMGroup" \ * Die Gruppe sollte auch für Images auf dem (Shared-)Storage für Migration genutzt werden. * Server und UVMMs müssen der Gruppe hinzugefügt werden, beim Auslesen muß dann zwischen Servern und UVMMs unterschieden werden: Alle in die /etc/libvirt/libvirtd.conf, aber nur die Server im UVMMd anzeigen (Lookup ob univentionService=*Host oder UVMM) DVS-Spezifisches: Im Session Broker muß dann die Gruppe(n?) konfiguriert werden: Darüber findet er einen UVMM und die Gruppe der Server. Hier müsste dann auch beim Auslesen zwischen UVMMd-Rechnern und Server unterschieden werden. Hier ist es vermutlich sinnvoll eine Konfigurationsdatei zu erstellen, in der u.a. diese Gruppe und auch die DB-Informationen konfiguriert werden können.
Der Begriff "Gruppen" im Titel und in Comment 2 bezieht sich auf "Eine Ansammlung von zusammengehörigen physikalischen Virtualisierungsservern, z.B. weil zwischen diesen VM migriert werden oder weil alle Server solche einer Gruppe zusammen angezeit/administriert werden sollen", d.h. "z.B. Gruppe der Server der Produktivumgebung, Menge der Entwicklungsserver, Menge der Server in Gebäude 42, aber auch Gruppe aller Server".
Zur Differenzierung: Ein Begriff "DVS Node Cluster" wäre meiner Meinung nach ein Konzept, das über die an diesem Bug angesprochenen "DVS Node Gruppen" hinausgeht und sich durch Features auszeichnen könnte: * Zuweisbarkeit einer DVS Vorlage an einen DVS Node Cluster in UMC * Zuweisbarkeit eines DVS Node Clusters als "Physikalischer Server" für die Desktop-Instanz eines Benutzers im UDM * Automatische Beauftragung eines geeigneten Nodes aus einem zugewiesenen DVS Node Cluster die neue Desktop-Instanz zu "syspreppen" * Möglichkeit der (automatisierten) Live-Migration zum Lastausgleich * Sinnvolle Voraussetzung dafür wäre ein gemeinsames Storage-Backend Hier geht es erstmal nur um DVS Node Gruppen.
OpenDVDI war der Arbeitstitel für die prototypische Implementierung und wird nicht mehr weiter entwickelt. Für Desktopvirtualisierung mit UCS existiert mittlerweile das Produkt UCS DVS. Sollte der hier beschriebene Bug für UCS DVS relevant sein, so kann dieser Bug nach UCS DVS geklont werden.