Verwaltung für ein- und auschecken von VMs
Hallo,
wir haben ca. 20 Mitarbeiter, die für die Wartung von älteren Maschinen und Anlagen, teils sehr alte Software benutzen müssen.
Passend zu der alten Software ist dementsprechend auch das OS. Ab Win XP ist alles dabei.
Früher hatten wir dazu eigene Laptops, die für den jeweiligen Auftrag dann aus dem Schrank geholt wurden.
Probleme: Überschneidung von Aufträgen, aber nur ein Gerät da und Hardwaredefekte.
Idee war dann, wir virtualisieren dies.
Dies funktioniert auch prinzipiell gut. Die MA kopieren sich die notwendige VMs auf den eigenen Laptop und fahren dann zur Anlage.
Nun hat sich aber herausgestellt, dass auf diesen VMs und an den Programmeinstellungen auch Änderungen vorgenommen werden müssen.
Die angepasste VM wird dann wieder auf die zentrale Ablage kopiert.
Damit ist die Herausforderung hier wahrscheinlich schon jedem klar.
Der letzte VM, die hochgeladen wird, gewinnt. Hat jemand vorher eine Änderung hochgeladen, wird das überschrieben.
Das Problem ist den MA bekannt, aufgrund der Anzahl der MA und mittlerweile auch VMs verliert man aber die Übersicht.
Wir sind also auf der Suche nach einer Lösung / Software / Verwaltungssystem mit der man VMs aus- und einchecken bzw auch versionieren kann.
Kennt jemand dazu etwas? Oder hatte schon mal eine ähnliche Herausforderung?
Derzeit nutzen wir den VMWare Workstation Player.
Danke und Gruß
wir haben ca. 20 Mitarbeiter, die für die Wartung von älteren Maschinen und Anlagen, teils sehr alte Software benutzen müssen.
Passend zu der alten Software ist dementsprechend auch das OS. Ab Win XP ist alles dabei.
Früher hatten wir dazu eigene Laptops, die für den jeweiligen Auftrag dann aus dem Schrank geholt wurden.
Probleme: Überschneidung von Aufträgen, aber nur ein Gerät da und Hardwaredefekte.
Idee war dann, wir virtualisieren dies.
Dies funktioniert auch prinzipiell gut. Die MA kopieren sich die notwendige VMs auf den eigenen Laptop und fahren dann zur Anlage.
Nun hat sich aber herausgestellt, dass auf diesen VMs und an den Programmeinstellungen auch Änderungen vorgenommen werden müssen.
Die angepasste VM wird dann wieder auf die zentrale Ablage kopiert.
Damit ist die Herausforderung hier wahrscheinlich schon jedem klar.
Der letzte VM, die hochgeladen wird, gewinnt. Hat jemand vorher eine Änderung hochgeladen, wird das überschrieben.
Das Problem ist den MA bekannt, aufgrund der Anzahl der MA und mittlerweile auch VMs verliert man aber die Übersicht.
Wir sind also auf der Suche nach einer Lösung / Software / Verwaltungssystem mit der man VMs aus- und einchecken bzw auch versionieren kann.
Kennt jemand dazu etwas? Oder hatte schon mal eine ähnliche Herausforderung?
Derzeit nutzen wir den VMWare Workstation Player.
Danke und Gruß
Please also mark the comments that contributed to the solution of the article
Content-ID: 668539
Url: https://administrator.de/contentid/668539
Printed on: October 13, 2024 at 10:10 o'clock
10 Comments
Latest comment
Also die Situation ist schon sehr speziell. Wenn die VMs auf ihrer zentralen Ablage nur "liegen" und nicht von dort aus online gehen könnte streng genommen auch jedes DMS dafür eingesetzt werden. Aber bei jeder neuen Version wird die komplette Datei dupliziert, nicht nur etwa Änderungen. Das könnte schnell speicherintensiv werden.
Du kannst den Nutzern auch das Recht Ändern und Löschen auf dem Volume für die VMDKs entziehen, damit zwingst du sie, neue Versionen auch als neue Datei abzulegen. Ein Datum + ggf. Benutzername als Namenskonvention und schon habt ihr eine Versionierung. Allerdings hast du dann kein Checkout / Sperre, das müsste auch organisatorisch gelöst werden.
Hallo,
über Versionierung wurde ja schon gesprochen.
Ich wäre auch ein Fan dafür die VM im RZ zu hosten und nur die Kommunikation zum Standort zu schicken.
Sofern das technisch geht. Es ist ja nicht alles Ethernet was glänzt...
Alternativ werfe ich noch eine verzögerte Versionierung in den Raum.
Die Techniker dokumentiere alle gemachten Änderungen und spielen die VM nicht zurück.
In der Firma setzt sich Jemand mit den Notiozen hin und ändert die VM direkt am Server.
Damit umgeht man auch das Problem, dass zwei Leute gleichzeitig Änderungen machen.
Ja, das ist aufwendiger. Ist aber die Frage wie häufig Änderungen vorkommen und wie aufwendig diese sind.
Stefan
über Versionierung wurde ja schon gesprochen.
Ich wäre auch ein Fan dafür die VM im RZ zu hosten und nur die Kommunikation zum Standort zu schicken.
Sofern das technisch geht. Es ist ja nicht alles Ethernet was glänzt...
Alternativ werfe ich noch eine verzögerte Versionierung in den Raum.
Die Techniker dokumentiere alle gemachten Änderungen und spielen die VM nicht zurück.
In der Firma setzt sich Jemand mit den Notiozen hin und ändert die VM direkt am Server.
Damit umgeht man auch das Problem, dass zwei Leute gleichzeitig Änderungen machen.
Ja, das ist aufwendiger. Ist aber die Frage wie häufig Änderungen vorkommen und wie aufwendig diese sind.
Stefan
Nachtrag zu Versionierung.
Man muss ja nicht die ganze VMDK übertragen.
Warum nicht Git innerhalb der VM nutzen um die Program- und Konfigurationsdateien zu übertragen?
Für Registryänderungen kann man diese recht einfach in eine Datei schreiben und dann zurückschreiben.
Sofern die VM Internet kann.
Stefan
Man muss ja nicht die ganze VMDK übertragen.
Warum nicht Git innerhalb der VM nutzen um die Program- und Konfigurationsdateien zu übertragen?
Für Registryänderungen kann man diese recht einfach in eine Datei schreiben und dann zurückschreiben.
Sofern die VM Internet kann.
Stefan
Ich finde den Ansatz von @StefanKittel tatsächlich besser, weil er auch eine Dokumentation bildet, in denen die Änderungen aufgelistet werden. Das kann helfen ähnliche Änderungen an ähnlichen Systemen umzusetzen und bildet die Information einfach sehr präzise ab.
Tatsächlich stellt sich die Frage wie oft wirklich Änderungen passieren und ob man bei einer Versionierung alte Versionen lange vorhalten muss. Wenn Anfangs schon niemand daher geht und die Änderungen, wie vorgeschlagen, dokumentiert und dann integriert, wird wohl auch niemand den Aufwand betreiben wollen, das rückwirkend zu machen. Das kann eigentlich nur dazu dienen, einen kürzlich aufgetretenen Versionskonflikt mühsam zu bereinigen. Wenn aber keine Probleme auftreten, wird keiner mehr zwei alte Versionen booten und sich allen Ernstes alle Unterschiede angucken.
Tatsächlich stellt sich die Frage wie oft wirklich Änderungen passieren und ob man bei einer Versionierung alte Versionen lange vorhalten muss. Wenn Anfangs schon niemand daher geht und die Änderungen, wie vorgeschlagen, dokumentiert und dann integriert, wird wohl auch niemand den Aufwand betreiben wollen, das rückwirkend zu machen. Das kann eigentlich nur dazu dienen, einen kürzlich aufgetretenen Versionskonflikt mühsam zu bereinigen. Wenn aber keine Probleme auftreten, wird keiner mehr zwei alte Versionen booten und sich allen Ernstes alle Unterschiede angucken.
Zitat von @ElmerAcmeee:
Hallo,
Du meinst die VMs im RZ hosten und das Protokoll per Converter, Fritzbox und VPN dorthin leiten?
Ansonsten eine Versionierungs-Software. PLM System usw...
Für Standard Dateien hätten wir ein DMS. PLMs sind auch im Einsatz. Aber nichts was mit 30GB VMDK Dateien umgehen könnte.
Aber von der Idee her, ja.
Hallo,
Die Maschinen Vor Ort haben ja nicht immer eine IP-Kommunikation. Schon mal drüber nach gedacht S5, S7, ModBus, RSxyz usw in IP zu Kapseln und den VMs zukommen zu lassen, VMs die nicht zwingend mit auf den Bau getragen werden müssen?
Kannst du das näher ausführen?Du meinst die VMs im RZ hosten und das Protokoll per Converter, Fritzbox und VPN dorthin leiten?
Ansonsten eine Versionierungs-Software. PLM System usw...
Aber von der Idee her, ja.
Ja. So die Idee. Selbst die Fritzbox wäre denkbar 11
Naja, du kannst auch GIT einsetzen um große Dateien zu versionieren. Zusammen mit Deduplizierung wird sich die Datenmenge hoffentlich in Grenzen halten. Die Mitarbeiter müssen Ihre Änderungen sauber dokumentieren und ggf. muss einer den Hut aufhaben und ggf. die Änderungen mergen.
Bei VM's sicher nicht einfach, daher: was @StefanKittel schrieb: Die Änderungen innerhalb der VM z.B. mit GIT versionieren
Und dann gibts zwei Varianten: Der Mitarbeiter holt sich alle Änderungen vor der Arbeit ab, oder es gibt eine Deploymentpipeline, welche eine neue VM erzeugt und der Mitarbeiter kann diese dann herunterladen
Alternativ sich mit Config-Management wie Puppet, Ansible usw. befassen.
Eine weitere, organisatorische, Lösung: Änderungen dürfen nur an einem laufenden System vorgenommen werden, an dem sich jeweils nur eine Person anmelden kann und dann wird nächtens ein Export erzeugt.
Bei VM's sicher nicht einfach, daher: was @StefanKittel schrieb: Die Änderungen innerhalb der VM z.B. mit GIT versionieren
Und dann gibts zwei Varianten: Der Mitarbeiter holt sich alle Änderungen vor der Arbeit ab, oder es gibt eine Deploymentpipeline, welche eine neue VM erzeugt und der Mitarbeiter kann diese dann herunterladen
Alternativ sich mit Config-Management wie Puppet, Ansible usw. befassen.
Eine weitere, organisatorische, Lösung: Änderungen dürfen nur an einem laufenden System vorgenommen werden, an dem sich jeweils nur eine Person anmelden kann und dann wird nächtens ein Export erzeugt.