VMware vCenter op een Windows Guest

[WRT54G]

Ik heb al een tijdje een ESXi server draaien.
Sinds kort de trial gedownload van vCenter en dat werkt allemaal prima.
Ik heb de ESXi server in een DC hangen en de vCenter server draait op een machine bij mij thuis.

Nou zou het makkelijk zijn als vCenter ook in het DC erbij komt te hangen.
Anders moet ik altijd mijn aparte machine thuis aan hebben wil ik vCenter kunnen gebruiken.

Ik weet dat er (linux) appliances zijn van vCenter, deze hebben echter geen Update Manager aangezien deze alleen onder Windows werkt.

Nou vroeg ik me af is het mogelijk om op de ESXi server een Windows guest te installeren en hier vCenter inclusief Update Manager op te installeren?
Op het moment dat ik ESXi ga voorzien van patches en updates via de Update Manager gaat dat dan wel goed, aangezien de Windows guest (waar vCenter op geinstalleerd is) op dezelfde ESXi machine draait waar de updates op verwerkt moeten worden?

[Dronium]

Die installatie is zeer goed mogelijk, maar zolang je een single host hebt gaat updaten niet werken. Daarvoor moet de host in maintenance mode staan en kunnen er dus geen VMs aktief zijn. Update Manager op een VM werkt alleen bij minimaal 2 hosts en shared storage.

[ Voor 0% gewijzigd door Dronium op 03-10-2013 20:47 . Reden: spelling ]

[Room42]

Precies wat Dronium helemaal zegt

Dit is alleen een berichtje om hem te backen

[WRT54G]

Dank voor de berichten.
Dat was idd al waar ik bang voor was, vandaar ook mijn vraag...

Dan houden we het gewoon zoals het nu is.

[_Arthur]

Dronium schreef op donderdag 03 oktober 2013 @ 19:44:
Update Manager op een VM werkt alleen bij minimaal 2 hosts en shared storage.

Waarom zou Update Manager shared storage benodigd hebben?

(Lees: ik gebruik Update Manager voor een 10-15 tal ESXi machines en geen van alle hebben uberhaupt shared storage).

[ Voor 19% gewijzigd door _Arthur op 05-10-2013 09:47 ]

[Linke Loe]

Update Manager is bedoeld om je ESX hosts makkelijk van updates te voorzien, zonder downtime. Als je updates gaat installeren op een ESX host, wordt deze in maintenance mode gezet. Dat betekent dat alle VM's ofwel verplaatst worden naar een andere host, ofwel uitgeschakeld moeten worden. Als je dus zonder downtime updates wil installeren met de update manager, heb je meerdere hosts met shared storage nodig. Update Manager werkt op zich dus prima zonder shared storage, maar in dat geval dus niet zonder downtime...

[Dronium]

@ _Arthur
En draait jouw Update Manager in een VM op een van die ESXi hosts? Of staat die op een aparte fysieke host? De TS geeft aan maar één fysieke ESXi host te hebben en daar zou hij, binnen een VM, ook de Update Manager op moeten draaien. De shared storage is nodig om je VM waarop Update Manager draait te kunnen migreren tussen verschillende hosts, bij een single host gaat die vlieger dus al niet op.

Als jij via Update Manager de ESXi host weet te updaten waarop de VM van Update Manager staat hoor ik graag hoe je dat doet.

[_Arthur]

Dronium schreef op zaterdag 05 oktober 2013 @ 12:09:
@ _Arthur
En draait jouw Update Manager in een VM op een van die ESXi hosts?

Jep, die draait in een VM op een ESXi host. En ja, de VM waar Update Manager in draait verhuizen we handmatig naar een andere ESXi host indien nodig. Update Manager is bij ons niet een applicatie die High Available hoeft te zijn. Veel van onze VM's trouwens ook niet. Daar is beperkte downtime in overleg altijd mogelijk.

En, de TS rept nergens over het niet mogen hebben van downtime. Dus gewoon de VM's plat, ESXi updaten, ding laten herstarten en eventueel je VM's automatisch mee laten starten.

Als er geen downtime mag zijn, zou de TS ook niet maar 1 ESXi host hebben

[KillerAce_NL]

Als je toch maar 1 host hebt, is het overkill om met update manager te werken voor de host zelf, voor guests niet.
Lekker je vcenter virtueel draaien en je host manual patchen.

[Wim-Bart]

Manual patchen is minder werk dan een Single ESX host voorzien van update manager. In een single host omgeving heb je geen HA, dus je update manager gaat altijd down. Overigens, Virtual center virtualiseren in een single host omgeving is een twijfelachtige oplossing en ik vraag me af wat de toegevoegde waarde is. Met de VCenter cluent kan je net zo goed die host zelf managen.

[ppl]

Linke Loe schreef op zaterdag 05 oktober 2013 @ 11:42:
Update Manager is bedoeld om je ESXESXi hosts makkelijk van updates te voorzien, zonder downtime. Als je updates gaat installeren op een ESXESXi host, wordt deze in maintenance mode gezet. Dat betekent dat alle VM's ofwel verplaatst worden naar een andere host, ofwel uitgeschakeld moeten worden. Als je dus zonder downtime updates wil installeren met de update manager, heb je meerdere hosts met shared storage nodig. Update Manager werkt op zich dus prima zonder shared storage, maar in dat geval dus niet zonder downtime...

Dan heb je dus niet goed nagedacht. In dit geval heb je alleen downtime van de vm's op de betreffende ESXi doos. Dat wil niet zeggen dat je downtime van je services hebt! Het is leuk dat je failover op ESXi niveau hebt geregeld maar als een vm om wat voor reden dan ook uitvalt ben je alsnog het haasje. Je wilt uiteindelijk dat de service in kwestie blijft draaien, niet de machine die voor de service verantwoordelijk is. Je zult dus verder moeten kijken. Als je dat goed doet kun je prima zonder shared storage en zonder downtime (van de service) een ESXi host updaten/upgraden. Uiteraard werkt het met shared storage en in een ESXi cluster wat mooier maar dat is dan ook waar dat pakket zich hoofdzakelijk op richt.

Kortom, een goede voorbereiding (plannen, goed design van je infrastructuur, etc.) is het halve werk en voorkomt downtime zoveel mogelijk. Bij een single host heb je altijd downtime als je daar updates/upgrades van gaat doen en dat zul je moeten plannen. Als het je thuisbak is dan is dat wat makkelijker dan wanneer het bij een (klein) bedrijf staat (meestal boeit het mensen niet zoveel als hun eigen spul er een paar dagen uit ligt; bij een bedrijf kan dat funest zijn voor de bedrijfsvoering). Updates zijn vaak ook snel geinstalleerd en een reboot van de ESXi host kun je op een later tijdstip uitvoeren. Afhankelijk van de hardware kan een reboot ook snel zijn (als in binnen 5 a 10 minuten) waardoor zoiets prima in een lunchpauze te plannen valt. Dan is er wel downtime maar aangezien iedereen dan toch aan het lunchen is, is er geen downtime voor de gebruikers zelf.

Als je in de documentatie van Update Manager kijkt zie je dat het zal draaien op iedere machine die voldoet aan de gestelde systeemeisen. Je kunt het dus ook draaien op een dedicated stuk hardware of als vm in bijv. Workstation/Player/Fusion. Het hoeft niet op een ESXi doos. Aangezien je er een database server voor nodig hebt is het ook helemaal niet slim om het in een vm te installeren (de vSphere client met de plugin daarentegen wel) hoewel dat met 1 of 2 hosts geen probleem moet zijn. Dit soort tools in een vm draaien zie je wel vaker bij de mensen die thuis wat lopen te knutselen met ESXi/vSphere.

[KillerAce_NL]

Als je genoeg hosts hebt kun je prima alles van Vmware virtueel draaien, designkeuzes hangen van je omgeving af en kun je niet zomaar algemeen geven.

[Question Mark]

Wim-Bart schreef op zaterdag 05 oktober 2013 @ 14:56:
Overigens, Virtual center virtualiseren in een single host omgeving is een twijfelachtige oplossing en ik vraag me af wat de toegevoegde waarde is.

Waarom is het twijfelachtig? VCenter kent gewoon wat extra voordelen bv. rechtstreeks managen. Denk bijvoorbeeld aan het kunnen deployen van vm's vanuit templates, of de al aangehaalde update manager (je kunt deze nl. voor meer gebruiken dan het patchen van hosts).

Met de VCenter cluent kan je net zo goed die host zelf managen.

Maar dan mis je dus de bovengenoemde features.

ppl schreef op zondag 06 oktober 2013 @ 22:14:
[...]
Als je in de documentatie van Update Manager kijkt zie je dat het zal draaien op iedere machine die voldoet aan de gestelde systeemeisen. Je kunt het dus ook draaien op een dedicated stuk hardware of als vm in bijv. Workstation/Player/Fusion. Het hoeft niet op een ESXi doos. Aangezien je er een database server voor nodig hebt is het ook helemaal niet slim om het in een vm te installeren (de vSphere client met de plugin daarentegen wel) hoewel dat met 1 of 2 hosts geen probleem moet zijn.

Waarom is het niet slim om Update Manager in een VM te draaien?

9 van de 10 keer zie ik deze geinstalleerd staan op een dedicated Vcenter server, waar toch al een SQL server instance op geinstalleerd staat. Dat kan en mag gewoon.

[ Voor 43% gewijzigd door Question Mark op 07-10-2013 09:09 ]

[Wim-Bart]

In een single host omgeving kan ESX namelijk he VM niet migreren naar een andere host wanneer je host in maintenance mode gaat. Dat wil zeggen, je VM gaat plat tijdens het update process. Dus wanneer je VM plat is, valt er weinig te managen. Misschien doet hij het slimmer dan ik denk, maar het in mijn ogen het kip/ei verhaal. In mijn visie moet je nooit services die afhankelijk zijn van een andere service door die andere service laten hosten.

Bijvoorbeeld: Je bouwt een ZFS VM, waarbij de boot VMDK van deze VM wordt aangeboden op een iSCSI target welke door deze machine wordt aangeboden. Ik heb het gezien dat ken dat deed, even de VM moven nadat het in de lucht was.

Zelde als Virtual center niet op autostart hebben op een 16-nose HA/DRS cluster. En dan handmatig op zoek naar dat ding wanneer je hele cluster down is geweest.

Maar tja, zelfde als bij Hyper-V. Je Hyper-V cluster afhankelijk maken van een DC welke als VM in je cluster draait. Takes forever To boot, wat uiteindelijk wel lukt maar netjes is het niet.

Andere fuckups, AD authenticatie gebruiken op je iSCSI san, en de DC's op dit SAN plaatsen. Gaat goed tot je je ESX omgeving reboot.

[Raven]

Question Mark schreef op maandag 07 oktober 2013 @ 09:06:
[...]
Waarom is het twijfelachtig? VCenter kent gewoon wat extra voordelen bv. rechtstreeks managen. Denk bijvoorbeeld aan het kunnen deployen van vm's vanuit templates, of de al aangehaalde update manager (je kunt deze nl. voor meer gebruiken dan het patchen van hosts).

[...]
Maar dan mis je dus de bovengenoemde features.

Sinds 5.5 ontbreken er toch meer features als je de vCenter Client gebruikt?

The bad news: I am a home user and have uncovered an unfortunate issue with the free version of ESXi 5.5. vSphere client no longer supports editing VM settings of a version 10 machine. You must use vSphere Web Client which requires vCenter. I downloaded a trial copy of vCenter Appliance and vSphere Enterprise Plus so that I could make the required pass-thru edit from vSphere Web Client.

http://www.tinkertry.com/...er-which-isnt-free-uh-oh/

[Question Mark]

Ik snap je voorbeelden, maar het is nog steeds geen echt antwoord op de specifieke vraag waarom VCenter niet virtueel kan. VSphere HA regelen de hosts onderling, nadat ze eenmalig de ruleset vanuit VCenter ontvangen hebben.

Je enige specifieke voorbeeld gaat over een single host omgeving waarbij de host in maintenance gaat. Dat kan in een dergelijke opstelling alleen pas nadat de VM's handmatig uitgeschakeld worden. Dat voorbeeld gaat dus niet op.

Wat betreft je andere voorbeelden heb je allemaal gelijk, maar dat zijn generieke voorbeelden die fout kunnen gaan als je afhankelijkheden met een deadlock gaat neerzetten, maar daar hebben we het hier niet over.

Uiteraard moet je goed weten wat je doet met een gevirtualiseerde VCenter Server, maar ik heb nog geen reden gehoord om het niet te doen. Sterker nog, VMWare levert zelfs een VCenter appliance die bedoeld is om virtueel te draaien.

Raven schreef op maandag 07 oktober 2013 @ 12:50:
[...]
Sinds 5.5 ontbreken er toch meer features als je de vCenter Client gebruikt?

Klopt, maar het zijn even wat snelle voordelen.

[ Voor 11% gewijzigd door Question Mark op 07-10-2013 12:52 ]

[Raven]

Het - niet meer - kunnen editten van VM's lijkt mij toch best wel een essentiële functie (niet een simpel/snel voordeel) dat wel genoemd mag worden

[ppl]

Question Mark schreef op maandag 07 oktober 2013 @ 09:06:
Waarom is het niet slim om Update Manager in een VM te draaien?

9 van de 10 keer zie ik deze geinstalleerd staan op een dedicated Vcenter server, waar toch al een SQL server instance op geinstalleerd staat. Dat kan en mag gewoon.

Waarom lees je niet wat er staat? Het heeft een db server nodig en dat virtualiseren is lang niet altijd een gelukkig feest door de vele I/O. Het kan wel en ik zou het op mijn eigen setup ook wel doen maar daar zit een snelle ssd in en de databases die ik draai zullen zelden geraadpleegd worden. Er zijn er ook waarbij dat niet het geval is en waar ze met problemen kampen.

Het gaat er niet om of iets kan en mag, het gaat er om of het wenselijk en/of slim is. Je zult dus moeten nadenken over waar je mee bezig bent en wat voor implicaties het heeft. Je moet niet alles willen virtualiseren. Dat was 10 jaar geleden al zo en dat is in de loop der tijd niets veranderd.

Raven schreef op maandag 07 oktober 2013 @ 12:50:
[...]

Sinds 5.5 ontbreken er toch meer features als je de vCenter Client gebruikt?

[...]

http://www.tinkertry.com/...er-which-isnt-free-uh-oh/

Ik heb die verhalen ook gelezen en moet concluderen dat die lui typische Windows gebruikers zijn die alleen maar de GUI zijn gewend. Wat er staat klopt niet. ESXi is prima zonder vSphere client te managen getuige het feit dat vele non-Windows gebruikers dat ook doen. Sterker nog, het kan ook in Windows zonder de vSphere client (PowerCLI bijv.).

Het enige wat je moet doen is ssh toegang aan zetten (dat kan op de console van de server zelf). De instellingen van de vm's zijn nog altijd vmx files die je middels een text editor prima kunt bewerken, ook wanneer ze op hardware versie 10 zitten. Het gebruik van scripts om automatisch een vm met bepaalde settings aan te maken werkt dan ook nog prima. Ik gebruik er eentje die de vm aanmaakt en 'm meteen in de dhcp en dns server registreert. Hoef ik 'm daarna alleen van het juiste OS te voorzien. Gewoon omdat ik geen zin in al dat handmatige gedoe heb Verder is er ook weinig voordeel aan hw versie 10 als je al op 9 zit.

Ik hoop dat ze in de toekomst management via de cli beter maken (en dan wel zowel via een unix systeem als via Powershell op Windows) en er ook een webclient voor de gratis versie eraan toevoegen (een basic versie met alleen de features van de gratis ESXi is prima).

Ow, en verwar de vSphere client niet met vCenter. Die laatste bevat de licentie voor de webclient waarmee je hw 10 vm's wel via de GUI kunt beheren.

[Dronium]

ppl schreef op maandag 07 oktober 2013 @ 19:37:
[...]

Waarom lees je niet wat er staat? Het heeft een db server nodig en dat virtualiseren is lang niet altijd een gelukkig feest door de vele I/O. Het kan wel en ik zou het op mijn eigen setup ook wel doen maar daar zit een snelle ssd in en de databases die ik draai zullen zelden geraadpleegd worden.

Laten we met zijn allen even terug gaan naar wat de Topic Starter vraagt :

Marcel_EA schreef op donderdag 03 oktober 2013 @ 19:23:
Ik heb al een tijdje een ESXi server draaien.
Sinds kort de trial gedownload van vCenter en dat werkt allemaal prima.
Ik heb de ESXi server in een DC hangen en de vCenter server draait op een machine bij mij thuis.

Nou zou het makkelijk zijn als vCenter ook in het DC erbij komt te hangen.
Anders moet ik altijd mijn aparte machine thuis aan hebben wil ik vCenter kunnen gebruiken.

Ik weet dat er (linux) appliances zijn van vCenter, deze hebben echter geen Update Manager aangezien deze alleen onder Windows werkt.

Nou vroeg ik me af is het mogelijk om op de ESXi server een Windows guest te installeren en hier vCenter inclusief Update Manager op te installeren?
Op het moment dat ik ESXi ga voorzien van patches en updates via de Update Manager gaat dat dan wel goed, aangezien de Windows guest (waar vCenter op geinstalleerd is) op dezelfde ESXi machine draait waar de updates op verwerkt moeten worden?

Een SINGLE ESXi host updaten met behulp van Update Manager die draait in een VM op deze SINGLE ESXi host. Als er iemand is die kan uitleggen hoe dat te doen ga ik het meteen testen.
Voor zover ik weet is dat namelijk niet mogelijk.

[ppl]

Dronium schreef op maandag 07 oktober 2013 @ 21:22:
Laten we met zijn allen even terug gaan naar wat de Topic Starter vraagt :

Je kunt beter beginnen bij het daadwerkelijk lezen van reacties van mensen hier. Even een citaat van mezelf:

Als je in de documentatie van Update Manager kijkt zie je dat het zal draaien op iedere machine die voldoet aan de gestelde systeemeisen. Je kunt het dus ook draaien op een dedicated stuk hardware of als vm in bijv. Workstation/Player/Fusion. Het hoeft niet op een ESXi doos.

Een fysieke machine, VMware Workstation/Fusion/Player zijn geen van allen een ESXi doos. Er staat ook nergens gemeld, noch in de documentatie noch in mijn reactie, dat de Update Manager in een vm op de betreffende ESXi doos moet draaien. Dat is een ideefix van jou. Wat moet de TS nou doen? Ofwel de Update Manager gebruiken die hij elders draait (fysiek of als vm) ofwel via de commandline de updates handmatig installeren. Hij mag kiezen. Zo simpel werkt het, nergens voor nodig om er zo'n bombarie om te gaan maken.

[Wim-Bart]

Dronium schreef op maandag 07 oktober 2013 @ 21:22:
[...]

Laten we met zijn allen even terug gaan naar wat de Topic Starter vraagt :
[...]

Een SINGLE ESXi host updaten met behulp van Update Manager die draait in een VM op deze SINGLE ESXi host. Als er iemand is die kan uitleggen hoe dat te doen ga ik het meteen testen.
Voor zover ik weet is dat namelijk niet mogelijk.

Dat zeg ik ook. Wanneer je geen HA hebt waarbij de VM met Update Manager naar een andere host kan wanneer de eerste in maintenance mode gaat stopt het proces gewoon.

Virtual Center in een VM is niks mis mee, zolang je de aanbevelingen maar aanhoud. Dus zorgt dat de VM waar de database op staat eerder op is dan de VC server. En dat je de VCS maar op autostart hebt staan. Het inrichten van een hardware doos voor VC is onzinnig in een grotere omgeving. Het beste is om ook je Domain Controller te starten voordat je de VM(s) met de VCenter spullen start.

[ppl]

Oh trouwens, als je een nieuwe vm aanmaakt in ESXi 5.5 dan is dat standaard gewoon hardware versie 8. Als je 9 of 10 wil hebben zul je dat zelf moeten doen. Rightclick op de vm en upgrade hardware brengt hem naar versie 10, voor versie 9 zul je de .vmx moeten editten. Zo'n groot probleem is het in de praktijk dus niet.

[KillerAce_NL]

ppl schreef op maandag 07 oktober 2013 @ 23:02:
Oh trouwens, als je een nieuwe vm aanmaakt in ESXi 5.5 dan is dat standaard gewoon hardware versie 8. Als je 9 of 10 wil hebben zul je dat zelf moeten doen. Rightclick op de vm en upgrade hardware brengt hem naar versie 10, voor versie 9 zul je de .vmx moeten editten. Zo'n groot probleem is het in de praktijk dus niet.

Dat komt omdat je met de oude client werkt (is al zo vanaf 5.1). Vanaf 5.5 is de webversie helemaal the way to go.

[Question Mark]

ppl schreef op maandag 07 oktober 2013 @ 19:37:
[...]

Waarom lees je niet wat er staat? Het heeft een db server nodig en dat virtualiseren is lang niet altijd een gelukkig feest door de vele I/O. Het kan wel en ik zou het op mijn eigen setup ook wel doen maar daar zit een snelle ssd in en de databases die ik draai zullen zelden geraadpleegd worden. Er zijn er ook waarbij dat niet het geval is en waar ze met problemen kampen.

Ho ho... Niet elke database heeft veel I/O nodig...

Uit de Sizing Estimator for vSphere Update Manager 5.5 volgt dat een omgeving met 50 hosts en 200 VM's een Update manager database van 150 MB heeft.

Een VCenter database voor dezelfde omgeving is na 1 jaar 2,2 GB groot (VC Database calculator). Het zijn met deze aantallen niet de meest spannende databases, dit is prima te virtualiseren.

We zijn het verder wel eens hoor. Per geval zal bekeken moeten worden of virtualisatie wel de juiste optie is, maar ik reageerde even op de posts die redelijk zwart/wit stellen dat virtualiseren van VCenter geen goed idee is. After all, it all depends..

[ppl]

KillerAce_NL schreef op dinsdag 08 oktober 2013 @ 07:30:
[...]
Dat komt omdat je met de oude client werkt (is al zo vanaf 5.1). Vanaf 5.5 is de webversie helemaal the way to go.

De vSphere Client is gewoon geupgrade naar 5.5 waar je achteraf de hardware versie van een vm kunt upgraden. Als je daarvoor kiest dan upgrade hij hem naar versie 10. Met de vorige versie (5.1) was dit versie 9. Als je standaard een vm aanmaakt dan is dat inderdaad by default versie 8.

Het enige wat je met de vSphere Client niet kunt en waarom je het de stempel "oud" zou kunnen geven is het niet meer kunnen managen van hardware versie 10 vm's. Maar ja, als we eerlijk zijn, versie 10 brengt alleen leuks voor wie een gigantische omgeving heeft waarbij het cluster ook de power heeft om voor die idiote hoeveelheid disk space, mem en vCPU's te zorgen. Het gros van de mensen zal er niets aan hebben. Het enige waar we ons zorgen om moeten maken is de ontwikkeling: ze gaan steeds meer naar die webclient toe. Wat als dit niet beschikbaar gemaakt wordt voor de gratis ESXi versie? De client doet namelijk meer dan alleen vm's beheren (monitoring van performance, networking opties zoals vSwitches).

Question Mark schreef op dinsdag 08 oktober 2013 @ 09:23:
Per geval zal bekeken moeten worden of virtualisatie wel de juiste optie is, maar ik reageerde even op de posts die redelijk zwart/wit stellen dat virtualiseren van VCenter geen goed idee is. After all, it all depends..

Dat is ook gewoon wat er in mijn post stond

[KillerAce_NL]

Er is veel meer dat webclient only is, zeker als je een wat hogere licentie hebt SSO Storage drs, etc..
De normale client zal nog wel even blijven, gezien vele klanten gebruik maken van 3rd party plugins (netapp b.v.)

QM: Ter info...Ik heb even je dubbele reactie verwijderd

[ Voor 15% gewijzigd door Question Mark op 10-10-2013 09:30 ]

[ppl]

Dat is geen probleem omdat het features zijn waar je sowieso al een licentie voor moet kopen. Dan heb je ook al toegang tot vCenter. Het valt dus allemaal reuze mee, zeker voor wie zich thuis voelt op de commandline (ssh aan; gebruik maken van esxcli, esxcfg, esxtop en je kunt zo goed als alles wat je in de webinterface kunt). Er is al een simpele webclient gemaakt waarin je in ieder geval een overview van je vm's hebt en deze kunt starten/stoppen: sxi-simple-web.

[tomtom901]

KillerAce_NL schreef op donderdag 10 oktober 2013 @ 07:56:
Er is veel meer dat webclient only is, zeker als je een wat hogere licentie hebt SSO Storage drs, etc..
De normale client zal nog wel even blijven, gezien vele klanten gebruik maken van 3rd party plugins (netapp b.v.)

[mbr]QM: Ter info...Ik heb even je dubbele reactie verwijderd :)[/]

Bijvoorbeeld ook de nieuwe vSphere Flash Read Cache (FRC) kan enkel met virtual machine hardware version 10 en daarmee dus enkel via de webclient. Het is even wennen, maar werkt aanzich wel fijn. NU nog hopen dat ze de snelheid verbeteren.

[KillerAce_NL]

Als je de client langzaam vindt (heb ik het niet over de startup), check dan ook ff je free ram van je vcenter. Ik had hem aardig strak afgesteld en met wat meer ram voelde het toch responsiever.
Uiteraard geen IE gebruiken met de client, chrome is vlotter.

[tomtom901]

KillerAce_NL schreef op zondag 13 oktober 2013 @ 21:26:
Als je de client langzaam vindt (heb ik het niet over de startup), check dan ook ff je free ram van je vcenter. Ik had hem aardig strak afgesteld en met wat meer ram voelde het toch responsiever.
Uiteraard geen IE gebruiken met de client, chrome is vlotter.

Mwa met 12GB moet hij toch wel lopen. Wellicht hangt het ook samen met het aantal objecten (hosts, clusters, vm's) in de inventory.