Kernel-Based Virtual Machine (KVM) ist eine Open Source-Virtualisierungstechnologie, die im Linux® Kernel integriert ist.

• Bare Metal-Hypervisor vom Typ 1 (wie ESXi, VM-Ressourcen werden vom Hypervisor direkt für die Hardware eingeplant)
• erfordert Virtualisierungsfunktion der CPU,  (grep -Ec '(vmx|svm)' /proc/cpuinfo) Antwort muss > 0 sein, ggf. im BIOS aktivieren
• erfordert VM-Emulation wie QEMU (LibVirt bzw. Proxmox)
• Open Source Enterprise Virtualisierer, Frontend+Bundle mit KVM-VM und LXC-Container Virtualisierung, ZFS auf Debian-Basis
• Gast-VM: Windows 2000, XP/2003, Vista/2008, 7/2008R2, 8/2012(R2), 10/2016/2019, 11/2022, Linux, Solaris und verschiedene BSD-Varianten auf Intel und AMD x64-Basis
• Gast-Container: Ubuntu, Debian, Fedora, OpenSuse u.a. Linux
• Filesystem: LVM (ext4) oder besser ZFS
• TPM-Support (kein Zwang), Snapshots, Clones, Backups, Templates, Live-Migration zwischen 2 Hosts, Thin-provisioned Storage
• Enterprise Support und Repository buchbar
• ohne Subscription Lizenz: Betrieb + Update über Community Repository im nichtkommerziellen Bereich möglich
• 04/2024: Proxmox 8.2 mit Importschnittstelle für VMWare ESX (Rechenzentrum -> Storage -> ESXi)
• 11/2025: Proxmox 9.1 Container mit Templates per Pull from OCI Registry (aus Docker u.a.)

zur Bedienung der VM.

QEMU Treiber:

• Qemu Guest Tools immer installieren + aktivieren! (VM Optionen und in der VM!)
• verbessert Leistung und Überwachung, flüssiger, Shutdown, Snapshots, qm-Befehle u.a.
• QEMU Treiber sind erforderlich u.a. für Backup Server (Snapshot, qm-Befehle)

noVNC-Konsole:

• Default VM-Konsole, einfach, browserbasierend, Fenster, keine Zwischenablage, kein Sound, teils ruckelige Grafik
• keine LAN-Verbindung zur VM erforderlich
• Mauszeiger reagiert in noVNC Konsole auch mit Qemu Guest Tools sehr träge (kein Vergleich zu VMWorkstation- oder ESXi-Konsole)

Spice-Konsole:

• Vollbild (VirtIO-GPU), Sound (Audiogerät hinzu fügen), im Wirts-PC "virt-viewer" inst.
• Zwischenablage in beide Richtungen, ggf. muß spice-vdagent (spice-guest-agent) bzw. Virt-Manager im Client installiert werden (Qemu Guest reicht nicht).
• Clipboard für VM nachträglich aktivieren: qm set <vmid> -vga <displaytype> clipboard=vnc
• VMs mit aktiviertem VNC-Clipboard lassen sich aktuell nicht Live migrieren! (v.8)
• Display: Spice oder VirtIO-GPU, USB (USB-Device: Spice Port)
• keine LAN-Verbindung zur VM erforderlich
• siehe Proxmox WiKi SPICE
• VirtIO CD ISO zum Mount in Client: https://logiqlinux.com/de/manuals/hrpc-proxmox-ve/creating-a-new-virtual-machine/installing-virtio-drivers/
• Linux Debian: (sudo apt install spice-vdagent, sudo systemctl start spice-vdagent, sudo systemctl enable spice-vdagent)
• Windows: spice-guest-tools
• All-OS: Virt-Manager
• Spice Fenster Focus verlassen: [Strg]-[Alt]-R

RDP-Konsole, Rustdesk, VNC usw.

• Installation der jeweiligen Server-Komponente in der VM erforderlich
• Sound, Zwischenablage, gute Grafik, Vollbild
• Voraussetzung: LAN-Verbindung zur VM

• ZFS nutzt per Default viel RAM als Cache (->viel RAM einbauen!)
• möglichst keine Consumer SSD/NVME verwenden, weil deren Cache zu gering ist und sie zu viel beschrieben werden
• 2 kleine SSD (256GB) für System (rpool) verwenden, große NVMe und HDD für die VM (RPOOL wird bei Neuinstallation immer gelöscht, andere Pools können importiert werden)
• RAID-1 oder RAID-10 für VMs nehmen
• ZFS ohne Hardware-RAID (direkter Datenzugriff!), LVM mit Hardware-Controller
• Booten von Software-RAID (ZFS) ggf. über HBA (Boot-Partition ist kein RAID)
• ZFS ist LVM vorzuziehen
  - hat keine Schreiblücke und benötigt keinen Akku-gepufferten Cache
  - flexible Software-RAID Level
  - Copy on write, Komprimierung, Checksummierung, Scrubbing
  - HA Cluster nur mit ZFS möglich
• NVME-Cache bringt viel
• Proxmox supportet Speichertypen

• HD-Seriennummern und Slots notieren! (falls RAID ausfällt)
• Installer: Optionen: ZFS-RAID + HDs wählen, HD-Size für System (rpool) festlegen (100GB), ashift= 12
• "Datastore behalten" wie VMWare kennt Proxmox nicht, der Installer macht die System-Partitions platt und "vergisst" die anderen Pools.
  Beim Neuinstallieren werden also alle VMs in rpool (sda3+sdb3) gelöscht!
  ZFS-Pools auf anderen Partitionen können per zpool import wieder eingebunden werden, wenn man die wichtigsten cfg-Dateien hat.
  /etc/pve/storage.cfg (notfalls manuell) wieder herstellen (enthält die Datastores für die GUI)
  Für VMs: /etc/pve/qemu-server, für Container /etc/pve/lcx - wieder herstellen, enthält die Configs der VMs
  Anleitung ZFS-Pool Import
  -> keine VMs auf rpool (local) planen, nur das System!

• Proxmox erstellt 3 Partitions (cfdisk /dev/sda): Legacy BIOS Boot (1MB), EFI Boot-System (512MB), ZFS/Proxmox-RAID 'rpool' (Rest bzw. Setup:HDSize)
  Partition 1 und 2 sind kein RAID!  (UEFI-Partition nach jedem größeren Update synchronisieren)
  • Boot-Loader auf allen Boot-Partitionen synchronisieren:
  • update-grub  - Aktualisierung der Grub Loader
  • grub-install /dev/sdb  - Installation des Grub-Loaders auf Laufwerk sdb
  • update-initramfs -u  - aktualisiert die Grub-Infos auf diesen HDs
  Partition 3 (ZFS-RAID) /dev/sda3 und /dev/sdb3 kann nicht direkt booten

  ZFS RAID-1:

  

  >>cfdisk  (sda, ZFS)

  

  >> lsblk  (sda und sdb)

  
• Software Defined Network (SDN): wird im Cluster organisiert, VLANs pro VM oder (besser) pro Bridge; Firewall pro VM
  1) vmbr0 -> VLAN-Aware = ON, Server neu starten
  2) pro VM/CT -> Netzwerk: VLAN-Tag setzen
  - in VM/CT ggf. geänderte IP konfigurieren
  3) zum PVE kommen vom Switch gebündelte VLAN-Trunk-Ports
  Strategie: Ports= BOND, Switche= VLAN, VMs= Firewall
  
  
• Proxmox WEB-GUI: <ip>:8006
• Proxmox SSH-Konsole: ssh root@<ip>

• eindeutige ID wird ab 100 hoch gezählt
  - mehrere Hosts im Cluster düfen nicht die gleiche ID nutzen
  - ID läßt sich nur durch backup + Restore ändern
  - je nach PVE Version werden gelöschte ID ggf. weiter blockiert (sonst kann z.Bsp. Backup History alte und neue VM nicht unterscheiden)
• Spice-Guest bei Installation anhaken (VNC Zwischenablage..) -> dann muss der QEMU Guest Agent auch in der VM installiert werden!
  (siehe Abschnitt Spice und QEMU)
  PVE -> Storage local -> ISO-Images -> Download from URL
  Suche: proxmox windows drivers stable -> Download-Link kopieren in URL oben, Query URL -> lädt virtio-win.iso (Treiber-CD)
  (https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/latest-virtio/virtio-win.iso)
  • Windows Installation: zusätzliches Laufwerk für VirtIO-Treiber hinzu fügen (CD2 = virtio-win.iso)
  • Windows7: virtio-win-0.1.173-4.iso
• Firmware:
  Default =SeaBIOS - altes BIOS
  OVMF (UEFI) - erforderlich für Win11, erstellt EFI-Boot Disk
  - "Pre Enrol Key" speichert MS Zertifikate und aktiviert Secure Boot (kann deaktiviert werden im OVMF Boot-Menu der VM)
• TPM - erstellt Storage für virtuelles TPM 2.0 (Hardware-unabhängig, wird mit der VM gesichert und im Cluster verschoben)
• Disk Controler -> "VirtIO SCSI Device" ist Best Practice!
  - Windows nimmt IDE, wenn man nicht zusätzliche VirtIO Treiber mit installiert
  - nach Migration Controler aktualisieren!
  1. temporäres VirtIO SCSI Gerät (kleine HD) installieren
  2. VirtIO Treiber in VM installieren
  3. migrierten Controler in SCSI (VirtIO SCSI) ändern
  Sollte bei der VirtIO Treiber-Installation kein VirtIO SCSI-Gerät vorhanden sein, wird kein VirtIO SCSI-Treiber in den Bootprozess integriert und das Laufwerk wäre nach der Umstellung nicht bootfähig.
• Disk: "Discard", "SSD Emulation" und "IO thread" anhaken, no Cache (nachträglich: qm guest cmd <vmid> fstrim)
• CPU: Sockets nicht höher setzen als physisch im Host vorhanden
  - Typ generisch (x86-64-v2-AES) am performantesten
• LAN: virtuelle Hardware nicht E-1000 (1GB) o.ä., sondern virtuelle Proxmox-Hardware (virtio) mit 100 GB/s nehmen!

1) manuell importieren

• vmdk, vhdx, raw, qcow2, ovf > mounten (Kopieren mit winscp) im Original nach mnt/pve/nfsstore
• zvols, lvm, usb, hdd, ssd (phys. Geräte)
• qm importdisk 100 /mnt/hypervfreigabe/dc.vhdx local-zfs  - importiert und konvertiert automatisch
• ova: entpacken von ovf, mf, vmdk, nvram

2) OVA -Datei

• VMWare Workstation oder ESX: Export als OVA (möglichst vorher VMWare Tools deinstallieren)
• WinSCP: Dateien auf Proxmox übertragen
• qm importovf 101 bitnami-wordpresspro-5.1.1-0-linux-debian-9-x86_64.ovf local-zfs
• bei UEFI-VM: BIOS auf UEFI setzen (qm set 101 --bios ovmf)
• Treiber von SCSI auf SATA ändern (sed -i 's/scsi/sata/g' /etc/pve/qemu-server/101.conf)
  Quelle: Krenn AG WIKI
• ESX.vmdk von Proxmox Shell aus importieren
• Disk als IDE-LW hinzu fügen

3) physische Systeme, manuell

• physische Systeme: mit VMWare Converter oder Clonezilla Festplatten erzeugen
• VM in Proxmox neu einrichten, HDs hinzu fügen (unused disk: discard + add)
• VMWare Tools deinstallieren
• virtio-win.iso installieren, QEMU-Guest installieren

4) Clonezilla (physisch oder virtuell)

• clonezilla Empfangsmodus auf neu erstellter, leerer VM
• clonezilla booten auf PC
• Übertragung komfortabel über Netzwerkmodus (Client + Server)

5) VMWare ESX per Proxmox Import Agent (neu 2024)

• ab Proxmox 8.2 mit Importschnittstelle für ESXi Host v. 6.5 - 8 (Datacenter -> Storage -> ESX)
• ESXi Datastore in Proxmox einbinden und VM importieren
  (Praxistest: LAN 1 Gb/s schafft ca. 300 GB pro Stunde)
• Assistent erkennt (je nach Ausgangs-VM) Controllertyp, CPU, RAM, HD automatisch
• Advanced: VirtIO Treiber CD einbinden
• VM muß aus sein, ESX-Tools möglichst vorher deinstallieren, Snapshots löschen
• Meldungen beim Import beachten:
  
  
  Ablaufbeschreibung:
• https://forum.proxmox.com/threads/new-import-wizard-available-for-migrating-vmware-esxi-based-virtual-machines.144023/
• https://www.thomas-krenn.com/de/wiki/ESXi_VM_Importer_-_Proxmox_VE_Storage_Plugin?xtxsearchselecthit=1

Nach dem Import
Treiber für HD auf VirtIO umstellen, LAN neu hinzu fügen, Qemu Guest Agent inst.

• VM starten, Funktion prüfen, herunter fahren
• Snapshot erstellen
  
  ggf. Controller in vioscsi ändern:
• Dummy-HD (1GB) mit SCSI-Controller einbinden
• Optionen: Qemu Guest aktivieren, VM starten
• virtIO Treiber installieren, VM herunter fahren
• Dummy-HD löschen
• SATA-HD "Detach"
• ADD "Unused Disk", SCSI-Bus, Discard + SSD emulation anhaken
• Bootreihenfolge auf SCSI ändern, booten

• Netzwerkkarte auf VirtIO ändern, passende VMBR und VLAN konfigurieren
• Gerätemanager prüfen
  
  
• vio-Treiber in nicht startendes Windows per CMD integrieren:
  - virt-IO -CD "einlegen"
  - System reparieren - > Eingabeaufforderung
  - Windows-Laufwerk (x:) und VirtIO-Laufwerk (d:) suchen
  - drvload d:\vioscsi\2k22\amd64\vioscsi.inf -> erfolgreich geladen
  - dism /image:x:\ /add-driver /driver:d:\vioscsi\2k22\vioscsi.inf  -> Operation successfully

• DMZ-Strategie: zweite OPNsense im Proxmox für geschützte VMs (Performance, Single-Point-of-failure), DMZ-Bridge ohne zweite Firewall
  Skizze: Baribal Studios
• Routing (manuell): ip route add 10.10.10.0/24 via 192.168.1.10 dev vmbr0  (Firewall nicht vergessen)
• Routing (dauerhaft): /etc/network/interfaces  (enthält alle Interfaces und Bridges)
  post-up ip route add 10.10.10.0/24 via 192.168.1.10 dev vmbr0
  
  
• zpool status - zeigt RAID-Status  (ZPOOL ist der RAID-Teil von ZFS)
• neuen Pool erstellen: einfach über Proxmox-GUI  (Mirror, shift=12), leere Partitionen auswählen (mit cfdisk erstellen)
• zpool list - zeigt Pool- Fragmente, Deduplizierung, (CAP soll nicht über 80% gehen!) - ggf. Autosnapshoots verkleinern
• zpool set autotrim=on rpool  - Autotrim anschalten! Wichtiger Platz- und Leistungsgewinn.
• zpool trim rpool  - führt TRIM manuell aus, nur zur Kontrolle, Anzeige mit zpool status
• cd /dev/disk/by-id/ -> ls -l zeigt HDs mit Seriennummer und logischem Name (Bsp: sdb3), wichtig bei HD-Defekt
• Datacenter / Storage / lokal-zfs: Blocksize auf 16k + ThinProv. ändern (ist jetzt DEFAULT), sonst ist Overhead riesig
  - jede danach angelegte VM bekommt per Default 16k - Blöcke
• zfs list  - zeigt Partitionen + Mountpoints
  
  • /rpool/ROOT/pve-1  = '/' = Proxmox-Partition
• E-Mail Alarmierung ist rudimentär (Postfix), besser Monitoring  (CheckMK-Plugins)
• Vollständige Conf einer VM: cat /etc/pve/qemu-server/101.conf
• Windows gibt gelöschten Speicherplatz deutlich verlangsamt wieder frei -> SSD-Trim (HD -> Tools -> Optimieren) regelmäßig planen
• Proxmox-User mit Two Factor -> TOTP absichern
  • PAM-User sind lokale Linux-User (meiste besser)
  • Proxmox-User sind User des Proxmox Datastore
• ssh-keygen  - Schlüsselpaar erzeugen
  
  Snapshots
• bei ZFS: ggf. Bashclub-ZFS Postinstall-Script ausführen, wechselt auf no-subscription-repository und schaltet Warnung ab, installiert Tools, konfiguriert Cache, Autosnapshots, Config-Backup, Systemaktualisierung  (Swap ab 95%, Mailer, Snapshots festlegen!! [Monate - Wochen - Tage - Viertelstunden], blocksize=16k)
• danach: GUI Updates Refresh / Rebooten
• Autosnapshot vererbt sich per Default
• zfs set com.sun:auto-snapshot=false <VMSTORE>  - Dateisystem nicht AutoSnapshoten
  
• zfs set sync=disabled rpool  - SYNC ausschalten
• zfs set com.sun:auto-snapshot=true <VMSTORE>/<VM>  - nur einzelne VM SnapShoten
• zfs list -t snapshot (zfs get written) - listet alle Snapshots auf
• zfs list -t snapshot | grep pve-1  - listet alle Snapshots der Proxmox-Partition auf
• Snapshots per cd anzeigen: /VMSTORE/<VMNAME> cd /.zfs/snapshot/ → ls -alh
• zfs rollback -r rpool/ROOT/pve-1@zfs-auto-snap_hourly-2023-05-27-1158  -> Rollback des angegebenen Snapshots
  so kann Proxmox und jede einzelne VM wieder hergestellt werden
• sollte sich auch die VM-Konfig geändert haben, extra /pve/ Snapshot holen. PBE Backup Server sichert auch die VM-Konfig.
• Proxmox Update: niemals via apt upgrade!! Nur über Proxmox-GUI oder so:
  • apt update  (Paketquellen updaten)
  • apt dist-upgrade  (Pakete mit ihren Abhängigkeiten installieren)
  • REBOOT nach jedem Kernel-Update
• Upgrade v8 -> v9: https://pve.proxmox.com/wiki/Upgrade_from_8_to_9
  
  
• ZFS-RAID löschen:
  • zfs list  - zeigt Pools
  • nano /etc/pve/storage.cfg  - Eintrag löschen
  • zpool desroy <pool>
  
  RAID-Cache mit schneller SSD oder NVM (sdc) erstellen
• es können mehrere Cache Laufwerke pro Pool angegeben werden
• zpool add -n hd-pool cache sdc sdd
  
• zpool iostat -v 1  - zeigt Befüllung des Cache
  
  Fehler: 1 ZFS RAID-HD (bsp: sda) gestorben oder ich will 2. HD zufügen
  
• RAID ist degraded, man merkt das nicht (Monitoring!!)
• zpool status zeigt RAID-Status (degraded)
• HD/SSD wechseln (darf auch größer sein)
• zpool set autoexpand=on rpool  - schaltet Autoexpand an
• sgdisk /dev/sdb -R /dev/sda  - überträgt (repliziert) Partitionen von sdb auf sda
• lsblk  - zeigt Partitionen an
• cfdisk /dev/sda  - gpt-Partition, Linux Filesystem, wenn neue HD sda größer ist, Proxmox-Partition sda3 resizen auf volle HD-Größe
• sgdisk -G /dev/sda  - erstellt neue GUID für die neue HD
• proxmox-boot-tool clean  - entfernt ID der defekten HD aus der Bootkonfig
• proxmox-boot format /dev/sda2  - formatiert Boot-Partition mit Windows Dateisystem (sda1 + sda2)
• proxmox-boot-tool init /dev/sda2  - überträgt Bootpartition auf neue HD
• proxmox-boot-tool status  - gelegentlich prüfen, muß wieder 2 HDs zum Booten haben
• zpool status   - zeigt immer noch, dass rpool DEGRADED ist (HD REMOVED), d.h. neue sda3 hat noch keine Daten
• (zpool replace rpool sda3  - Daten werden auf neue Partition repliziert)
• ls -althr /dev/disk/by-id/ zeigt HDs mit Seriennummer und logischem Name (Bsp: ata-Gigastone_SSD_GSTGGGHABK2406260460-part2 -> ../../sdb2)
• zpool attach rpool sdb3 ata-Gigastone_SSD_GSTGGGHABK2406260460-part2
  -> füge neue HD (sdb2) über ID (wichtig beim Umstecken der HD!!) zum rpool (zu funktionierender Platte sdb3, ggf. auch als ID) hinzu
• zpool status   - jetzt Online, resilvering
• zpool status -v [pool] - zeigt genauen Status des Resilvering an
  
  Notfall-Recovery bei defektem Proxmox Bootsystem
• Intallation Proxmox von CD auf beliebigen anderen Datenträger ohne ZFS inst. (sonst hätten wir 2x RPOOL) (gute Datenplatten raus ziehen)
• zfs list  - keine Volumes da   (HD wieder rein)
• zpool import -fa  - importiert alle ZFS-Pools
• Kopieren storage.cfg, qemu-server (/rpool/pveconf/)
• System läuft (ohne SSH-Keys, Autosnapshot usw)
• siehe auch Thomas Krenn WiKi
  
  neue HD hinzufügen, ohne die Alte zu löschen (Backup o.ä.)
• zpool attach rpool sdb3 <neue HD>  - statt REPLACE kann man mit ATTACH weitere HDs hinzufügen
• zpool status  - zeigt dann 3 HD im RAID an
• nun kann man 1 HD entnehmen und aus dem RAID entfernen:
• zpool detach rpool sdb3  - löscht HD aus RAID-Konfig
• proxmox-boot-tool clean  - entfernt ID der entfernten HD aus der Bootkonfig
• bootet man jetzt nur von der entnommen sdb, würde sie immer noch melden dass die beiden anderen HD fehlen
  
  separaten ISO-Pool erstellen (NVMe-RAID ist dafür zu schade)
  Bsp: ZFS-Pool heißt "hd-pool" und soll Dataset "ISOs" bekomme und ein Directory Storage "ISOs"
• zfs create hd-pool/ISOs  - Dataset erzeugen
• zfs destroy hd-pool/ISOs - Dataset löschen
• zfs set compression=zstd hd-pool/ISOs  - ZSTD-Kompression für weniger Platzverschwendung
• zfs set relatime=on hd-pool/ISOs  - ggf bei SSD: unnötige Writes vermeiden
• zfs set quota=100G hd-pool/ISOs  - ggf. Quota auf 100GB setzen
• pvesm add dir ISOs --content iso --is_mountpoint yes --shared 0 --path "/hd-pool/ISOs"  - Directory Storage für ISOs anlegen
  (Pool für VMs: Content= images), auch manuell mit nano /etc/pve/storage.cfg
  
  VM erstellen:
• siehe Abschnitt "VM einrichten"
• Windows Installation findet keine Festplatte -> Treiber laden -> vioscsi -> win10
• von CD virto-win.iso 'virto-win-guest-tools' installieren -> installiert alle fehlenden Treiber
• QEMU Guest Agent installieren
  • Windows: virto-win.iso, Verzeichnis guest-agent
  • Linux: apt-get install qemu-guest-agent , systemctl start qemu-guest-agent
  Danach zeigt die VM unter Übersicht die IP, Meldung "kein Agent" verschwindet, qm-Befehle gehen, Shutdown über GUI geht.
  
• im Host Qemu Guest aktivieren: qm set <vid> --agent 1
  Test: qm agent <vid> ping
• ggf. Spice oder RDP aktivieren
  
  Hochlastige VM optimieren, Auslagerungsdatei ohne Snapshot
  
• powercfg -h off  - Hyperfil off
• zfs create -o com.sun:autosnapshot=false rpool/swap  - erstellt Verzeichnis, in dem keine Autosnapshots gemacht werden
• Proxmox Datacenter -> Stoarage -> Add -> ID: rpool-swap, ZFS-Pool auswählen, Content= Disk Image, 16k Block Size
• VM -> Hardware -> Add HD -> Bus: SCSI, Storage: rpool-swap, Size: 8GB, SSD-Emulation, Discard
• Windows Datenträgerverwaltung: Datenträger initialisieren, LW-Buchstabe
• Windows Systemeigenschaften -> Leistungsoptionen -> Auslagerungsdatei ändern in Swap-LW
  
  ZFS-HD einer Windows-VM vergrößern
• HD in Proxmox vergrößern: VM -> Hardware -> Harddisk -> Disk Action: Resize
• in Windows hindert die Widerherstellungspartition am Vergrößern von LW C:
• Proxmox: lsblk, Widerherstellungspartition identifizieren
  
• cfdisk /dev/cd16
  Windows RE (546MB) löschen (nicht hier Resizen!)
• HD in Windows Datenträgerverwaltung vergrößern
• ggf. in /etc/pve/qemu-server/100.conf anpassen, sonst wird das weiter falsch angezeigt
  
  USB-Stick in VM durchreichen
• USB-Stick an Host stecken, Stick erscheint im Host unter "Disks"
• USB-Device in VM hinzu fügen, "Use USB Vendor/Device ID"
• Stick auswählen, fertig

Der Proxmox VE-Server kann nicht mit der eigenen Backup-Funktion oder dem Proxmox Backup Server gesichert werden.

Backup-Strategien:

• /etc/cron.daily (Cronjob)
• VM herunter fahren (qm shutdown...)
• Snapshot
• VM starten
• Snapshot weg sichern (repl)
• PBS ermöglicht Backup ohne Shutdown
• keine Backups, Hyperfil oder Auslagerungsdatei auf produktive Volumes legen (mit Snapshot)
• keine Backups auf "Local-Store" legen, denn das ist der PVE

Allgemeines

• möglich wären Linux Backup-Lösungen
• der PVE-Server ist schnell wieder installiert
• der Installer macht das System (RPOOL) platt!
• alle wichtigen Config-Files vorher(!) sichern
• möglichst keine VMs auf RPOOL sichern

Backup Replication einfach und trojanersicher (SysOps) mit pull, geht auch remote in LAN/WAN

• zfs create -o com.sun:autosnapshot=false backup/repl (data, clone, rpooldata)  - auf neuem Volume anlegen
• zfs set com.sun:autosnapshot=false backup  - ganzer Datenträger ohne Autobackup
• gihub.com bashclub: bashclub-zfs-push-pull  -> Link kopieren
• git clone <link>  - installiert
• chmod +x 02pull bashclub-zfs  - ausführbar machen
• cp bashclub-zfs /usr/bin/  - kopiere an bessere Stelle
• nano 02pull - editieren
  Scriptpaht='/usr/bin'
  Sourcehost='localhost'
  DestPath='backup/repl'
• Trojanersicher ist das initiiert vom Remote Backup Server aus. Auf den Systemen läuft zfs send / zfs receive mit Prüfsumme.

Backup PVE-Host (3 Kopien)

• PVE: zfs list  - suche geeigneten Storage für Backups (Bsp: /hd-vol3/Backups)
• PVE: touch /home/pve-backup.sh  - erstelle Backup-Script
• PVE: nano /home/pve-backup.sh
  #!/bin/bash
# PVE - Backup

# Definiere destinationdir und Logfile
DEST="/hd-vol3/Backups/host1"
LOG="/hd-vol2/daten2/Uwe/logfiles/backup_monat_PVE-Host--PVE.log"

echo "*** Backup PVE-Host nach $DEST-kopie1" &> "$LOG"
echo `date` &>> "$LOG"

# lösche kopie3
if [ -d "$DEST-kopie3" ]
then
echo " Lösche $DEST-kopie3" &>> "$LOG"
rm -r "$DEST-kopie3"
fi

# Verschiebe kopie2 -> kopie3
if [ -d "$DEST-kopie2" ]
then
echo " Move $DEST-kopie2 -> $DEST-kopie3" &>> "$LOG"
mv "$DEST-kopie2" "$DEST-kopie3"
fi

# Verschiebe &DEST-kopie1 in kopie2
if [ -d "$DEST-kopie1" ]
then
echo " Move $DEST-kopie1 -> $DEST-kopie2" &>> "$LOG"
mv "$DEST-kopie1" "$DEST-kopie2"
fi

# erstelle $DEST
echo " Erstelle $DEST-kopie1" &>> "$LOG"
mkdir "$DEST-kopie1"

# r - recursiv
# h - human readable
rsync -rptgoh --progress --stats "/etc/" "$DEST-kopie1"etc &>> "$LOG"
rsync -rptgoh --progress --stats "/home/" "$DEST-kopie1"home &>> "$LOG"
rsync -rptgoh --progress --stats "/boot/" "$DEST-kopie1"boot &>> "$LOG"
rsync -rptgoh --progress --stats "/root/" "$DEST-kopie1"root &>> "$LOG"
# Dumps nicht mit sichern
rsync -rptgoh --exclude='lib/vz/dump/' --progress --stats "/var/" "$DEST-kopie1"var &>> "$LOG"
• Script per Cronjob im gewünschten Intervall ausführen

Management-Zugriff auf Hosts muß also vor dem Aktivieren der Firewall gewährt werden!
-> Regel im Datacenter: Ingoing, Accept, Interface: LanBridge (vmbr0), TCP, Destination(s)= IPs der Hosts, Ports: 22 (SSH), 8006 (NoVNC), 3128 (Spice)
(wird inzwischen per Default über NonBlockingRules gelöst)

Firewall steht per Default auf:
- In: DROP
- Out: Accept

Sollte man sich vor die Tür setzen:
Host-Shell: nano /etc/pve/firewall/cluster.fw  -> enable: 1  -> auf 0 setzen
Host-Shell: pve-firewall stop

Firewallregeln werden nicht im PBS gesichert.
Unbedingt /etc -Ordner des Hostes sichern!

Firewall aktivieren in:

• Datacenter (Regeln für Datacenter <-> Hosts))
• Host (Host-Management, Ping, SMB, kein Effekt auf VM)
• VM
• Netzwerkkarte der VM
  Alle Firewalls wirken auch auf die untergeordneten Instanzen.

Security Gruppen für gleichartige VMs im Datacenter anlegen.
Regeln in der Gruppe erstellen.
Insert: Security Group -> Gruppe hinzu fügen.

IPSet - Regeln für Listen von spezielle IPs bzw. IP-Bereichen

Aliases - Regeln für einzelne spezielle IP (Router o.ä.) oder IP-Bereich (LAN..)

Aliases und IPSets können in Firewall-Regeln als Source oder Destination eingesetzt werden.

Beispiele:

• ICMP IN - von allen Verwaltungs-PC zu gewünschten Hosts und VMs
• SSH IN, TCP Port 22 - von allen Verwaltungs-PC zu gewünschten Hosts und VMs
• NoVNC IN, TCP Port 8006 - von allen Verwaltungs-PC zu gewünschten Hosts und VMs
• NoVNC IN, TCP Port 8007 - von allen Verwaltungs-PC zu Proxmox Backup Server
• Spice IN, TCP Port 3128 - von allen Verwaltungs-PC zu gewünschten Hosts und VMs
• RDP IN, TCP Port 3389 - von allen gewünschten PC zu gewünschten VMs
• SNMP IN, UDP 161 + 162 - vom Monitoring-Server zu allen gewünschten Hosts und VMs

Bsp.: VM darf nur ins Internet, aber nicht zu anderen Geräten im LAN
- Out - Accept - Destination= Gateway
- Out - Reject - Destination= LocalNet

• Proxmox Backup-Server benötigt nur ACCEPT-IN zwischen PVE-Host und PBS-Server (ggf. NAS)
• Veeam Backup Server benötigt Zugriff auf alle zu sichernden VMs

PVE Default Rules: https://pve.proxmox.com/wiki/Firewall#pve_firewall_default_rules

Per Default läuft ein Virtualisierungshost sinnvollerweise ohne Powersafe.
Im Homelab ist das aber eventuell sinnvoll.

• cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor  - zeigt Powermodus für jede einzelne CPU
  Proxmox Default: performance
• cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq  - zeigt Frequenz für jede einzelne CPU
• echo "powersave" | tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor  - setzt Governor = powersafe  (ggf. nicht bootfest, in Crontab eintragen)
• alle CPU Scaling Werte erklärt
• siehe Powersafe, CPU Governor (Homeserver)

• UK: Proxmox wichtige Befehle, Pfade und Dateien
• UK: Proxmox Backup Server (PBS)
• UK: Proxmox Firewall
• UK: Proxmox Cluster und HA Storage
• UK: Linux KVM
• UK: Samba / SMB-Freigaben
• Proxmox konfigurieren, Postfix, Fail2ban usw. https://decatec.de/home-server/proxmox-ve-installation-und-grundkonfiguration/
• Proxmox VE Helper Scripts (Microcode Updates, Datacenter Manager, Host Backup...)
• Proxmox PVE Host Sicherung auf Proxmox PBS und forum.proxmox.com (Erklärung + Restore)
• UK: Linux Basics