ESX / ESXi - Hilfethread

Wie verhält sich das bei den CPU Cores?

Mit der CPU ist es nicht ganz so extrem, da sich die VMs die CPU Leistung noch nicht bunkern können, aber auch hier gilt, man sollte es nicht übertreiben. Du kannst hier also problemlos mehr vCPUs an die VMs verteilen als es physikalisch gibt (ist ja schließlich auch der Sinn der Virtualisierung) Was du aber tunlichst vermeiden solltest, währe einer VM mehr vCores zu geben als physikalisch vorhanden sind, sonst geht die Leistung auch hier in den Keller.

Generell ist es bei den CPUs so, dass die VMs die meiste Zeit nicht die volle CPU Leistung benötigen und du daher in den meisten Fällen die physikalische CPU nicht voll auslastest. Wenn die VMs dann doch mal die CPU voll auslasten, dann werden auch hier die CPU Ressourcen geshared, sprich deine VMs bekommen nur noch teilweise ihre Leistung. Damit wichtige VMs auch immer eine bestimmte Mindestleistung erreichen, bietet es sich hier ggf. an, mit CPU Reservierungen zu arbeiten.

In meiner Umgebung teilen sich z.B problemlos 30VMs nen Six Core Xeon mit HT und die CPU hat die meiste Zeit nicht wirklcih viel zu tun.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Danke für die Infos.
In meinem Fall teilen sich 2 VMs einen 8 Core Xeon mit HT...dem Exchange habe ich alle gegeben, dem Datev lediglich 2 Kerne. Muss reichen :)
 
richtig CPUs sind unkritisch, weil die VMs keine Leistung "reservieren"... Denn entgegen dem RAM Verbrauch geht die CPU Last immer! gen Null, wenn keine Leistung benötigt wird. Beim RAM ist dies aber eben nicht der Fall, da das OS cleverer Weise ungenutzten RAM für Dinge wie den Diskcache nutzt.

Auch ist die CPU unter dem Gesichtspunkt eher wenig ausschlaggebend, dass man idR keine VMs auf den Host betreibt, die extreme CPU Leistungsanforderungen haben. Sprich Dauervolllast auf vielen vielen Cores. -> das ist nicht der typische Virtualisierungsfall. Man hat also dort idR mehr als genügend Reserve.
 
Widerspricht das alles nicht dem Konzept des Balloon-Treibers, der genau dazu da ist, dass der Host dem Gast sagen kann, dass er seinen Filecache freigeben soll?
 
Widerspricht das alles nicht dem Konzept des Balloon-Treibers, der genau dazu da ist, dass der Host dem Gast sagen kann, dass er seinen Filecache freigeben soll?

Nicht ganz ;)
Denn der Balloning Treiber fragt beim Gast OS an, welchen Speicher er bekommen darf. Das Gast OS entscheidet somit immernoch, was freigebbar ist und was nicht. Es muss also nicht zwingend der Filecache sein.
Beim dem Thema Filecache bei Microsoft kommt beispielsweise noch hinzu, das es dort ggf. intern in der VM schon zu Konflikten kommen kann. Speziell wenn man Serverdienste betreibt, die selbst viel RAM verpulvern, aber gleichsam viel Schreib/Lesearbeit auf der HDD ausführen (DBs, Exchange usw.) Da gibts im übrigen auch KB Artikel zu Themen, wo sich Anwendungsverbrauch und Filecacheverbrauch im RAM gegenseitig behindern.
Ohne oder mit wenig Filecache geht die Storageperformance beim Randomzugriff auf häufig gleiche Bereiche in den Keller. -> das tut der Sache also nicht unbedingt gut ;)

Unterm Strich ist das aber auch alles mehr oder weniger egal. Denn es ist ja sogar schon rein logisch so, das zu wenig RAM im Host bei zu viel angeforderten RAM schon langsam sein muss. Der Host kann nicht zaubern. Es gibt nun im ESX mehrstufige Mittel, die Performance möglichst effizient und lange hochzuhalten.
Richtig gut funktionieren tut das Balloningkonzept aber nur, wenn man A) viele VMs betreibt, die auch mit Reserve betrieben werden (RAM) und B) das Storage genügend Bumms hat, um die mehr Arbeit durch weniger Caching und weniger RAM bei den Servicen zu kompensieren.

Die Empfehlung den RAM möglichst nicht! zu überbuchen bleibt also weiterhin die beste.
 
Damit wiedersprichst du dir selbst ;)
Entweder man überbucht... Oder man hat Reserven. Hat man Reserven, überbucht man schlicht nicht.

Na dann zähl mal den RAM der ganzen Maschinen zusammen und vergleiche das mit dem tatsächlichen Verbrauch des Hosts.

Und was willst du hier mit DRS? Mit DRS in einem Cluster ändert sich am Verhalten absolut gar nichts. Es gibt dann halt mindestens zwei Hosts. Der physische RAM wird addiert. Das Verhalten bleibt identisch.

DRS verhindert schlichtweg das ein Host zu stark ausgelastet wird weil sich der Ressourcen Verbrauch auf alle Hosts gleichmäßig verteilt.
 
Na dann zähl mal den RAM der ganzen Maschinen zusammen und vergleiche das mit dem tatsächlichen Verbrauch des Hosts.
Und was bringt das?
Der RAM aller VMs, die vom gesamten DRS Cluster benötigt werden ist die Summe des RAM Verbrauchs aller Hosts im DRS Cluster. -> logisch oder?
Wie in meinem Screen oben ist zu sehen, das die VMs sich quasi immer den zugeteilten RAM auch physisch am Host belegen. Die Werte zusammengezählt entsprechend dabei exakt dem, was der Host an Gesamtverbrauch benötigt, addiert mit dem, was der Host für sich selbst noch reserviert (~1GB)
Daran gibt es nichts zu diskutieren... Das ist schlicht Fakt.

DRS verhindert schlichtweg das ein Host zu stark ausgelastet wird weil sich der Ressourcen Verbrauch auf alle Hosts gleichmäßig verteilt.

Das ist zwar grundsätzlich nicht falsch, spielt hier aber keine Rolle... Zu deiner Erinnerung, du hast gesagt, der RAM wird überbucht! Somit besteht schlicht keine Reserve im DRS Cluster. Alle im Cluster gebundenen Hosts laufen RAM technisch mit Überbuchung. DRS bietet zwar die Möglichkeit, dynamisch nach Auslastung im Cluster die Last "optimal" auf alle im DRS Cluster erhaltenen Hosts zu verlagern. Es ändert aber nichts an der Tatsache, das DRS nicht zusätzlichen RAM hinzuzaubern kann.
Auf welchem Host schlussendlich balloont oder geswappt wird, ist vollkommen egal. -> die Performance geht je nach Grad der Überbuchung massiv in den Keller.

Als Beispiel:
1x 64GB RAM im Single Host vs. 2x 32GB RAM im DRS Cluster.
Überbuchst du nun den gesamten RAM mit sagen wir VM seitig angeforderten 80GB, wird der Single Host genau so den Balloningwert/Swapwert hochjagen wie auch die beiden Nodes im DRS Cluster. Absolut gesehen bei funktionierendem DRS hast du bestenfalls noch ~8/~8GB pro DRS Clustermember, wärend der Singlehost allein die 16GB swappt/balloont. Am Verhältnis und somit am Speedeinbruch ändert sich nahezu gar nix. Denn zwei mal 8GB von zwei mal 32GB sind das Selbe Verhältnis wie einmal 16GB von einmal 32GB.

Ergo -> Verhalten absolut identisch.
Hast du jemals schon vor so einem Cluster gesessen? Geschweige denn sowas überhaupt schonmal betrieben? Deine Ausführungen klingen irgendwie nicht danach :fresse: Denn sie gehen an jeglicher Praxis, ja sogar jeglicher Theorie vorbei.
 
Hast du jemals schon vor so einem Cluster gesessen? Geschweige denn sowas überhaupt schonmal betrieben? Deine Ausführungen klingen irgendwie nicht danach :fresse: Denn sie gehen an jeglicher Praxis, ja sogar jeglicher Theorie vorbei.

Nu werd aber nicht frech nur weil du dich besser in Exchange auskennst! Ich hatte 2x ESX 3.5 Cluster mit ingesamt 8 Nodes auf HP BL460c Blades + Dell 6850 mit EMC/Brocade FC SAN + Netapp Cluster aufgebaut + etliche standalone ESX.

Ich hatte im Anfangspost gesagt das Overcommit möglich ist* und nicht das man es nutzen muss!!

Und overcommit != memory sharing (meine 2 letzten Post bezogen sich auf memory sharing bzw. TPS), fange nicht an das durcheinander zu würfeln.

Wenn du z.B. 30 VMs auf einem Host hast, alle mit gleichem OS und bei jedem ist genau die gleiche DLL geladen dann lädt der Host diese eben nur 1x und nicht 30x. Ich erinnere mich dadurch einiges an Einsparungen gehabt zu haben, dass waren aber insgesamt 100 VMs und max. 2 verschiedene Betriebssysteme (2003,2008) ohne Exchange,SQL (aber Domino). Durch dieses memory sharing war es eben möglich das den VMs mehr zugewiesen war als RAM physikalisch genutzt wurde. Dadurch kann man eben mehr RAM zuweisen als man hat aber das muss noch lange nicht overcommit bzw. ballooning bedeuten.

Der Link unten zeigt übrigens das man overcommit im Staging durchaus nutzen kann und nicht soviel Performance kostet wie gefürchtet.

*Memory Overcommit – Real life examples from VMware customers | Virtual Reality - VMware Blogs
Memory overcommit in production? YES YES YES

A Beginner’s Guide to Memory Reclamation in ESX/ESXi | VMware Support Insider - VMware Blogs

Transparent Page Sharing
In situations where many virtual machines with identical memory content are running on an ESX host, the hypervisor will maintain just a single copy while reclaiming the redundant ones. This results in a reduction of the host memory consumption by the virtual machines.
 
Zuletzt bearbeitet:
ESX 3.5 ist alte Kamelle ;)

Und nein, ich werfe die Begriffe nicht durcheinander. Das machst schon du selbst ;)
Memorysharing hat grundsätzlich nichts mit überbuchen ansich zu tun.
Es sind grundverschiedenen Sachen. Du erwähntest aber, mit dem einen, kann man auch gleichsam das andere machen. -> was potentiell zwar geht, aber eben nicht so gewollt sein muss.
Auch sprichst du von Anfang an von irgendwelchen riesen Hosts mit xx VMs um deine Aussagen zu untermauern. Wärend LaMagra-X von einem Host mit genau Zwei! VMs sprach. Somit bist du fernab der Fragestellung.
Beide VMs sind dazu noch mehr oder weniger Grundverschieden. 2012 Server + Exchange sowie Windows 7 mit Datev irgendwas...
Das eine hat mit dem anderen also vllt ein paar wenige hundert MB am reinen RAM Bedarf gemein. Wenn überhaupt.

Memorysharing fällt zu einem Großteil also gänzlich flach. Womit sich deine ganze Aussage in Luft auflöst ;) Weil hat einfach nichts mit der Frage mehr zu tun.


Übrigens, hast du deine Links überhaupt gelesen?
Im "Memory overcommit in production? YES YES YES" Link steht ähnliches beschrieben, wie ich schon sagte.

"ESX will start some memory optimization and reclaim techniques, but in the end it will swap host memory to disk, which is bad. It is essential to carefully monitor your hosts to see if you’re moving from good memory overcommit to bad memory overcommit."
Genau das sagte ich oben, mehrfach...

Im Beispiel aus dem Link waren 48GB im Host. = 12 x 4GB pro VM im simplen Fall.
Realverbrauch im Beispiel von ~2,5GB = 19 VMs in 48GB parkbar.
Im Beispiel genutzt = 17 VMs zu ~2,5GB = 42,5GB am Host.

Das Problem an diesem Beispiel ist aber, es sind alle samt VMs mit scheinbar vorhersagbarem RAM Verbrauch. Sprich ohne beispielsweise dem Filecachingmöglichkeiten von aktuellen Windows/*nix Sytemen.
Wie ich eingangs erwähnt habe, hängt es vom Gast-OS ab, wie der Verbrauch sich in der VM zusammensetzt. Ein Windows 2003 Server oder älter hat so in der Art keinen riesigen Filecache. Der RAM Verbrauch hält sich extrem übersichlich. Und ist weitestgehend vorhersagbar bzw. einschränkbar.
Neuere Windows OSen hingegen haben vollkommen unvorhersagbar einen Filecache per default, der dir binnen Minuten den RAM vollständig wegfressen kann.

Um beim konkreten Beispiel zu bleiben, der Realverbrauch der VMs liegt somit nicht bei ~2,5GB, sondern schlechtestenfalls im Schnitt bei ~4GB (eben das, was zugewiesen ist).
Betreibt man damit eben 17 oder 19 VMs am Host, sind ~20GB RAM, die die VMs wollen schlicht nicht vorhanden. So bleibt nur Platz für 12 VMs in 48GB. Oder man lebt mit extremen Leistungseinbußen.

Siehe dazu das von mir gepostete Bild über mehrere 2008/2008R2 VMs bei mir auf der Arbeit. Realverbrauch zu 99% = zugewiesenem RAM.
Um das noch weiter auszubauen. Ich kenne auch das Verhalten von überbuchtem RAM bzw. zu knapp bemessenem RAM. Seinerzeit lagen unsere Hosts mit 4x64GB bei nem Realverbrauch von ~55-60GB pro Host. Inkl. greifender Sharing/Swapping/Balloningmechanismen. -> und inkl. teils grottig schlechter Performance.

Nun sind wir auf 4x144GB RAM. Der reine RAM Verbrauch selbst ist weit gestiegen, teils 10-15GB pro Host. Der Speed hat sich merklich gesteigert. Auch das Ansprechverhalten. Die HDD Last ist teils massiv gefallen. Ballooning/Swappingwerte nun = Null -> voller Speed, wie man es erwartet.

Wie ich eingangs schon erwähnte, virtualsierung ist nicht dafür da, den Host gnadenlos zu überbuchen, auch wenn es gehen würde. Sondern soll Ressourcen möglichst effizient ausnutzen. Beim RAM und auch beim Storage gibts aber eben einige Einschränkungen. Verbrauch = Verbrauch. Kann nichts verbraucht werden, weil nicht vorhanden -> schlechte Performance.
Und ja, das SIND! Prasixerfahrungen... Die man eben haben muss und erst bekommt, wenn man sowohl die eine, als auch die andere Theorieseite mal überhaupt gesehen hat.
 
Zuletzt bearbeitet:
Hi zusammen.
Ich hatte eine für mich nicht zu erklärende Fehlermeldung (siehe Screenshot).

Der ESXi hat die VM pausiert und die Meldung im Anhang rausgegeben.

Sowohl auf dem Host als auch in der VM selbst besteht noch massig freier Speicherplatz.

Woher kommt dann die Meldung?
 

Anhänge

  • esxi fehler.PNG
    esxi fehler.PNG
    4,7 KB · Aufrufe: 99
Gibt es evtl. Snapshots, die den Datastore verstopfen? Mit welcher Blockgröße ist der Datastore formatiert? Ist die virtuelle Festplatte Thick oder Thin provisioniert? Wenn die Thin provisioniert ist und die mal auf einen anderen Datastore verschoben wurde, kann es sein, dass die gewachsen ist und an die maximale Größe der Datei im Datastore gestoßen ist.
 
Was mich wundert, diese xxx-00001.vmdk bedeuten eigentlich, das es sich um eine Snapshot VMDK handelt. Die "normalen" HDDs haben per default eigentlich nen Namen "VMNAME.vmdk" bzw. wenn es ne zweite vmdk gibt, "VMNAME_1.vmdk" usw.

Die Frage ist aber viel eher, was machst du genau?
Bei welcher Aktion kommt die Meldung?
Und um was handelt es sich bei der VM? Wenn du sagst, pausiert, wäre ggf. ein hartes ausknipsen und neu booten möglich? -> könnte bei DBs tödlich sein. Wobei da auch das pausieren nicht wirklich gut kommt :fresse:
 
Also ich habe zu dem Zeitpunkt nichts gemacht (ich weiss das sagen alle :fresse:), was damit zusammenhängen könnte (siehe Ereignisanzeige).

Die Meldung kam jetzt ein paar mal...zuletzt aber am 15.03...

Der Speicher hat noch knapp 40GB frei...die Festplatten sind thick-provision lazy-zeroed formatiert.


Und warum kommt in der Anzeige auch immer die Meldung, ich solle die VMWare Tools installieren? Das ist nämlich längst geschehen.



VG
 

Anhänge

  • esxi-1.png
    esxi-1.png
    18,8 KB · Aufrufe: 86
  • esxi-2.png
    esxi-2.png
    9,6 KB · Aufrufe: 79
Zuletzt bearbeitet:
sicher das da noch 40GB frei sind?
Weil der Wert wurde das letzte mal am 12.3. aktualisiert... Was man am Screen auch sieht.

Wie gesagt, meine Vermutung, das ist irgendwas mit Snapshots. Vllt läuft zu den Zeiten auch irgendwie ein Backup auf Snapshotbasis?
Oder irgendwelche anderen VMs verprassen punktuell mehr Platz, beispielsweise durch Snapshots.
 
Habs grad aktualisiert. Es sind sogar noch 44GB frei.

Snapshots habe ich alle gelöscht.

Und was hats mit der Aufforderung der VMWare Tools Installation auf sich?


Grüße und danke
 
Du hast gerade vorher die VM gestartet, wenn man dem Eintrag trauen kann. Das hab ich hier auch. Weil die Tools wohl ne Ecke brauchen, nach dem Boot der VM, bis der Host mitbekommt, dass da auch Tools laufen.
Würde ich gekonnt erstmal ausklammern.

Wie gesagt, interessant wäre eben zu wissen, ob da bei dir noch irgendwas läuft. Von irgendwelchen scheduled Tasks von Backups via Snapshotverfahren oder irgendwelche Tools, die selbst Snapshots anlegen. Kann ja alles sein.
Die Meldung besagt ja nur, das diese vmdk mit den vielen Nullen nicht erstellbar ist. -> und das kommt eigentlich nur, wenn man nen Snapshot erzeugt.
Nur die Snapshots kommen nicht von allein.

Kannst du denn Snapshots händisch anlegen?

Mal was anderes, hast du zufällig eine/die vmdk in den Settings zur VM von den Snapshots ausgenommen? Das könnte ggf. so ne Meldung erzeugen...
 
Also ich habe (noch) keinerlei gescriptete Tasks, etc. am Laufen.

Händisch hatte ich zwei mal einen Snapshot gemacht. Diesen habe ich dann aber wieder gelöscht, als der DC richtig eingerichtet war. Vielleicht stört er sich an einem gelöschten Snapshot.

Neu gebootet habe ich den Host aber schon mehrmals.


Grüße
 
Du kannst ja mal mit Rechtsklick auf die VM im Inventory -> Snapshot -> Konsolidieren die Kiste konsolidieren lassen. Ggf. ist da noch irgendwie ein Rest Zeugs inkludiert, was nicht mehr hätte sein sollen.

Ein Blick in die VMX Datei mit nem Texteditor könnte auch aufschluss bringen. Falls du mit den Angaben nix anfangen kannst -> hier mal die VMX Datei posten.
 
Im jeweiligen Ordner auf dem Datastore direkt...
Ansonsten siehst du den Pfad auch in den Einstellungen zur jeweiligen VM.
 
Was kann man da raus lesen, was Aufschluss auf die Meldung bringt? :)

Code:
.encoding = "UTF-8"
config.version = "8"
virtualHW.version = "8"
pciBridge0.present = "TRUE"
pciBridge4.present = "TRUE"
pciBridge4.virtualDev = "pcieRootPort"
pciBridge4.functions = "8"
pciBridge5.present = "TRUE"
pciBridge5.virtualDev = "pcieRootPort"
pciBridge5.functions = "8"
pciBridge6.present = "TRUE"
pciBridge6.virtualDev = "pcieRootPort"
pciBridge6.functions = "8"
pciBridge7.present = "TRUE"
pciBridge7.virtualDev = "pcieRootPort"
pciBridge7.functions = "8"
vmci0.present = "TRUE"
hpet0.present = "TRUE"
nvram = "London.nvram"
virtualHW.productCompatibility = "hosted"
powerType.powerOff = "soft"
powerType.powerOn = "hard"
powerType.suspend = "hard"
powerType.reset = "soft"
displayName = "London"
extendedConfigFile = "London.vmxf"
numvcpus = "8"
cpuid.coresPerSocket = "8"
scsi0.present = "TRUE"
scsi0.sharedBus = "none"
scsi0.virtualDev = "lsisas1068"
memsize = "12288"
scsi0:0.present = "TRUE"
scsi0:0.fileName = "London.vmdk"
scsi0:0.deviceType = "scsi-hardDisk"
ide1:0.present = "TRUE"
ide1:0.clientDevice = "TRUE"
ide1:0.deviceType = "cdrom-raw"
ide1:0.startConnected = "FALSE"
ethernet0.present = "TRUE"
ethernet0.virtualDev = "e1000e"
ethernet0.networkName = "VM Network"
ethernet0.addressType = "generated"
chipset.onlineStandby = "FALSE"
disk.EnableUUID = "TRUE"
guestOS = "windows8srv-64"
uuid.location = "56 4d 9a 54 97 90 89 8f-e7 16 e6 c5 92 01 76 66"
uuid.bios = "56 4d 9a 54 97 90 89 8f-e7 16 e6 c5 92 01 76 66"
vc.uuid = "52 ae f3 f8 bf 5b c6 9e-1a 8f 05 4b b5 a9 02 0e"
snapshot.action = "keep"
sched.cpu.min = "0"
sched.cpu.units = "mhz"
sched.cpu.shares = "normal"
sched.mem.min = "0"
sched.mem.shares = "normal"
usb.present = "TRUE"
ehci.present = "TRUE"
ehci.pciSlotNumber = "33"
scsi0.pciSlotNumber = "160"
ethernet0.generatedAddress = "00:0c:29:01:76:66"
ethernet0.pciSlotNumber = "192"
usb.pciSlotNumber = "32"
vmci0.id = "-1845397914"
vmci0.pciSlotNumber = "34"
tools.syncTime = "FALSE"
cleanShutdown = "FALSE"
replay.supported = "FALSE"
unity.wasCapable = "FALSE"
sched.swap.derivedName = "/vmfs/volumes/50febce2-cead75df-1b99-f80f41f2349a/London/London-e0856a3f.vswp"
replay.filename = ""
scsi0:0.redo = ""
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
scsi0.sasWWID = "50 05 05 64 97 90 89 80"
usb:1.present = "TRUE"
ethernet0.generatedAddressOffset = "0"
vm.genid = "5882268016124412742"
vm.genidX = "7354228910396427374"
tools.remindInstall = "TRUE"
hostCPUID.0 = "0000000d756e65476c65746e49656e69"
hostCPUID.1 = "000206d70020080017bee3ffbfebfbff"
hostCPUID.80000001 = "0000000000000000000000012c100800"
guestCPUID.0 = "0000000d756e65476c65746e49656e69"
guestCPUID.1 = "000206d700080800969822031fabfbff"
guestCPUID.80000001 = "00000000000000000000000128100800"
userCPUID.0 = "0000000d756e65476c65746e49656e69"
userCPUID.1 = "000206d700200800169822031fabfbff"
userCPUID.80000001 = "00000000000000000000000128100800"
evcCompatibilityMode = "FALSE"
vmotion.checkpointFBSize = "4194304"
softPowerOff = "FALSE"
usb:1.speed = "2"
usb:1.deviceType = "hub"
usb:1.port = "1"
usb:1.parent = "-1"
ide1:0.fileName = "/usr/lib/vmware/isoimages/windows.iso"
floppy0.present = "FALSE"
usb:0.present = "TRUE"
usb:0.deviceType = "hid"
usb:0.port = "0"
usb:0.parent = "-1"


Mit der Meldung zu den VMWare Tools hast du übrigens vollkommen Recht. Man sieht es daran, dass die Meldung sofort nach dem Einschalten der VM ins Log geht. Das ist natürlich Käse...


EDIT:

Ich möchte nun eine USB Festplatte dauerhaft einbinden.

Muss ich dann ein Pass-Through einrichten?

Das ist relativ einfach:
Im vSphere Client rechtsklick auf die VM-> Einstellungen bearbeiten.
Danach einen USB Controller hinzufügen. Und nun, musst du noch ein USB Gerät hinzufügen.
Fertig.

Das funzt nämlich nicht...
 
Zuletzt bearbeitet:
Ich möchte nun eine USB Festplatte dauerhaft einbinden.

Muss ich dann ein Pass-Through einrichten?

Das funzt nämlich nicht...

Nein, Pass-Through brauchst du nur, wenn du anstatt der emulierten Hardware ein teil der echten Hardware des Hosts z.B ein RAID Controller exklusiv dieser VM zur Verfügung stellen willst. Bei USB ist das aber unnötig, da dir der ESXi auch virtuelle USB Controller anbietet, die dann die USB Geräte an die VM duchreichen.

Was genau funktioniert denn da bei dir nicht?

Du solltest in den Einstellungen deiner VM eigentlich dieses Bild hier bekommen, wenn du Hardware hinzufügen möchtest und unter anderem dort auch einen USB Controller finden

USB.PNG

Danach klickst du noch ein paar Mal auf "weiter" und dann auf "beenden" und wiederholst den Vorgang. Dieses Mal wählst du dann aber nicht den USB Controller aus, sondern ein USB Gerät.
 
Aaaah...das hat geklappt. Ich hatte zwar den USB Controller drin, aber dass ich danach nochmal das USB Gerät hinzufügen musste, wusste ich nicht! Super!

Nun die Frage: Kann ich jetzt die USB-Festplatte abstecken und eine andere wieder dran, so wie an einer physikalischen Maschine?

EDIT: Ja, es geht...habe es eben testen können. Wieso gibts dann das Durchschleifen?

Zudem möchte ich einen Datev-Dongle dauerhaft einer VM zuweisen. Ich habe HIER gelesen, dass man das nur über das Pass-through realisieren kann. (Galt für Version 4)

VG und danke!
 
Zuletzt bearbeitet:
Was kann man da raus lesen, was Aufschluss auf die Meldung bringt? :)

Zumindest hier ran:
scsi0:0.fileName = "London.vmdk"
sieht man, das du wirklich irgendwie scheinbar ein Snapshotproblem hast. Denn dort in der vmx Datei steht die richtige vmdk Platte drin.
Die angemeckerte mit den vielen Nullen in der Meldung muss also irgendwas mit einem Snapshot oder irgend einem Mechanismus aufbauend auf einem Snapshot zu tun haben.

Beispielsweise wird beim Klonen einer VM ein Snapshot angelegt und aus dem Snapshot geklont ;)
Da gibts noch sicher ganz paar mehr Anwendungsfälle, aus heiterem Himmel dürfte aber nix passieren.

Kannst du irgendwie genauestens analysieren, was du da machst?

EDIT: Ja, es geht...habe es eben testen können. Wieso gibts dann das Durchschleifen?

Der ESXi kann nicht alle Geräte so anbinden wie eben USB Hardware ;)
Beispielsweise das Durchreichen von einem Storagecontroller geht nur via Passthrough.

Mit dem Dongle müsstest du probieren, könnte passieren, die USB Version geht nicht.
Dann könnte ggf. helfen, den USB Controller selbst durchzureichen. IdR haben die Boards mehrere USB Controller drauf. Sprich reichst du den durch, wo der Dongle dran klemmst, gehen die anderen ganz normal weiter ;)
 
Was sind euere Empfehlungen fürs Backuppen von VMs?
Will mir in der nächsten Zeit einen Überblick verschaffen.

Ist es wichtig, den ESX als solches zu sichern? Im Grunde ändert sich ja u.U. lange Zeit nichts. Wenn ich mal von meiner Verwendung ausgehe, sind das vlt. 3-4 VMs auf dem Host - d.h. relativ schnell wieder angelegt und zurückgesichert.
Mir gehts eher darum, z.B. die DCs in den VMs "richtig" zu sichern (nein, keine Windows Server Sicherung).

Was haltet ihr von "normaler" Backupsoftware (z.B. Storagecraft), die auf dem virtualisierten System läuft, wie als würde sie in einem physikalischen Rechner laufen?

Brauch bloß ein paar Stichworte, von Software die taugt. Danke
 
Was sind euere Empfehlungen fürs Backuppen von VMs?
Will mir in der nächsten Zeit einen Überblick verschaffen.

Das kommt ein wenig darauf an, wie du sichern willst. Sprich innerhalb der VM oder über den ESXi die ganze VM inklusive Config.

Ist es wichtig, den ESX als solches zu sichern? Im Grunde ändert sich ja u.U. lange Zeit nichts. Wenn ich mal von meiner Verwendung ausgehe, sind das vlt. 3-4 VMs auf dem Host - d.h. relativ schnell wieder angelegt und zurückgesichert.

Den ESXi kannst du notfalls neuinstallieren. Wichtiger währe es da eher, die Config zu sichern. Das kannst zu z.B mit dem Tool vicfg-cfgbackup machen.

Mir gehts eher darum, z.B. die DCs in den VMs "richtig" zu sichern (nein, keine Windows Server Sicherung).

Mit DC's ist das mit dem Sichern immer so eine Sache, vor allem, wenn das AD aus mehreren DC's besteht, die sich gegenseitig replizieren. Da hast du bei Snapshotsicherungen ruckzuck ein USN Rollback und damit inkonsistente Datenbanken.
Wenn du mehrere DC's im AD hast, dann ist es am einfachstens, den ausgefallenen DC aus dem AD rauszuschmeißen, einen neuen Server zu installieren und diesen dann via dcpromo zum DC hochzustufen.

Was haltet ihr von "normaler" Backupsoftware (z.B. Storagecraft), die auf dem virtualisierten System läuft, wie als würde sie in einem physikalischen Rechner laufen?

Naja, das sichert dir zwar die Daten in der VM, aber nicht die VM selber (und dessen Config). Besser sind da Tools, die auf Snapshotbasis die VMs wegsichern. Es gibt da sowohl kostenpflichtige wie z.B. Acronis Backup & Recovery oder Backup-Exec von Symantec, aber auch kostenlose Scripte und Tools z.B. Veeam
 
Memorysharing hat grundsätzlich nichts mit überbuchen ansich zu tun.

/loriot
*ach*

Was meinst du eigentlich was ich die ganze Zeit schreibe?

Mir dann auch noch mit 5 Jahren Berufserfahrung in ESX zu unterstellen, ich hätte keine Ahnung ist dann der Gipfel.
Und tschüss!
 
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