Hope This Helps

Problem
Nach der initialen Einrichtung des Netapp Simulators unter VMWare ESX oder VMWare Workstation scheint das ONTAP beim Starten stehen zu bleiben. Nach einigen Minuten ist der Node oder Cluster aber per SSH und HTTPS erreichbar.


Lösung
Leider handelt es sich hier um einen BUG, der nicht gefixt wird (weder VMWare noch Netapp).
Entweder man ignoriert das Verhalten, da der Cluster bzw. Node nach der Bootvorgang ganz normal erreichbar ist, oder man kann im VLOADER anpassen, damit die Anzeige korrekt ist. Das ist vor allem im Fehlerfall hilfreich!
Die Anpassung muss aber JEDES MAL gemacht werden und ist nicht persistent:

- Bootvorgang des Nodes am Anfang (Countdown) mit einer non-Enter-Taste unterbrechen.
- Der Prompt "VLOADER>" wird angezeigt
- Hier den Befehl "setenv screen.textmode 1" eingbene
- Bootvorgang mit dem Befehl "boot_ontap" starten
- Die Anzeige ist nun korrekt und der Bootvorgang wird vollständig angezeigt

Quelle:
ONTAP Select node 9.13.1 appears to hang during boot

Problem:
Wir wollten einen physikalischen Server inkl. Applikation auf einen virtuell Server umziehen und from scratch neu installieren (kein P2V). Hierzu mussten wir die originalen Installationsmedien des Herstellers verwenden, da es sich um eine ROK-Lizenzen gehandelt. Bei der Installation in einer VM unter VirtualBox kam der Hinweis, dass das installationsmedium Vendor branded ist und die Installation bricht ab.

Lösung:
Man kann der VM unter VirtualBox einen Vendor BIOS Tag mitgeben, damit die Installation funktioniert. Das konnten wir bei Fujitsu und HP sauber abbilden.

Folgende Befehle haben hier den Vendor im BIOS gesetzt:

Fujitsu

VBoxManage setextradata "Analysis" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor"      "FUJITSU"
VBoxManage setextradata "Analysis" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVendor"        "FUJITSU // Phoenix Technologies Ltd."

HP

VBoxManage setextradata "VM Name" "VBoxInternal/Devices/pcbios/0/Config/DmiBIOSVendor" "HP"
VBoxManage setextradata "VM Name" "VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor" "HP"

Ein überblick aller Befehle findet man hier: Configuring the BIOS DMI Information

Manchmal kann es vorkommen das unter Proxmox ein Node nur ein graues Ausrufezeichen zeigt. Das ist meistens auf einen Fehler mit dem Storage zurückzuführen. In meinem Fall hatte ich testweise den Proxmox Backup Server virtualisiert, das Storage kann dann beim booten nicht verbunden werden und sorgt für einen Fehler, daraus resultiert das graue Ausrufezeichen.

Ein Neustart des Dienstes pvestatd auf dem betroffenen Node hat den Fehler behoben und der Node wurde grün

systemctl restart pvestatd.service

Ich habe festgestellt das wenn man einen LXC mit Debian 11 auf einem Proxmox laufen lässt, die Performance auf ssh ziemlich schlecht ist. Auch sudo dauert ziemlich lange (wenn man es verwendet)

Das liegt am Service systemd-logind wenn man diesen deaktiviert hat man wieder die gewohnte Performance.

Um zu verifizieren ob es an diesem Service liegt , grept einfach mal nach 'org.freedesktop.login1' in der Datei /var/log/auth.log

grep 'org.freedesktop.login1' /var/log/auth.log

wenn ihr dort Einträge findet, die wie folgt aussehen, liegt es vermutlich an diesem Dienst.

Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms)

Problem wird dann mit diesen Befehl behoben (muss als root ausgeführt werden)

systemctl mask systemd-logind && pam-auth-update

Ich setzte zuhause Proxmox ein und lasse alles auf LXC laufen, da es einiges an Overhead spart.
Normalerweise läuft ein LXC als "Unprivileged container" in machen Fällen kann es jedoch vorkommen das ein LXC als "Privileged container" laufen muss. Ein konvertieren des LXC ist nur über einen kleinen Umweg möglich.

Das einfachste Vorgehen :

1.) Stoppen des LXCs (in meinen Fall 102)
2.) einen Snapshot des LXC erstellen
2.) Diesen Snapshot dann als neue Maschine (hier 103) restoren und den Parameter für unprivileged auf 0 setzen

pct restore 103 /var/lib/vz/dump/vzdump-lxc-102-2021_11_18-22_49_58.tar.zst -ignore-unpack-errors 1 -unprivileged 0 --storage ZFS-DATA

3.) Starten des LXC

Dieses Vorgehen sollte aber nur verwendet werden wenn es GAR NICHT anders geht


Proxmox : https://www.proxmox.com/de/
LXC : https://de.wikipedia.org/wiki/LXC

Unser Azubi hat hier zum spielen ein Proxmox aufgebaut. Den Server den er hier installiert hatte muss ich jetzt in unsere VM-Ware Umgebung übernehmen. Da ich jetzt den Weg Proxmox -> VMware benötige konvertiere ich das alles mit qemu-img in das vmdk Format.

1.) Schauen wir uns die Konfiguration der VM an.

cat /etc/pve/nodes/xxx/qemu-server/100.conf 

bootdisk: scsi0
cores: 2
ide2: local:iso/14393.0.161119-1705.RS1_REFRESH_SERVER_EVAL_X64FRE_DE-
DE.ISO,media=cdrom
memory: 12288
name: servername.home.box
net0: e1000=1A:AF:17:D8:B0:44,bridge=vmbr0,firewall=1
numa: 0
ostype: l26
sata0: local-lvm:vm-100-disk-0,size=80G
sata1: zfs-storage:vm-100-disk-0,size=800G
scsihw: virtio-scsi-pci
smbios1: uuid=5c3fa82f-83a6-4206-92e7-34ac8fa38100
sockets: 1
vmgenid: c399e3ee-37c9-4b48-bb3b-585905633f84

2.) jetzt schauen wir uns mal an was so an Platten rumliegt und suchen uns die richtige raus

pvesm list local-lvm

local-lvm:vm-100-disk-0   raw 85899345920 100
local-lvm:vm-101-disk-0   raw 17179869184 101
local-lvm:vm-102-disk-0   raw 12884901888 102
local-lvm:vm-103-disk-0   raw 34359738368 103
local-lvm:vm-104-disk-0   raw 34359738368 104

wir brauchen hier die vm-100-disk-0 dafür lesen wir jetzt mal den Speicherort aus.

pvesm path local-lvm:vm-100-disk-0

/dev/pve/vm-100-disk-0

mit folgenden Befehl konvertiere ich die erste hdd in vmdk

qemu-img convert -f raw -O vmdk /dev/pve/vm-100-disk-0 ~/root_c.vmdk

3.) jetzt machen wir das selbe für die 2. hdd die liegt allerdings im zfs-storage ab

pvesm list zfs-storage

zfs-storage:vm-100-disk-0   raw 858993459200 100

4.) Naja ich hab keinen Bock 800G zu konvertieren deswegen shrink ich das Teil einfach mal ein wenig.



4.1.) Erstmal müsste ihr im installierten System sicherstellen wieviele GB ihr braucht
4.2.) Dann im System die Partition verkleinern (bei mir waren das 40G)
4.3.) Nun kann man die HDD auf die gewünscht Größe shrinken ich hab mich für 50G entschieden.

zfs set volsize=50G zfs-storage/vm-100-disk-0

nachdem das durchgelaufen ist muss der Eintrag in der Konfigurationsdatei noch angepasst werden.
aus sata1: zfs-storage:vm-100-disk-0,size=800G wird sata1: zfs-storage:vm-100-disk-0,size=50G

5.) wir lesen wieder den Speicherort aus

pvesm path zfs-storage:vm-100-disk-0

/dev/zvol/servername/vm-100-disk-0

6.) und konvertieren wieder

qemu-img convert -f raw -O vmdk /dev/zvol/servername/vm-100-disk-0 ~/hdd_d.vmdk

7.) naja ich konvertiere das nochmal über die vmkfstools

vmkfstools -i root_c.vmdk system.vmdk -d thin -a buslogic
Destination disk format: VMFS thin-provisioned
Cloning disk 'root_c.vmdk'...
Clone: 52% done.

vmkfstools -i hdd_d.vmdk data.vmdk -d thin -a buslogic
Destination disk format: VMFS thin-provisioned
Cloning disk 'hdd_d.vmdk'...
Clone: 36% done.

Quellen :
https://forum.proxmox.com/threads/shrink-zfs-disk.45835/
https://kb.vmware.com/s/article/1028042