ESX / ESXi - Hilfethread

Den Fehler [Errno 28] No space left on device hatte ich unter 6.7 auch regelmäßig. Hab es als sehr nervig in Erinnerung.
Mal in die Logs geschaut, ob hier infos hervorgehen?
Ja, in den Logs steht:
[OSError]
[Errno 28] No space left on device

Das war's. :rolleyes2:
Keine weiteren Angaben, ob und welche Paket erfolgreich waren und / oder fehlgeschlagen sind, um diese manuell zu installieren.
Hatte unter /var/log/esxcli nachgesehen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
@Gen8 Runner
Ich kann mit deiner Volumes-Auflistung nichts anfangen, weil ich die Partitionierung in Abhängigkeit zur Bootmedium-Grösse nicht im Kopf habe. Ich komme wegen ZFS aus dem VMware-Forum und habe dieses Platzproblem wie folgt gelöst:

Navigator > Host > Manage > System > Swap > Edit Settings >

Enable - Yes

Datastore - "chose your ssd"

Local swap - Enabled - Yes

Host Cache Enabled -Yes


Wegen der Platzmeldung wird meines Wissens überhaupt nichts aktualisiert, weil dadurch etwaige Abhängigkeiten einen erfolgreichen Reboot verhindern könnten sprich Komplett-Update entweder ganz oder garnicht oder man hat die Updates einzeln aufgerufen. Mein 6.5er ESXi startet immer noch vom selben 4GB-Stick wie zuvor der 5.5er und den 6.5er habe ich per Direktupgrade aktualisiert. Damit habe ich in meinen Augen auch die den 6.5er jetzt einschränkende Partitionierung vom 5.5er übernommen.
 
VMFS-6 551.2G 1.7G 549.6G 0% /vmfs/volumes/datastore1

Das ist eine eigenständige SAS Festplatte, welche ESXI bei der Installation vollständig zur Verfügung gestellt wurde. Also hat ESXI theoretisch noch 549,6GB an Speicher frei.

Deine SWAP-Einstellungen hatte ich auch schon in jeglicher Kombination versucht, ohne Erfolg.
Wenn ich einzeln die Patches für das neue Update installieren möchte, kommt immer nur der Abhängigkeiten-Fehler (Dependency Error). :rolleyes2:

Bin echt ratlos, wie ich das nun noch lösen kann.
Gibt es die Möglichkeit das Profile-Update Schritt für Schritt durchzugehen? Bei Google finde ich da nicht sonderlich viel von.
Notfalls: Backup, platt machen, einmal neu und Update.
 
Okay, dann könnte noch eine der beiden Bootbank ein Problem haben. Ich befürchte viel mehr Möglichkeiten dürfte es nicht geben, leider.



Laß dir mal den Inhalt/Bestandteile des Updates anzeigen.
esxcli software profile update --depot=<depot_location> --profile=<profile_name>

Wichtig: dies ist die einzige Update-Methode, die VMware für die von VMware gelieferten ZIP-Pakete bereitstellt.
Die Namen der von VMware bereitgestellten ZIP-Pakete haben folgendes Format: VMware-ESXi-<version_number>-<build_number>-depot.zip.

Der Profilname für die von VMware bereitgestellten ZIP-Pakete hat folgendes Format.

  • ESXi-<version_number>-<build_number>-standard
  • ESXi-<version_number>-<build_number>-notools (umfasst nicht die VMware Tools)
 
Zuletzt bearbeitet:
Bin echt ratlos, wie ich das nun noch lösen kann.
Ich habe/hatte damit (wie viele andere) auch zu kämpfen; keine schöne Lösung gefunden. swap einschalten in ESXi hat leider nicht geholfen.

Gibt es die Möglichkeit das Profile-Update Schritt für Schritt durchzugehen? Bei Google finde ich da nicht sonderlich viel von.
JA, die Möglichkeit gibt es:

Du kannst die VIBs einzeln (oder in eiemm Rutsch) mit "esxcli software vib update -v [link-zu-vib]" installieren.

So zB aktuelles (2020-11-19) update von ESXi 6.7:
Code:
esxcli network firewall ruleset set -e true -r httpClient
esxcli software vib update -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/esx-base/VMware_bootbank_esx-base_6.7.0-3.132.17167734.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/esx-update/VMware_bootbank_esx-update_6.7.0-3.132.17167734.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/nvme/VMW_bootbank_nvme_1.2.2.28-4vmw.670.3.132.17167734.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vmkusb/VMW_bootbank_vmkusb_0.1-1vmw.670.3.132.17167734.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vmw-ahci/VMW_bootbank_vmw-ahci_2.0.5-2vmw.670.3.132.17167734.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vsan/VMware_bootbank_vsan_6.7.0-3.132.17135222.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vsanhealth/VMware_bootbank_vsanhealth_6.7.0-3.132.17135221.vib
esxcli network firewall ruleset set -e false -r httpClient
 
Ich habe/hatte damit (wie viele andere) auch zu kämpfen; keine schöne Lösung gefunden. swap einschalten in ESXi hat leider nicht geholfen.

JA, die Möglichkeit gibt es:

Du kannst die VIBs einzeln (oder in eiemm Rutsch) mit "esxcli software vib update -v [link-zu-vib]" installieren.

So zB aktuelles (2020-11-19) update von ESXi 6.7:
Code:
esxcli network firewall ruleset set -e true -r httpClient
esxcli software vib update -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/esx-base/VMware_bootbank_esx-base_6.7.0-3.132.17167734.vib -v 
[/QUOTE]
Hatte folgenden Befehl zu Anfang genutzt:
esxcli software vib install -v "/vmfs/volumes/datastore1/updates/VMware_bootbank_esx-base_6.7.0-3.132.17167734.vib" 

Also ähnlich, nur install anstatt update, da kam aber immer der Dependency Fehler und das Update brach ab.
 
Versuch Mal mit "Update" und mehreren vibs gleichzeitig. Glaube, auch da kann es Fehlermeldungen wg Abhängigkeiten geben, aber vermutlich ändert "Install" die vibs im laufenden System und ist daher deutlich zickiger.
 
update und install lassen sich doch als dry-run starten, dann sieht man auch direkt die zu aktualisierenden Pakete.

[add]
wie ich vorhin schon schrieb, probiere doch mal die Updates mit einzelnen Profilen aus.
 
Du kannst die VIBs einzeln (oder in eiemm Rutsch) mit "esxcli software vib update -v [link-zu-vib]" installieren.

So zB aktuelles (2020-11-19) update von ESXi 6.7:
Code:
esxcli network firewall ruleset set -e true -r httpClient
esxcli software vib update -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/esx-base/VMware_bootbank_esx-base_6.7.0-3.132.17167734.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/esx-update/VMware_bootbank_esx-update_6.7.0-3.132.17167734.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/nvme/VMW_bootbank_nvme_1.2.2.28-4vmw.670.3.132.17167734.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vmkusb/VMW_bootbank_vmkusb_0.1-1vmw.670.3.132.17167734.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vmw-ahci/VMW_bootbank_vmw-ahci_2.0.5-2vmw.670.3.132.17167734.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vsan/VMware_bootbank_vsan_6.7.0-3.132.17135222.vib -v https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vsanhealth/VMware_bootbank_vsanhealth_6.7.0-3.132.17135221.vib
esxcli network firewall ruleset set -e false -r httpClient
[DependencyError]
VIB QLogic_bootbank_net-qlcnic_5.3.191-1OEM.500.0.0.472560 requires vmkapi_2_0_0_0, but the requirement cannot be satisfied within the ImageProfile.
VIB QLogic_bootbank_net-qlcnic_5.3.191-1OEM.500.0.0.472560 requires com.vmware.driverAPI-9.2.0.0, but the requirement cannot be satisfied within the ImageProfile.
Please refer to the log file for more details.


@Stangensellerie
Mit Profile Update kommt entweder wieder, dass ein Dependency Error vorliegt bzw., als ganzes Paket, dass nicht mehr genügend Speicher vorhanden sei.
Hatte schon überlegt vmkapi und driverapi manuell zu installieren und dann den Rest drüberzubügeln, aber noch habe ich die Pakete nicht gefunden.
 
Code:
[root@ESXIFujitsu:~] esxcli software sources profile list -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml | grep ESXi-6.7.0-202011040
01


Plan war eigentlich: ESXI wie üblich patchen, mit folgendem Befehl.
[CODE]esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -p ESXi-6.7.0-20201104001-standard \
-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
esxcli network firewall ruleset set -e false -r httpClient

Nachdem das wegen zig Dependency-Errors fehl schlug, wollte ich erstmal ein profile update mit obigstem Befehl durchführen...Ständig kommt aber Error 28, egal ob mit oder ohne VM Tools.
Auslagerung bringt auch keine Lösung (Verwalten -> Auslagerung). Habt ihr noch Ideen? Ich bin mittlerweile ratlos.
Das war wieder mal eine Geburt...Hier die Lösung für die Nachwelt für das diesige Update, Copy & Paste für die Shell:


Code:
cd /tmp

wget http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/esx-base/VMware_bootbank_esx-base_6.7.0-3.132.17167734.vib
esxcli software vib install -f -v /tmp/VMware_bootbank_esx-base_6.7.0-3.132.17167734.vib

wget http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/esx-update/VMware_bootbank_esx-update_6.7.0-3.132.17167734.vib
esxcli software vib install -f -v /tmp/VMware_bootbank_esx-update_6.7.0-3.132.17167734.vib


wget http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/nvme/VMW_bootbank_nvme_1.2.2.28-4vmw.670.3.132.17167734.vib
esxcli software vib install -f -v /tmp/VMW_bootbank_nvme_1.2.2.28-4vmw.670.3.132.17167734.vib


wget http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vmkusb/VMW_bootbank_vmkusb_0.1-1vmw.670.3.132.17167734.vib
esxcli software vib install -f -v /tmp/VMW_bootbank_vmkusb_0.1-1vmw.670.3.132.17167734.vib


wget http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vmw-ahci/VMW_bootbank_vmw-ahci_2.0.5-2vmw.670.3.132.17167734.vib
esxcli software vib install -f -v /tmp/VMW_bootbank_vmw-ahci_2.0.5-2vmw.670.3.132.17167734.vib

wget http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vsan/VMware_bootbank_vsan_6.7.0-3.132.17135222.vib
esxcli software vib install -f -v /tmp/VMware_bootbank_vsan_6.7.0-3.132.17135222.vib


wget http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/esx/vmw/vib20/vsanhealth/VMware_bootbank_vsanhealth_6.7.0-3.132.17135221.vib
esxcli software vib install -f -v /tmp/VMware_bootbank_vsanhealth_6.7.0-3.132.17135221.vib

*.vib herunterladen, auf den ESXI in einen Ordner packen und von dort aus installieren: Unmöglich!
Mit wget zuerst herunterladen und anschließend per obigen Befehlen installieren: Problemlos!

Warum auch immer...Nun ist es endlich durch.
 
Zuletzt bearbeitet:
@Gen8 Runner
Du hast mit "install" statt "update" aktualisiert. Das ändert vieles. Ausgehend von "but the requirement cannot be satisfied within the ImageProfile" hätte mich interessiert, welche Profile im "VIB" enthalten waren. Der Dreizeiler zum Updaten sieht mir nach https://esxi-patches.v-front.de/ESXi-7.0.0.html aus und Andreas wäre bestimmt dankbar über eine Rückmeldung, falls da ein Fehler enthalten sein sollte.
 
@Gen8 Runner
Du hast mit "install" statt "update" aktualisiert. Das ändert vieles. Ausgehend von "but the requirement cannot be satisfied within the ImageProfile" hätte mich interessiert, welche Profile im "VIB" enthalten waren. Der Dreizeiler zum Updaten sieht mir nach https://esxi-patches.v-front.de/ESXi-7.0.0.html aus und Andreas wäre bestimmt dankbar über eine Rückmeldung, falls da ein Fehler enthalten sein sollte.

Schritt 1, den ich versucht hatte:
Code:
esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -p ESXi-6.7.0-20201104001-standard \
-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
esxcli network firewall ruleset set -e false -r httpClient
Ende vom Lied: No space on device.

Schritt 2:
2020-11-19, Imageprofile ESXi-6.7.0-20201104001-standard (Build 17167734)
Von dort die *.vib heruntergeladen und auf den Datastore geladen -> manuelle Installation versucht (egal ob install, update...) -> Dependency error

Schritt 3:
Volles Profile-Update:
Fehlgeschlagen. No Space left on device.

Schritt 4:
Wie in Schritt 2 die Links genutzt, diese aber per wget heruntergeladen und nach obiger Sammlung installiert. Das funktionierte dann problemlos.

Aber:
Wer ist Andreas? Der Betreiber von obiger Seite (esxi-patches)?
Profile im VIB hätte ich dir gerne ausgelesen, aber da bin ich dann doch zu wenig im Thema drin, um (Sattelfest) diese herauszusuchen und mitzuteilen. Sonst sehr gerne! :giggle:
In der Shell bin ich oft überfordert und muss dann zig Jahre googlen, um wieder die (eigentlich altbekannten) Befehle hervorzukramen.
 
Schritt 1, den ich versucht hatte:
Code:
esxcli network firewall ruleset set -e true -r httpClient
esxcli software profile update -p ESXi-6.7.0-20201104001-standard \
-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml
esxcli network firewall ruleset set -e false -r httpClient
Ende vom Lied: No space on device.

Schritt 2:
2020-11-19, Imageprofile ESXi-6.7.0-20201104001-standard (Build 17167734)
Von dort die *.vib heruntergeladen und auf den Datastore geladen -> manuelle Installation versucht (egal ob install, update...) -> Dependency error

Schritt 3:
Volles Profile-Update:
Fehlgeschlagen. No Space left on device.

Schritt 4:
Wie in Schritt 2 die Links genutzt, diese aber per wget heruntergeladen und nach obiger Sammlung installiert. Das funktionierte dann problemlos.

Aber:
Wer ist Andreas? Der Betreiber von obiger Seite (esxi-patches)?
Profile im VIB hätte ich dir gerne ausgelesen, aber da bin ich dann doch zu wenig im Thema drin, um (Sattelfest) diese herauszusuchen und mitzuteilen. Sonst sehr gerne! :giggle:
In der Shell bin ich oft überfordert und muss dann zig Jahre googlen, um wieder die (eigentlich altbekannten) Befehle hervorzukramen.
Booten die ESXi von SD-Karte oder so? Bekomme no Space Meldungen immer dann, wenn der ESXi von ner SD-Karte oder einem USB STick bootet. Mit 7.0 hat sich ja auch nochmal geändert wieviel Speicherplatz benötigt wird.

Wenn ESXi auf ner 120er SSD etc. installiert flutscht es einfach durch.


Hab grad gelesen, dass es eine SAS Platte ist... hmm strange.
 
Tach auch,

steige gerade wieder in die ESXi-Welt ein. Hab einen neuen Homeserver zusammengebastelt und zunächst zwei Fragen / Probleme.

1. Würde gerne Passthrough für die SATA-Controller vom x570-Chipsatz aktivieren. Auf dem Mainboard sind vier Controller aktiv (alle vom/im Chipsatz). Bei zweien konnte ich Passthrough aktivieren, bei zweien steht "Aktiviert / Erfordert Neustart". Hostneustart ändert diesen Status aber bei zweien von den vier Controllern nicht auf "Aktiv". Was könnte das Problem sein? Ich hab keinerlei SATA-Devices angeschlossen. ESXi bootet aktuell vom USB Stick und es steckt noch ne M.2-PCIe-SSD auf dem Board (direkt an der CPU).

1606499959826.png


2. Ich wollte eigentlich zunächst von USB den ESXi booten und auf einer kleinen USB-SATA-SSD ein VMFS einrichten, um da TrueNAS drauf zu parken. Leider erkennt ESXi die USB-Platte nicht. Was kann ich da tun?

Es ist eine alte 128GB OCZ Vertex 3 SSD. Diese steckt an einem Sabrent USB-SATA Kabel. Das UEFI erkennt diesen Speicher ohne Problem. Ich kann auch Windows drauf installieren und booten. Nur ESXi listet die Platte nicht auf, wenn ich einen neuen Datenspeicher hinzufügen will. Die Vertex 3 wurde mit diskpart clean von jeglicher Dateisystemstruktur befreit.

Danke für eure Hilfe.
 
Zuletzt bearbeitet:
@chicken
Ausgehend von https://communities.vmware.com/t5/E...er-not-working-on-ESXi-7-AMD-x570/m-p/2285366 wird das eher nix werden oder nur mit Gebastel. Welche CPU wurde verbaut, ich frage wegen der obersten Bildzeile mit Renoir. Das sollten die Deskop-APUs sprich mit GPU sein. Für grundlegende Dinge braucht es bei AMD-CPUs keinen Chipsatz, weil die CPU bereits viel Funktionalität mitbringt. Die Adressen mit Passtrough-Aktiv deuten für mich darauf hin, daß sich nur die 2 zusätzlichen Controller im Chipsatz durchreichen lassen und die in der CPU dauerhaft auf "Aktiv/Neustart" verbleiben. Mangels x570 kann ich das nicht selber probieren.

Ein VMFS-Datastore auf USB wird von VMware nicht supportet und erfordert meines Wissens daher in jedem Fall Handarbeit.
 
Seit der Neuinstallation meines VSphere7.0U1 (VMware-VMvisor-Installer-7.0U1-16850804.x86_64.iso) habe ich ein merkwürdiges Verhalten einiger VMs festgestellt.
Es ist es so das all meine VMs zwar normal starten, sie auch per SSH Login normal wie zu erwarten zu erreichen sind. Die openVMWare-Tools werden auch als Guest managed wenn ich ins VCenter schaue angezeigt.
Die Konsole hatte vor der ESXI neuinstallation bisher problemlos funktioniert.
Das Passthrough (HBA / Graka) insofern zu einzelnen VMs durchgereicht funktioniert auch problemlos bzw. wird erkannt wenn die VM ein Passthrough gerät zugewiesen hat.

Folgende Probleme bestehen:

- Im ESXI kann man zwar die Konsole öffnen, aber meine Ubuntu VMs nehmen merkwürdiger weise keinerlei Tastatureingaben. Es ist über die Konsole somit kein Login möglich.
Die Konsole zu meinem Solaris, kann ich auch öffnen aber jegliche buchstaben eingabe wird wie folgt dargestellt, Benutzernamen oder Kennwort einzugeben ist somit unmöglich.

1606504144831.png


- Ebenfalls starten die VMs nicht korrekt neu, wenn man per SSH Login ein sudo reboot ausführt. Wenn korrekt hatte man immer den Status in der Konsole gesehen, wie auch den folgenden Boot. Das ist jetzt nicht mehr so.
Beim Herunterfahren per ESXI bleiben die VMs aktiv und bekommen kein PowerOFF.

- Zu meinen Win 10 VMs funktioniert die Konsole Problemlos. Tastatureingaben wie auch Mauseingaben funktionieren hier ohne Probleme.

Eigentlich sollte die ESXI VM konsole immer funktionieren, tut sie aber leider nicht???
Ebenfalls scheint es egal wo die VMs liegen, ob auf der direkten SSD oder auf dem VM Mount oder auch neu erstellt. Selbst wenn ich eine neue VM erstelle, das Ubuntu ISO einhänge, diese starte, kann ich im Installmanager keine Menüauswahl über die Konsole vornehmen.

Ich hatte auch den VSphere ebenfalls erneut installiert, hier stellt sich leider selbige Problematik ein.

Zufällig jemand eine Idee hierzu?
Sonst würde mir nur einfallen ein älteres v7 ISO zur ESXI Install zu testen, dann zu patchen.
 
Zuletzt bearbeitet:
@chicken
Ausgehend von https://communities.vmware.com/t5/E...er-not-working-on-ESXi-7-AMD-x570/m-p/2285366 wird das eher nix werden oder nur mit Gebastel. Welche CPU wurde verbaut, ich frage wegen der obersten Bildzeile mit Renoir. Das sollten die Deskop-APUs sprich mit GPU sein. Für grundlegende Dinge braucht es bei AMD-CPUs keinen Chipsatz, weil die CPU bereits viel Funktionalität mitbringt. Die Adressen mit Passtrough-Aktiv deuten für mich darauf hin, daß sich nur die 2 zusätzlichen Controller im Chipsatz durchreichen lassen und die in der CPU dauerhaft auf "Aktiv/Neustart" verbleiben. Mangels x570 kann ich das nicht selber probieren.

Ein VMFS-Datastore auf USB wird von VMware nicht supportet und erfordert meines Wissens daher in jedem Fall Handarbeit.

Es ist eine 4750G Pro - zumindest bis Zen3 zu vernünftigen Preisen verfügbar ist. Ja, die CPU kann ganz schön viel, aber laut Handbuch Seite 14 (Blockdiagramm) sind alle Onboard-SATA-Ports sowie alle Onboard-USB-Ports am x570 angeschlossen, somit sollten keine Controller von der CPU belegt sein. Der x570 hängt über PCIe4.0 an der CPU. Kann natürlich sein, dass ASRock das nicht richtig dokumentiert hat. Und ich weiß auch nicht, inwiefern man diese Controller per BIOS-Settings adressieren, zuweisen, sonstige Dinge damit tun kann.

Das mit dem VMFS-Datastore über USB war mir neu. Mir war so als wäre das früher einfacher gewesen. Danke. Dann besorg ich mir nen M.2 zu SATA-Adapter und häng die Platte so an.

Edit: Hab jetzt aber grad ein anderes Problem. Das Mainboard bootet, beept 5x, geht sofort ins Bios und friert dann auf der Hauptseite ein....
Edit2: Geht wieder nachdem ich die Knopfzelle gezogen hab....
 
Zuletzt bearbeitet:
Die Deutsche Tastatur gilt dann aber nur direkt auf der DCUI sprich direkt am ESXi-Host. Damit kommt man zumindest unter 6.5 nicht in die Gast-Console.

[edit]
"sudo reboot" triggert meines Wissens nach nicht einen VM-Shutdown an oder nur wenn die VMs auch per Auto-Start/Stopp konfiguriert sind.
 
Das Tastaturlayout habe ich auch auf Deutsch gestellt so hatte es zuvor immer funktioniert. So richtig wird mir kein Schuh daraus, warum es auch bei einer neuen VM nicht funzt.
Es sieht so aus als funktioniert ca 6 Zeichen die Eingabe direkt nach dem Start der VM. Danach geht nix mehr in der Konsole. SSH funktioniert solang kein reboot darin ausgeführt wird, sonst erst wieder nach VM PowerOFF / ON. Firefox wie auch Chrome zeigen das gleiche Verhalten.

1606510407297.png




[edit]
"sudo reboot" triggert meines Wissens nach nicht einen VM-Shutdown an oder nur wenn die VMs auch per Auto-Start/Stopp konfiguriert sind.

Sorry hatte es vorhin auf die schnelle zusammengeschrieben. Natürlich triggert es einen Reboot. Aber den sehe ich nicht wie es sein sollte in der Konsole, also den folgenden init bzw. Loginprompt.
 
Zuletzt bearbeitet:
Installiert ist:
ESXi-Version: 7.0.1
ESXi-Build-Nummer: 17168206
Lizenz: Free

Hab ein Board mit x550 Dual 10G-Nic.
SR-IOV lässt sich aktivieren, d.h. ich kann jeden der zwei Adapter in nochmal bis zu 63 weitere NICs aufteilen.
Eine oder mehrere dieser virtualisierten single root NICs kann ich dann einer VM zuordnen und speichere die Einstellungen der VM ab. Keine Fehlermeldung.
Starte ich die VM, kommt diese Fehlermeldung:

1608088515027.png


Für die Suchmaschine:
Fehler beim Einschalten der virtuellen Maschine Napp-IT1. Aufgrund einer Lizenzbeschränkung kann dieser Vorgang nicht ausgeführt werden. Entweder die Lizenzedition des ESXi-Hosts unterstützt diesen Vorgang nicht, oder das vCenter Server-System, das den Host verwaltet, verfügt über eine Lizenz, die diesen Vorgang über eine Direktverbindung mit diesem Host beschränkt. Überprüfen Sie die lizenzierten Funktionen für den Host oder stellen Sie eine Verbindung mit vCenter Server her und wiederholen Sie den Vorgang. Klicken Sie hier, um weitere Informationen zu erhalten.

Ich habe bisher noch nie was davon gelesen, dass SR-IOV nicht funktioniert mit der Free Version. Konnte auch gerade bei einer Suche nichts finden.
Ist das tatsächlich ein feature cut der nirgends beschrieben steht oder liegt das Problem wo anders?

Da es der einzige Adapter ist mit SR-IOV-support in meinem System kann ich es mit anderen nicht testen.

Passthrough des ganzen Adapters ist kein Problem. Mach ich schon mit dem LSI3008 HBA oder andere NICs.


Edit: Hab mal das Userinterface auf englisch gestellt und nach der englischen Fehlermeldung gesucht. Hat geholfen:


Demnach ist SR-IOV erst ab der Enterprise Plus Lizenz möglich. Grmpf....

Doch besser auf Proxmox wechseln?
Beitrag automatisch zusammengeführt:

OK andere Frage...

Im Internet gibts ja genug Key-Reseller und gebrauchte Lizenzen kaufen ist ja jetzt nichts verbotenes.
Wenn ich mir von dort VMware-Lizenzen kaufe, kann ich die irgendwie auf Echtheit prüfen? Nicht, dass die aus dem Keygen fallen, denn solche Keys gibts günstiger...
 
Zuletzt bearbeitet:
Ausgehend von https://www.vmware.com/content/dam/...vsphere/vmware-vsphere-pricing-whitepaper.pdf Seite 6 ist SR-IOV wirklich erst ab E+ enthalten. Das man bei VMware mit der deutschen, den Sinn entstellenden 1:1-Übersetzung der Oberfläche nicht weiterkommt, ist ja nix neues und war hatte vom alten Windows-Client bekannt.


Bezüglich der Key-Reseller kannst man sich die Frage selbst beantworten. Dazu schaut man sich https://www.vmware.com/de/reusable_content/vsphere_pricing.html an und deutlich billiger wird es auch bei offiziellen Händlern nicht. Neben der Lizenz wird in jedem Fall 1 Jahr SnS fällig. Einzigste Ausnahme hinsichtlich SnS ist das kleine Essentials-Kit, bei dem nur eine verringerte Service-Gebühr und für jeden Fall einzeln bezahlt wird.
 
Der einzigste Nachteil der EvalExperience ist, daß die Keys wirklich nur für ein Jahr gelten. Man muß also jedes Jahr einen neuen Key eingeben. In diesem Jahr kam es bei der Verlängerung zu Schwierigkeiten, weil die neuen Keys nicht rechtzeitig im Account bereit standen.
 
Bezüglich der Key-Reseller kannst man sich die Frage selbst beantworten. Dazu schaut man sich https://www.vmware.com/de/reusable_content/vsphere_pricing.html an und deutlich billiger wird es auch bei offiziellen Händlern nicht. Neben der Lizenz wird in jedem Fall 1 Jahr SnS fällig. Einzigste Ausnahme hinsichtlich SnS ist das kleine Essentials-Kit, bei dem nur eine verringerte Service-Gebühr und für jeden Fall einzeln bezahlt wird.

Was sind denn offizielle Resesseller und was sind inoffizielle? Als Keyreseller braucht man ja nicht den Segen vom Softwarehersteller, sondern das kann ja jeder Händler sein, der gebrauchte Lizenzen kauft/verkauft?

Und wieso muss ich bei ner gebrauchten Lizenz nochmal 1 Jahr Support buchen? Dachte das sind Lifetimelizenzen bei VMWare, die aber halt nach einem Jahr kein Update mehr zulassen (gilt das für jede Art von Update oder nur für Funktionsupdates?)

@chicken
Wie wäre es damit ?

Ist legal und alles dabei inkl vCenter und noch mehr.

Ja davon hab ich hier im Forum schon gelesen. Danke nochmal für den Hinweis. 200USD ist auch nicht ganz aus der Welt beim aktuellen Wechselkurs.
 
Zuletzt bearbeitet:
So grob habe ich den Unterschied zwischen VMXNET und SRV-IOV bei einer NIC ja verstanden. Direkter Zugriff auf Kosten der Snapshots. Was wäre denn ein typischer Anwendungsfall? Chicken versucht es bei Napp-IT, ist der Vorteil so groß?
 
@chicken
Offizielle Reseller sind für mich Systemhäuser wie Takenet und inoffizelle unter anderem die Bauernfänger in der Bucht.

Die EvalExperience hat/hatte einen weiteren Nachteil, falls man Support bei VMware braucht und per Incedent bezahlen will/wollte. Das geht/ging bisher nicht und auch hinsichtlich der Nutzung abseits des privaten Raums gab es meines Wissens einige Besonderheiten.


@wenzilinho
Das frage ich mich auch gerade. SR-IOV macht in meinen Augen nur Sinn, wenn man wirklich viel Netzwerkverkehr hat und sich eine Verringerung der Last auf der Host-CPU durch Umgehen des VMKernel bei gleichzeitiger Latenzverringerung auszahlen würde oder durch eine hohe Konsolidierungsrate eh schon viel Grundlast anliegt.
 
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