v0.9.2

Plugin-Release v0.9.2.

v0.9.1

Das Repo ist umgezogen: von github.com/Kroste/… in die neue Organisation
LHP542, unter der ab jetzt alle dienstlichen
Projekte der Arbeitsgruppe 5424 IT-Basis-Dienste liegen.

Was sich ändert

Am Verhalten nichts. Angepasst sind die Adressen:

• der Update-Kanal des Plugins (api.github.com/repos/LHP542/…)
• RepositoryUrl und die Links in der README

Ein Plugin bezieht seine Updates über denselben Weg wie das Cockpit — es ergäbe
keinen Sinn, die Anwendung aus dem Verwaltungsnetz zu beziehen und ihre
Erweiterungen von woanders.

Für Entwickler

In einer bestehenden Arbeitskopie einmal:

git remote set-url origin https://github.com/LHP542/Checkmk-Plugin-VSphereBaseImage.git

Wer das Cockpit mit Submodulen ausgecheckt hat, zusätzlich dort
git submodule sync --recursive.

Arbeitsgruppe: 5424 IT-Basis-Dienste

v0.9.0

Quality-of-Life. Die drei Kleinigkeiten, die man täglich merkt, aber
selten explizit erwähnt: Standard-Tastenkürzel, ein Kontextmenü am
Log-Panel, und ein Zusammenfassungs-Modal am Batch-Ende, das den Bericht
für das Ticket schon fertig macht.

Neu

Standard-Tastenkürzel

• F5 — aktualisiert die VM-Liste (analog Cockpit-Status-Tab).
• Enter im Freitext-Filter — selektiert die erste gefilterte VM und
  gibt den Fokus ans Grid; von da geht’s mit Cursor-Tasten weiter und
  Enter auf einer Zeile öffnet Details.
• Ctrl+F (unverändert) — fokussiert das Freitext-Feld.
• Esc im Filter (unverändert) — leert das Filterfeld.

Log-Panel-Kontextmenü

Rechtsklick im Log-Panel bietet:

• Log kopieren — direkt in die Zwischenablage (ins Ticket paste-bar).
• Log als Datei speichern… — SaveFilePicker mit Default-Namen
  vsphere-batch-YYYYMMDD-HHmm.log.
• Log leeren — für den Fall dass man einen zweiten Batch mit
  frischem Log starten will, ohne die App neu zu starten.

Bisher war das Log nach App-Neustart weg, und der NLog-Datei-Pfad ist
für die Nicht-Entwickler im Fachbereich nicht bekannt.

Batch-Bericht-Modal

Nach Batch-Ende öffnet sich ein Modal mit:

• Kopfzeile mit Zeitstempel und Aggregat („5/7 erfolgreich, 2 Fehler,
  4 Snapshots, 3 Kataloge publiziert").
• DataGrid mit einer Zeile je VM: Erfolg, VM-Name, Snapshot-Name,
  Katalog, Meldung.
• „Bericht kopieren" legt eine druckbare Textform in die
  Zwischenablage — im Ticket sofort einfügbar.
• „Log speichern…" — zweiter Weg zur .log-Datei, direkt aus dem Modal.

Das Modal erscheint auch nach Batch-Abbruch: der Runner notiert die
abgebrochene VM als eigene Zeile und listet die schon erledigten VMs
oben. Damit fällt kein Fortschritt „ins Leere".

Downloads

• Checkmk-Plugin-VSphereBaseImage-0.9.0.zip

Fachbereich: 5424 IT-Basis-Dienste

v0.8.0

Timeouts sind nicht mehr hart codiert. Die drei Werte, die den
Batch-Verlauf prägen (PowerOn/Tools-Ready-Fenster, Guest-Shutdown-
Fenster, Poll-Intervall), stehen jetzt in den Batch-Settings und sind
im Dialog editierbar. Damit deckt das Plugin auch VMs ab, die
länger booten oder herunterfahren als die Baseimage-Standardwerte.

Neu

Neuer Bereich „Timeouts" im „Batch-Skript & Agent-Share"-Dialog:

• PowerOn + Tools-Ready + Ping (Default 600 s / 10 min) — Zeit,
  in der die VM nach PowerOn per VMware-Tools und per Ping erreichbar
  sein muss.
• Guest-Shutdown → Power-Off (Default 300 s / 5 min) — Zeit für den
  Guest-Shutdown vor der Snapshot-Anlage.
• Poll-Intervall (Default 5 s) — Wartefrequenz beim Prüfen von
  Tools-Ready und Power-Off.

Untergrenzen erzwingt der Runner via Math.Max (Timeouts ≥ 30 s,
Poll ≥ 1 s) — so kippt ein zu strammer Wert nicht in einen
Sofort-Timeout.

Bisher waren die drei Werte hart im VSphereViewModel codiert; jetzt
kommen sie aus BatchSettings (JSON in
batch-settings.json im Plugin-Data-Dir).

Downloads

• Checkmk-Plugin-VSphereBaseImage-0.8.0.zip

Fachbereich: 5424 IT-Basis-Dienste

v0.7.0

Bedienung + Aufräumen: der Batch ist jetzt abbrechbar, das Plugin
räumt seine eigenen Snapshots auf, und Doppelklick auf eine VM öffnet
ein Detail-Fenster mit Guest-Info und Snapshot-Manager.

Neu

Batch-Abbruch

Während eines laufenden Batches erscheint neben „Batch starten" ein rot
hinterlegter „Batch abbrechen"-Button. Klick löst die interne
CancellationTokenSource aus — die Warteschritte (Tools-Ready, Ping,
Power-Off) brechen sauber ab, die aktuell laufende VM wird zu Ende
geführt (Snapshot + Publish falls schon in Arbeit), weitere VMs werden
übersprungen. Ein von aussen übergebenes CancellationToken wird via
CreateLinkedTokenSource eingekoppelt und greift damit ebenfalls durch.

Snapshot-Retention

Nach jedem neuen checkmk-update-*-Snapshot listet der BatchRunner
die vorhandenen Snapshots derselben VM auf, sortiert sie chronologisch
(create_time, Fallback Name) und löscht alles ausser den N=3
neuesten. Der Name-Fallback funktioniert, weil die Namenskonvention
checkmk-update-YYYYMMDD-HHmmss selbst chronologisch ist.

Nur Snapshots mit dem festgelegten Präfix werden angefasst; manuell
angelegte Snapshots des Admins bleiben unberührt. Delete-Fehler sind
non-fatal — es ist reine Aufräum-Kosmetik, das frisch angelegte
Master-Image steht für den Publish bereit.

VM-Detail-Fenster

Doppelklick auf eine VM (oder Kontextmenü → „VM-Details…") öffnet ein
Detail-Fenster analog zum Cockpit-HostDetailWindow:

• Kopf: VM-Name, Power-State, VM-ID, CPU/RAM plus
  RDP/Ping/Aktualisieren.
• Guest-Panel: Hostname, IP-Adresse, Guest-OS-Bezeichnung,
  VMware-Tools-RunState (bei laufender VM; sonst „(VM aus)").
• Snapshot-Liste (DataGrid): Name, Erstellzeit, Beschreibung. Pro Zeile
  ein rot hinterlegter „Löschen"-Button — damit sind auch manuelle
  Snapshots ausserhalb der Retention-Konvention bedienbar wegputzbar.

Der Doppelklick öffnet ab jetzt das Detail-Fenster; RDP direkt gibt's
weiterhin über das Kontextmenü und den Detail-Header.

Neuer VSphereClient

• ListSnapshotsAsync(vmId) — GET /api/vcenter/vm/{vm}/snapshots,
  verkraftet direktes Array und value-Wrapper.
• DeleteSnapshotAsync(vmId, snapshotId) — DELETE /api/vcenter/vm/{vm}/snapshots/{snapshot}.

Downloads

• Checkmk-Plugin-VSphereBaseImage-0.7.0.zip

Fachbereich: 5424 IT-Basis-Dienste

v0.6.0

Kontextmenü am VM-Grid — analog zum Cockpit. Die zwei täglichen
Handgriffe (RDP zum Draufschauen, Ping zum Netz-Check) sind jetzt direkt
an der Zeile, ohne Umweg über den vSphere-Web-Client oder ein zweites
Fenster.

Neu

Rechtsklick auf eine VM-Zeile:

• RDP öffnen — mstsc /v:<vm-name> startet die Windows-RDP-Session
  gegen die VM. Baseimages tragen den Windows-Hostnamen als VM-Namen, also
  reicht der VM-Name als Ziel. Sollte das im Fachbereich mal auseinander-
  laufen (VM-Name ≠ Hostname), kommt ein Domain-Suffix als Plugin-Setting.
• Ping (Fenster) — cmd /k ping -t <vm-name> in einer neuen Konsole
  für den kontinuierlichen Reachability-Check (z. B. wenn der Batch beim
  Ping-Warteschritt hängen bleibt).
• VM-Name kopieren / VM-ID kopieren — der Name geht in
  PowerShell-Skripte oder Ticket-Referenzen, die ID (vm-1234) ist für
  vCenter-REST/PowerCLI-Debug hilfreich.

Doppelklick auf eine VM öffnet direkt RDP — bei Windows-Baseimages
ist das der Regelfall, deshalb als Shortcut zusätzlich zum Kontextmenü.

Downloads

• Checkmk-Plugin-VSphereBaseImage-0.6.0.zip

Fachbereich: 5424 IT-Basis-Dienste

v0.5.0

Roadmap 1c ist drin: nach Snapshot hebt das Plugin das Master-Image des
zugehörigen Citrix Machine Catalogs automatisch auf den neuen Snapshot. Damit
ist der Baseimage-Update-Workflow End-to-End erledigt — Agent-Update →
vSphere-Snapshot → Citrix-Katalog-Publish, ohne Handgriff im DDC.

Neu

Citrix-CVAD-On-Prem-Machine-Catalog-Update

Nach dem Snapshot ruft der BatchRunner das CitrixClient.PublishMasterImageAsync
gegen die Citrix-Orchestration-REST-API (POST /citrix/orchestration/api/…):

• Auth via POST tokens mit Basic (Domänen-User aus dem seit v0.3.0
  konfigurierbaren DDC-Anmeldedialog) → Bearer, alle weiteren Requests mit dem
  Token im Authorization: Bearer …-Header. 401 löst einen einmaligen
  Token-Refresh + Retry aus.
• Site-ID kommt via GET Sites — die erste Site gewinnt, cached für den Batch.
  Sollte für die Fachbereichs-Single-Site-Umgebung reichen; für Multi-Site
  wäre eine Auswahl in den Settings der nächste Schritt.
• Master-Image-Pfad wird aus dem aktuellen Katalog-Pfad abgeleitet:
  XdHyp:\HostingUnits\{unit}\{oldVm}.vm\{oldSnap}.snapshot → \{newVm}.vm\{newSnap}.snapshot.
  Damit muss die Hosting-Unit nicht separat konfiguriert werden — sie steckt
  bereits in der Katalog-Metadata.
• Auslöser: POST Sites/{sid}/MachineCatalogs/{id}/$UpdateProvisioningScheme
  mit { MasterImage: <neuer Pfad> }.
• Non-fatal: Publish-Fehler bricht die restliche VM-Bearbeitung nicht ab.
  Update + Snapshot sind ja schon durch — der Admin kann im DDC manuell
  nachziehen, das wird pro VM im Log summiert.

Katalog-Picker vor dem Batch

Neuer Dialog CatalogPickerDialog blendet sich zwischen „Batch starten" und
CredentialDialog ein, mit einer Zeile pro sichtbarer VM:

• ComboBox mit allen Machine Catalogs vom DDC (GET Sites/{sid}/MachineCatalogs).
• Automatischer Vorschlag über die längste gemeinsame Namens-Präfix-Match
  (case-insensitive, min. 3 Zeichen): CTX01100 → Katalog CTX01; „Vorschlag"-Label
  markiert die Vorbelegung als überschreibbar.
• Leerlassen = kein Publish für diese VM (nur Update + Snapshot).
• DDC nicht erreichbar / keine Anmeldedaten → leere Katalog-Liste; der Batch
  läuft trotzdem, nur eben ohne Publish-Optionen im Picker.

Neuer Batch-Ablauf pro VM

Katalog-Picker (VM ↔ Machine Catalog, Vorschlag via Praefix-Match)
    ↓
Ausgangs-Power-State merken
    ↓
(falls aus) PowerOn
    ↓
warten auf VMware-Tools
    ↓
warten auf Ping
    ↓
Agent-Update (IAgentUpdater aus Plugin 1)
    ↓
Guest-Shutdown
    ↓
warten auf Power-Off
    ↓
Snapshot anlegen  (checkmk-update-YYYYMMDD-HHmmss)
    ↓
(wenn Katalog zugeordnet) Citrix-Publish  ← NEU
    ↓
(wenn wasOn) PowerOn → VM in Ausgangszustand

Downloads

• Checkmk-Plugin-VSphereBaseImage-0.5.0.zip

Fachbereich: 5424 IT-Basis-Dienste

v0.4.0

Zwei Roadmap-Punkte umgesetzt: der Batch-Runner respektiert den Power-State
und legt nach jedem Update einen sauberen Snapshot der Baseimage-VM an. Damit
ist der vSphere-Teil des Post-Update-Workflows komplett — es fehlt nur noch
die Citrix-Katalog-Anbindung (Roadmap 1c, wartet auf DDC-Zugang und die zwei
schon geklärten Design-Fragen).

Neu

Roadmap 1a: Power-State-Restore

Der BatchRunner erfasst am Anfang jeder VM den Ausgangs-Power-State
(wasOn = current.IsPoweredOn) und stellt ihn nach dem Update wieder her:

• VM vorher AN → nach Update wieder AN (nach dem Snapshot wird
  PowerOnAsync gerufen).
• VM vorher AUS → bleibt AUS — der klassische CTX???00-Baseimage-Fall,
  unverändert zum Verhalten aus v0.3.x.

Vorher wurde jede VM bedingungslos runtergefahren. Für Baseimages
unauffällig, für alle anderen VM-Typen (Ad-hoc-Updates auf laufenden Servern)
korrekt.

Roadmap 1b: vSphere-Snapshot nach Agent-Update

Nach dem Guest-Shutdown legt der Batch-Runner einen frischen Snapshot der VM
an (POST /api/vcenter/vm/{vm}/snapshots):

• Name: checkmk-update-YYYYMMDD-HHmmss — eindeutig, gruppierbar.
• Beschreibung: „Angelegt vom Checkmk Cockpit (vSphere-Baseimage-Plugin)
  nach Agent-Update."
• memory: false — VM ist aus, kein Memory-State-Snapshot nötig, schneller
  und kleiner.
• Non-fatal: Snapshot-Fehler bricht die VM-Bearbeitung nicht ab. Das
  Update ist ja schon drin; ohne Snapshot fehlt nur die Referenz für den
  späteren Citrix-Katalog-Publish (Roadmap 1c).

Ergebnis (Snapshot-Name + Snapshot-ID) landet in einem erweiterten
BatchStepResult — die Referenz für den kommenden Citrix-Publish-Schritt
ist damit vorhanden, sobald 1c gebaut wird.

Neuer Ablauf pro VM

Ausgangs-Power-State merken
    ↓
(falls aus) PowerOn
    ↓
warten auf VMware-Tools
    ↓
warten auf Ping
    ↓
Agent-Update (IAgentUpdater aus Plugin 1)
    ↓
Guest-Shutdown
    ↓
warten auf Power-Off
    ↓
Snapshot anlegen  (checkmk-update-YYYYMMDD-HHmmss)
    ↓
(wenn wasOn) PowerOn → VM in Ausgangszustand

Downloads

• Checkmk-Plugin-VSphereBaseImage-0.4.0.zip

Fachbereich: 5424 IT-Basis-Dienste

v0.3.0

Vorbereitung für die Roadmap-Erweiterung: der Verbindungs-Dialog hat jetzt
zwei Tabs — vCenter wie bisher, plus DDC (Citrix) für die Anmeldedaten
zum Delivery Controller. Die eigentliche Machine-Catalog-Update-Anbindung
folgt in einer späteren Version (siehe CLAUDE.md Roadmap 1c).

Neu

Zwei-Tab-Settings-Dialog (Button jetzt „Verbindungen…")

• Tab „vCenter": URL, AD-User, Passwort, Zertifikatsfehler-Ignorieren —
  identisch zum bisherigen Dialog. Passwort weiterhin DPAPI-verschlüsselt
  in credentials.json.
• Tab „DDC (Citrix)": DDC-URL (z. B. https://ddc.lhp.intern),
  Anmeldename (typischerweise Domänen-User), Passwort. Neu unter
  ddc-credentials.json im plugin-eigenen Datenverzeichnis
  (%APPDATA%\Kroste\Checkmk\plugins\kroste.checkmk.vsphere-baseimage\),
  ebenfalls DPAPI-verschlüsselt (CurrentUser-Scope).

Absichtlich keine Vorbelegung mit Environment.UserName — der DDC-Account
weicht typischerweise vom Windows-Login und vom vCenter-User ab (drei
verschiedene Konten sind bei euch die Regel).

Noch nicht drin

• Test-Verbindung-Button für DDC.
• Machine-Catalog-Update im Batch nach dem Agent-Update — die zugehörige
  API-Anbindung (Citrix-REST-API bzw. PowerShell-Remoting an den DDC)
  braucht noch die Klärung, die in der Roadmap-CLAUDE.md unter 1c
  aufgeführt ist.

Downloads

• Checkmk-Plugin-VSphereBaseImage-0.3.0.zip

Fachbereich: 5424 IT-Basis-Dienste

v0.2.4

Bugfix: das Plugin meldete an das Cockpit die Version 0.0.0, auch nach
Update. Selbes Problem wie im AgentUpdater-Plugin.

Behoben

Directory.Build.props hatte keinen <MinVerTagPrefix>v</MinVerTagPrefix>.
Die Tags heißen v0.2.0, v0.2.1, … — MinVer mit leerem Default-Prefix
hat sie ignoriert und stattdessen die Default-Version 0.0.0-alpha.0 +
Commit-Height gemeldet. Das Plugin.cs-Fallback (?? "0.0.0") griff.

Fix analog Cockpit: <MinVerTagPrefix>v</MinVerTagPrefix> gesetzt. Ab
v0.2.4 stimmt die Versionsanzeige.

Fachbereich: 5424 IT-Basis-Dienste