ESX / ESXi - Hilfethread

Moin,

ich hab ein Problem mit meinem ESXI.
meine üblichen VMs laufen ohne Probleme. Eine, die ich aber nur hin und wieder mal starte zickt auf einmal rum.
Sie lässt sich nicht mehr starten und ESXI bringt den Fehler "Das Gerät 2:14.0 wurde nicht gefunden"
Storrage hab ich aktualisiert und es wurden keine Fehler gefunden. Geräte werden nicht in die VM durchgeschleift.
Beim letzten Mal lief die VM noch ohne Probleme. Weiss jemand einen Rat oder einen Hinweis wo ich mit der Suche anfangen soll?
Das Ereigniss Protokol zeigt mir auch nur die gleiche Meldung.

Kannst du mal den Inhalt deiner vmx Datei dieser VM hier anhängen?
Da scheint irgend eine Einstellung drin zu sein, welche so nicht funktioniert.

Mal eine blöde Frage, habe bisher nur mit ESXi 4.1 und 5.0 gearbeitet. Hab gestern mal den ESXi 5.1 installiert und hatte mal ein Feature gelesen von wegen vSphere Web GUI, aber ich muss trotzdem die vSphere Client EXE herunterladen um den ESXi 5.1. zu administieren. Muss ich noch etwas extra installieren damit das verwalten per Webbrowser klappt? Wenn ja schade, wäre cool gewesen den ESXi Host direkt anzusprechen.

Den WebClient gibts definitiv schon seit 5.0. Bei der 4.0/4.1 weis ich es nicht genau, aber könnte sein das es den da auch schon gab.
Mach dir aber keine sonderlich großen Hoffnungen dadrauf. Denn das Teil ist an einen Server gebunden. Der Host selbst (sprich der ESXi) gibt dir nicht die Möglichkeiten, sich selbst über eine Weboberfläche zu administrieren. Das heist, du brauchst ne dedizierte VM oder physische Maschine mit nem Webserver und dem Webclient da drauf.

Beim 5.1er funktioniert das definitiv nur in Verbindung mit nem vCenter. Vor allem hat VMware bei Version 5.1 den Schritt hin zu ihrer SSO Implementation vollständig erzwungen. Alles, was an Verwaltungstechnik bereit steht in der aktuellen Version, setzt auf den SSO Service auf. (vCenter, Webclient, Syslog, usw.)
Mit nem Hypervisor only kommst du da wohl um den VI Client nicht drum rum...

PS: noch dazu frisst der WebClient massivst Ressourcen. Das ganze basiert auf Java und frisst RAM ohne Ende. Selbst mit ner Single Instanz eines vCenters und einem einzigen Aufruf ist es durchaus üblich, das die Kiste mal locker 5-7GB RAM belegt, nur damit du die Verwaltungskonsole über Web bekommst.
Wobei man aber auch sagen muss, das ganze Konzept des 5.1ers frisst RAM ohne Ende... Da war der 5.0er noch ein genügsames Schaf dagegen...
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
ESXi Server mit 3D VM

Hi Leute,

ich habe mal wieder ein spezielleres Problem.

Ich setze @work einen EXI 5.0U1 auf Basis von nem Athlon II mit Perc 5/i als Storage Server ein (WHSv1 und v2). Nebenher laufen mehrere Win 7 und WinXP VM´s drauf. Soweit bin ich damit sehr zufrieden.
Allerdings komm ich ab und an ins RAM Limit (16Gb sind verbaut).
Jetzt soll bei uns eine Workstation für 3D Proteinmodelling (sozusagen Folding@work) und die Auswertung einiger biotechnischen Spektren gekauft werden. Die Kiste soll zudem 3D-Monitorfähig sein, und genug Power haben um ein wenig Raytracing zu nutzen (haben ein Programm mit dem man 3D Models raytracen kann, das unterstützt AFAIK CUDA oder OpenCL zur Berechnung) um Videos für Präsentationen zu erstellen. Keine Ahnung ob das echtes Raytracing ist, allerdings dauerts ewig zu berechnen (auf nem C2D so 1-2h für 10sec Film).

Da mein ESXi ja ab und an am Limit ist, kam mir die Idee den ESXi und die 3D Workstation miteinander zu kombinieren. Soll heißen, ein Sockel 1155 oder 2011 System anschaffen, den ESXi darauf umziehen und zusätzlich ein Quadro oder FireGLPro mit reinzuhängen und die an eine VM durchzureichen auf die dann per RDP zugegriffen wird. Ein 3D Monitor wäre dann am Client angeschlossen. Funktioniert das?
Hat hier jemand Erfahrung mit durchgereichten Graphikkarten und wie die Performance dabei ist?

Was haltet ihr insgesamt von der Idee? Wäre es besser Server und Workstation getrennt zu halten? Mir graut es halt davor einen teuren Rechner anzuschaffen dessen Leistung nur selten ausgereizt wird, und der so deutlich besser genutzt werden würde. Zudem könnte man dann über das komplette Netzwerk darauf zugreifen und wäre nicht auf diese eine Workstation beschränkt.
Es besteht eine 100MBit Netzwerkstruktur, teilweise auch 1GBit.
Bisher habe ich mir mal folgende Konfiguration überlegt:

Sockel 2011 Intel/Supermicro/Tyan Brett: steht noch nix fest, IPMI wär schön, Dual GB Intel LAN wär fast ein Muss)
32Gb RAM (wahrscheinlich 4*8Gb um evtl. noch auf 64Gb hochzugehen falls nötig)
FireGL 4800 oder Quadro 600 (je nachdem was der Rest kostet)
Samsung oder Intel SSD mit 120 GB

Übernommen aus dem "alten" ESX würden 8*1Tb Platten als Storage am Perc 5/i (RAID 10) sowie ein paar kleinere als VM Stores.

Da es ja nur am Rande ne ESXi Frage ist, würde ich nen Mod bitten das in ein neues Thema zu verschieben falls es hier stören sollte.
 
Dein Vorhaben kannst du so knicken. GPUs in die VMs schieben ist ein Graus und funktionier eher schlecht als recht.

Bau das dediziert auf, oder nutze HyperV.
 
Inwiefern Hyper-V? So wie ich das verstehe ist das doch auch nur eine Abstraktionsebene zwischen HW und OS, sodass die Client OS keinen direkten Zugriff auf die HW haben, oder seh ich das falsch?

Dediziert, nicht so schön, aber wenns denn sein muss würd ichs machen.
 
Ich nehme mal stark an Hyper-V ein nettes Feature RemoteFX dafür hat im Gegensatz zu ESXi.
 
Mhm, müsste ich mal probieren, eine Server 200R2 Lizenz hab ich noch rumliegen (MSDNAA) und ne FireGL müsst ich auch noch auftreiben können.
Thin Clients als Backend für die User hören sich auch ganz gut an, allerdings will ich das erstmal sehen. Scheinbar gibts ja viele Fallstricke die RemoteFX stören.

Und ob das dann noch einfacher als ne dedizierte Kiste ist, lass ich mal dahingestellt. Auf jeden Fall ist es interessant.
 
Ich denke, der Vorteil wäre eher, dass Hyper-V als Basis ein Windows System hat. So könnten die 3D-Anwendungen nativ unter Windows laufen, ohne irgendwelche Hardware in eine VM durchreichen zu müssen.
 
Hallo Ihr,

kann ich einen vCenter Server virtualieren und um mich vor dem Ausfall zu schützen, diesen als VM auf 2 ESXi-Host laufen lassen, sowas wie ein vCenter Servercluster? Dies alles für den Privatbetrieb bzw. um mich fortzubilden. Geht das?
Welche Lizenz benötige ich dazu? Geht das mit der Essential Plus? Kann ich damit überhaupt 2 vCenter Server hochziehen?
 
Man würde eher nur einen vCenter Server installieren und den durch vSphere HA schützen. Wenn der vCenter Server ausfällt, funktionieren die anderen VMs ja uneingeschränkt weiter. Der Betrieb vom VC ist auf jeden Fall supportet.
 
Hallo Ihr,

kann ich einen vCenter Server virtualieren und um mich vor dem Ausfall zu schützen, diesen als VM auf 2 ESXi-Host laufen lassen, sowas wie ein vCenter Servercluster? Dies alles für den Privatbetrieb bzw. um mich fortzubilden. Geht das?
Welche Lizenz benötige ich dazu? Geht das mit der Essential Plus? Kann ich damit überhaupt 2 vCenter Server hochziehen?
Einen wirklich unterbrechungsfreien Betrieb kann man nur mit Fault Tolerance sicherstellen, aber wenn es nicht um eine wirklich große Installation geht, kann man das auch per High Availability sicherstellen, dafür braucht's dann nur die Essentials Plus. Dort wird die virtuelle Maschine, wenn ein Host ausfällt, nach kurzer Zeit auf einem anderen Host neu gestartet. Das funktioniert auch für den vCenter Server, weil HA, wenn es aktiviert ist, nicht vom vCenter Server abhängt.
 
Kannst du mal den Inhalt deiner vmx Datei dieser VM hier anhängen?
Da scheint irgend eine Einstellung drin zu sein, welche so nicht funktioniert.

Gern.

{.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 = "Win7Work.nvram"
virtualHW.productCompatibility = "hosted"
powerType.powerOff = "soft"
powerType.powerOn = "hard"
powerType.suspend = "hard"
powerType.reset = "soft"
displayName = "Win7Work"
extendedConfigFile = "Win7Work.vmxf"
scsi0.present = "TRUE"
scsi0.sharedBus = "none"
scsi0.virtualDev = "lsisas1068"
memsize = "2048"
ide0:0.present = "TRUE"
ide0:0.clientDevice = "TRUE"
ide0:0.deviceType = "cdrom-raw"
ide0:0.startConnected = "FALSE"
guestOS = "windows7-64"
uuid.location = "56 4d 85 98 88 07 99 d4-60 bc 42 40 f9 a3 e4 51"
uuid.bios = "56 4d 85 98 88 07 99 d4-60 bc 42 40 f9 a3 e4 51"
vc.uuid = "52 7e 00 cf 7d d4 a2 da-bc 11 43 34 47 e8 9e ff"
svga.vramSize = "16777216"
vmci0.id = "-106699695"
tools.syncTime = "FALSE"
cleanShutdown = "TRUE"
migrate.hostlog = "./Win7Work-2a2d6f0a.hlog"
replay.supported = "FALSE"
sched.swap.derivedName = "/vmfs/volumes/4fc5c349-bf8f52ea-6547-00259006383a/Win7Work/Win7Work-2a2d6f0a.vswp"
replay.filename = ""
pciBridge0.pciSlotNumber = "17"
pciBridge4.pciSlotNumber = "21"
pciBridge5.pciSlotNumber = "22"
pciBridge6.pciSlotNumber = "23"
pciBridge7.pciSlotNumber = "24"
scsi0.pciSlotNumber = "160"
ethernet0.virtualDev = "vmxnet3"
vmci0.pciSlotNumber = "32"
ethernet0.pciSlotNumber = "192"
scsi0.sasWWID = "50 05 05 68 88 07 99 d0"
hostCPUID.0 = "0000000b756e65476c65746e49656e69"
hostCPUID.1 = "000106e5001008000098e3fdbfebfbff"
hostCPUID.80000001 = "00000000000000000000000128100800"
guestCPUID.0 = "0000000b756e65476c65746e49656e69"
guestCPUID.1 = "000106e500020800809822011febfbff"
guestCPUID.80000001 = "00000000000000000000000128100800"
userCPUID.0 = "0000000b756e65476c65746e49656e69"
userCPUID.1 = "000106e500100800009822011febfbff"
userCPUID.80000001 = "00000000000000000000000128100800"
evcCompatibilityMode = "FALSE"
vmotion.checkpointFBSize = "16777216"
ethernet0.startConnected = "TRUE"
ethernet0.allowGuestConnectionControl = "TRUE"
ethernet0.features = "1"
ethernet0.wakeOnPcktRcv = "TRUE"
ethernet0.networkName = "VM Network 2"
ethernet0.dvs.switchId = ""
ethernet0.present = "TRUE"
ethernet0.addressType = "generated"
unity.wasCapable = "FALSE"
ethernet0.generatedAddress = "00:0c:29:a3:e4:51"
ethernet0.generatedAddressOffset = "0"
ide0:0.fileName = "/usr/lib/vmware/isoimages/windows.iso"
numvcpus = "2"
cpuid.coresPerSocket = "2"
mks.enable3d = "TRUE"
sched.mem.min = "2048"
sched.mem.shares = "normal"
usb.present = "TRUE"
ehci.present = "TRUE"
sched.cpu.min = "0"
sched.cpu.units = "mhz"
sched.cpu.shares = "normal"
sched.mem.pin = "FALSE"
usb.pciSlotNumber = "33"
ehci.pciSlotNumber = "34"
usb:1.present = "TRUE"
usb:1.speed = "2"
usb:1.deviceType = "hub"
usb:1.port = "1"
usb:1.parent = "-1"
tools.remindInstall = "FALSE"
pciPassthru0.present = "TRUE"
pciPassthru0.deviceId = "15"
pciPassthru0.vendorId = "1028"
pciPassthru0.systemId = "4f2402f0-ca81-1d76-292e-00259006383a"
pciPassthru0.id = "02:14.0"
pciPassthru0.pciSlotNumber = "224"
usb:0.present = "TRUE"
usb:0.deviceType = "hid"
usb:0.port = "0"
usb:0.parent = "-1"
scsi0:1.present = "TRUE"
scsi0:1.fileName = "/vmfs/volumes/4f7742c3-72f563ca-cda5-00259006383b/Win7Work/Win7Work.vmdk"
scsi0:1.deviceType = "scsi-hardDisk"
scsi0:0.present = "FALSE"
pciPassthru1.present = "FALSE"
pciPassthru2.present = "FALSE"
pciPassthru3.present = "FALSE"
floppy0.present = "FALSE"
scsi0:1.redo = ""}
 
Ich hätte die Möglichkeit an nen Fujitsu TX150 S6 zu kommen und würde da den ESXi 5.1 laufen lassen.

Kann ich prinzipiell einen SCSI Autoloader der an einem PCI SCSI Controller hängt in eine VM durchreichen?
Nicht zwingend den kompletten Controller, im Prinzip reichen mir 2 der SCSI Geräte die dran hängen (der Loader und das Laufwerk).
 
Gern.

pciPassthru0.id = "02:14.0"
pciPassthru0.pciSlotNumber = "224"
Da hast Du dein Gerät, was Du da rauslöschen musst. ;) Am besten über die vSphere Client-Oberfläche, außer Du weißt, was Du tust, wenn Du vmx-Dateien manuell editierst.

Ich hätte die Möglichkeit an nen Fujitsu TX150 S6 zu kommen und würde da den ESXi 5.1 laufen lassen.

Kann ich prinzipiell einen SCSI Autoloader der an einem PCI SCSI Controller hängt in eine VM durchreichen?
Nicht zwingend den kompletten Controller, im Prinzip reichen mir 2 der SCSI Geräte die dran hängen (der Loader und das Laufwerk).
Laut VMWare Knowledgebase-Artikel geht das seit 5.0 nicht mehr, ich habe das allerdings noch nicht ausprobiert.
 
Hallo Ihr,

kann ich einen vCenter Server virtualieren und um mich vor dem Ausfall zu schützen, diesen als VM auf 2 ESXi-Host laufen lassen, sowas wie ein vCenter Servercluster? Dies alles für den Privatbetrieb bzw. um mich fortzubilden. Geht das?
Welche Lizenz benötige ich dazu? Geht das mit der Essential Plus? Kann ich damit überhaupt 2 vCenter Server hochziehen?

Es gibt zwei Möglichkeiten...
Entweder die hier schon angesprochene Methode, die VM selbst zu clustern, sprich mindestens zwei Hosts, FT aktiv und die VM dann da drauf packen. Nachteil, du benötigst quasi doppelte Ressourcen. Und (zumindest war das mal so, keine Ahnung ob das in der aktuellen Version immernoch so ist) bist du an gewisse Hardwarerestriktionen gebunden. Was damals mal eine einzige vCPU war. Ob man das jetzt ggf. mit Cores erschlagen kann, weis ich nicht, müsste mal jemand testen...

Möglichkeit zwei, der vCenter selbst bietet die Möglichkeit geclustert zu werden. Sprich zwei vCenter im Cluster, fällt einer weg, läuft der andere weiter. Ich kann dir aber auch hier nicht aus dem Hut sagen, was dort für Vorraussetzungen zu erfüllen sind. Sicher dürfte aber sein, das es nur mit der Lizenz Standard und höher gehen sollte. Einfach, weil die Ess. Pakete dediziert für drei Hosts + einen vCenter gebaut sind.

Man würde eher nur einen vCenter Server installieren und den durch vSphere HA schützen. Wenn der vCenter Server ausfällt, funktionieren die anderen VMs ja uneingeschränkt weiter. Der Betrieb vom VC ist auf jeden Fall supportet.

Ob es sinnvoll ist, den vCenter selbst auf dem von ihm verwalteten Hosts-Cluster zu betreiben!? Hier scheiden sich die Geister. Klar, die VMs laufen erstmal weiter, aber was, wenn es dir die VM des vCenters mal gänzlich zerhaut? Sei es durch ein Storage Problem oder durch andere Hardwareprobleme auf dem Host. Das wird dann schon etwas mehr komplex, die Kiste zu recovern. ;)
Da wäre es dann wohl einfacher, den vCenter auf nem Hypervisor zu betreiben. Bzw. wenn man mehrere Host-Cluster fährt, die vCenter VMs jeweils über Kreuz auf dem jeweils anderen Cluster.

Ich nehme mal stark an Hyper-V ein nettes Feature RemoteFX dafür hat im Gegensatz zu ESXi.

An der Stelle aber eher ungeeignet. Da man via RemoteFX soweit ich weis auch nur eine Grafikkarte in einer VM emuliert, die dann zu einem gewissen Teil auf der Hardware des Hosts beschleunigt wird. Man hat aber definitiv keinen vollen Featureumfang, gerade was propritäte Lösungen ala NVs Cuda und AMDs Stream angeht. OpenCL könnte hingegen funktionieren (beim 2012er Server, beim 2008R8 wohl eher nicht)

Ob es aber wirklich Hyper-V sein muss, ist eine Glaubensfrage. Ne VMware Workstation in der aktuellen Version wäre auch ne Option. Rennt wie hanne, wenn die Hardware passt und man kann nebenbei immernoch quasi uneingeschrenkt auf dem "Host" arbeiten. Im Vergleich zum Hyper-V bei Windows 8 ist der Speed gerade auf das Storage auch ungleich schneller. (Hyper-V bei nem Server habe ich so noch nicht gemessen)

Mhm, müsste ich mal probieren, eine Server 200R2 Lizenz hab ich noch rumliegen (MSDNAA) und ne FireGL müsst ich auch noch auftreiben können.
Thin Clients als Backend für die User hören sich auch ganz gut an, allerdings will ich das erstmal sehen. Scheinbar gibts ja viele Fallstricke die RemoteFX stören.

Und ob das dann noch einfacher als ne dedizierte Kiste ist, lass ich mal dahingestellt. Auf jeden Fall ist es interessant.

Wie gesagt, so 100% sinnvoll ist RemoteFX nicht. Du verlierst einfach zu viele Features, da im Grunde einfach eine Hyper-V VM benutzt wird, anstatt dediziert auf die Host Ressourcen zuzugreifen.
Da kommst du wohl weiter, wenn du dir ne 2008 R2 oder 2012 Server (mindestens Standard) Lizenz besorgst, dort dann die Hyper-V Rolle nachinstallierst (oder ggf. VMware Workstation nutzt) und via RDP dediziert auf dem Host deine Rechenaufgaben vollziehst. Die VMs laufen dann im Hyper-V/VMware Workstation nebenbei...
Vorteil wäre sogar noch, du kannst dir den WHS als VM(s) schenken, und die Storages direkt auf dem Host betreiben, was deutlich fixer sein sollte...

Einen wirklich unterbrechungsfreien Betrieb kann man nur mit Fault Tolerance sicherstellen, aber wenn es nicht um eine wirklich große Installation geht, kann man das auch per High Availability sicherstellen, dafür braucht's dann nur die Essentials Plus. Dort wird die virtuelle Maschine, wenn ein Host ausfällt, nach kurzer Zeit auf einem anderen Host neu gestartet. Das funktioniert auch für den vCenter Server, weil HA, wenn es aktiviert ist, nicht vom vCenter Server abhängt.

Bei letzterem stellt sich aber eventuell das Problem ein, das die VM gar nicht mehr hochkommt. Gerade die SQL DB ist beim vCenter recht anfällig. Lässt man die VM einfach so hinten runter fallen (nix anderes passiert ja), kann es sein, die DB ist korrupt und man bekommt den vCenter gar nicht mehr gestartet :fresse:

Ich hätte die Möglichkeit an nen Fujitsu TX150 S6 zu kommen und würde da den ESXi 5.1 laufen lassen.

Kann ich prinzipiell einen SCSI Autoloader der an einem PCI SCSI Controller hängt in eine VM durchreichen?
Nicht zwingend den kompletten Controller, im Prinzip reichen mir 2 der SCSI Geräte die dran hängen (der Loader und das Laufwerk).

Wenn es nicht direkt mit dem Gerät funktioniert, einfach den Controller durchreichen. Das sollte wiederum funktionieren, sofern die Hardware passthrough unterstützt.
 
Hallo fdsonne,

vielen Dank.

Hauptsächlich benötige ich den vCenter Server nur für den VDR und zur Templateerstellung. Ständig laufen muss der vCenter Server dann wohl eigendlich nicht. Macht es dann Sinn, eine dedizierte Maschine nehmen und diese nur bei Bedarf hochzufahren? Oder als VM und halt regelmäßig sichern?
 
sichert der VDR auch zeitgesteuert, wenn der vCenter aus ist? Das wäre durchaus interessant :fresse:

Mal anders gefragt, als dedizierte Maschine, wie sicherst du das Teil dann?
Ich würde es wohl als VM betreiben, aber auf ner dedizierten Hardware, um eben den Vorteil der zusätzlichen Abstraktionsschicht zu nutzen, wenn mir die Hardware wegbrennt. So kannst du bequem die VM woanders drauf packen ohne umständlich den Host und dessen Host OS wiederzubeleben. Was gerade bei HDD Ausfällen schwerer werden könnte, sofern man kein Full Backup hat.

Andererseits, wenn du nur das vCenter nutzt, um den VDR zeitgesteuert zu nutzen, und ein paar Templates zu verwalten. Kannst du auch ganz auf ne Sicherung des ganzen verzichten. Einfach irgendwo nen Abzug (VCB oder ähnliches) der Host OS Install abkippen, bei Bedarf den vCenter fix neu installen. Lizenzen einspielen und den/die Hosts neu verbinden. Aufwand: ich denke maximal zwei Stunden, bis die Kiste wieder rennt.
Ob du das dann auf physischer Hardware, oder als VM machst, ist auch ziemlich egal. Sofern dein Host OS Abzug für den vCenter Server sauber läuft.
Alternativ die vCenter Appliance irgendwo als VM laufen lassen, das dürfte ggf. sogar in ner VMware Player Umgebung irgendwo auf ner Workstation laufen... Für privat ist der Player ja noch kostenfrei... Oder wirklich mit aufs Cluster packen, brennt dir das System mal weg, kannst du immernoch fix was neues hochziehen.


Wie gesagt, sofern du nicht irgendwelche exorbitanten Konfigorgien im vCenter selbst durchgeführt hast, wie beispielsweise tonnenweise verschiedenste Berechtigungen über verschiedenste hinzugefügte Rollen usw. ist ein Aufsetzen eines neuen vCenters im Problemfall ggf. gar schneller als irgendwelche umständlichen Backupszenarien über Skripte und Co.
 
Zuletzt bearbeitet:
Guten Morgen zusammen,
weiß jemand wie ich unter OpenMediaVault die VMWare Tools installieren kann?
 
Kurzes durchwinken meiner ESXi Konfiguration? Wenn jemand so nett wäre.
Was meint ihr kriegt man damit idle an Verbrauch hin?
Ich wollte erst mehr in Richtung Intel Core i5 gehen, allerdings verlocken die AMD Preise und auf reine Performance kommt es nicht mehr drauf an. Nur wenn die AMD Kiste jetzt 30w mehr idle verbraucht würde ich mir das noch einmal überlegen..

Es laufen sowieso max. 4 VMs dadrauf. Aufgrund der günstigen Speicherpreise nehme ich jedoch viel RAM mit, um das ner Solaris VM mit ZFS als caching möglichkeit zu geben.

~260€ und damit knapp 100€ günstiger als ein Core i5-3470 Build..
 
Zuletzt bearbeitet:
Was meint ihr kriegt man damit idle an Verbrauch hin?
Es gibt einen Test mit dem FX-6100, da nimmt der FX-6100 gerade mal 4 Watt im Idle auf. Komplett idle wird der Host aber so gut wie nie sein, so dass ich denke, dass der im Normalbetrieb zwischen 15 und 20 Watt aufnehmen wird. Besser wird ein i5 allerdings wahrscheinlich auch nicht sein.

Das sind aber alles nur Vermutungen, außerdem ist da das Mainboard noch nicht mit drin, wo ich nicht weiß, wie gut oder schlecht die AMD- gegen die Intel-Mainboards aussehen.
 
Teillastverbrauch zu messen ist so quasi unmöglich, da Teillast eben immer unterschiedlich hoch ausfällt. Fakt ist, das die CPU wohl nie vollständig im idle verweilen wird. Ohne groß Last der VMs wird das Teil also recht sparsam sein.
Da ich aber Solaris als Storage VM lese, normal müsste theoretisch der Spaß recht CPU lastig sein. Da Berechnungen auf der CPU durchgeführt werden. Was wiederum heißt, das die CPU auf einem vllt auch zwei Cores recht stark beansprucht wird, wenn Storageaktivitäten stattfinden. Ich behaupte, der Intel macht dort ne bessere Figur, weil einfach der maximale Lastverbrauch deutlich niedriger ausfällt.

Der nächste Punkt wäre, das der Vergleich der beiden CPUs hinkt. Der AMD ist auch nur deswegen so günstig, weil er einfach nur ~100€ leistet. Der Intel hingegen leistet seine ~160€ und ist damit auch deutlich fixer. Braucht man das natürlich nicht, stellt sich die Frage, ob es nicht auch ein i3 Dualcore mit SMT tut ;)
Der ist dann wiederum günstiger, braucht noch wenigst Strom und reicht imho auch vollkommen aus.

Ansonsten, 3x8GB RAM macht keinen Sinn, entweder du nimmst 2x8 oder 4x8... 3x8 passt nicht zum DualChannel Mode und drückt etwas die Performance...

ebenso solltest du dir Gedanken über die NIC machen. Sprich wie viel brauchst du an Ports. Der auf deinem verlinkten Board vorhandene Realtek geht wenn überhaupt nur sehr bescheiden mit dem ESXi. Besser wäre hier Intel. [20-25€ als 1Gbit PCIe 1x Karte)
Oder alternativ ein Board mit nativem Support (~150-160€ für S1155), dafür dann mit zwei Ports und IPMI.
 
Servus an die ESXi Spezialisten!

Habe nur eine Performancefrage.
Und zwar wollte ich ggf. am WE meinen Server aus der Signatur - wo momentan lediglich der WHS2011 drauf läuft - auf nen ESXi 5 (U1) umstellen. Darauf wollte ich FreeNAS, WHS2011 und zwei Windows 7 drauf laufen lassen.
Nun zur Frage:

Wie ist die Performance der VM's wenn ich diese auf eine physische HDD installiere? Oder eher ratsam für jede VM eine eigene HDD vorzusehen?

Danke euch schon mal...
 
Wer soll dir das beantworten?
Wir wissen weder die Anforderungen an den Storage Speed noch die Belastung deiner VMs, sowie den Speed der vorhandenen? HDD...
 
Es geht nur um die Platte wo die Betriebssysteme installiert werden sollen. Die Datenplatten (8) gehen per LSI Controller ans FreeNAS. HDD wo die Betriebssysteme installiert werden sollen ist ne Caviar Blue 7200rpm.

Oder hab ich nen Denkfehler?
 
Es gibt einen Test mit dem FX-6100, da nimmt der FX-6100 gerade mal 4 Watt im Idle auf. Komplett idle wird der Host aber so gut wie nie sein, so dass ich denke, dass der im Normalbetrieb zwischen 15 und 20 Watt aufnehmen wird. Besser wird ein i5 allerdings wahrscheinlich auch nicht sein.

Das sind aber alles nur Vermutungen, außerdem ist da das Mainboard noch nicht mit drin, wo ich nicht weiß, wie gut oder schlecht die AMD- gegen die Intel-Mainboards aussehen.
Genau so etwas hatte ich gesucht. Ok, dann ist er idle ja schon recht sparsam.
Das es noch weitere Faktoren (Board, NT, HDDs etc. gibt ist mir schon klar - lässt sich nicht vermeiden).

Teillastverbrauch zu messen ist so quasi unmöglich, da Teillast eben immer unterschiedlich hoch ausfällt. Fakt ist, das die CPU wohl nie vollständig im idle verweilen wird. Ohne groß Last der VMs wird das Teil also recht sparsam sein.
Da ich aber Solaris als Storage VM lese, normal müsste theoretisch der Spaß recht CPU lastig sein. Da Berechnungen auf der CPU durchgeführt werden. Was wiederum heißt, das die CPU auf einem vllt auch zwei Cores recht stark beansprucht wird, wenn Storageaktivitäten stattfinden. Ich behaupte, der Intel macht dort ne bessere Figur, weil einfach der maximale Lastverbrauch deutlich niedriger ausfällt.
Da hast du natürlich recht. Allerdings lässt sich nur durch höheren Verbrauch unter Last denke ich die Intel CPU nicht rechtfertigen, denn prozentual gesehen läuft das System ja die meiste Zeit unter Idle bis niedrige Teillast.

Der nächste Punkt wäre, das der Vergleich der beiden CPUs hinkt. Der AMD ist auch nur deswegen so günstig, weil er einfach nur ~100€ leistet. Der Intel hingegen leistet seine ~160€ und ist damit auch deutlich fixer.
Klar, die AMD CPU ist definitiv auf pro Takt gerechnet langsamer.
Allerdings ist die Rechnung für mich dabei auch, das ich der Storage VM 2 CPUs gebe und habe immer noch 4 Kerne für andere VMs!

Ok, niemand von euch kennt mein Anforderungsprofil aber immoment läuft das System mit einem Intel C2Q Q8200 mit mehr als ausreichend performance.
Allerdings habe ich das Problem das sich auf der Hardware kein ESXi installieren lässt :(

Die Atom CPUs wiederrum sind halt einfach zu langsam..

Braucht man das natürlich nicht, stellt sich die Frage, ob es nicht auch ein i3 Dualcore mit SMT tut ;)
Der ist dann wiederum günstiger, braucht noch wenigst Strom und reicht imho auch vollkommen aus.
Ok, ich bin technisch wohl noch auf dem Sandy-Bridge stand...
Seit wann gibt es i3 nicht-Xeon CPUs mit VT-d?

Ansonsten, 3x8GB RAM macht keinen Sinn, entweder du nimmst 2x8 oder 4x8... 3x8 passt nicht zum DualChannel Mode und drückt etwas die Performance...
Der Dualchannel Mode bringt aber doch auch "nur" <5% Performance, oder?
16GB ist "knapp" (Hypervisor/ESXi, 8GB Storage, dann bleiben vielleicht noch 10GB für 5 VMs. Reicht ist aber schon fast "knapp").
Daher ging ich lieber erstmal auf 24GB und kaufe bei Bedarf nochmal 8GB dazu.

ebenso solltest du dir Gedanken über die NIC machen. Sprich wie viel brauchst du an Ports. Der auf deinem verlinkten Board vorhandene Realtek geht wenn überhaupt nur sehr bescheiden mit dem ESXi. Besser wäre hier Intel. [20-25€ als 1Gbit PCIe 1x Karte)
Oder alternativ ein Board mit nativem Support (~150-160€ für S1155), dafür dann mit zwei Ports und IPMI.
Jap, sorry vergessen. Ich hab schon ne Dual-Port Intel PCIe Nic die ich übernehmen werde.
Beim Intel Board würde ich auf nen Q77 Chipsatz greifen ebend wegen der INtel Onboard NIC und IPMI.
Allerdings sind mir fast 100€ Aufpreis zwischen Intel und AMD das immoment noch nicht wert. Es sei denn es gibt jetzt doch i3 CPUs mit VT-d..
 
Der kleinste Intel Prozessor mit vt-d ist der i5 3350P, mit IGP der 2400er.

Ggf. brauchst du auch kein vt-d. (hab nicht alles gelesen)
Nehmen würde ich es trotzdem, so hat man wenigstens die Option.
 
Der kleinste Intel Prozessor mit vt-d ist der i5 3350P, mit IGP der 2400er.

Ggf. brauchst du auch kein vt-d. (hab nicht alles gelesen)
Nehmen würde ich es trotzdem, so hat man wenigstens die Option.

OK, den 3550P hätte ich bei einem Intel-Build auch genommen.
Also gibt es wohl keine Intel CPU mit vt-d für ein ähnliches Budget.. dann muss der FX wohl ausreichen ;)
 
Stimmt, VT-d hab ich glatt mal übersehen :fresse:

Klar, die AMD CPU ist definitiv auf pro Takt gerechnet langsamer.
Allerdings ist die Rechnung für mich dabei auch, das ich der Storage VM 2 CPUs gebe und habe immer noch 4 Kerne für andere VMs!

Bitte nicht verwechseln, die Bulldozer AMD CPUs bieten dir nicht sechs Cores!, wie es noch ein Thuban X6 tat, es ist eine "Technik" die sich CMT schimpft. Diese arbeitet gänzlich anders zu Intel bekannten SMT (HyperThreading), zeigt sich für den Enduser aber recht analog, wenn man das so sagen kann.
Im grunde ist die 6000er FX CPU ein drei Kern Prozessor, welcher durch CMT die Möglichkeit hat, quasi zur gleichen Zeit zwei Threads abzuarbeiten. Dabei hat der Spaß einige gravierende Nachteile, nämlich, wenn der Threadscheduler die Last ungünstig verteilt. Aktuell ist dies bei Windows 7 der Fall. Bei Windows 8 hat MS das Problem quasi behoben. Da der ESXi 5.0 schon ein paar Tage auf dem Buckel hat, wird es wohl ähnlich laufen.

Je nachdem, wie gut oder schlecht eine Solaris VM auf der Bulldozer Architektur performt, kann sich das aber durchaus ausgehen ;)

Der Dualchannel Mode bringt aber doch auch "nur" <5% Performance, oder?
16GB ist "knapp" (Hypervisor/ESXi, 8GB Storage, dann bleiben vielleicht noch 10GB für 5 VMs. Reicht ist aber schon fast "knapp").
Daher ging ich lieber erstmal auf 24GB und kaufe bei Bedarf nochmal 8GB dazu.

Neja, schwierig zu sagen... Das Problem ist, ich kenne keine Benches, die unter RAM Volllast Performancetest zwischen den Channelmodes durchtesten.
Fakt dürfte aber sein, je mehr Bandbreite desto besser für den Speed der VM. Einfach aus dem Grund, da man nicht nur ein OS hat, was auf die gesamt Bandbreite des RAMs zugreift, sondern eben mehrere. Die Bandbreite teilt sich. Gerade bei VMs, welche den RAM als Cache nutzen (Solaris als Storage VM) kommen enorm viel Bewegungen im RAM vor. Das drückt die Performance runter bei allen anderen VMs. Also warum nicht die 40€ mehr investieren und gleich auf Dualchannel setzen.
Reicht dir 24GB RAM, wäre ggf. auch 2x4GB zu den 2x8GB die günstigere Alternative. Vllt ahst du da sogar was rumliegen ;)
 
Hallo Ihr,

kann mir jemand einen preiswerten PCI-Raidkontroller 2..4 Ports RAID1 empfehlen, der vom ESXi 5.0U1 ohne viel Klimmzüge unterstützt wird? Der ESX muss nicht davon booten, ist alleine für einen Datastore für Openindiana und einen W2k3 DC. Habe schon bei Ebay nach preiswerten alten 3ware geschaut, aber diese tauchen leider nicht mehr in der HCL auf.
 
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