ESX / ESXi - Hilfethread

Wenn es keine einfache Möglichkeit gibt, dass das Script erst endet wenn ein create oder remove nicht nur angestoßen sondern erfolgreich abgearbeitet ist oder ein Timeout stattgefunden hat, dann muss man halt darauf hinweisen dass man das manuell per web-ui kontrollieren muss. Man kann ja zumindest zwischen mehreren remove eine Wartezeit einbauen damit das wenigstens in der Regel funktioniert.

Viele Snaps auf dem ESXi sind ja eh die Ausnahme. Ich habe allerdings erst mit deinem Script gesehen dass ich bei einigen VMs zu alte oder zu viele Snaps hatte. Ein automatisiertes Löschen aller ESXi Snaps ist schon hilfreich, eben weil man die wegen ZFS nicht mehr braucht.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wie gesagt. Es gibt noch die Methode "RemoveAllSnapshots" von Haus aus. Wenn das hilfreich wäre.

Und auch hier wäre die Frage, ob das gewollte deaktivieren der Konsolidierung wünschenswert ist.

Gruß
Thomas
 
Wäre hilfreich für dieses besonders zeitkritische Problem.

Kann snap_create solange warten bis der Snap tatsächlich angelegt ist damit ein auf das Script folgende ZFS snapshot create auch sicher einen ESXi Snap enthält?
 
Könnte schon, müsste ich schauen wie ich das mit dem Rückgabewert implementieren kann.
Allerdings hindert es ja die Weboberfläche nicht zwingend einen neuen call auf das Script zu setzen.
 
gea schrieb:
Vermisst sonst jemand der auch ESXi All in One oder ESXi + VMs auf NFS ganz allgemein nutzt noch eine Aktion?
Zum Vergrößern anklicken....
Ich habe jetzt nicht alle Einzelheiten verfolgt - kann man jetzt über napp-it z.B. konfigurieren, dass ESXi eine oder mehrere bestimmte VM(s) sauber herunter fährt, dann nen ZFS-Snapshot vom Storage macht, den snapshot am besten noch wegrepliziert und dann die VM(s) sauber wieder hoch fährt? Ich bräuchte ESXi-Snaps eher nicht, mir wäre eine kurze nächtliche Auszeit und damit ein sicher konsistenter Zustand der VMs lieber.
 
besterino schrieb:
Ich habe jetzt nicht alle Einzelheiten verfolgt - kann man jetzt über napp-it z.B. konfigurieren, dass ESXi eine oder mehrere bestimmte VM(s) sauber herunter fährt, dann nen ZFS-Snapshot vom Storage macht, den snapshot am besten noch wegrepliziert und dann die VM(s) sauber wieder hoch fährt? Ich bräuchte ESXi-Snaps eher nicht, mir wäre eine kurze nächtliche Auszeit und damit ein sicher konsistenter Zustand der VMs lieber.
Zum Vergrößern anklicken....


Ja auf jeden Fall
Man bräuchte momentan ein Script das die komplette Aktion kontrolliert steuert oder aber man nutzt einfach einen oder mehrere "other job" die jeweils die benötigten Befehle einzeln oder per Shellscript Auflistung absetzen bzw. zeitlich darauf mit 5min Abstand folgende Replikationsjobs. Man kann auch Shell Scripts jobid.pre und jobid.post anlegen die vor und nach einem napp-it Autosnap oder ZFS Replikationsjob ausgeführt werden.

Im Menü System > ESXi > Soap kann man eine Aktion z.B. vm shutdown aufrufen und sieht den dazu benötigten Aufruf.

z.B.
in https://www.hardwareluxx.de/community/threads/esx-esxi-hilfethread.748644/page-291#post-29760606
sieht man unterhalb der Scriptausgabe von "summary" den dazu nötigen Aufruf.

Prinzipiell ist das Ziel jeden z.B. täglichen ZFS Snap des NFS Dateisystems mit einem ESXi hot memory snap auszustatten. Damit kann man dann eine laufende VM ohne shutdown sicher per ZFS snapshotten. Nach einem ZFS Rollback oder VM recovery (via Windows vorherige Version) sollte man dann in der ESXi web-ui auf den darin enthaltenen sicheren ESXi Snap zurückgehen. Wenn man nur den letzten ESXi Snap per VM löscht sollte es auch kein Timing Problem geben wie bei der obigen Diskussion um ESXi Mass Remove aller Snaps aller VMs.
Beitrag automatisch zusammengeführt:

Cluster_ schrieb:
Könnte schon, müsste ich schauen wie ich das mit dem Rückgabewert implementieren kann.
Allerdings hindert es ja die Weboberfläche nicht zwingend einen neuen call auf das Script zu setzen.
Zum Vergrößern anklicken....

Ein reines Snapshot delete ohne Konsolidierung wäre ok und vermutlich schneller. Der ESXi Snap dient dabei ohnehin nur dazu für einen ZFS Snap ein sicheres Backup/Recovery einer laufenden VM zu ermöglichen.

Bei mehreren interaktiven Aufrufen kann man ja das Ergebnis nochmal kontrollieren. Möglich sind die ja auch nur bei mehreren parallelen Sessions/Usern. Eine zeitgesteuertes automatische Ausführung wird nicht mehrfach gleichzeitig auf das gleiche Datastore erfolgen und auf jeden Fall auch >= 1x pro Stunde. Häufigere wiederherstellbare ZFS Snaps einer VM wird wohl niemand brauchen. Prinzipiell soll das eher die Intervalle abdecken die man auch VEEAM als Backup angesetzt hätte wobei mit ZFS natürlich durchaus mehr und häufigere Zyklen möglich sind.
 
Zuletzt bearbeitet:
Seit wann gibts eig diese dämliche Beschränkung, das VMKernelports nich mehr derselben Portgroup angehören dürfen wie VMs ?
 
Ich habe meine ESXi 7.0.0 (Build 16324942) Installation von einem Xeon System auf Epyc umgezogen und nun lässt sich Passthrough für meine Optane 900p nicht mehr aktivieren. Der Passthrough Status ist "Aktiviert / Erfordert Neustart" und egal wie oft ich neustarte, der Status bleibt so. Ich habe sicherheitshalber auch mal VMkernel.Boot.disableACSCheck auf True gesetzt, hat nichts geändert.
Vorher lief die Optane über ein Oculink Kabel an meinem Supermicro X11SPH-nCTPF, jetzt über den original m.2 Adapter an einem Supermicro H12SSL-i. Sollte ja eigentlich kein Unterschied machen.

Aus den Logs werde ich nicht wirklich schlau. Evtl relevante Ausschnitte:
/var/log/vmkernel.log
Code: 
2023-03-22T09:39:48.960Z cpu4:2098196)ScsiDevice: 5343: Computing hash based VML id on the string 'NVMe    INTEL SSDPE21D280GA                     PHM2736400AU280AGN  00000001' for the device t10
2023-03-22T09:39:48.960Z cpu4:2098196)NVMe____INTEL_SSDPE21D280GA_____________________PHM2736400AU280AGN__00000001
2023-03-22T09:39:48.960Z cpu4:2098196)ScsiDevice: 5373: Legacy VML ID : vml.05ce413ba297293ac9486f477d0b24e2a5c8932363704a32bef5ab2f02e68e71fc
2023-03-22T09:39:48.960Z cpu6:2098196)VMWARE SCSI Id: Id for vmhba7:C0:T0:L0
0x50 0x48 0x4d 0x32 0x37 0x33 0x36 0x34 0x30 0x30 0x41 0x55 0x32 0x38 0x30 0x41 0x47 0x4e 0x20 0x20 0x49 0x4e 0x54 0x45 0x4c 0x20
2023-03-22T09:39:48.960Z cpu4:2098196)ScsiDeviceIO: 9174: QErr is correctly set to 0x0 for device t10.NVMe____INTEL_SSDPE21D280GA_____________________PHM2736400AU280AGN__00000001.
2023-03-22T09:39:48.960Z cpu6:2098196)WARNING: NvmeScsi: 148: SCSI opcode 0x1a (0x459a425fd300) on path vmhba7:C0:T0:L0 to namespace t10.NVMe____INTEL_SSDPE21D280GA_____________________PHM2736400AU280AGN__00000001 failed with NVMe error
2023-03-22T09:39:48.960Z cpu6:2098196)WARNING: status: 0x2 translating to SCSI error H:0x0 D:0x2 P:0x0 Valid sense data: 0x5 0x24 0x0
2023-03-22T09:39:48.960Z cpu4:2098196)ScsiDeviceIO: 9671: Could not detect setting of sitpua for device t10.NVMe____INTEL_SSDPE21D280GA_____________________PHM2736400AU280AGN__00000001. Error Not supported.
2023-03-22T09:39:48.961Z cpu4:2098196)ScsiEvents: 301: EventSubsystem: Device Events, Event Mask: 40, Parameter: 0x43057c0a2680, Registered!
2023-03-22T09:39:48.961Z cpu4:2098196)ScsiEvents: 301: EventSubsystem: Device Events, Event Mask: 200, Parameter: 0x43057c0a2680, Registered!
2023-03-22T09:39:48.961Z cpu4:2098196)ScsiEvents: 301: EventSubsystem: Device Events, Event Mask: 800, Parameter: 0x43057c0a2680, Registered!
2023-03-22T09:39:48.961Z cpu4:2098196)ScsiEvents: 301: EventSubsystem: Device Events, Event Mask: 400, Parameter: 0x43057c0a2680, Registered!
2023-03-22T09:39:48.961Z cpu4:2098196)ScsiEvents: 301: EventSubsystem: Device Events, Event Mask: 8, Parameter: 0x43057c0a2680, Registered!
2023-03-22T09:39:48.961Z cpu4:2098196)ScsiEvents: 301: EventSubsystem: Device Events, Event Mask: 2000, Parameter: 0x43057c0a2680, Registered!
2023-03-22T09:39:48.961Z cpu4:2098196)ScsiDevice: 5745: Successfully registered device "t10.NVMe____INTEL_SSDPE21D280GA_____________________PHM2736400AU280AGN__00000001" from plugin "NMP" of type 0

/var/log/vmkwarning.log
Code: 
2023-03-22T09:39:48.960Z cpu6:2098196)WARNING: NvmeScsi: 148: SCSI opcode 0x1a (0x459a425fd300) on path vmhba7:C0:T0:L0 to namespace t10.NVMe____INTEL_SSDPE21D280GA_____________________PHM2736400AU280AGN__00000001 failed with NVMe error

Irgendwelche Ideen? Muss ich im BIOS irgendwas einstellen? Normalerweise hätte ich jetzt ESXi für den Schuldigen gehalten und aktualisiert, aber die Optane lief ja vorher mit genau diesem Softwarestand.
 
Man könnte noch folgendes versuchen:

passthrough deaktivieren, reboot
passthrough erneut aktivieren, reboot

oder
- ssh to ESXi
- edit /etc/vmware/passthru.map
- add following lines at the end of the file:
(Adresse überprüfen, in dem Menü in dem man passthrough aktiviert)

# Intel Optane 900P
8086 2700 d3d0 false

- restart hypervisor

Wenns nicht hilft, würde ich es als Anlass für ein Update auf ESXi 8 nehmen.
Im Bios kann man nichts einstellen außer dass iommu/vt-d aktiviert sein muss.
 
Die reboot Idee klang gut, hat aber leider nicht geholfen.
Den Eintrag in der passthru.map hatte ich schon von früher drin. vendor und device id passen auch immer noch (wäre seltsam wenn nicht).

Ich versuch mich dann mal an einem ESXi Update. Leider kann ich dann meine ConnectX-3 nicht mehr verwenden. Gibts ein billigen ESXi 8 fähigen Ersatz?
 
Man könnte noch eine Neuinstallation von ESXi 7 versuchen (keine Ahnung ob das was ändert)
oder die Optane unter ESXi als lokalen Datastore einbinden und als vdisk nutzen. Performance sollte fast gleich sein.
 
Moin zusammen,

ich habe einen ESXi Community server mit Version 7.0.3k. Ich habe gestern Updates eingespielt und die Dateispeicher mit einer 9560-8i neu organisiert.

Dabei hat mir der ESXi 5 VMs zerschossen, die vmdks hatten alle statt 111GB im VM Manager nur 16GB und keine weiteren informationen.

Nun habe ich halt einen SambaServer schnell neu aufgesetzt und wollte nun meine 1TB SATA durchreichen.
Code: 
 vmkfstools -z /vmfs/devices/disks/t10.ATA_____Samsung_SSD_860_EVO_1TB_________________S4X6NE0MB04946L_____ "/vmfs/volumes/641e02eb-ffe6e81
a-b0fb-001b21590519/ESCSamba1/Data.vmdk"

Anhang anzeigen 869578

Aber wenn ich eine vohandene Disk zur VM zufügen will erzählt mir das System, die Platte hätte 16GB und alle anderen Informationen sind leer und auch nichts wählbar.
Anhang anzeigen 869579

Update : Ich habe grad spaßeshalber mal die Platte einer funktionierenden VM als 2. zufügen wollen (natürlich war die VM abgeschaltet) -- gleiches Problem :(

Hilfe...!? :(
 
Zuletzt bearbeitet:

ESXi 8.0 unable to add hard disk to VM | ESXi

Hello!I am unable to add an existing vmdk to a VM, the same vmdk worked fine in ESXi 7.0.. I can create a new VM with a new disk, I just can't add an existing
communities.vmware.com

Da gehts zwar um ESXi 8 aber gleiches Phänomen, scheint ein Bug zu sein

Edit : Jupp, isn Bug im Frontend. Workaround mit manipulation der VMX funktioniert
 
Zuletzt bearbeitet:
Hallo zusammen,
ich habe gerade ESXi 8 auf einer neuen SSD installiert und eine gesicherte Konfiguration eingespielt (gleicher Host, auch ESXi 8, nur andere SSD). Nun mag ESXi nicht booten, sondern meldet eine security violation an. Soweit ich das verstehe hat das mit der config-Verschlüsselung zu tun.
Muss man wirlich immer den Recovery-Key händisch als Boot-Option per Hand eingeben? Das finde ich ein bisschen lästig. Kann man das umgehen? Ich habe bisher bzgl. Sicherung der Einstellungen noch nirgends gelesen, dass man noch Keys sichern muss.

Edit: Jetzt bootet auch die alte SSD nicht mehr. Gleiche Meldung "Unable to restore the system configuration. A system violation was detected"
Insbesondere weil ich jetzt den Key nicht mehr auslesen kann.
Kann man dieses Sicherheitsfeature abschalten?
 
Zuletzt bearbeitet:
Die beiden Artikel hatte ich schon gelesen (und hoffentlich auch grob verstanden).

Zum ersten Link: Die TPM- und secure boot Optionen fallen m.E. als Ursache raus. Ich habe nichts im BIOS verändert.
"execInstalledOnly=TRUE" könnte ich nochmal probieren. Aber da ja auch die Original-Installation nicht mehr läuft, kann ich mir nicht vorstellen dass das hilft. Zumindest dort sollte der Wert ja unverändert sein.
Oder anders herum: Wenn man damit die Sicherheitsprüfung umgehen könnte, ergäbe das Konstrukt insgesamt keinen Sinn.

Der zweite Link beschreibt wie man den Recovery Key sichert. Leider zu spät...

Mit meinem laienhaften Wissen stelle ich es mir derzeit so vor:
ESXi speichert seinen Schlüssel im TPM. Die Neuinstallation hat den nun überschrieben, wodurch die alte Installation nicht mehr lauffähig ist. Ebenso eine wiederhergestellte Konfiguration dieser auf einer Neuinstallation.

Alternativ könnte es noch an der geänderten Hardware liegen (vorher SSD x, nun SSD x+y). Ich teste es vielleicht nochmal mit Ausbau der zweiten y. Ich glaube aber nicht dass das was bringt.

Notfalls richte ich es halt wieder neu per Hand ein. Aber ich würde es gern verstehen. Das mit dem Recovery Key war mir neu (hatte bislang noch 6.5).
 
Probiere doch einfach einmal ein Update über Iso einzuspielen. Direkt auf die neue SSD. Nur mal so als Versuch, ich kann mir nicht vorstellen das wirklich ein Problem am ESXI selbst (Software) ist, sondern irgendwas am Board(einstellung sich verschluckt was auch immer). Die alte SSD mit unveränderter Installation hätte booten müssen.
 
Geht bei beiden SSD's nicht.
Was mir gerade noch einfällt: Als ich per SSH die backup-config eingespielt habe, hat der Host direkt neu gebootet (als ob ich einen hard reset gemacht hätte). Ich dachte nur "eine Nachfrage wäre nett gewesen". Mitterweile interpetiere ich das eher als Absturz oder ist das Verhalten normal?

Immerhin die Neuinstallation läuft. Ist es normal, dass der Teil "activating: config-encryption-early" über anderthalb Minuten dauert? (Das war bei mir mit V8 aber schon immer so).
 

Anhänge

  • upgrade.jpg
    upgrade.jpg
    103 KB · Aufrufe: 80
Zuletzt bearbeitet:
dstockm schrieb:
Geht bei beiden SSD's nicht.
Was mir gerade noch einfällt: Als ich per SSH die backup-config eingespielt habe, hat der Host direkt neu gebootet (als ob ich einen hard reset gemacht hätte). Ich dachte nur "eine Nachfrage wäre nett gewesen". Mitterweile interpetiere ich das eher als Absturz oder ist das Verhalten normal?

Immerhin die Neuinstallation läuft. Ist es normal, dass der Teil "activating: config-encryption-early" über anderthalb Minuten dauert? (Das war bei mir mit V8 aber schon immer so).
Zum Vergrößern anklicken....
Sofortiger "Absturz" nach Einspielen des Backups ist normal. ESXI Version der Sicherung und der aktuellen Installation ist exakt 1:1 dasselbe?
 
Ja, sogar gleiches Installationsmedium (ich habe erst vor ein paar Tagen V8 erstmalig installiert).
Ich habe die neue SSD jetzt neu installiert. So ist das dann bei mir voreingestellt:
esxcli system settings encryption get
Mode: TPM
Require Executables Only From Installed VIBs: false
Require Secure Boot: false

Ich habe jetzt mal testhalber das TPM im BIOS deaktiviert. Nun kommt bei der Neuinstallation wieder der PSOD. Es hat also mit dem TPM-Modul zu tun.
Dann TPM reaktiviert und zurückgesetzt. Jetzt kann ich beide SSDs noch nicht mal mehr als Bootmedium auswählen.
Mir ist das irgendwie ein bisschen zu sicher...

--------------
Edit:
Ich hake das Thema jetzt ab. Ich sichere mir jetzt den Recovery-Key, aber auszuprobieren ob das danach klappt habe ich jetzt keine Lust mehr.

--------------
Mal was ganz anderes:
Die Neuinstallation legt auf dem freien Speicher der SSD ja einen datastore an. Klemme ich nun die alte SSD mit an, wo noch der alte datastore inkl. der VM's drauf ist, dann wird nur noch dieser datastore gemounted. Den auf der Boot-SSD kann ich nicht mehr einbinden. Es wird auch kein freier Platz zur Erweiterung angeboten. Ich wollte eigentlich eine der VMs auf das Bootmedium verschieben...

--------------
Edit:
Mit dem Recovery-Key der Neuinstallation lässt sich die alte Config nicht reaktivieren. War eigentlich auch klar.
Merke: Wenn Du eine Config einspielst deren Recovery-Key Du nicht hast, ist die Installation kaputt. Da hilft es auch nichts wenn Du die zu Key passende Config gesichert hattest. Die kannst Du dann nicht mehr einspielen.
 
Zuletzt bearbeitet:
Neues update mal wieder (ESXi 8.0c):

VMware ESXi 8.0 Patch History

esxi-patches.v-front.de esxi-patches.v-front.de
Code: 
# Cut and paste these commands into an ESXi shell to update your host with this Imageprofile
# See the Help page for more instructions
#
esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -p ESXi-8.0c-21493926-standard \
-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
esxcli network firewall ruleset set -e false -r httpClient
#
# Reboot to complete the upgrade

Release notes:

What's New​

  • ESXi 8.0c delivers a fix for a licensing issue on vSphere systems with the vSphere Distributed Services Engine feature enabled.
Zum Vergrößern anklicken....
 
also jetzt ich habe doch noch Probleme mit NFS41: beim Booten des ESXi-7.0U3g-20328353 will es die Verbindungen wiederherstellen - aber das klappt nicht, weil die VM mit dieser Freigabe noch nicht gestartet ist/noch nicht fertig mit booten ist.
Also habe ich einerseits das Timeout dafür verlängert:
Code: 
esxcli system settings advanced set -o /NFS41/MountTimeout -i 60
Nur leider werden Werte über 60 Sekunden gar nicht erlaubt, sodass es immer noch nicht klappt. Vor allem klappt es nicht, wenn die VM erst gestartet wird, nachdem diese Verbindung fehlgeschlagen ist, laut Log 🤦‍♂️.

Der vorherige Hinweis, in der boot.cfg die Zeile anpassen zu
Code: 
kernelopt=weaselInstalled jumpstart.disable=restore-nfs-volumes
hat den Erfolg gebracht, dass der NFS Datastore zwar nicht gemountet ist nach dem Boot - aber ich kann ihn per CLI nun auch nicht online bringen...
per `esxcfg-nas --version 4.1 -l` wird er nicht mal mehr angezeigt.
entsprechend bringt `esxcfg-nas --version 4.1 -r` auch keinen Erfolg, es wird nichts gemountet.

Aber: wenn ich sie danach mounten will per CLI, dann klappt das auch nicht:
/bin/localcli storage nfs41 add --hosts=192.168.211.2 --share=/poolx --volume-name=poolx
Errors:
Volume poolx already Exists

Das ist ja ne olle Sache... also müssten sie vorher noch entfernt werden per CLI, kann man ja machen 🤦‍♂️.
vi /etc/rc.local.d/local.sh
dort Zeilen ergänzen:
Code: 
touch /tmp/mountnfs.sh

cat >> /tmp/mountnfs.sh<< EOF
/bin/echo "$(date)" > /tmp/nach_reboot.txt
/bin/sleep 120
/bin/echo "$(date)" >> /tmp/nach_reboot.txt
/bin/echo "nun wird gemountet..." >> /tmp/nach_reboot.txt
/bin/localcli storage nfs41 remove -v poolx
/bin/localcli storage nfs41 add --hosts=192.168.211.2 --share=/poolx --volume-name=poolx
EOF

/bin/chmod +x /tmp/mountnfs.sh

/bin/sh /tmp/mountnfs.sh &
und anschließend /sbin/auto-backup.sh und reboot.
Das ist ja eine ziemliche Verrenkung, klappt aber immerhin 🤷‍♀️
 
Wir hatte hier kürzlich das Thema Soap und ESXi:
Thomas hat dazu ein tolles add-on beigesteuert,

www.hardwareluxx.de

ESX / ESXi - Hilfethread

Gibt es zufällig ein fertige ISO von ESXI 7 mit Treiber für Realtek NIC ? Ich bekomme es nicht hin . Hardware: I3 7100 Gigabyte GA-H110-S2V . Jetzt habe ich eine ISO mit ESXI 6.7 und wollte ein Upgrade/Update auf 7 machen dort sagt er siehe Bild . Was kann ich machen das ich das beheben kann?
www.hardwareluxx.de www.hardwareluxx.de
Ich habe das jetzt in napp-it 23.dev integriert um damit ESXi snaps in ZFS Snaps zu integrieren. Das Timin Problem habe ich mit einer Verzögerung beim Löschen der ESXi Snaps soweit im Griff.

Neues Feature in napp-it 23.dev (Apr 05):
ZFS autosnaps and ZFS replications bei ESXi/NFS Dateisystemen mit ESXi hot memory snaps.

Damit ist es möglich, z.B. täglich Snaps oder Replikationen laufender VMs zu erstellen, diese zu sichern oder wiederherzustellen um anschließen auf einen sicheren online Stand der VM zum Backupzeitpunkt zurückzugehen. Man muss dazu die VM aus dem Snap wiederherstellen und ein vim-cmd vmsvc/reload vmid (Putty oder ssh) ausführen, VMs neu starten und auf den ESXi snap zurückgehen. Nur mit ZFS Snaps allein besteht immer die Gefahr dass eine VM die zum Zeitpunkt eines Snaps an war korrupt ist.

siehe

napp-it ZFS server on OmniOS/Solaris: news, tips and tricks

How to duplicate a ZFS pool with ongoing replications? New pool should be exact identical to old pool but for ex. larger or with a different vdev structure You must care of the following: 1. Transfer ZFS filesystems with a "recursive" job setting This includes all datasets in the transfer...
forums.servethehome.com forums.servethehome.com
 
Zuletzt bearbeitet:
Update:
Ich habe den bisherigen SSH Mechanismus um ESXi snaps (mit memstate oder quiesce) in ZFS Snaps zu integrieren so umgestellt dass er gleich funktioniert wie der soap Mechanismus. Man muss für SSH halt Keys erzeugen und den Public Key auf ESXi eintragen. Man hat damit aber remote Zugriff auf alle esxcli und vim-cmd Konsole Befehle.

zfs_esxi_snaps.png
 
Hi, hatte zwar schon einen eigenen Post erstellt aber leider konnte mir keiner Antworten dahher nochmal hier die Frage nach der 12th und 13th Intel Generation in Verbindung mit ESXI zum Thema P/E Cores. Hat da einer was gehört? Was ich so lese gibt es einige die die E Cores abschalten... Dann brauche ich mir aber keine CPU holen die E Cores hat. Ich finde im Netz aber auch nix neues diesbezüglich.
 
@kmxak

Ich hatte mal im vmware Forum nachgefragt. Allerdings ging es dabei um die Desktopprodukte. Aber das Problem wird bei vSphere ähnlich gelagert, wenn nicht noch verschärfend sein.

Erfahrungen mit P und E Kern CPU - VMware-Forum

Hi Im Moment habe ich einen 6 Core Haswell-E Desktop, sowie ein 6 Core Broadwell ESXi Server mit 128GB. Dazu das brutale Netzwerk mit jenen Strippen, Firewall,…
vmware-forum.de

Ich würde da eher zu einer Server CPU/Plattform greifen. Auch wegen Themen wie VT-d bzw. IOMMU bist Du da besser aufgestellt.
 
Interessantes neues Update für ESXi 8:

Übersicht: https://esxi-patches.v-front.de/
2023-04-18 (Update 1)

Imageprofile ESXi-8.0U1-21495797-standard (Build 21495797) includes the following updated VIBs:
Zum Vergrößern anklicken....

Release notes: https://docs.vmware.com/en/VMware-v...ex.html#esxi-8-0u1-21495797-standard-resolved

Install:
Code: 
# Cut and paste these commands into an ESXi shell to update your host with this Imageprofile
# See the Help page for more instructions
#
esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -p ESXi-8.0U1-21495797-standard \
-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
esxcli network firewall ruleset set -e false -r httpClient
#
# Reboot to complete the upgrade
 
Zuletzt bearbeitet:
asche77 schrieb:
Interessantes neues Update für ESXi 8
Zum Vergrößern anklicken....

Hat es schon wer installiert? Mir ist irgendwie ein vmkernel nicht mehr erreichbar. Weder per SSH, noch auf den Hostclient, bzw. VMRC über die vmware Workstation. Pingen lässt sich der Host aber.

Nach Update Host nicht mehr erreichbar - VMware-Forum

Hi Ich habe heute das neue ESXi-8.0U1-21495797-standard per ISO geupdatet. Vorher war die letzte 8.0.0 drauf. Auf dem Host hat es 2 vmkernel Ports. Nun ist der…
vmware-forum.de
 
Ja: Hab meine beiden Server aktualisiert. Beide erreichbar. Hab aber nur jeweils 1 vmkernel Port.
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh