[ervaringen/discussie] het grote virtualisatie topic

[TheBrain]

Eldee schreef op dinsdag 21 november 2006 @ 00:22:
[...]

Dus iedereen die thuis met VMware ESX wil gaan spelen moet alleen maar spullen van de HCL kopen?
Wat doe je dan op Tweakers?

Jij bent zeker ambtenaar

Iedereen die thuis met ESX wil gaan spelen moet nog steeds een licentie kopen of een VMTN abonnement afsluiten ($299). Je hebt er imho bijzonder weinig aan als je een configuratie in elkaar prutst waarmee je ESX aan de praat krijgt die gebruik maakt van componenten die niet op de HCL staan. Anders dan dat je ESX misschien geboot krijgt en een VM kan aanmaken zegt het verder weinig t.o.v. een productiesituatie.

[Arfman]

ESX is niet bedoeld om thuis mee te spelen.

[Eldee]

Arfman schreef op dinsdag 21 november 2006 @ 08:37:
ESX is niet bedoeld om thuis mee te spelen.

Ik kom als consultant zat systeembeheerders tegen die op het werk ESX beheren en die het 'leuk' vinden om er thuis mee te spelen. De meeste laten zich hier echt niet van weerhouden omdat het - volgens jou - niet bedoeld zou zijn om mee te spelen.

TheBrain schreef op dinsdag 21 november 2006 @ 08:33:
[...]
Iedereen die thuis met ESX wil gaan spelen moet nog steeds een licentie kopen of een VMTN abonnement afsluiten ($299). Je hebt er imho bijzonder weinig aan als je een configuratie in elkaar prutst waarmee je ESX aan de praat krijgt die gebruik maakt van componenten die niet op de HCL staan. Anders dan dat je ESX misschien geboot krijgt en een VM kan aanmaken zegt het verder weinig t.o.v. een productiesituatie.

Heb je wel eens gehoord van key-generators ? Die bestaan ook voor ESX hoor, daar maken die bovengenoemde systeembeheerders vaak gebruik van. (Zelf heb ik idd een VMTN (en MSDN) abo. )

Natuurlijk is het verstandig om productieomgevingen op gecertificeerde hardware te draaien.
Daarnast is het imho juist erg nuttig op b.v. ESX te (proberen) te draaien op eigengebouwde systemen, b.v. voor testdoeleinden of om er ervaring mee op te doen.
En als je hier kijkt zie zat mensen in de VMware community die dit het mij eens zijn.
Uiteraard heb jij recht op je eigen mening, maar juist op Tweakers wil ik toch de andere kant belichten.

[Zwelgje]

je kan ook gewoon een trial aanvragen van esx hoor dan hoef je ook geen keygen te gebruiken (keygen=gewoon moedwillig illegaal esx willen draaien thuis, dat heeft niks met testen meer te maken)

sanfranjake

[ Voor 4% gewijzigd door Zwelgje op 21-11-2006 22:50 ]

[MAX3400]

Foutje ontdekt... Tenminste; ik krijg iets niet aan de gang en ik moet nog uitzoeken waarom niet. VisionApp onder ESX-server kan wel volledig worden geconfigureerd; andere VM's zien de VA-server ook maar daarna houdt het op. Oftewel; de configuratie die ik heb gemaakt onder VisionApp kunnen niet naar andere VM's toe.

Toch maar eens kijken of de VM's een echte/fysieke VA-server wel zien...

[TheBrain]

Eldee schreef op dinsdag 21 november 2006 @ 22:47:
Heb je wel eens gehoord van key-generators ? Die bestaan ook voor ESX hoor, daar maken die bovengenoemde systeembeheerders vaak gebruik van. (Zelf heb ik idd een VMTN (en MSDN) abo. )

Joh, je meent het. Dat er keygens zijn was mij ook wel bekend maar dat hoeft nog niet te betekenen dat ik het met het gebruik daarvan eens hoef te zijn.

Overigens, als we toch met functies gaan gooien: ik ben teamleider van een infra afdeling (systeem- en netwerkbeheer) en security officer bij een ICT dienstverlener. Ik zorg ervoor dat mijn mensen de faciliteiten krijgen om op het werk al het experimenteerwerk met ESX te doen dat ze willen.

[Verwijderd]

Zym0tiC schreef op donderdag 16 november 2006 @ 19:16:
Zijn er al mensen die ervaring hebben met Intel VT? Wat ik zelf heb begrepen is dat deze techniek die oa op de Intel Core(2) Duo's aanwezig is tot nu toe alleen in combinatie werkt met Xen.
Ik ben wel eens benieuwd af dit nu echt zo veel scheelt, volgens wat documents van Intel zelf wel natuurlijk maar in de praktijk?

Wij werken hier inderdaad al een poosje mee en inderdaad alleen in combinatie met xen. De nieuwe xeon's komen ook met de VMX flag. Ik weet niet wat je precies bedoelt met hoeveel het scheelt? Maar als je hiermee de overhead bedoelt die is inderdaad erg laag.

De grootste toepassingen waarvoor wij (xen) virtualisatie gebruiken is om soms tot gehele racks aan servers die vaak maar 1 service aanbieden en verder 24/7 99% idle draaien te virtualizeren naar 1 machine. Of meestal 2 als het gaat om bedrijfs kritische toepassingen zodat in het geval van een crash, system failure of hardware maintenance de instances live van de ene naar de andere machiene gemigreerd worden. Dit bespaart hardware, rack space, en met name veel stroom.

Als je de keuze hebt om de services op oude machines die aan vervanging toe zijn maar eigenlijk niet meer resources zijn gaan gebruiken allemaal op 1 nieuwe snellere machine samen te voegen onder 1 OS, of ze allemaal een eigen instance te geven was het uit een beheer oogpunt voor ons gemakkelijker om voor optie 2 te gaan. Ook beveiliging is gemakkelijker, de instances worden centraal gefirewalled en als 1 service wordt gehacked is niet het hele systeem een risicofactor. Instance weggooien, snapshot van de backup server halen, lek dichten en terugzetten. Dit neemt vaak niet meer dan 5 minuten in beslag. Daarnaast is de dom0 niet beschikbaar voor de buitenwereld.

Ook het aanmaken van nieuwe instances kan gedaan worden met 1 click in een webinterface en zijn binnen een paar minuten bruikbaar.

[Eldee]

TheBrain schreef op woensdag 22 november 2006 @ 10:47:
[...]
... Dat er keygens zijn was mij ook wel bekend maar dat hoeft nog niet te betekenen dat ik het met het gebruik daarvan eens hoef te zijn.

Ik zeg nergens dat ik het gebruik van keygen's goedkeur, ik stel slechts vast dat ze bestaan en gebruikt worden. Dit is puur bedoeld als antwoord op jouw statement dat je een licentie moet aanschaffen. Maar, zoals zwelgje al aangeeft, kan je idd ook een trial licentie aanvragen.

Overigens, als we toch met functies gaan gooien: ik ben teamleider van een infra afdeling (systeem- en netwerkbeheer) en security officer bij een ICT dienstverlener. Ik zorg ervoor dat mijn mensen de faciliteiten krijgen om op het werk al het experimenteerwerk met ESX te doen dat ze willen.

Het is echt heel mooi en nobel van je dat jij ervoor zorgt dat al je medewerkers (niet cynisch bedoeld!) op hun werk naar hartelust kunnen expirimentern. Echter, pas als dat voor alle werkgevers/leidinggevenden geldt, kan je imho stellen dat het voor iedereen zinloos is om thuis met software als ESX te spelen.
Ik ben zelf tevens docent in de ICT (nog meer functies ) en hoor maar al te vaak van cursisten dat ze geen tijd en/of middelen van 'de baas' krijgen om te expirimenteren. Ze mogen vaak al blij zijn dat ze op cursus mogen, en worden geacht 'het' daarna direct in de praktijk te kunnen toepassen. Voor die mensen is vaak de enige verstandige oplossing er thuis ervaring mee op te doen (en uitkijken naar een baas zoals jij, wederom niet cynisch bedoeld).

[ Voor 1% gewijzigd door Eldee op 22-11-2006 14:21 . Reden: zin afgemaakt ]

[Arfman]

Eldee schreef op dinsdag 21 november 2006 @ 22:47:
[...]Ik kom als consultant zat systeembeheerders tegen die op het werk ESX beheren en die het 'leuk' vinden om er thuis mee te spelen. De meeste laten zich hier echt niet van weerhouden omdat het - volgens jou - niet bedoeld zou zijn om mee te spelen.

Oh nou meneer de consultant, mijn excuses hoor
ESX is bedoeld als enterprise oplossing om te virtualiseren. Dat veel beheerders er thuis mee spelen wil nog niet zeggen dat het doel van de oplossing dan ook maar veranderd.

[Eldee]

Arfman schreef op woensdag 22 november 2006 @ 15:46:
[...]
... ESX is bedoeld als enterprise oplossing om te virtualiseren. Dat veel beheerders er thuis mee spelen wil nog niet zeggen dat het doel van de oplossing dan ook maar veranderd.

En spelen is bedoeld om ergens ervaring mee op te doen...

[Arfman]

Eldee schreef op woensdag 22 november 2006 @ 16:52:
[...]
En spelen is bedoeld om ergens ervaring mee op te doen...

Prima, maar dan moet je vervolgens niet gaan mekkeren als die enterprise-oplossing niet werkt op je Athlon XP 2000+ thuis. That's my point.

[Eldee]

Arfman schreef op woensdag 22 november 2006 @ 17:11:
[...]

Prima, maar dan moet je vervolgens niet gaan mekkeren als die enterprise-oplossing niet werkt op je Athlon XP 2000+ thuis. That's my point.

Waar haal je vandaan dat ik loop te mekkeren? En waar haal je die Athlon XP 2000+ vandaan?
Heb je mijn originele post wel goed gelezen? Ik vertel daarin namelijk dat VMWare server (en dus niet ESX!) niet goed werkt op een een Intel SE moederbord, (SE staat voor Server Entry, dus geen goedkoop thuis spul, maar budget server componenten) en WEL goed werkt op een Intel Desktop bord.

Verder ben niet aan het 'mekkeren', maar mijn 'ervaring aan het delen' met mijn mede tweakers. (tip: kijk eens naar de titel van dit topic) Als jij daar geen prijs op stelt, prima, dan lees je het niet. Je hoeft mij echter niet af te kraken, omdat jij vindt dat je niet met ESX mag spelen.

Nogmaals, dit is Tweakers, een site waar dit soort ervaringen juist op prijs wordt gesteld. En er zijn ook zat Tweakers die niet alleen maar Athlon XP 2000+ systeempjes thuis hebben. En als ze dat wel hebben vinden ze het soms leuk om dit soort software hierop toch aan de praat te krijgen. En daarover dan HIER ervaringen over willen uitwisselen. Wie ben jij dan wel niet om te zeggen dat ze dat niet mogen doen?

[ Voor 5% gewijzigd door Eldee op 23-11-2006 02:29 ]

[spectator]

Hi, op het moment zijn wij de mogelijkheden van consolidatie door middel van viriualisatie aan het bekijken. Doordat het een vrij nieuw concept is (althans voor mij), is het moeilijk om hier een goed en vertrouwd gevoel bij te krijgen.

Op zich, zo globaal gezien is het voor een bedrijf met 30+ fysieke servers (ons geval) een uitkomst. Daarbij komt ook het ten einde lopen van onderhouds contracten op de hardware.

Heb dus al wat uitgezocht en ben er niet helemaal uit. Hopelijk kan iemand met ervaring op dit gebied mij een beetje clue bijbrengen.

Wij hebben veel Citrix machines en ook enkele MS SQL servers en vraag mij af of het wel verstandig is om deze te virutaliseren.
Ook gaan we binnekort van 400 mailboxen op de Exchange naar 800+. En ook hierbij vraag ik mij of het een goed idee is deze mee te nemen.

Mocht het voor bovenstaande services niet werken, dan houdt het snel op qua virualisatie.

Ook over de configuratie van het SAN gedeelte kom ik niet uit. Wordt het een FC icm iSCSI of enkel FC, als hybride kunnen er dan goedkope SATA shijven in een aparte DAE voor storage van niet veel gebruikte data en voor back-up naar disk. Nu heb je ook SAN's (EMC CX 3-20), die een 4gb's bus hebben, de FC schijven die dit ook ondersteunen zijn peperduur. Maar heb ik die 4gb's wel nodig, heb ik geen bottleneck elders. etc... In het kort de best practices.

En ook zeer belangrijk, op welk moment stap je hierin. Is VMWare 3 al stabiel genoeg om mee te starten (voorkomen upgrade en mogelijk issues). Nieuwe ontwikkelingen op hardware gebied de moeite waard om nog even uit te stellen, etc.


Heb dit topic nu gelezen en kwam een zeer interessante blog tegen. Zal hier op inhaken en lezen. Ben de naam even kwijt, maar een top idee om je voortgang te delen en zo bij te houden. Hopelijk kan het menig zoekende helpen.

O ja, ook een even belangrijk punt is het besparen op energie kosten. Naast de onderhoudscontracten en het afschrijven van hardware heb ik opgevangen dat 1 server per jaar zo'n 2400,- aan energie verbruikt. Dit lijkt mij aan de hoge kant, maar mocht het redelijk in de buurt komen, dan is dit een goede motivator om te consolideren.

Groet,
spectator.

[ Voor 8% gewijzigd door spectator op 28-11-2006 18:23 ]

[Asteroid9]

Even een korte reactie van mijn kant, ik draai ongeveer 800 Exchange 2003 mailboxen op 1 VM (ESX 2.5.2 - dual CPU - 2GB)
Geen performance problemen tot dusver.
Met MSSQL op VMware heb ik geen ervaring maar dat ga ik nog eens verder testen.

Citrix op ESX staat bij ons hoog op de verlanglijst, primair voor de standaardisatie en snapshot opties.
Hardware consolidatie is daarbij voor ons niet relevant, kostentechnisch is ESX starter een leuke optie voor een Citrix server.

De onafhankelijkheid van hardware is een verademing, helemaal als je legacy applicaties langere tijd moet supporten...

[Question Mark]

Asteroid9 schreef op dinsdag 28 november 2006 @ 20:11:
Citrix op ESX staat bij ons hoog op de verlanglijst, primair voor de standaardisatie en snapshot opties.

Op de laatste MS TechEd waar ik naartoe geweest ben, was ook een presentatie van Citrix. De spreker van Citrix gaf echter aan dat virtualisatie van Citrix Metaframe niet aangeraden wordt vanwege de performance-penalty's die je toch door virtualisatie oploopt. De bottleneck zou komen te liggen op het grote aantal I/O's, niet zozeer een memory of CPU bottleneck.

Mocht je ook een support-issue krijgen met een Citrix MF Server onder ESX, dan is het eerste wat Citrix gaat vragen, of dit probleem zich ook voordoet op een niet-virtuele server. Als hier geen problemen mee zijn, dan geeft Citrix de "schuld" aan de virtualisatie en doet verder niets met je support-call. Een hotfix voor je probleem wordt alleen opgeleverd indien je probleem reproduceerbaar is op een fysieke server. Wel iets om rekening mee te houden.

Zie ook: Support for MetaFrame with VMware ESX Server or Microsoft Virtual Server

[ Voor 12% gewijzigd door Question Mark op 29-11-2006 08:05 ]

[Arfman]

spectator schreef op dinsdag 28 november 2006 @ 18:18:
Wij hebben veel Citrix machines en ook enkele MS SQL servers en vraag mij af of het wel verstandig is om deze te virutaliseren.
Ook gaan we binnekort van 400 mailboxen op de Exchange naar 800+. En ook hierbij vraag ik mij of het een goed idee is deze mee te nemen.

Ik heb er geen hands-on ervaring mee, maar zowel Citrix, als SQL en al helemaal Exchange, worden altijd afgeraden om te virtualiseren. Sowieso worden disk intensieve applicaties (SQL, Exchange) afgeraden omdat virtualisatie (onder ESX) ervoor zorgt dat de harddiskperformance iets terugloopt, tot ongeveer 85% van wat het origineel was ongeveer.

[Abom]

Ik hoor steeds vaker dat bedrijven simpelweg alles virtualiseren. Op zich is er iets van te zeggen, persoonlijk zie ik er het nut alleen voor in, wanneer je op geen andere manier high availability kunt realiseren of wanneer die andere oplossing te duur of te complex is.

Citrix servers virtualiseren voor hardware onafhankelijkheid vind ik lichtelijk overdreven, ESX kost immers ongeveer 5.00,- euro per 2 CPUs. Er zijn legio andere mogelijkheden om je machines snel uit te rollen, op je Citrix servers hoort immers allen statische data te staan...

Aan de andere kant, wanneer alleen je Citrix servers niet gevirtualiseerd zouden zijn, zou je voor uniformiteit er voor kunnen kiezen om deze servers toch te virtualiseren.

[djluc]

Ik ben er over aan het denken om onze DC's op de vestigingen te te virtualiseren. Deze vestigingen worden nu op afstand beheerd, wat niet echt ideaal is. Het zou handig zijn als we op afstand gewoon een nieuwe virtuele image kunnen sturen welke daarna gaat booten. Zo ook met specifieke lokale software: We sturen een geteste image met daarop bijvoorbeeld een administratiepakket naar de server waarna deze gestart wordt en gebruikt kan worden.

Iemand ervaring met een dergelijke opzet? Het lijkt me veel tijd besparen aangezien we niet lokaal een pakket hoeven te installeren, te onderhouden, te backuppen enzovoorts.

[MAX3400]

djluc schreef op woensdag 29 november 2006 @ 10:52:
Ik ben er over aan het denken om onze DC's op de vestigingen te te virtualiseren. Deze vestigingen worden nu op afstand beheerd, wat niet echt ideaal is. Het zou handig zijn als we op afstand gewoon een nieuwe virtuele image kunnen sturen welke daarna gaat booten. Zo ook met specifieke lokale software: We sturen een geteste image met daarop bijvoorbeeld een administratiepakket naar de server waarna deze gestart wordt en gebruikt kan worden.

Iemand ervaring met een dergelijke opzet? Het lijkt me veel tijd besparen aangezien we niet lokaal een pakket hoeven te installeren, te onderhouden, te backuppen enzovoorts.

Dan moet je niet zozeer aan virtualiseren denken maar aan application delivery.

Ik zie zelf het nut niet om 1 server te virtualiseren op 1 fysieke server. Voor applicaties kan je denken aan (misschien) Tarpon of SVS...

[Question Mark]

djluc schreef op woensdag 29 november 2006 @ 10:52:
Het lijkt me veel tijd besparen aangezien we niet lokaal een pakket hoeven te installeren, te onderhouden, te backuppen enzovoorts.

Is een Terminal Server oplossing hier niet veel handiger voor?

[MAX3400]

Question Mark schreef op woensdag 29 november 2006 @ 10:57:
[...]
Is een Terminal Server oplossing hier niet veel handiger voor?

Als DC?

[Question Mark]

Die ben je op lokatie niet meer nodig, als je overstapt op SBC

Voor centraal beheer en backup is SBC ideaal.

[ Voor 27% gewijzigd door Question Mark op 29-11-2006 10:59 ]

[MAX3400]

Question Mark schreef op woensdag 29 november 2006 @ 10:58:
Die ben je op lokatie niet meer nodig, als je overstapt op SBC

Voor centraal beheer en backup is SBC ideaal.

Klopt, maar dan zie ik ook geen nut meer van een lokale DC. Met een beetje DSL-verbinding deel je dus met je modem/router IP-adressen uit die getunneled connecten naar een SBC-omgeving.

@djluc: kan je iets specifieker zijn met je vraagstelling?

[Asteroid9]

Question Mark schreef op woensdag 29 november 2006 @ 07:59:
[...]
Op de laatste MS TechEd waar ik naartoe geweest ben, was ook een presentatie van Citrix. De spreker van Citrix gaf echter aan dat virtualisatie van Citrix Metaframe niet aangeraden wordt vanwege de performance-penalty's die je toch door virtualisatie oploopt. De bottleneck zou komen te liggen op het grote aantal I/O's, niet zozeer een memory of CPU bottleneck.

Mocht je ook een support-issue krijgen met een Citrix MF Server onder ESX, dan is het eerste wat Citrix gaat vragen, of dit probleem zich ook voordoet op een niet-virtuele server. Als hier geen problemen mee zijn, dan geeft Citrix de "schuld" aan de virtualisatie en doet verder niets met je support-call. Een hotfix voor je probleem wordt alleen opgeleverd indien je probleem reproduceerbaar is op een fysieke server. Wel iets om rekening mee te houden.

Zie ook: Support for MetaFrame with VMware ESX Server or Microsoft Virtual Server

Bedankt voor de link, die officiele support gaat ook op voor Exchange.
Mocht het ooit zo ver komen zetten we in no time een config over naar fysieke hardware, maar ik heb nog nooit van iemand gehoord dat men dit ook daadwerkelijk heeft moeten doen.

Wel apart dat je tijdens de configuratie van een VM aan kan geven dat deze gebruikt gaat worden als Citrix server.
Kennelijk wil Citrix wel een graantje meepikken terwijl ze het anderszijds niet aanbevelen.

Arfman schreef op woensdag 29 november 2006 @ 08:56:
[...]

Ik heb er geen hands-on ervaring mee, maar zowel Citrix, als SQL en al helemaal Exchange, worden altijd afgeraden om te virtualiseren. Sowieso worden disk intensieve applicaties (SQL, Exchange) afgeraden omdat virtualisatie (onder ESX) ervoor zorgt dat de harddiskperformance iets terugloopt, tot ongeveer 85% van wat het origineel was ongeveer.

Als dat de enige reden zou zijn zorg je toch dat je een 20% snellere diskconfiguratie kiest?
Lijkt me niet iets om de hele virtualisatie maar voor af te blazen.

Zelf draai ik naar volle tevredenheid een grote Exchange omgeving op ESX.
Nou gebeurt dat wel via een SAN, maar ik kan geen meetbare verschillen vinden tussen de SAN doorvoersnelheid via een fysieke machine en via een VM.

[MAX3400]

@Asteroid9: Citrix onder VM is geen probleem. Wij hebben ook een aantal omgevingen voorzien van, pak 'm beet, 15 fysieke CTX-bakken en 2 of 3 VM/CTX-bakken. Dit voor test-doeleinden maar echt langzamer zijn ze niet, moet ik zeggen.

Kan me wel voorstellen dat de bridged networking en dergelijke een probleem kan worden maar CPU-wijs zien we weinig verschil.

[djluc]

Question Mark schreef op woensdag 29 november 2006 @ 10:57:
[...]
Is een Terminal Server oplossing hier niet veel handiger voor?

Het probleem is het veelal software is die we niet op onze centrale servers willen hebben. Denk aan oude database pakketten e.d. die niet goed met TS werken enzovoorts. Daarnaast is er sowieso een lokale server beschikbaar, wat het de meest logische stap lijkt te maken om het daarop te zetten.

MAX3400 schreef op woensdag 29 november 2006 @ 10:56:
[...]
Dan moet je niet zozeer aan virtualiseren denken maar aan application delivery.
Ik zie zelf het nut niet om 1 server te virtualiseren op 1 fysieke server. Voor applicaties kan je denken aan (misschien) Tarpon of SVS...

Je rijgt dan dus bijvoorbeeld:
1 fysieke server op locatie met:
1x dc
1x database server

Mocht er een andere vage applicatie komen kan die ook op een virtuele server. Het is geen super goede software die je middels een MSI kan deployen en vervolgens configureren middels een GPO o.i.d. Er moeten echt handmatig vinkjes gezet worden enzovoorts. Daarom dacht ik aan virtualisatie.

Daarnaast lijkt het me handig als backup: Zodra die lokale server (Meestal een redelijke goedkope server) uitvalt kan de image op een andere server gestart worden. Dan kunnen ze weer verder werken.

[Qwerty-273]

djluc schreef op woensdag 29 november 2006 @ 11:36:
Het probleem is het veelal software is die we niet op onze centrale servers willen hebben. Denk aan oude database pakketten e.d. die niet goed met TS werken enzovoorts. Daarnaast is er sowieso een lokale server beschikbaar, wat het de meest logische stap lijkt te maken om het daarop te zetten.

Trouwens een andere vorm voor virtualisatie van zulke pakketten die niet/slecht in een TS omgeving werken kan natuurlijk met het virtueel draaien van een 'werkstation' waar je naar toe connect vanuit je TS sessie via RDP/VNC (whatever). Het virtuele werkstation is zo afgeschermd dat het alleen die ene applicatie kan draaien. Per gebruiker (die deze applicaties nodig heeft) heb je dan zo'n virtueel werkstation klaar staan.
Met zo'n oplossing zou je alles centraal kunnen doen, op elke locatie alleen thinclients nodig en een VPN naar je SBC-omgeving. Punt is alleen wel een investering in centrale capaciteit en stabiele verbindingen vanuit je locaties naar je centrale punt.

[Question Mark]

@Djluc:

Al eens gekeken naar application streaming van softricity? (sinds kort overgenomen door MS) Met behulp van application streaming worden niet de servers virtueel aangeboden, maar worden de applicaties gevirtualiseerd.

Er worden dus geen applicaties fysiek geinstalleerd op een server. Applicaties worden éénmalig gepackaged en "virtueel" gedraaid.

Een mooie demo die de werking en het concept laat zien is hier te vinden. Licentiekosten zitten rond de 20 euro per client. Niet abnormaal veel

[Arfman]

Asteroid9 schreef op woensdag 29 november 2006 @ 11:07:
Als dat de enige reden zou zijn zorg je toch dat je een 20% snellere diskconfiguratie kiest?
Lijkt me niet iets om de hele virtualisatie maar voor af te blazen.

Zo werkt het niet
Bedenk dat die virtuele server nooit alleen op een ESX host draait, en dus ook geen 100% access heeft tot de harde schijf. Daarnaast is de ESX host heel druk met disk requests, en haal je de performance van alle andere machines ook naar beneden.

Wij hebben er hier voor gekozen om alleen de wat lichtere applicatieservers te virtualiseren, juist om deze reden.

[djluc]

Dat is wel een interessant idee! Ik ga daar zeker naar kijken. Al vraag ik me wel af of het concept ook werkt als je lokale server uitvalt, je internetlijn wegvalt o.i.d. In elk geval bedankt voor de tip! Het zou een hoop resources schelen i.v.m. meerdere installaties op 1 server.

[Asteroid9]

Arfman schreef op woensdag 29 november 2006 @ 13:09:
[...]

Zo werkt het niet
Bedenk dat die virtuele server nooit alleen op een ESX host draait, en dus ook geen 100% access heeft tot de harde schijf. Daarnaast is de ESX host heel druk met disk requests, en haal je de performance van alle andere machines ook naar beneden.

Wij hebben er hier voor gekozen om alleen de wat lichtere applicatieservers te virtualiseren, juist om deze reden.

Nooit? Voor onze Citrix servers gaan we dat waarschijnlijk juist wel doen.
Gelukkig heb je nu ook een ESX starter licentie die ongeveer 1000 Euro kost, heel stukje minder dan een volledige VIN.
Geen zeer gangbare situatie, maar voor versiebeheer en disaster recovery toepassingen komt dit wel degelijk voor.

Als je virtualisatie inzet voor hardwareconsolidatie komen servers die nu al >80% van hun fysieke hardware benutten uiteraard nooit in aanmerking.
Dat wil dus niet zeggen dat je SQL / Exchange / etc. niet KAN virtualiseren, maar dat je een goede kosten/baten analyse er op los moet laten.
Kostenbesparing door hardware consolidatie valt misschien af, maar er zijn nog legio andere redenen te verzinnen.

[Tylen]

Uit ervaring werkt Citrix op virtuele server best. Maar hou hem dan alleen voor test doeleinde (QA of Test omgeving) of bepaalde SILO's waar niet veel CCU's op werken. Bij een belasting van zo'n 20 CCU's word het allemaal echt traag.

[ Voor 22% gewijzigd door Tylen op 29-11-2006 14:25 . Reden: Onnodige ingo. ]

[spectator]

Asteroid9 schreef op dinsdag 28 november 2006 @ 20:11:
Even een korte reactie van mijn kant, ik draai ongeveer 800 Exchange 2003 mailboxen op 1 VM (ESX 2.5.2 - dual CPU - 2GB)
Geen performance problemen tot dusver.
Met MSSQL op VMware heb ik geen ervaring maar dat ga ik nog eens verder testen.

Citrix op ESX staat bij ons hoog op de verlanglijst, primair voor de standaardisatie en snapshot opties.
Hardware consolidatie is daarbij voor ons niet relevant, kostentechnisch is ESX starter een leuke optie voor een Citrix server.

De onafhankelijkheid van hardware is een verademing, helemaal als je legacy applicaties langere tijd moet supporten...

Is deze ESX server dedicated voor Exchange of draaien er meer containers op?
En hoe hebben jullie de maximale load geregeld op de ESX servers? Vaak is de strategie 3 servers met een maximale load van ongeveer 60% elk, zodat bij een falende server de ovrige de load op kunnen vangen.

Groet

[Abom]

Asteroid, begrijp ik het goed dat jullie van plan zijn om de hele infrastructuur (inclusief citrix servers) te virtualiseren met ESX Starter?
Mijn lijkt het juist zinvol om dan VI te gebruiken. Het beheer van alle losse ESX machines gaat je handen vol met tijd kosten...je kunt natuurlijk zaken zoals ESX Ranger gebruiken, maar persoonlijk zou ik dat niet zien zitten.

[ Voor 3% gewijzigd door Abom op 29-11-2006 16:10 ]

[Asteroid9]

spectator schreef op woensdag 29 november 2006 @ 16:03:
[...]


Is deze ESX server dedicated voor Exchange of draaien er meer containers op?
En hoe hebben jullie de maximale load geregeld op de ESX servers? Vaak is de strategie 3 servers met een maximale load van ongeveer 60% elk, zodat bij een falende server de ovrige de load op kunnen vangen.

Groet

Niet geheel dedicated, er draaien circa 7 machines waaronder 3 Exchange servers op 3 ESX servers. Dat functioneert momenteel prima, de fileserver trekt momenteel nog de meeste resources.
Daarmee is nog wel de nodige capaciteit over, zeker qua memory.
Onze strategie is inderdaad om maximaal 2/3 van de resources te benutten zodat 1 uitvallende host geen grote problemen veroorzaakt.

Abom schreef op woensdag 29 november 2006 @ 16:10:
Asteroid, begrijp ik het goed dat jullie van plan zijn om de hele infrastructuur (inclusief citrix servers) te virtualiseren met ESX Starter?
Mijn lijkt het juist zinvol om dan VI te gebruiken. Het beheer van alle losse ESX machines gaat je handen vol met tijd kosten...je kunt natuurlijk zaken zoals ESX Ranger gebruiken, maar persoonlijk zou ik dat niet zien zitten.

Momenteel draaien we nog op ESX 2.5 met Virtualcenter, deze omgeving gaan we upgraden naar VI3.
De enige toepassing waar we ESX starter voor overwegen zijn de Citrix servers, met dan 1 VM per host.
Het maken en uitrollen van bijvoorbeeld snapshots pakken we dan op via scripting.
Centraal beheer zoals in VI3 is voor onze gestandaardiseerde Citrix omgeving minder belangrijk, in elk geval niet genoeg om het prijsverschil tussen de licenties te rechtvaardigen.

[Abom]

Ik vind het vreemd dat je juist die functionaliteit, die je realiseert door het gebruik van VMware, voor Citrix gebruikt. Citrix servers zijn servers waarvan je de installatie zo moet automatiseren dat ze dmv een druk op de knop geinstalleerd kunnen worden.

Ik zou OS deployment met RIS doen en applicaties met Citrix, WISDOM of Application Deployment van AD uit laten rollen. Hiermee kun je, mocht het nodig zijn, ook in no-time je farm met weinig moeite uitbreiden (en dit kun je dus ook gebruiken om machines te 'herstellen').

Waarom zou je snap-shots van je Citrix servers willen hebben? Er hoort toch geen dynamische data op te staan?

[ Voor 3% gewijzigd door Abom op 29-11-2006 17:02 ]

[MAX3400]

Abom schreef op woensdag 29 november 2006 @ 17:00:
Ik vind het vreemd dat je juist die functionaliteit, die je realiseert door het gebruik van VMware, voor Citrix gebruikt. Citrix servers zijn servers waarvan je de installatie zo moet automatiseren dat ze dmv een druk op de knop geinstalleerd kunnen worden.

Ik zou OS deployment met RIS doen en applicaties met Citrix, WISDOM of Application Deployment van AD uit laten rollen. Hiermee kun je, mocht het nodig zijn, ook in no-time je farm met weinig moeite uitbreiden (en dit kun je dus ook gebruiken om machines te 'herstellen').

Waarom zou je snap-shots van je Citrix servers willen hebben? Er hoort toch geen dynamische data op te staan?

Eens, maar voor een snellere schaling van Citrix-omgevingen, vind ik het erg interessant om een x aantal virtuele servers te hebben staan (bijvoorbeeld op dagen dat je 99.99% van alle gebruikers ingelogd hebt) tegenover een uitgebreid fysiek farm wat misschien maar de helft van de tijd echt letterlijk niks staat te doen.

[Question Mark]

MAX3400 schreef op woensdag 29 november 2006 @ 17:24:
[...]Eens, maar voor een snellere schaling van Citrix-omgevingen, vind ik het erg interessant om een x aantal virtuele servers te hebben staan (bijvoorbeeld op dagen dat je 99.99% van alle gebruikers ingelogd hebt) tegenover een uitgebreid fysiek farm wat misschien maar de helft van de tijd echt letterlijk niks staat te doen.

Wat is het verschil dan?

In beide gevallen zal ik de hardware moeten hebben om de load van alle maximaal concurrent aangelogde users te kunnen hosten. Ongeacht of ik dit nu over fysieke servers of VM's verdeel.

Als jij op rustiger momenten VM's uitschakeld, dan staat ook je hardware niets te doen...

De uitrol van Citrix servers stelt (mits goed ingericht) niet veel voor. Installatie middels RIS en applicaties kunnen via de installation manager ge-assigned worden aan de nieuwe servers. (zoals Abom ook al terecht opmerkt).

[Asteroid9]

Abom schreef op woensdag 29 november 2006 @ 17:00:
Ik vind het vreemd dat je juist die functionaliteit, die je realiseert door het gebruik van VMware, voor Citrix gebruikt. Citrix servers zijn servers waarvan je de installatie zo moet automatiseren dat ze dmv een druk op de knop geinstalleerd kunnen worden.

Ik zou OS deployment met RIS doen en applicaties met Citrix, WISDOM of Application Deployment van AD uit laten rollen. Hiermee kun je, mocht het nodig zijn, ook in no-time je farm met weinig moeite uitbreiden (en dit kun je dus ook gebruiken om machines te 'herstellen').

Waarom zou je snap-shots van je Citrix servers willen hebben? Er hoort toch geen dynamische data op te staan?

Het ligt wel wat anders, momenteel draaien we heel wat zaken al op VMware, alleen net niet de Citrix farm.

OS deployment via RIS vind ik nauwelijks interessant voor een farm van ca. 10 servers.
Volledig automatisch installeren is zeer tijdrovend om in te richten, en niet de moeite waard voor onze omgeving. Bovendien laat lang niet iedere applicatie laat zich makkelijk via AD pushen.
Momenteel gebruiken we primair imaging om de systemen synchroon te houden, maar dat is tamelijk omslachtig.

Zonder Virtualcenter kan ik net zo snel de farm uitbreiden, het kopieren van wat .vmdk files en het booten zet je in 10 minuten in een scriptje.
Ik ben enthousiast VC gebruikers, maar voor deze toepassing zou het belachelijk duur zijn.

Citrix servers krijg je nooit 100% dichtgespijkerd, en door fouten in de applicaties krijg je vroeg of laat vanzelf corrupte files of andere systeemfouten.
Lang niet allemaal even ernstig, maar ze komen toch wel regelmatig voor.
Een toepassing van snapshots zou kunnen zijn om bijvoorbeeld op zondagnacht alle servers terug te laten springen naar hun clean install status.

[kaasaanfiets]

Hoe zit het eigenlijk met het instellen van policies?
met vmware server en workstation kun je dat niet instellen of wel?
Wel met vmware ACE maar ook met ESX?
kan je ace icm met workstation gebruiken?

[Grolsch]

ik wil dus ook gaan virtualiseren dmv van VMWARE esx, en wel gebruik makend van onze iSCSI NAS/SAN doos van Fujitsu Siemens.

De bedoeling is om het volgende te gaan virtualiseren

1 x win2k domain controller
1 x win2k SQL server
1 x win2k exchange2k server
2 x win2k database servers (oracle)
2 x NT4.0 Terminal Servers met Citrix Metaframe 1.8

Het probleem zit hem denk ik in de laatste 2, wie heeft er hier ervaringen met NT4.0 terminal servers virtualiseren

Ik wil totaal 2 x HP neerzetten met 8GB geheugen per stuk

Ik krijg as. januari een test server van mijn leverancier, dus dan ga ik er mee bezig.

Verder iemand nog tips waar ik het beste een opleiding zou kunnen gaan doen

[Zwelgje]

http://www.brianmadden.com/content/content.asp?ID=620

... na het kijken van deze video wil je vast geen citrix/ts meer op vm's draaien (tenzij je met 10 users genoegen neemt)

memory is vaak niet het probleem het probleem zit hem in cpu gebruik, ga je overigens al deze machines op 1 esx machine draaien

[ Voor 27% gewijzigd door Zwelgje op 20-12-2006 17:40 ]

[Question Mark]

Zwelgje schreef op woensdag 20 december 2006 @ 17:39:
ga je overigens al deze machines op 1 esx machine draaien

Da's ook het eerste wat in mij opkomt, theoretisch kun je de load spreiden over beide nog aan te schaffen servers, maar in het geval van calamiteiten zul je de load op één server moeten kunnen hosten...

Zeven servers (waarvan zelfs 3 stuks DB-servers zijn) lijkt me redelijk aan de hoge kant voor één server met 8 GB (ook Exchange is redelijk "memory hungry").

Eea is uiteraard wel afhankelijk van het huidige gebruik/load van de servers, maar let er wel op

[Grolsch]

de citrix servers zijn momenteel dual xeon P3 900 mhz machines met 1GB geheugen waar maar 1 published application op draait. totaal werken er zo'n 50 concurrent users op de servers, de average load per server is zo'n 800MB aan geheugen, en de processor komt niet boven de 10% uit. Zelfs alle 50 clients op 1 zo'n server gaat momenteel perfect, maar heb er 2 ivm uitwijkmogelijkheden.

zoals ik vertelde wil ik 2 esx servers aanschaffen, maar in geval van calamiteiten moet alles op 1 kunnen draaien. In een geval van calamiteit is het mogelijk een aantal minder kritische servers down te brengen.

Exchange gebruikt momenteel 1,4GB geheugen en de SQL server welke momenteel gecombineerd is met de domain controller verbruikt 1,8 GB
1 database server gebruikt 600MB geheugen (tbv die published citrix application) en de laatste database server gebruikt zo'n 1,5 GB geheugen.

Als ik dit bij elkaar optel kom ik op :

citrix x 2 = 1,6 GB
Exchange = 1,4 GB
SQL = 1,8 GB
data 1 = 0,6 GB
data 2 =1,5 GB
= totaal 7GB
Nu wil ik dus wel een losse DC virtueel gaan maken, dus zal iets bij op komen.

Wat ik met heb laten vertellen (of wijs heb laten maken) is dat je niet "domweg" het verbruikte geheugen mag optellen, maar dat VMWARE er vriendelijker mee omgaat.

de reden van het virtualiseren van die NT4 bakken is afscheid nemen van oude hardware ivm verlopen support packs etc.

[Spectre75]

Abom schreef op woensdag 29 november 2006 @ 17:00:
Ik vind het vreemd dat je juist die functionaliteit, die je realiseert door het gebruik van VMware, voor Citrix gebruikt. Citrix servers zijn servers waarvan je de installatie zo moet automatiseren dat ze dmv een druk op de knop geinstalleerd kunnen worden.

Ik zou OS deployment met RIS doen en applicaties met Citrix, WISDOM of Application Deployment van AD uit laten rollen. Hiermee kun je, mocht het nodig zijn, ook in no-time je farm met weinig moeite uitbreiden (en dit kun je dus ook gebruiken om machines te 'herstellen').

Waarom zou je snap-shots van je Citrix servers willen hebben? Er hoort toch geen dynamische data op te staan?

Hangt helemaal af van hoe je je Citrix Farm gebruikt.

Bij ons wordt de Citrix boerderie gebruikt met relatief veel verschillende published apps (+/- 150 applicaties) Maar per app niet zoveel gebruikers. Komt ook nog eens bij dat die app's veel updates kennen. Dus het is altijd een heel gepuzzel om apps te verdelen over de verschillende servers (ene app heeft Office 97 (I know ) nodig en een ander kan alleen met Office 2003 werken, weer een ander alleen met .Net1 of .Net2 en zo kan ik nog een tijdje doorgaan.)

Dus hebben wij gekozen om alle Citrix servers te virtualiseren, en dat is op 1 app (van de 150) goed gelukt. Je maakt als het ware silo's van apps die mekaar kunnen verdragen en per silo reken je op 15-20 gebruikers. En we hebben het voordeel van snapshots van je VMWare images erbij. In het verleden is het al meermaals voorgekomen dat na een update van app A, app B niet meer wilde werken.

Als je een beperkte/constante applicatie korf hebt voor je Citrix met veel gebruikers per app, zie ik geen reden op dat op ESX te zetten.

[Question Mark]

Spectre75 schreef op donderdag 21 december 2006 @ 15:09:
Dus het is altijd een heel gepuzzel om apps te verdelen over de verschillende servers (ene app heeft Office 97 (I know ) nodig en een ander kan alleen met Office 2003 werken, weer een ander alleen met .Net1 of .Net2 en zo kan ik nog een tijdje doorgaan.)

In het verleden is het al meermaals voorgekomen dat na een update van app A, app B niet meer wilde werken.

Elkaar "bijtende" applicaties, of applicaties die elkaar op een andere manier dwars zitten, is in Presentation Server 4.0 op te lossen met Application Isolation Enviroment (AIE). Voor mij dus nog steeds geen reden om Citrix Servers te virtualiseren.

[ Voor 21% gewijzigd door Question Mark op 21-12-2006 19:24 ]

[Grolsch]

kan één van de VMWARE experts mij nog tips geven of bekritiseren na mijn laatste post

Is het mission imposible wat ik wil

[Spectre75]

Question Mark schreef op donderdag 21 december 2006 @ 18:34:
[...]
Elkaar "bijtende" applicaties, of applicaties die elkaar op een andere manier dwars zitten, is in Presentation Server 4.0 op te lossen met Application Isolation Enviroment (AIE). Voor mij dus nog steeds geen reden om Citrix Servers te virtualiseren.

Dat is de theorie (je voelt hem al aankomen) maar de praktijk is natuurlijk anders

Even een voorbeeldje:

Access 97 frontend applicatie die met een Oracle ODBC driver moet praten met een Sun Oracle server.
In AIE werkt dit dus niet.

Applicaties die andere apps aanroepen (Office, PDF reader, ....) moeten allemaal in je AIE zitten wil het goed werken.

AIE is een eerste stap, maar nog geen super oplossing !!!

[Zwelgje]

Spectre75 schreef op dinsdag 26 december 2006 @ 16:15:
[...]


Dat is de theorie (je voelt hem al aankomen) maar de praktijk is natuurlijk anders

Even een voorbeeldje:

Access 97 frontend applicatie die met een Oracle ODBC driver moet praten met een Sun Oracle server.
In AIE werkt dit dus niet.

Applicaties die andere apps aanroepen (Office, PDF reader, ....) moeten allemaal in je AIE zitten wil het goed werken.

AIE is een eerste stap, maar nog geen super oplossing !!!

in versie 4.5 heb je straks application streaming heb je ook minder last van bijtende apps. (ala softricity)

softricity is nu van microsoft dus daar verwacht ik ook wel het eea van

[Spectre75]

@Zwelgje

Ook bij application streaming heb je het probleem dat je stream eventuele andere apps moet kunnen 'zien'......

Voor zaken zoals Office of PDF kan je die gewoon buiten de stream op je Citrix servers zetten. Maar voor zaken die dieper in je OS zitten (zoals ODBC drivers of andere zaken die in het OS zitten verweven ) gaat het (nog) niet lukken

Maar ze zitten zeker op de goede weg !!!!

[Tylen]

Tarpon is zeker een mooi product. Maar softricity werkt nog steeds beter.

@Grolsch: Kiijk eens naar PlateSpin. Daarmee kan je heel makkelijk je servers omzetten naar VMWare.

[Grolsch]

Jeroen_Tielen schreef op woensdag 27 december 2006 @ 11:09:
Tarpon is zeker een mooi product. Maar softricity werkt nog steeds beter.

@Grolsch: Kiijk eens naar PlateSpin. Daarmee kan je heel makkelijk je servers omzetten naar VMWare.

ik ken platespin kwa naam, maar ik zou graag praktijk ervaringen horen van mensen welke daadwerkelijk een NT4.0 Terminal server gevirtualiseerd hebben mbv platespin

[Zwelgje]

* Zwelgje meldt

werkt prima wij gebruiken zelf ook dergelijke software om productiemachines van onze klanten 'mee te nemen' naar ons testlab of om productiemachines te virtualiseren, werkt echt super!

alleen gebruiken wij geen platespin maar andere software (volgens hetzelfde principe)

[TheBrain]

Zwelgje schreef op donderdag 28 december 2006 @ 16:17:
* Zwelgje meldt

werkt prima wij gebruiken zelf ook dergelijke software om productiemachines van onze klanten 'mee te nemen' naar ons testlab of om productiemachines te virtualiseren, werkt echt super!

alleen gebruiken wij geen platespin maar andere software (volgens hetzelfde principe)

Dan ben ik benieuwd welke aangezien bijvoorbeeld Leostream of VMware Converter alleen Windows machines kunnen virtualiseren.

Als iemand nog een converter weet die LVM kan converteren naar LVM dan hou ik me aanbevolen.

[Zwelgje]

Lvm

Linux Virtual Machine

* Zwelgje doet geen linux maar alleen windows enterprise meuk

sorry

[TheBrain]

Zwelgje schreef op vrijdag 29 december 2006 @ 13:25:
Lvm

Linux Virtual Machine

* Zwelgje doet geen linux maar alleen windows enterprise meuk

sorry

Hehe, Logical Volume Manager --> http://en.wikipedia.org/wiki/Logical_volume_management (in ons geval: http://sources.redhat.com/lvm2/)

Ik ben niet heel technisch onderlegd op dit vlak maar grofweg kan je daarmee logische volumes definieren op je hardwarematig aangemaakte RAID array. Met LVM is het bijvoorbeeld heel makkelijk om een volume te vergroten.

Ik heb het een en ander beschreven in de log die in mijn sig staat (virtualize, zoeken op lvm).

[Grolsch]

ik krijg de 22e en 23e iemand van m'n leverancier om een VMWARE server te testen icm onze NT4.0 citrix servers, we zijn benieuwd

Iemand hier nog tips mbt opleidingen

[MrBarBarian]

TheBrain schreef op dinsdag 02 januari 2007 @ 01:00:
[...]

Hehe, Logical Volume Manager --> http://en.wikipedia.org/wiki/Logical_volume_management (in ons geval: http://sources.redhat.com/lvm2/)

Ik ben niet heel technisch onderlegd op dit vlak maar grofweg kan je daarmee logische volumes definieren op je hardwarematig aangemaakte RAID array. Met LVM is het bijvoorbeeld heel makkelijk om een volume te vergroten.

Ik heb het een en ander beschreven in de log die in mijn sig staat (virtualize, zoeken op lvm).

Wat is je vraag dan? LVM naar LVM? Euh.. converter??

[TheBrain]

MrBarBarian schreef op vrijdag 12 januari 2007 @ 09:40:
[...]

Wat is je vraag dan? LVM naar LVM? Euh.. converter??

Zwelgje zei dat hij goede converter software had, anders dan Platespin. Ik vroeg me af welke aangezien ik nog geen software was tegengekomen die fatsoenlijk een fysieke server met LVM kan converteren naar een virtuele server met LVM.

We zijn er namelijk nog niet in geslaagd om een Linux VM (SLES9) zijn disks te laten expanden zonder LVM. Dus als er een converter zou zijn die LVM to LVM kan dan heb ik daar wel interesse in

Toen vroeg Zwelgje zich weer af wat LVM was en dat heb ik toegelicht.

[sanfranjake]

TheBrain, ik denk dat Zwelgje www.invirtus.com bedoelt. Dat is software die ik laatst ook op zijn aanraden eens heb uitgeprobeerd Werkt erg goed.

[Verwijderd]

Net bezig geweest met een contract op te stellen voor het huren van een server. Een virtuele server dit keer

[djluc]

Dat vinden we mooi...

Nog interessante details te melden hierover?

[Verwijderd]

djluc schreef op maandag 15 januari 2007 @ 22:47:
Nog interessante details te melden hierover?

Voornamelijk dat het qua beheer een stuk handiger wordt. Mocht de machine ooit nog gereboot worden, dan hoef je niet van je stoel af te komen En de klant heeft toch het idee een eigen servertje te hebben zonder dat er hardware aan te pas komt.

(en of je dit interessant vindt verschilt natuurlijk per persoon )

[Question Mark]

Verwijderd schreef op maandag 15 januari 2007 @ 22:59:
[...]Voornamelijk dat het qua beheer een stuk handiger wordt. Mocht de machine ooit nog gereboot worden, dan hoef je niet van je stoel af te komen

Da's ook met fysieke servers zo.....

[DJ-B]

Het is me nu nog niet helemaal duidelijk hoe je de backup goed kunt inregelen.

Stel je hebt VMware Server draaien met ongeveer 7-8 Guests.
Is het dan mogelijk om elke nacht automatisch een snapshot op een centrale file server / SAN te plaatsen? Dit moet natuurlijk gebeuren als de Guests on-line zijn.

Als het host systeem onderuit gaat en ik kan niet meer bij mijn VM bestanden wil ik natuurlijk wel een backup hebben zodat ik die eenvoudig op een ander systeem kan importeren.

Ik heb al wat documentatie doorgelezen maar kan er niet echt een duidelijk antwoord op krijgen.

[Jazzy]

Ik zou niet weten hoe. Wat je kunt doen is de VM's klassiek backuppen met backupsoftware naar keuze en wekelijks een kopie van de images trekken. Daarvoor moet je ze wel even down brengen maar in de meeste settings kan dat wel op bijvoorbeeld zondagochtend.

Zo heb je altijd een VM van maximaal 6 dagen oud en een volledige backup om de meest recente data/systemstate te restoren.

Je kunt dit trouwens scriptmatig doen, als je het interessant vind wil ik wel even een scriptje zoeken.

[Zwelgje]

met MS Virtualserver kan je met ntbackup gewoon draaiende hosts backuppen .. niks geen 3rdp party voor nodig. werkt ideaal

[Abom]

Wijzigingen naar op virtual disks worden, ook in GSX/Server, eerst naar een redo-log gekopieerd. Volgens mij moet je met ntbackup gewoon een backup kunnen maken van de directory waar je vmdk en redo-log files staan.
Ik ben niet zo thuis in ntbackup, maar volgens mij kan ntbackup onder 2003 open files backupen door gebruik te maken van VSC.

Onder ESX kan het zeker, iemand heeft een erg handig perl script hiervoor gemaakt (www.vmts.net).

[Stouten]

Op mijn werk zijn we bezig om een server in te richten voor het compilen van software onder diverse omgevingen.

De bedoeling is dat er als moeder OS Ubuntu 6.06.1 LTS 64 64 Bit komt te draaien op een Dual Xeon 3.2 Ghz met 4 GB Ram. Het is de bedoeling onder Ubuntu dan een SQL database te gaan draaien en de benodigheden voor het compilen van software. Ook word er voor de nodige security gedraaid in mirror Raid en is het de bedoeling deze bak te voorzien van LVM.

Nu komt dus de issue, er komen namelijk een aantal verschillende machine's onder te draaien met behulp van VMWare Server:

- Windows XP Professional
- Windows XP Professional 64 bit
- Vista
- Mac Os X PowerPC (Iemand hier trouwens ervaring mee onder VMWare Server?)

Elke nacht zal de boel compleet worden gebackuped. Maar nu vraag ik mij af of het niet beter is om het compilen van software (voor linux) ook te gaan doen in een VMWare machine. Mede omdat hardware nog wel eens kapot wil gaan en het makkelijker is om een image van vmware ergens weer te draaien dan het systeem compleet terug zetten (op wss andere hardware).

Mijn grote vraag is dus, wat is het wijste om te doen met betrekking tot de veiligheid?

[Abom]

Ten eerste zul je OS X PowerPC niet onder VMware kunnen draaien. VMware emuleert de CPU namelijk niet.

Het idee om VMware te gebruiken zodat de verschillende machines hardware onafhankelijk zijn heb ik eerder gezien. Het idee vind ik interessant, maar ik zou het alleen inzetten wanneer ik 99,999% uptime zou willen hebben. Maar dan zou ik kiezen voor VMware ESX/VI ipv VMware Server en daar zit een prijskaartje aan. Sowieso is er een limiet aan de resources die VMware Server aan kan.
A-merk hardware is toch zeker betrouwbaar genoeg? Gewoon voor HP of Dell kiezen en regel een goed support contract.

[Stouten]

Oke, dan zullen we toch moeten gaan voor de Intel versie hiervan en het compilen van software voor de PowerPC zal dan gewoon gebeuren op een Mac die hier nog staat. VMWare Server zal wel voldoen voor onze doeleinde, aangezien er niet de hele dag onder elk OS gecompiled hoeft te worden (een keer in de week hoogstens). We draaien al op HP en Dell systemen overigens.

Maar waarom zou je het alleen inzetten als je 99,999% uptime zou willen hebben? Het is de bedoeling dat we alles op 1 test machine hebben en makkelijk de boel kunnen benaderen op deze manier. Multi-boots zijn geen optie vanwege het feit dat er een database naast draait die 99,999 % uptime vereist voor onze software devvers.

[Abom]

Volgens mij heb ik je verhaal verkeerd begrepen, de eerste keer dat ik het las. Imho kun je er best een extra vmm langs plaatsen voor een linux guest os.

[DJ-B]

Zwelgje schreef op vrijdag 19 januari 2007 @ 22:16:
met MS Virtualserver kan je met ntbackup gewoon draaiende hosts backuppen .. niks geen 3rdp party voor nodig. werkt ideaal

Je schrijft dat je de host kan backuppen. Kun je dan gewoon alle Guests met ntbackup kopieeren?
Ik wil dus niet de Guests backuppen maar de VM van de guests zodat ik deze indien nodig op een andere machine kan aankoppelen

[Zwelgje]

DJ-B schreef op maandag 22 januari 2007 @ 09:59:
[...]


Je schrijft dat je de host kan backuppen. Kun je dan gewoon alle Guests met ntbackup kopieeren?
Ik wil dus niet de Guests backuppen maar de VM van de guests zodat ik deze indien nodig op een andere machine kan aankoppelen

je kan met ntbackup op de host de .vhd files backuppen terwijl de machines draaien.

[Grolsch]

wij zijn dus 1,5 dag bezig geweest om de test esx server te installeren.

Allereerst de argumentatie.
Wij draaien hier 2 NT4.0 Terminal Servers met Citrix Metaframe 1.8 welke dateren uit 2000.
Dit zijn dual xeon 1000mhz processoren met 1,5GB geheugen.
Op deze servers draait alleen onze ERP applicatie dmv published applications.

De reden om te virtualiseren is de verouderde hardware, en niet de performance.
We zijn zo afhankelijk van ons ERP pakket dat we niet het risico kunnen en willen lopen dat de hardware kadoek gaat. En probeer op recente hardware maar eens NT4.0 aan de praat te krijgen.

Maandag morgen ervoor gezorgt dat er geen gebruikers waren ingelogt. Vervolgens voor platespin een iets geinstalleerd (framework ofzo ) en dat vereist een reboot.
Server gaat uit, en gewoon NIET meer aan.
Geen piepjes, geen beeld, helemaal niets noppes nada behalve een legertje draaiende ventilatoren.

WAAROM GEBEURT DIT ALTIJD ALS HET NIET UITKOMT

Troubleshooting, geheugen, processor, switches, videokaart vormden allemaal niet het probleem.
Toen bleek de Mylex RAID controller het probleem te veroorzaken. Na het verwijderen van deze kaart starte het systeem wel door. Na wat knooi en puzzelwerk gelukkig nog ergens zo'n mylex kaart gevonden hier uit een ander oude server.

Nu is dus duidelijk wat de risico's zijn van oude hardware !

Uiteinde toen de hardware weer werkte (maandag laat in de middag) was de migratie redelijk gauw gepiept.
Dinsdag morgen begonnen met platespin, en om 11:00 was de NT server virtueel.
Her en der wat tweaken met de hal.dll ivm multiprocessor etc. etc. de M en de N schijven weer recht zetten, een aantal permissions onder de m:\wtsrv klopten niet meer maar om 12:00 werkt dat ding compleet naar behoren!

Nu draaien alle citrix users op de virtuele server, en tot nu toe geen klachten

[Qwerty-273]

Grolsch schreef op woensdag 24 januari 2007 @ 10:58:
Maandag morgen ervoor gezorgt dat er geen gebruikers waren ingelogt. Vervolgens voor platespin een iets geinstalleerd (framework ofzo ) en dat vereist een reboot.
Server gaat uit, en gewoon NIET meer aan.
Geen piepjes, geen beeld, helemaal niets noppes nada behalve een legertje draaiende ventilatoren.

WAAROM GEBEURT DIT ALTIJD ALS HET NIET UITKOMT

Troubleshooting, geheugen, processor, switches, videokaart vormden allemaal niet het probleem.
Toen bleek de Mylex RAID controller het probleem te veroorzaken. Na het verwijderen van deze kaart starte het systeem wel door. Na wat knooi en puzzelwerk gelukkig nog ergens zo'n mylex kaart gevonden hier uit een ander oude server.

Nu is dus duidelijk wat de risico's zijn van oude hardware !

Ten eerste gefeli met de geslaagde migratie
En bovenstaande gebeurt inderdaad wel vaak met 'oude' servers die jaren zonder problemen dienst doen en pas als er 'onderhoud' aan gaat gebeuren en er een reboot volgt. Dan komen de problemen naar voren, bv voeding die niet meer de benodige piek spanning kan leveren met het opstarten of inderdaad raid controllers die het voor gezien houden.

[Jazzy]

Grolsch schreef op woensdag 24 januari 2007 @ 10:58:
Allereerst de argumentatie.
Wij draaien hier 2 NT4.0 Terminal Servers met Citrix Metaframe 1.8 welke dateren uit 2000.
Dit zijn dual xeon 1000mhz processoren met 1,5GB geheugen.
Op deze servers draait alleen onze ERP applicatie dmv published applications.

Inderdaad, file met de geslaagde klus en bedankt voor je verslagje.

Je schrijft dat je met 2 Citrix-servers werkte, draaien die nu op 1 fysieke server? Kun je wat meer vertellen over de nieuwe hardware, aantal gebruikers en serverbelasting?

[Grolsch]

Jazzy schreef op woensdag 24 januari 2007 @ 11:43:
[...]
Inderdaad, file met de geslaagde klus en bedankt voor je verslagje.

Je schrijft dat je met 2 Citrix-servers werkte, draaien die nu op 1 fysieke server? Kun je wat meer vertellen over de nieuwe hardware, aantal gebruikers en serverbelasting?

tnx voor de felicitaties

1 vd 2 citrix servers draait nu virtueel

momenteel zitten zijn er 20 users ingelogd op de server

dit is het screen van VMWARE



de server nu is een dual xeon P4 3,4 GHZ dus er zijn 6,8 GHZ'en te verdelen.

gisteren had ik de andere server (fysieke) gedisabled, en toen was de average load ik meende 900 mhz met pieken tot 1500 mhz, niet slecht al zeg ik het zelf

[Question Mark]

Grolsch schreef op woensdag 24 januari 2007 @ 10:58:
Wij draaien hier 2 NT4.0 Terminal Servers met Citrix Metaframe 1.8 welke dateren uit 2000.

We zijn zo afhankelijk van ons ERP pakket dat we niet het risico kunnen en willen lopen dat de hardware kadoek gaat. En probeer op recente hardware maar eens NT4.0 aan de praat te krijgen.

Thanx voor het leuke verslag!

Maar waarom nog steeds NT4 en niet meteen overgestapt naar een nieuwer OS? Is dit vanwege applicatie-requirements of om de doorlooptijd van de transitie te verkorten? [/nieuwsgierig]

[Grolsch]

Question Mark schreef op donderdag 25 januari 2007 @ 12:56:
[...]
Thanx voor het leuke verslag!

Maar waarom nog steeds NT4 en niet meteen overgestapt naar een nieuwer OS? Is dit vanwege applicatie-requirements of om de doorlooptijd van de transitie te verkorten? [/nieuwsgierig]

Dit is vanwege de applicatie welke stamt uit 1998 en gebaseerd is op magic versievlaknadeoorlog.
De leverancier van het ERP pakket is sinds 2002 failiet.
De firma waar ik werzaam ben heeft het goede voornemen binnen nu en een jaar over te stappen naar een nieuw ERP pakket, maar je kent managers en deathlines

trouwens vandaag het voorstel + financiële begroting ingeleverd bij de directie, gaat over zo'n 50.000 € voor 2 VMware dozen

[ Voor 8% gewijzigd door Grolsch op 26-01-2007 00:58 ]

[reapher]

Ja en Nee, je draaid nu 2 keer een OS. Dus je creerd een extra SPOF. immers je ESX server kan ook crashen. Eingenlijk creer je 2 * een SPOF met ESX, je hebt 2 kernels draaien. een Linux Redhat kernel voor de console en je vmware kernel. Beide kunnen niet zonder elkaar. Als de 1 onder uitgaat gaat de andere ook onderuit. Maar dit is over het algemeen wel vele vele malen stabieler. ESX werkt ook gegarandeerd op de supporte hardware. Je kan ook garantie geven op de CPU/memory. Dat gaat je niet lukken met vmware server. Daarom adviseerd vmware ESX server.

Even voor de duidelijkheid de Redhat achtige kernel is een vm. Dit betekend dat je server dus gewoon zonder deze vm kan draaien. Gaat dit down dan doen je andere vmtjes het nog goed. Gaat de vm kernel down heb je een probleem maar deze is zo klein en zonder toeters en bellen dat de kans dat dit gebeurt niet groot is.

Geld overigens ook voor de vs

[Rolfie]

reapher schreef op zaterdag 27 januari 2007 @ 01:11:
[...]


Even voor de duidelijkheid de Redhat achtige kernel is een vm. Dit betekend dat je server dus gewoon zonder deze vm kan draaien. Gaat dit down dan doen je andere vmtjes het nog goed. Gaat de vm kernel down heb je een probleem maar deze is zo klein en zonder toeters en bellen dat de kans dat dit gebeurt niet groot is.

Geld overigens ook voor de vs

Ze kunnen niet zonder elkaar. De Linux kernel is nodig net zoals de vm kernel. Beide zijn nodig voor het vmware OS.
Volgens mij is het in esx 3 niet meer een losse vm Maar dit weet ik niet meer helemaal zeker.

[Abom]

Rolfie schreef op zaterdag 27 januari 2007 @ 10:18:
[...]

Ze kunnen niet zonder elkaar. De Linux kernel is nodig net zoals de vm kernel. Beide zijn nodig voor het vmware OS.
Volgens mij is het in esx 3 niet meer een losse vm Maar dit weet ik niet meer helemaal zeker.

Je ESX machine blijft gewoon overeind, ook wanneer je management console onderuit ligt. Op het moment dat je management console onderuit is, kun je alleen niet meer zoveel met de machine doen... Vanuit dat opzicht hebben ze inderdaad mekaar nodig. Maar het is niet zo dat de vmm's afhankelijk zijn van het management console om te kunnen draaien.

[ Voor 23% gewijzigd door Abom op 27-01-2007 14:02 ]

[Eldee]

Abom schreef op zaterdag 27 januari 2007 @ 14:00:
[...]

Je ESX machine blijft gewoon overeind, ook wanneer je management console onderuit ligt. Op het moment dat je management console onderuit is, kun je alleen niet meer zoveel met de machine doen... Vanuit dat opzicht hebben ze inderdaad mekaar nodig. Maar het is niet zo dat de vmm's afhankelijk zijn van het management console om te kunnen draaien.

Hmm, maar hoe zit het met het opstarten van de host, b.v. als het filesystem waar het management console corrupt raakt? Ik heb eens gehad, tijdens het testen van diverse iSCSI targets het systeem (in mijn ogen de Red Hat kernel) niet verder wilde starten omdat er een iSCSI target niet meer beschikbaar was, en deze blijkbaar persé gemount moest worden. Na een uur heb ik het systeem maar hard gereset (het was toch een test systeem) en vervolgens wilde VMware niet meer starten omdat het filesystem corrupt was geraakt (niet het VMFS, althans nog niet). Na een fchk wilde het systeem inclusief VMware weer wel starten, maar bleek de enige guest ook niet meer te starten, maar het VMFS was volgens mij wel in orde. Ik had/heb echter te weinig kennis van VMware ESX om uit te zoeken wat er nu precies mis was met de guest.

De vraag die ik hieraan overhield is dus hoe afhankelijk VMWare bij ESX afhakelijk is van de - volgens reapher en Abom als Virtual Machine draaiende - RedHat kernel.

Het doe mij als oude rot namelijk veel denken aan de oudere Novell Netware versies, die als OS MS-DOS gebruiken om de PC te starten en met een loader het Netware OS van disk in het geheugen van het systeem te krijgen. Op het moment dat het werkelijke Netware OS draait zit DOS nog steeds in het geheugen, en als je Netware afsloot kwam je weer terug in DOS. Je kon overigens het geheugen reclaimen met het 'remove DOS' commando, maar dan kon je niet meer terugkeren naar DOS als je netware afsloot.

[ Voor 4% gewijzigd door Eldee op 28-01-2007 02:04 ]

[Abom]

Het klopt dat eerst Redhat boot. Maar de Redhat kernel wordt tijdens het boot process vervangen door de vmkernel en de redhat instance wordt vervolgens de eerste virtual machine.

Ik heb een keer gehad dat het management console helemaal niet meer reageerde, kwam er met geen mogelijkheid meer op, ssh, telnet en de webinterface werkte allemaal niet meer. Maar de virtual machines liepen vlekkeloos door. Ik heb de machine uiteraard wel gereboot op het moment dat het mogelijk was, aangezien backups vanuit het management console liepen.
Verder zie je bij top ook maar één CPU ipv 2, 4 of meer.

[anvil]

Ik zie hier vooral veel over VMWare... zijn er ook ervaringen met Xen?

Mijn scenario :

Momenteel een netwerk met 7 clients, een oude NT4 server (P2 machine) en een "zware" CentOS3 server (P4 met 1GB RAM)

NT4 word binnenkort uitgefaseerd, maar vanwege uitbreiding (15 extra XP clients, nieuwe software met een Win32 backend) moet er een Win2k3 server komen... deze zal echter alleen voor SUS en als CAD backend worden gebruikt en dus amper draaien. CentOS machine draait file&printer sharing, bovendien draait er een grote Advantage database op (circa 3 GB data totaal) voor het ERP systeem

De CentOS machine moet ook worden vervangen, waarschijnlijk door CentOS5 (zou over dik een maand uit moeten zijn) Tevens willen we naar een "Failsafe" systeem gaan met een hot spare...

Nou is mijn idee 2 zware CentOS5 servers, met hierop Xen en zowel CentOS5 als Win2k3 virtueel. Door middel van heartbeat software wil ik dat op de 'backup' services automatisch worden opgestart als de main host down gaat. Dit om downtime te voorkomen. Volgens mij door aan VM's IP's te koppelen moet dit mogelijk zijn met minimale verstoring van de clients?

Het liefst zou ik natuurlijk de 'free' versie van Xen gebruiken, zit echter met wat vragen :
- Op dit moment bevat de 'free' versie schijnbaar niet alle benodigde VT drivers, iemand enige ervaring met de performance zonder en met die drivers (vergelijking zou mooi zijn)
- Hoe bepaal je de optimale splitsing tussen de guest OS'es? Ik heb nu op een Linux machine zowel database, samba, sendmail als caching DNS draaien. Kan ik het beste voor vrijwel iedere task een apart guest OS opzetten of doe ik er beter aan dingen als sendmail/DNS te combineren en alleen database en samba eigen dedicated guest OS te geven? Kan nergens whitepapers vinden over beste verdeling (heb oa Xen site en de daar gegeven links naar community sites bezocht)
- Hoe goed zal dit werken met dual/quad Xeons? Kan ik systeem zelf resources laten managen of moet ik harde limits instellen om vastlopen te voorkomen?
- Zijn er mensen die ervaring hebben met het opstarten van VM op een andere machine met zelfde IP? Hoe gaat bijvoorbeeld Windows file&print sharing ermee om?

Redenen dat ik naar virtualisatie kijk :
- 4 servers ipv 2 (om toch failsafe te kunnen werken) kost veel meer ruimte, die we niet echt hebben.
- Onze huidige database server laat soms hele grote load pieken zien (door slecht ontwerp, maar daar kan ik niks aan doen), maar die zijn zo sporadisch dat ik alleen daarvoor eigenlijk geen systeem kan kopen als ik voor andere taken ook nog servers moet aanschaffen, gezien budget (2 grote zware servers zijn circa 10000 totaal, 4 minder zware ben ik ruim 12000 kwijt)
- Remote beheer... ik gebruik nu SSH voor remote beheer, met Windows erbij zou dat lastiger worden (zou ik VNC moeten gebruiken oid) Overigens : ik ben meer thuis in Linux dan Windows, dus eventuele tips zouden welkom zijn.

[Abom]

Voor zover ik weet kun je met Xen nog geen Windows guests draaien. Sowieso nu zonder VT/Pacifica support.
Verder hoor ik dat Xen nog iets te experimenteel is en veel hack werk is om goed aan het werk te krijgen, maar ik heb er zelf geen ervaring mee.

[ Voor 11% gewijzigd door Abom op 28-01-2007 16:40 ]

[Jazzy]

Xen kan alleen gepatchte kernels draaien dus het is niet echt transparante virtualisatie.

[anvil]

Als ik http://www.xensource.com/files/xen_install_windows.pdf doorneem zie ik niks over een gepatchte kernel, blijkbaar kan w2k3 er op draaien... of mis ik nu iets?

[Jazzy]

anvil schreef op zondag 28 januari 2007 @ 17:52:
Als ik http://www.xensource.com/files/xen_install_windows.pdf doorneem zie ik niks over een gepatchte kernel, blijkbaar kan w2k3 er op draaien... of mis ik nu iets?

Als je een processor met VT hebt. In het artikel was je aanhaalt staat:

Requirements
• A VT-enabled Intel system or an AMD-V enabled AMD system with 1GB or more of physical memory

Zolang je die niet hebt kan Xen alleen gepatchte kernels draaien. De actuele lijst van processors die geschikt zijn voor HVM (HardwareVirtualMachine):

AMD(TM)
HVM should work with all CPU's in the AMD-V (SVM) series. The desktop processors must be for the "socket AM2" with DDR2 and F2 stepping that are not Sempron brand.

Athlon™ 64 3800+
Athlon™ 64 3500+
Athlon™ 64 3200+
Athlon™ 64 3000+
Athlon™ 64 FX FX-62
Athlon™ 64 X2 Dual-Core 5000+
Athlon™ 64 X2 Dual-Core 4800+
Athlon™ 64 X2 Dual-Core 4600+
Athlon™ 64 X2 Dual-Core 4400+
Athlon™ 64 X2 Dual-Core 4200+
Athlon™ 64 X2 Dual-Core 4000+
Athlon™ 64 X2 Dual-Core 3800+
Notebook processors are all branded Turion 64 X2.

Turion(TM) 64 X2 TL-60
Turion(TM) 64 X2 TL-56
Turion(TM) 64 X2 TL-52
Turion(TM) 64 X2 TL-50
AMD Opteron™ with DDR2

1000 Series
2000 Series
8000 Series
AMD Processor's may be compared with the tools at http://www.amdcompare.com/us-en/default.aspx?sid=txtlnk


Intel(R)
See also - IntelVT

Intel® 2 Core(TM) Duo Extreme processor X6800
Intel® 2 Core(TM) Duo processor E6700
Intel® 2 Core(TM) Duo processor E6600
Intel® 2 Core(TM) Duo processor E6400
Intel® 2 Core(TM) Duo processor E6300
Intel® Core(TM) Duo processor T2600
Intel® Core(TM) Duo processor T2500
Intel® Core(TM) Duo processor T2400
Intel® Core(TM) Duo processor L2300
Intel® Pentium® processor Extreme Edition 965
Intel® Pentium® processor Extreme Edition 955
Intel® Pentium® D processor 960
Intel® Pentium® D processor 950
Intel® Pentium® D processor 940
Intel® Pentium® D processor 930
Intel® Pentium® D processor 920
Intel® Pentium® 4 processor 672
Intel® Pentium® 4 processor 662
Intel® Xeon® processor 7041
Intel® Xeon® processor 7040
Intel® Xeon® processor 7030
Intel® Xeon® processor 7020
Intel® Xeon® processor 5080
Intel® Xeon® processor 5063
Intel® Xeon® processor 5060
Intel® Xeon® processor 5050
Intel® Xeon® processor 5030

[reapher]

Vind dat zen er nog niet helemaal is. Maar volgens mij kan dit in toekomst zeker een goede player worden.

Tot nu toe is het zeker nog vmware in mijn ogen. Maar een beetje concurentie kan geen kwaad. Vmware is nou niet echt de goedkoopste.

Zen mist in mijn ogen nog een beetje het centraliseren van multi servers. Maar ik heb vernomen dat hier verandering in komt.

[Jazzy]

Wat ik me trouwens afvraag, over 64-bits guests. Als ik het goed begrijp heb je om 64-bits guests te draaien onder VMware Server een processor met Intel VT of AMD Pacifica nodig. Als je die niet hebt dan kun je geen 64-bits guests draaien.

Maar het gebruik van een 64-bits host-OS levert wel voordeel op omdat je meer dan 4GB kunt verdelen over de guests. Toch?

[Abom]

De enige beperking die ik ken is dat het alleen mogelijk is dat je alleen 64bit guests kunt draaien op een 64bit host OS. Volgens mij kun je zowel 32bit als 64bit guests draaien op een 64bit host.

[Jazzy]

Abom schreef op maandag 29 januari 2007 @ 15:43:
De enige beperking die ik ken is dat het alleen mogelijk is dat je alleen 64bit guests kunt draaien op een 64bit host OS. Volgens mij kun je zowel 32bit als 64bit guests draaien op een 64bit host.

Als ik het goed begrijp stel je dat je met een 64-bits host OS geen 32-bits guests kunt draaien. Dat klopt niet.

[Eldee]

Abom schreef op maandag 29 januari 2007 @ 15:43:
De enige beperking die ik ken is dat het alleen mogelijk is dat je alleen 64bit guests kunt draaien op een 64bit host OS. Volgens mij kun je zowel 32bit als 64bit guests draaien op een 64bit host.

Nee hoor, dat is geen beperking. Ik heb hier VMware Server draaien op een 32-bits versie van Windows 2003 met daarop als guests Windows 2003 64-bits. Vooral handig om Exchange 2007 te testen. Uiteraard is dit niet slim als je meer dan 4 GB geheugen moet/kunt/wil gebruiken, maar het is iig geen beperking.

[Jazzy]

Maar dan heb je dus wel een processor met VT?

[Abom]

Jazzy schreef op maandag 29 januari 2007 @ 15:47:
[...]
Als ik het goed begrijp stel je dat je met een 64-bits host OS geen 32-bits guests kunt draaien. Dat klopt niet.

Mn eerste zin is wat slecht. Wat ik stel is dat je minimaal een 64bit OS als host moet hebben om 64bit guests te kunnen draaien. Langs deze 64bit guests kun je ook 32bit guests draaien.

Maar blijkbaar heeft Eldee die stelling al ontkracht

[ Voor 6% gewijzigd door Abom op 29-01-2007 17:19 ]

[Eldee]

Jazzy schreef op maandag 29 januari 2007 @ 16:14:
Maar dan heb je dus wel een processor met VT?

Klopt. Volgens mij heb je altijd een processor met VT nodig om 64-bits guests te draaien, of je host nu 32-bits is of 64-bits. Heeft te maken met de architectuur van VMware en geheugen-segmentatie.

[Stouten]

Eldee schreef op dinsdag 30 januari 2007 @ 23:07:
[...]

Klopt. Volgens mij heb je altijd een processor met VT nodig om 64-bits guests te draaien, of je host nu 32-bits is of 64-bits. Heeft te maken met de architectuur van VMware en geheugen-segmentatie.

Nee hoor, ik draai hier 64-bits ubuntu versies onder vmware op een amd sempron 2800+ zonder de mooie VT techniek... VMWare server gebruik ik hiervoor.

[ Voor 3% gewijzigd door Stouten op 01-02-2007 23:38 ]

[Eldee]

Stouten schreef op donderdag 01 februari 2007 @ 23:30:
[...]
Nee hoor, ik draai hier 64-bits ubuntu versies onder vmware op een amd sempron 2800+ zonder de mooie VT techniek... VMWare server gebruik ik hiervoor.

Bedankt voor de correctie/aanvulling t.a.v. NON-Windows platforms. Ik heb zelf alleen ervaring met Windows OSsen als host en guest en Intel processoren, vandaar dat ik zei 'volgens mij'.
Ik herhaal/verduidelijk hierbij dat je volgens mij je bij met VMware Server altijd een Intel processor met VT nodig hebt om 64-bits Windows guests te draaien, of je host nu 32-bits is of 64-bits Windows is. Dat heb ik namelijk zelf getest op de Intel Pentium 630 en Pentium D 820 zonder VT en de Pentium D 920 en Core2Duo E6300 mét VT.