[[software:proxmox]]

Proxmox VE

Proxmox VE (Proxmox Virtual Environment; kurz PVE) ist eine auf Debian basierende Open-Source-Virtualisierungsplattform zum Betrieb von virtuellen Maschinen mit einer Web-Oberfläche zur Einrichtung und Steuerung von x86-Virtualisierungen. Die Umgebung basiert auf QEMU mit der Kernel-based Virtual Machine (KVM). PVE bietet neben den Betrieb von klassischen virtuellen Maschinen (Gastsystemen), die auch den Einsatz von Virtual Appliances erlauben, auch LinuX Containers (LXC) an.

Durch die Verwendung einer Web-Oberfläche wird ein Großteil der einfachen Arbeiten wie das Einrichten, Starten und Stoppen, Erstellen von Backups und Verwaltung der Netzwerkinfrastruktur und der laufende Betrieb von virtuellen Maschinen und den dazugehörigen Speichersystemen am Hostsystem erleichtert. Weiters können Cluster von mehreren PVE-Hostsystemen basierend auf der Corosync Cluster Engine gebildet werden welche gemeinsam verwaltet werden und zwischen welchen virtuelle Maschinen und deren virtuelle Festplattenspeicher ausgetauscht werden können. Dies ermöglicht den Aufbau von Hochverfügbarkeitsclustern.

Quelle: Wikipedia

Bei der Installation vom Proxmox-ISO werden abgefragt:

  1. root-Passwort (aktuell x…)
  2. E-Mail-Adresse für fail-over-Warnungen etc.

Leider kann die Partitionierung nicht beeinflusst werden, daher kann es Sinn machen Proxmox auf einem Debian nachzuinstallieren: Install Proxmox VE on Debian Stretch.

Ohne eine Subskription wird bei Web-Login eine Warnmeldung angezeigt und Zugriff auf das enterprise-Repo von Proxmox ist nicht möglich. Also auch keine Kernel-Updates.

Die Preise beginnen bei ~90€ pro Jahr und CPU-Sockel.

Anzahl der Sockel anzeigen (auch via GUI möglich).

dmidecode -t4 | egrep 'Designation|Status'
	Socket Designation: CPU1
	Status: Populated, Enabled
	Socket Designation: CPU2
	Status: Unpopulated

https://pve.proxmox.com/wiki/Backup_and_Restore https://cyberpersons.com/2016/09/13/backup-transfer-proxmox-vm-another-proxmox-node/

Nach Transfer von VMs auf einen anderen Node sind ggf. iso-Einbindungen anzupassen (:!: Wichtig! sonst funktioniert auch das automatisierte Backup nicht), zusätzlich könnten die network devices anders heißen (vmbr0 → vmbr1 o.ä.).

Durch ZFS on Linux ist unter Proxmox die Nutzung von ZFS möglich.

:!: NTP-Dienst muss laufen, clock skew kommt schon mit Standardeinstellungen (Warnung bei 0,05s Unterschied) - entweder die skew höher erlauben oder NTP-intervall erhöhen „server xxx iburst minpoll 4 maxpoll 7“)

  • auf jeder Node: pveceph install
  • Netzwerk definieren (Beispielnetz: 10.1.2.0/24): pveceph init –network 10.1.2.0/24 (dieser Wert wird für public network + cluster network benutzt!)
  • mon/mgr anlegen (mind. 3x):
    1. über SSH: pveceph createmon
    2. oder über web auf einem beliebigem Node

Festplatten als OSD hinzufügen (hier sda bis sdh):

for disk in sda sdb sdc sdd sde sdf sdg sdh
do
  pveceph createosd /dev/$disk
done

via gui oder:

  1. MDS entfernen: via GUI oder pveceph mds destroy NAME
  2. ceph rm fs NAME –yes-i-really-mean-it

(leider nicht über GUI möglich)

Schema: ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class>

Erklärung:

  • <rule-name> name of the rule, to connect with a pool (seen in GUI & CLI)
  • <root> which crush root it should belong to (default ceph root „default“)
  • <failure-domain> at which failure-domain the objects should be distributed (usually host)
  • <class> what type of OSD backing store to use (eg. nvme, ssd, hdd)

ceph osd crush rule create-replicated ssd_only default host ssd ceph osd crush rule create-replicated hdd_only default host hdd ceph osd crush rule ls

replicated_rule → mixed ssd_only → ssd hdd_only → hdd

Welche OSDs gehören zur Klasse SSD? - den kompletten Baum: ceph osd tree (Spalten CLASS, NAME) - ceph osd crush class ls-osd ssd → zeigt die osd.NUMMERN an

For replicated pools it is the ruleset specified by the osd pool default crush replicated ruleset config variable. → http://docs.ceph.com/docs/luminous/rados/operations/pools/

anschließend einem Pool zuweisen. - GUI - Shell

ceph osd pool set {pool-name} {key} {value}

Beispiel: der pool „cephfs_metadata“ bekommt nun die rule „ssd_only“: ceph osd pool set cephfs_metadata crush_rule ssd_only Ausgabe: „set pool 7 crush_rule to ssd_only“ → Achtung: Die Daten werden nun ggf. umkopiert!

  • Backup-Job (System)
    1. manuell starten können
    2. inkrementelle Jobs möglich machen
    3. run before/run after-Hooks
    4. freier definierbar Backup-Jobs via GUI (Quelle z.B. ein Verzeichnis)
  • ZFS storage von der Oberfläche löschen können
    1. Erweiterung der bulk Aktionen „Bulk config change“:
    2. bridge ändern (MAC bleibt!)
    3. boot-CD ändern
    4. autostart-Modus
  • ceph
    • crush-rules editierbar machen
  • storage
    1. Spalte Dateidatum bei Content-auflistung würde z.B. beim Backup-Restore helfen
    2. Festplatte „sauber“ machen (use-case: zfs auf ehemals gebrauchten Festplatten anlegen, zfs-Befehl erkennt das mal ein ext4 drauf lag und verlangt -f/force was die gui aber nicht mitgibt. daher ssh-login und dd notwendig)
  • Permission-System anhand der Pfade ggf. verbesserungswürdig
  • Upload von Dateien über Web >2G nicht möglich (scp nehmen)