Kali Linux VM-Steuerung
Start, Stopp und Zustand der Kali-Linux-VM — gesteuert über die HYPDB.ONE-Oberfläche, mit ehrlicher Voraussetzungsprüfung vor jedem Start.
/media/danijeljd/kali (kali-linux-2026.2-installer-amd64.iso 4,5 GB, kali-linux-2026.2-virtualbox-amd64(1).7z 3,7 GB, kali.qcow2 25,0 GB, win10-sm.qcow2 64,4 GB), 2 weitere in /media/danijeljd/kali/linux mint-Klon (NewVirtualDisk.vdi 2,0 MB, word-jd-clone.vdi 33,4 GB) und 1 Overlay in vm-disks (kali-run.qcow2 1,7 GB) — zusammen also 7, aber über drei Verzeichnisse verteilt. Neu gegenüber dem gespeicherten Inventar: win10-sm.qcow2 (64,4 GB) ist neu, NewVirtualDisk.vdi und word-jd-clone.vdi liegen nicht im Kali-Verzeichnis, und das Overlay ist inzwischen 1,7 GB statt 46 MB.VM-Steuerung
Live-Zustand
Bildschirm der VM
Gemessen: — · Bild über localhost (intern)
Die Steuerung ist nur von diesem Rechner aus möglich. Über die öffentliche Adresse ist sie absichtlich gesperrt.
Voraussetzungsprüfung (Stand 18.09.2026)
Messung vom 2026-09-18T23:24:39+02:00 auf Host SERVER durch scripts/kali_status.sh (read-only).
Steuerungsablauf
Die VM wird über ihren Image-Pfad identifiziert, nie über eine Gerätenummer.
Hypervisor-Binary, KVM-Module und /dev/kvm werden vor jedem Start geprüft.
Läuft bereits eine Maschine? Welche Ressourcen sind gebunden?
Nur starten, wenn alle Voraussetzungen erfüllt sind — sonst blockieren.
Hypervisor mit dem Image starten und Prozess-ID erfassen.
Prozess, Port und Erreichbarkeit prüfen; Ergebnis dokumentieren.
Startkommando (nur vorbereitet)
Das Kommando ist dokumentiert, wird aber erst ausgeführt, wenn die Voraussetzungsprüfung erfolgreich war.
qemu$ qemu-system-x86_64 -enable-kvm -m 4096 \
-drive file=$IMAGE,format=qcow2 -nic user,hostfwd=tcp::2222-:22
state$ nur ausführen, wenn hypervisor.binary != none
Image-Inventar (Stand 18.09.2026)
Träger: /dev/nvme1n1p1 (ext4), 91G von 234G belegt (41%), 132G frei · Stand 18.09.2026.
Systemressourcen (Stand 18.09.2026)
Systembindung
scripts/kali_status.sh ist hier bewusst nicht abrufbar. Nachprüfbar ist allein die ausgelieferte Messdatei assets/data/kali_vm_status.json, die den Zugehörenden Stand traegt.Live-Messung (gespeicherter Stand 18.09.2026)
Gemessen: 2026-09-18T23:24:39+02:00 · Host SERVER
Hypervisor: qemu-system-x86_64 (rootless) · KVM: kvm, kvm_intel, irqbypass · /dev/kvm: beschreibbar
Images: 6 · Träger belegt: 91G / 234G (41%)
Root-Dateisystem Stand 18.09.2026: 40G / 43G (97%)
Endpunkt-Messung (live beim Seitenaufruf)
Warum diese Kachel existiert: nginx liefert für unbekannte Pfade die Startseite zurück — HTTP 200, aber text/html. Ein 200 allein belegt also nichts. Diese Seite prüft deshalb Inhaltstyp und erste Zeichen der Antwort und weist einen HTML-Fallback ausdrücklich als „kein Backend" aus. Stand der Messung am 05.10.2026: Die echte Steuerung liegt unter /kali-api/vm/status (JSON, live) und meldet kvm: true, Zustand LÄUFT — /dev/kvm existiert auf diesem Host, VT-x ist im BIOS aktiv. Damit ist der Sperrhinweis vom 03.10.2026 überholt: Die Schaltflächen werden jetzt nicht mehr gesperrt, weil kvm fehlt, sondern nur dann, wenn die Messung es selbst feststellt. /kali-api/vm/screen antwortet 403 — der Bildschirm ist absichtlich nur lokal erreichbar. Die Start-/Stopp-Aktionen gehen als POST an /kali-api/vm/start|stop|reset; ein GET darauf liefert korrekt 404, das ist kein Fehler.
VM-Innenleben (live aus der laufenden Maschine)
Die beiden Routen oben liefern den Zustand innerhalb der Kali-Maschine, nicht auf dem Host. Die Angaben stammen aus der laufenden VM und werden bei jedem Seitenaufruf neu geholt.
| Werkzeug | Kategorie | Version | Status |
|---|---|---|---|
| Werkzeuge werden geladen … | |||
–