Server/Proxmox Virtual Environment: Unterschied zwischen den Versionen
Zeile 222: | Zeile 222: | ||
====== Änderung der Konfiguration von Instanzen der Containerisierung von privilegiert zu unprivilegiert durch backup and restore ====== | ====== Änderung der Konfiguration von Instanzen der Containerisierung von privilegiert zu unprivilegiert durch backup and restore ====== | ||
Test durchgeführt von goeranh -> Container und VMs können restored werden, indem man auf den Server(n1-3) klickt und dort auf den Storrage b1 -> aus dieser liste kann dann selbst ein gelöschter Container wiederhergestellt werden. Es wurde das Bedenken geäußert, dass VM-IDs kollidieren, wenn ein Container gelöscht wird, ein neuer erstellt und dann der alte Container wieder restored wird. In dieser Situation wird einfach eine neue ID vergeben. | |||
Ungetestet! | Ungetestet! |
Version vom 3. Juni 2022, 19:15 Uhr
Administration
web user interface
Browser für das web user interface
Es kann nur zu Chromium (notfalls Chrome) geraten werden. Firefox scheint nicht (ideal) geeignet zu sein.
Erreichbarkeit vom web user interface
Standardmäßig ist das web user interface per https auf Port 8006 zu erreichen.[1]
sources.list
- Proxmox Version 6
- in Anlehnung an Proxmox:Wiki Install Proxmox VE on Debian Buster#Adapt your sources.list
Wahrnehmen des Fehlers (401) bei Beziehen der Quelle enterprise.proxmox.com
- Für die Quelle enterprise.proxmox.com bedarf es Zugangsdaten (die entsprechend zu vergüten sind). Ohne Zugangsdaten wird der Code (für den Fehler) 401 (fehlerhafte Autorisierung) ausgeliefert.
apt update
Hit:1 http://security.debian.org/debian-security buster/updates InRelease Hit:2 http://deb.debian.org/debian buster InRelease Hit:3 http://deb.debian.org/debian buster-updates InRelease Hit:4 http://download.proxmox.com/debian/ceph-nautilus buster InRelease Hit:5 http://download.proxmox.com/debian/pve buster InRelease Err:6 https://enterprise.proxmox.com/debian/pve buster InRelease 401 Unauthorized [IP: 2a01:7e0:0:424::249 443] Reading package lists... Done E: Failed to fetch https://enterprise.proxmox.com/debian/pve/dists/buster/InRelease 401 Unauthorized [IP: 2a01:7e0:0:424::249 443] E: The repository 'https://enterprise.proxmox.com/debian/pve buster InRelease' is not signed. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details.
Anzeigen des Datei mit dem Eintrag für diese Quelle
cat /etc/apt/sources.list.d/pve-enterprise.list
deb https://enterprise.proxmox.com/debian/pve buster pve-enterprise
Hinzufügen einer (vergleichbaren) alternativen Quelle ohne sich registrieren zu müssen
echo "deb http://download.proxmox.com/debian/pve buster pve-no-subscription" > /etc/apt/sources.list.d/pve-no-subscription.list
wget http://download.proxmox.com/debian/proxmox-ve-release-6.x.gpg -O /etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg
Resolving download.proxmox.com (download.proxmox.com)... 2a01:7e0:0:424::249, 212.224.123.70 Connecting to download.proxmox.com (download.proxmox.com)|2a01:7e0:0:424::249|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 1202 (1.2K) [application/octet-stream] Saving to: '/etc/apt/trusted.gpg.d/proxmox-ve-release-6.x.gpg' /etc/apt/trusted.gpg.d/proxmo 100%[===============================================>] 1.17K --.-KB/s in 0s
cat /etc/apt/sources.list.d/pve-install-repo.list
deb http://download.proxmox.com/debian/pve buster pve-no-subscription
mv /etc/apt/sources.list.d/pve-enterprise.list /root/pve-enterprise.list
mv /etc/apt/sources.list.d/pve-install-repo.list /root/pve-install-repo.list
apt update
Hit:1 http://security.debian.org/debian-security buster/updates InRelease Hit:2 http://deb.debian.org/debian buster InRelease Hit:3 http://deb.debian.org/debian buster-updates InRelease Hit:4 http://download.proxmox.com/debian/ceph-nautilus buster InRelease Reading package lists... Done Building dependency tree Reading state information... Done 10 packages can be upgraded. Run 'apt list --upgradable' to see them.
apt upgrade
- Proxmox Version 5
- versteckt
ZFS
Bei Server/Proxmox Virtual Environment gibt es keine direkte (integrierte) Verwaltung von ZFS. Es wird (größtenteils) verwendet wie alle anderen Dateisysteme. Auf der Kommandozeile geht aber alles.
Zurücksetzen der Konfiguration vom Betriebssystem auf einen vorherigen Schnappschuss von ZFS
Auch wenn es (seitens ZFS) möglich ist das Dateisystem "unter dem Arsch" vom Betriebssystem zurückzusetzen, so sei davon abgeraten, denn laufende Dienste können damit schlecht umgehen.
- möglichst alle relevanten Dienste stoppen
- (Es ist leider unklar welche Dienste relevant sind.)
- Anzeigen lassen aller laufender Dienste
systemctl list-units --type=service --state=running
- zfs rollback
- (möglichst unverzüglich) System neu starten lassen
Proxmox Storage
Proxmox Storage Content
Proxmox Storage Content Disk image
Proxmox Storage Content ISO image
Proxmox Storage Content Container template
Proxmox Storage Content VZDump backup file
Proxmox Storage Content Container
Proxmox Storage Content Snippets
Proxmox Storage Type
Proxmox Storage Type Directory
Proxmox Storage Type LVM
Proxmox Storage Type LVM-thin
Proxmox Storage Type CephFS
ls /mnt/pve/
cephfs
ls /mnt/pve/cephfs/
Proxmox Storage Type RDB
ls /dev/rbd/
storage
ls /dev/rbd/storage/
Proxmox Storage Type ZFS
Proxmox Ceph
Ceph Dashboard
Containerisierung
Für die Containerisierung bei Server/Proxmox Virtual Environment wird LXC verwendet.
Auflisten aller bereitgestellten Container
pveam available
Bei Server/Proxmox Virtual Environment wird nach #Container für bestimmte Betriebssysteme system (also ohne einen konkreten Zweck der Anwendung angedacht zu haben) und #Container für bestimmte Anwendungen turnkeylinux. (Genau genommen gibt es noch mail, für die #Containerisierung für Proxmox Mail Gateway.)
Erstellung von Instanzen der Containerisierung
Konfiguration von Instanzen der Containerisierung
Änderung der Konfiguration von Instanzen der Containerisierung
Änderung der Konfiguration von Instanzen der Containerisierung von privilegiert zu unprivilegiert
Änderung der Konfiguration von Instanzen der Containerisierung von privilegiert zu unprivilegiert durch backup and restore
Test durchgeführt von goeranh -> Container und VMs können restored werden, indem man auf den Server(n1-3) klickt und dort auf den Storrage b1 -> aus dieser liste kann dann selbst ein gelöschter Container wiederhergestellt werden. Es wurde das Bedenken geäußert, dass VM-IDs kollidieren, wenn ein Container gelöscht wird, ein neuer erstellt und dann der alte Container wieder restored wird. In dieser Situation wird einfach eine neue ID vergeben.
Ungetestet!
pct restore 321 /mnt/pve/cephfs/dump/vzdump-lxc-321-2020_10_11-00_14_05.tar.zst -ignore-unpack-errors 1 -unprivileged
Änderung der Konfiguration von Instanzen der Containerisierung von privilegiert zu unprivilegiert durch chown
Der Test (2020-10-10 -11) schlug fehl! Der Test der Änderung fand bei einem Container nach der StuRa:Server/TurnKey#Aktualisierung von TurnKey 15 auf TurnKey 16 (StuRa:Server/Nextcloud#TurnKey 15) statt.
- leidiges Ergebnis
systemctl
● sys-kernel-config.mount loaded failed failed Kernel Configuration File System ● sys-kernel-debug.mount loaded failed failed Kernel Debug File System
● mariadb.service loaded failed failed MariaDB 10.3.23 database server
● systemd-update-utmp.service loaded failed failed Update UTMP about System Boot/Shutdown
● systemd-journald-audit.socket loaded failed failed Journal Audit Socket
● systemd-update-utmp.service loaded failed failed Update UTMP about System Boot/Shutdown
● systemd-journald-audit.socket loaded failed failed Journal Audit Socket
● sys-kernel-config.mount loaded failed failed Kernel Configuration File System ● sys-kernel-debug.mount loaded failed failed Kernel Debug File System
● mariadb.service loaded failed failed MariaDB 10.3.23 database server
systemctl status mariadb.service
● mariadb.service - MariaDB 10.3.23 database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Sun 2020-10-11 08:59:26 CEST; 47s ago Docs: man:mysqld(8) https://mariadb.com/kb/en/library/systemd/ Process: 217 ExecStartPre=/usr/bin/install -m 755 -o mysql -g root -d /var/run/mysqld (code=exited, status=0/SUCCESS) Process: 235 ExecStartPre=/bin/sh -c systemctl unset-environment _WSREP_START_POSITION (code=exited, status=0/SUCCESS) Process: 247 ExecStartPre=/bin/sh -c [ ! -e /usr/bin/galera_recovery ] && VAR= || VAR=`cd /usr/bin/..; /usr/bin/galera_recovery`; [ $? -eq 0 ] && systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1 (code=exited, status=0/ Process: 427 ExecStart=/usr/sbin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION (code=exited, status=7) Main PID: 427 (code=exited, status=7) Status: "MariaDB server is down" Oct 11 08:59:22 nextcloud systemd[1]: Starting MariaDB 10.3.23 database server... Oct 11 08:59:23 nextcloud mysqld[427]: 2020-10-11 8:59:23 0 [Note] /usr/sbin/mysqld (mysqld 10.3.23-MariaDB-0+deb10u1) starting as process 427 ... Oct 11 08:59:26 nextcloud systemd[1]: mariadb.service: Main process exited, code=exited, status=7/NOTRUNNING Oct 11 08:59:26 nextcloud systemd[1]: mariadb.service: Failed with result 'exit-code'. Oct 11 08:59:26 nextcloud systemd[1]: Failed to start MariaDB 10.3.23 database server.
- https://forum.proxmox.com/threads/31066/#post-261883 (https://forum.proxmox.com/threads/convert-privileged-to-unprivileged-container.31066/#post-261883)
Stoppen vom bisherigen Container, der geändert werden soll
pct stop 321
(optionales) Erstellen von einem Snapshot vom bisherigen Container, der geändert werden soll, um im Fall von eines Fehlschlages der Änderung den Container zurücksetzen zu können
(optionales) Erstellen von einer Datensicherung vom bisherigen Container, der geändert werden soll, um im Fall von eines Fehlschlages der Wiederherstellung von einem Snapshot den Container wiederherstellen zu können
Ersrellen von einem zeitweisen Verzeichnis (in dem die Änderung abgearbeitet werden soll)
mkdir /tmp/321
Einhängen vom Speicher vom bisherigen Container, der geändert werden soll, ohne den Container zu starten, um die Dateien ändern zu können (Der Ablageort - im Beispiel /dev/rbd/storage/vm-321-disk-0 - muss ermittelt werden. Im Beispiel ist der #Proxmox Storage Content Container im #Proxmox Storage Type RDB storage abgelegt. Im Beispiel ist die ID von der #Erstellung von Instanzen der Containerisierung 321.)
mount -o loop /dev/rbd/storage/vm-321-disk-0 /tmp/321
(massenhaftes) Ändern vom Recht fürs Eigentum von Dateien beim bisherigen Container
Achtung! Die Ausführung dauert über 1 Stunde!
find /tmp/321 -type f | while read S; do U="$(ls -ln "${S}" | awk '{print$3}')"; G="$(ls -ln "${S}" | awk '{print$4}')"; F=100000; chown "${F:0: -${#U}}${U}:${F:0: -${#G}}${G}" "${S}"; done
(massenhaftes) Ändern vom Recht fürs Eigentum von Dateien beim bisherigen Container
Achtung! Die Ausführung dauert über 1 Stunde!
find /tmp/321 -type d | while read S; do U="$(ls -lnd "${S}" | awk '{print$3}')"; G="$(ls -lnd "${S}" | awk '{print$4}')"; F=100000; chown "${F:0: -${#U}}${U}:${F:0: -${#G}}${G}" "${S}"; done
Löschen von /tmp/321/var/spool/postfix/dev/-random
beim bisherigen Container
[ -e /tmp/321/var/spool/postfix/dev/-random ] && rm -ri /tmp/321/var/spool/postfix/dev/-random
Löschen von /var/spool/postfix/dev/-urandom
beim bisherigen Container
[ -e /tmp/321/var/spool/postfix/dev/-urandom ] && rm -ri /tmp/321/var/spool/postfix/dev/-urandom
wenn das Paket sudo
installiert ist, Ändern vom Modus von der Datei /usr/bin/sudo
beim bisherigen Container
[ -e /tmp/321/usr/bin/sudo ] && chmod u+s /tmp/321/usr/bin/sudo
Aushängen vom Speicher vom bisherigen Container, der geändert wurde, um den Container geändert in Betrieb nehmen zu können
umount /tmp/321
Änderung der
Achtung! Das ist ein wenig spooky. Einfach unten drunter schreiben? Es gibt (auch) verschiedene Abschnitte für jeden Snapshot.
echo -e "\nunprivileged: 1" >> /etc/pve/lxc/321.conf
nano /etc/pve/lxc/321.conf
Starten vom bisherigen Container, der geändert wurde
pct start 321
(bei Problemen beim) Starten vom bisherigen Container, der geändert wurde, mit Aufzeichnung von möglichen Problemen
pct start --debug=1 321
Problembehebung bei der Containerisierung
- aka Troubleshooting pct
Probĺemerkennung bei der Containerisierung
Starten von einem Container (LXC) im Modus für die Fehlerbehehung
lxc-start -n <Containernummer> -F -l DEBUG
Problem, dass ein Container lange nicht startet
- Problem zur (falschen) Konfiguration zur Verwendung von IPv6
- Wenn versehentlich bei der Erstellung von einem Container bei Network was zu IPv6 (beispielsweise DHCP) konfiguriert und damit aktiviert wurde, dann wird beim Starten vom Container mehrere (etwa 5) Minuten versucht IPv6 zu verwenden. Leider gibt es in unserer Umgebung (Server HTW Dresden) kein IPv6.
- Das Problem lässt sich beheben in dem bei der Konfiguration bei IPv6 die voreingestellte Option Static ausgewählt wird und Einträge zu IPv6 (beispielsweise bei IPv6/CIDR) bestehen.
- Im Übrigen kann dazu auch die Datei für die Konfiguration vom Container (beispielsweise mit der Nummer 1337) gesichtet und womöglich angepasst werden.
less /etc/pve/lxc/1337.conf
nano /etc/pve/lxc/1337.conf
unterschiedliche Container
Containerisierung für bestimmte Betriebssysteme
Ein Server/Proxmox Virtual Environment bietet eine Vielzahl von üblichen Varianten an Linux: http://download.proxmox.com/images/system/
pveam update
pveam available --section system
pveam download
pveam download cephfs debian-10-standard_10.5-1_amd64.tar.gz
Containerisierung für nicht bestimmte Betriebssysteme
Containerisierung für NixOS
Erstellung von Instanzen der Containerisierung für NixOS
Aktuell (2020-03) gibt es keine für Server/Proxmox angebotene Vorlage für das Betriebssystem NixOS.
Nachfolgend (2021-10) wurde sich damit dennoch weiter auseinandergesetzt, um zukünftig auch NixOS (mit der Vielzahl von Vorteilen) verwenden zu können. Seit 2021-10 wurde auch das PVE 7 verwendet, weswegen es zuvor vermieden wurde noch etwas für PVE 6 gangbar zu machen, was nachfolgend vielleicht nicht mehr funktioniert und viel Aufwand für die Überwindung von Hindernissen zur Nutzung und Weiternutzung entsteht.
Besonderheiten Erstellung von Instanzen der Containerisierung für NixOS
- Options
-
- Console mode
- console (statt Default (tty))
Containerisierung für NixOS Aktualisierung
Containerisierung für NixOS Aktualisierung 21.11
(optionales) Auflisten aller verfügbaren Kanäle (für Software) für NixOS
nix-channel --list | grep nixos
nixos https://nixos.org/channels/nixos-21.05
Hinzufügen des neuen (nachfolgenden) Kanals (für Software) für NixOS (beispielhaft 21.11)
nix-channel --add https://nixos.org/channels/nixos-21.11 nixos
nixos-rebuild switch --upgrade
unpacking channels...
==================== Results =================== No issues found. ==================== Summary =================== Total issues: Unspecified: 0 Low: 0 Medium: 0 High: 0
ln: failed to create symbolic link '/sbin/init': No such file or directory Activation script snippet 'installInitScript' failed (1) restarting systemd... setting up tmpfiles reloading the following units: dbus.service, dev-mqueue.mount, firewall.service, sys-fs-fuse-connections.mount Job failed. See "journalctl -xe" for details. restarting the following units: dhcpcd.service, network-addresses-eth0.service, nginx.service, systemd-journald.service starting the following units: acme-fixperms.service, acme-pro.stura.htw-dresden.de.timer, network-local-commands.service, network-setup.service, nix-daemon.socket, nscd.service, resolvconf.service, systemd-sysctl.service, systemd-tmpfiles-clean.timer, systemd-tmpfiles-setup-dev.service warning: error(s) occurred while switching to the new configuration
nixos-rebuild switch --upgrade
unpacking channels... created 1 symlinks in user environment building Nix... building the system configuration... activating the configuration... setting up /etc... ln: failed to create symbolic link '/sbin/init': No such file or directory Activation script snippet 'installInitScript' failed (1) setting up tmpfiles warning: error(s) occurred while switching to the new configuration
mkdir /sbin/
nixos-rebuild switch --upgrade
Containerisierung für bestimmte Anwendungen
Containerisierung für TurnKey
Server/Proxmox Virtual Environment bietet verschiedene (übliche) Anwendungen als Container. Dazu werden vorbereitete Container von TurnKey (wikipedia:en:TurnKey Linux Virtual Appliance Library) verwendet. (Systeme von TurnKey verwenden auch (wie Server/Proxmox Virtual Environment selbst Debian als Grundlage (Betriebssystem.)
pveam update
pveam available --section turnkeylinux
pveam download
pveam download cephfs debian-10-turnkey-core_16.0-1_amd64.tar.gz
Containerisierung für TurnKey ab Version 16
#Containerisierung mit Debian 10
Containerisierung für TurnKey bis Version 15
Leider scheint (2020-02) für TurnKey die Möglichkeit für unprivileged LXC container nicht zu funktionieren.
Mit der Version 16, also auch dem Wechsel von Version 9 zu Version 10 bei Debian als Grundlage, scheint sich das geändert zu haben.
Containerisierung für Docker
Für den Betrieb von Instanzen mit Docker kann Server/Proxmox Virtual Environment, neben der dazu empfohlenen Technik der #Virtualisierung, auch Container entsprechend konfigurieren. Dazu werden unprivileged LXC container erstellt und mit zusätzlichen Berechtigungen (auf das Gesamtsystem) ausgestattet, um die von Docker erforderlichen Funktionalitäten bereitstellen zu können.
- nicht privilegierter Container
- Anscheinend kann Docker nur innerhalb von einem nicht privilegierten Container betreiben werden. (Eigentlich ist das ja sogar sehr schön, denn es erscheint schöner einen Container mit möglichst wenigen Privilegien (Berechtigungen) zu benutzen.)
- Einschalten der Funktionalität (für Container bei Server/Proxmox Virtual Environment) keyctl
- Um Docker innerhalb von einem Container betreiben zu können, scheint Docker jedoch den Systemaufruf keyctl zu benötigen. In einem standardmäßigen nicht privilegierten Container wird dieser aber als non-existent nicht gesehen, wodurch Docker nicht richtig funktionieren kann. Mit dem Einschalten der standardmäßigen Option keyctl für einen nicht privilegierten Container bei Server/Proxmox Virtual Environment kann das Problem behoben werden.
- Einschalten der Funktionalität (für Container bei Server/Proxmox Virtual Environment) nesting
- Um Docker innerhalb von einem Container betreiben zu können, scheint Docker jedoch Zugriff auf
procfs
undsysfs
zu benötigen. In einem standardmäßigen nicht privilegierten Container wird dieser aber nicht zugelassen (nicht bereitgestellt), wodurch Docker nicht richtig funktionieren kann. Mit dem Einschalten der standardmäßigen Option nesting für einen nicht privilegierten Container bei Server/Proxmox Virtual Environment kann das Problem behoben werden.
- Um Docker innerhalb von einem Container betreiben zu können, scheint Docker jedoch Zugriff auf
- #Virtualisierung als Alternative zur Containerisierung für Docker
Containerisierung für Kubernetes
- https://kvaps.medium.com/run-kubernetes-in-lxc-container-f04aa94b6c9c
- https://gist.github.com/kvaps/25f730e0ec39dd2e5749fb6b020e71fc
Containerisierung mit Debian 10
- Jede #Containerisierung für bestimmte Anwendungen (also mit TurnKey) ist eine #Containerisierung mit Debian 10.
Containerisierung mit Debian 10 nesting
- Einschalten der Funktionalität (für Container bei Server/Proxmox Virtual Environment) nesting
- Um bespielsweise MariaDB innerhalb von einem Container mit Debian 10 betreiben zu können, scheint Debian jedoch ein Problem mit AppAmor zu haben.[2] Im Übrigen ist das bei sowohl nicht privilegierten Containern als auch privilegierten Containern. Mit dem Einschalten der standardmäßigen Option nesting für einen Container bei Server/Proxmox Virtual Environment kann das Problem behoben werden.
- beispielhaftes Problem (ohne nesting)
-
- Umgebung
Die Anwendung startet nicht.
Anzeigen vom Status (dem Problem) der Anwendung MariaDB
systemctl status mariadb.service
* mariadb.service - MariaDB 10.3.23 database server Loaded: loaded (/lib/systemd/system/mariadb.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Wed 2020-09-16 20:35:41 CEST; 23s ago Docs: man:mysqld(8) https://mariadb.com/kb/en/library/systemd/ Sep 16 20:35:41 test-ghost systemd[1]: Starting MariaDB 10.3.23 database server... Sep 16 20:35:41 test-ghost systemd[17751]: mariadb.service: Failed to set up mount namespacin Sep 16 20:35:41 test-ghost systemd[17751]: mariadb.service: Failed at step NAMESPACE spawning Sep 16 20:35:41 test-ghost systemd[1]: mariadb.service: Control process exited, code=exited, Sep 16 20:35:41 test-ghost systemd[1]: mariadb.service: Failed with result 'exit-code'. Sep 16 20:35:41 test-ghost systemd[1]: Failed to start MariaDB 10.3.23 database server.
Containerisierung für Proxmox Mail Gateway
Ein Server/Proxmox Virtual Environment bietet die spezielle Anwendung für Mail von Proxmox: http://download.proxmox.com/images/mail/
pveam update
pveam available --section mail
pveam download
pveam download cephfs proxmox-mailgateway-6.2-standard_6.2-1_amd64.tar.gz
Sicherung und Wiederherstellung von Instanzen der Containerisierung
Sicherung von Instanzen der Containerisierung
Wiederherstellung von Instanzen der Containerisierung
Wiederherstellung von Instanzen der Containerisierung über die grafische Oberfläche
Wiederherstellung von Instanzen der Containerisierung über die Kommandozeile
Backups werden momentan (Version 5.2) in /var/lib/vz/dump
gespeichert.
pct restore NEW_CONTAINER_ID CONTAINER_BACKUP
Für den Fall, dass es den vorherigen Storage nicht gibt, kann mit den Storage angeben:
pct restore NEW_CONTAINER_ID CONTAINER_BACKUP -storage STORAGENAME
Virtualisierung
Konfiguration der Virtualisierung
Benutzung der Funktionalität der Unterstützung der Hardware zur Virtualisierung
https://pve.proxmox.com/wiki/Nested_Virtualization#Enable_Nested_Hardware-assisted_Virtualization
Standardmäßig benutzt Server/Proxmox Virtual Environment nicht die Funktionalität der Unterstützung der Hardware zur Virtualisierung. Standardmäßig ist aber die Benutzung der Funktionalität möglich, wozu die Konfiguration von Server/Proxmox Virtual Environment einfach geändert werden kann.
Es kann Gründe für und gegen die Benutzung der Funktionalität der Unterstützung der Hardware zur Virtualisierung geben.
- dagegen
- Es ist nicht möglich eine Migration von Instanzen durch Virtualisierung im laufenden Betrieb vorzunehmen.
- dafür
- Es ist eine höhere Leistungsfähigkeit bei Instanzen durch Virtualisierung gegeben.
Virtualisierung Debian
Es sollte einen unabdingbaren Grund geben warum nicht die #Containerisierung Debian genutzt wird.
Bei der Virtualisierung von Debian ab 2020 geht es ausschließlich um Debian (Version) 10 oder was tagesaktuell gerade stable ist und tagesaktuell die Basis für Server/Proxmox Virtual Environment ist.
Virtualisierung CentOS
Es sollte einen unabdingbaren Grund geben warum nicht die #Containerisierung CentOS genutzt wird.
Bei der Virtualisierung von CentOS ab 2020 geht es ausschließlich um CentOS (Version) 8.
Virtualisierung OpenBSD
Virtualisierung FreeBSD
Virtualisierung CoreOS
Virtualisierung RancherOS
Der Betrieb von RancherOS kommt eigentlich nur in Frage, wenn wegen Docker eine Basis virtualisiert werden muss und die Vorteile gegenüber der #Virtualisierung Debian erkennbar gemacht werden können.
- https://rancher.com/docs/os/v1.x/en/installation/workstation/boot-from-iso/
https://rancher.com/docs/os/v1.x/en/installation/workstation/docker-machine/#using-docker-machine-with-proxmox-ve
Sicherung und Wiederherstellung von Instanzen der Virtualisierung
Sicherung von Instanzen der Virtualisierung
Wiederherstellung von Instanzen der Virtualisierung
Wiederherstellung von Instanzen der Virtualisierung über die grafische Oberfläche
Wiederherstellung von Instanzen der Virtualisierung über die Kommandozeile
qmrestore VMACHINE_BACKUP NEW_VM_ID -storage STORAGENAME