Gathering of Tweakers

quote:

Grolsch schreef op woensdag 26 maart 2008 @ 09:07:
[...]


Yup, ik ga meerdere 500GB grote VRAID5 VMFS volumes maken, zodat ik een beetje spreiding heb, en ik ga geen RDM gebruiken.

Dus gewoon een cold migration denk ik dan en als dat niet lukt, gewoon met winscp

Ik kon even niet vinden of je de HBA's al in de server had zitten maar een cold migrate is in dat geval wel het makkelijkst.

quote:

TheBrain schreef op donderdag 27 maart 2008 @ 23:17:
[...]

Ik kon even niet vinden of je de HBA's al in de server had zitten maar een cold migrate is in dat geval wel het makkelijkst.

HBA's zaten niet in de server, maar gewoon stuk voor stuk in maintence mode zetten, en HBA's plaatsen.

Gisteren 90% van de VM's gemigreerd, en wat een performance verschil

Een bepaalde verwerking duurde eerder 35 minuten, met de EVA teruggebracht naar 6 minuten

quote:

Jazzy schreef op zondag 28 januari 2007 @ 17:34:
Xen kan alleen gepatchte kernels draaien dus het is niet echt transparante virtualisatie.

Vergeet geen ouderscheid te maken tussen Xen die je van een website trekt en bijvoorbeeld Xen Enterprise. Ik gebruik Xen Enterprise en daarbij kun je gewoon je eigen kernel bouwen, zonder aanpassingen.

Zijn er ondertussen al mensen die ervaring hebben met het virtualiseren van parallel? Parallel naar IP oid? En kun je gewoon ISDN kaarten virtualiseren?

quote:

jep schreef op zondag 06 april 2008 @ 21:54:
[...]

Vergeet geen ouderscheid te maken tussen Xen die je van een website trekt en bijvoorbeeld Xen Enterprise. Ik gebruik Xen Enterprise en daarbij kun je gewoon je eigen kernel bouwen, zonder aanpassingen.

Kan met de Open Source Xen ook hoor. Da's namelijk exact hetzelfde, maar dan zonder dat XenServer management appje. Je hebt alleen wel (net als met XenEnterprise) hardwareondersteuning nodig. (En de performance is bagger-- ik raad 't af als je ook paravirtualized kunt draaien.)

quote:

CyBeR schreef op vrijdag 18 april 2008 @ 00:41:
[...]


Kan met de Open Source Xen ook hoor. Da's namelijk exact hetzelfde, maar dan zonder dat XenServer management appje. Je hebt alleen wel (net als met XenEnterprise) hardwareondersteuning nodig. (En de performance is bagger-- ik raad 't af als je ook paravirtualized kunt draaien.)

Paravirtualisatie lukt alleen met OSen die 'virtualisatie-aware' zijn. Dat lukt op dit moment alleen met open source OSen. Windows moet dus altijd fully virtualized worden. Wel zijn er (o.a. van Novell/Suse) driver packs te krijgen met 'accelleration drivers' die toch een betere, snellere performance bieden voor Windows.

Alle Xen producten zijn in essentie hetzelfde, al vindt er de laatste tijd wel een behoorlijke versplintering plaats. Performance hoeft niet bagger te zijn, dat is maar net hoe je het inricht!

We willen hier binnenkort gaan upgraden naar ESX 3.5 (we hebben nu 3.0.2).

Zijn er al mensen welke dit gedaan hebben En kan ik rare zaken verwachten

quote:

Grolsch schreef op vrijdag 18 april 2008 @ 09:26:
We willen hier binnenkort gaan upgraden naar ESX 3.5 (we hebben nu 3.0.2).

Zijn er al mensen welke dit gedaan hebben En kan ik rare zaken verwachten

Wij hebben dit enkele weken geleden gedaan en toch wel wat issue's gehad.

Bij een van de ESX-servers lukte de upgrade niet (we konden de VM's niet vmotionen naar de reeds ge-upgrade node). Uiteindelijk is dit met behulp van VMWare Nederland wel gelukt (supportcall aangemaakt), alleen lukte hierna de upgrade zelf niet, waarna een complete re-install van ESX nodig was op deze node.

Nadat beide ESX-servers geupgrade waren, hadden we het probleem dat na het vmotionen van een VM de cpu-usage naar 100% liep. In onderstaand VMWare KB staat een workaround beschreven (wat ook weer flink wat uitzoekwerk gekost heeft):

http://kb.vmware.com/self...KC&externalId=1003638

Al met al een redelijk moeizame migratie. Overigens was dit volgens onze leverancier een uitzondering en verlopen de meeste upgrades vlekkeloos.

Question Mark wijzigde dit bericht 18-04-2008 10:17 (4%)

quote:

Question Mark schreef op vrijdag 18 april 2008 @ 10:11:
[...]
Wij hebben dit enkele weken geleden gedaan en toch wel wat issue's gehad.

Bij een van de ESX-servers lukte de upgrade niet (we konden de VM's niet vmotionen naar de reeds ge-upgrade node). Uiteindelijk is dit met behulp van VMWare Nederland wel gelukt (supportcall aangemaakt), alleen lukte hierna de upgrade zelf niet, waarna een complete re-install van ESX nodig was op deze node.

Nadat beide ESX-servers geupgrade waren, hadden we het probleem dat na het vmotionen van een VM de cpu-usage naar 100% liep. In onderstaand VMWare KB staat een workaround beschreven (wat ook weer flink wat uitzoekwerk gekost heeft):

http://kb.vmware.com/self...KC&externalId=1003638

Al met al een redelijk moeizame migratie. Overigens was dit volgens onze leverancier een uitzondering en verlopen de meeste upgrades vlekkeloos.

tsjah, volgens leveranciers zijn problemen altijd uitzonderingen, en verloopt normaal gesproken altijd alles soepel

Ik vind praktijk ervaringen veel geloofwaardiger

Tnx voor je tips!

misschien dat iemand hier een handige oplossing heeft :

ik heb inmiddels 7 esx servers draaien in 1 cluster (ha + drs)
nu zoek ik een handige oplossing om een nieuwe vlan (virtual switch) op alle nodes aan te maken
het is erg veel handwerk om per vlan 7 handmatige aanmaak acties te doen... (/foutgevoelig)

Hebben ze daar niet zo'n mooie scriptable API voor dan?

leuk om 'mijn' topic nog in leven te zien

is er onderhand iemand die ervaring heeft met Xen live migratie? Het werkt perfect hier op een 2 node DRBD'ed cluster, maar het kost toch ~40secs downtime... Nu gebruik ik een 100mbit netwerk voor de DRBD en migratie, dus wellicht dat een gbit netwerk dit kan terugbrengen naar ~4secs, maar graag jullie ervaringen

de upgrade naar ESX 3.5 is geheel vlekkeloos verlopen.

Alles zonder 1 seconde downtime

quote:

Grolsch schreef op zaterdag 03 mei 2008 @ 19:35:
de upgrade naar ESX 3.5 is geheel vlekkeloos verlopen.

Alles zonder 1 seconde downtime

Onzin, je ESX servers zijn down gegaan.
Maar ik snap wat je bedoeld.

Ik heb de upgrade naar 3.5 een maand geleden uitgevoerd, en tot nu toe geen problemen geconstateerd met VC2.5 en ESX 3.5

quote:

nzyme schreef op zaterdag 03 mei 2008 @ 16:57:
leuk om 'mijn' topic nog in leven te zien

is er onderhand iemand die ervaring heeft met Xen live migratie? Het werkt perfect hier op een 2 node DRBD'ed cluster, maar het kost toch ~40secs downtime... Nu gebruik ik een 100mbit netwerk voor de DRBD en migratie, dus wellicht dat een gbit netwerk dit kan terugbrengen naar ~4secs, maar graag jullie ervaringen

Bij Xen live migratie hoor je in ieder geval geen downtime te hebben. Gewoon helemaal niet.

Welke Xen software gebruik je?

quote:

seq_uence schreef op dinsdag 06 mei 2008 @ 21:41:
[...]


Onzin, je ESX servers zijn down gegaan.
Maar ik snap wat je bedoeld.

Ik heb de upgrade naar 3.5 een maand geleden uitgevoerd, en tot nu toe geen problemen geconstateerd met VC2.5 en ESX 3.5

De ESX servers zijn wel down geweest, maar de VM's geen seconde

Lang leve Vmotion

Hebben we ook zo gedaan bij onze Xen Enterprise upgrade (ook geen downtime). Zolang je genoeg capaciteit hebt om een machine vrij te maken kun je gewoon altijd upgraden.

quote:

jep schreef op dinsdag 06 mei 2008 @ 22:50:
[...]

Bij Xen live migratie hoor je in ieder geval geen downtime te hebben. Gewoon helemaal niet.

Welke Xen software gebruik je?

nieuwe poging met beter hardware (gbit oa.) geeft inderdaad maar een paar ms downtime en dat is niet hinderlijk natuurlijk werkt perfect dus, met Xen 3.0.3 rpm op CentOS 5.

Echter, ik heb nu het volgende probleem icm migraties:

DomU starten op node1, ssh sessie starten: werkt ok
Migreren naar node2, ssh sessie blijft behouden: alles in orde
wget 100mb.bin, hangt, en heeft even later met 48.8GB/sec de file binnen: klopt van geen kant
migreer terug naar node1, opnieuw wget doen en gaat normaal: prima

Snap het niet

de servers gebruiken onboard Broadcom gbit nics voor migratie en DRBD doeleinden (crosslink) en hebben een 10/100 realtech kaart voor normaal verkeer. Iig wel 2x dezelfde chips.

Wat ook opvalt, als ik vanuit een windows machine de VM ga pingen en vervolgende een migratie start lijkt de downtime vrij lang (afhankelijk van startpunt vd migratie, node1 of node2), maar als ik op zowel node1 als node2 ook een ping sessie begin met de VM is het antwoord wat ik op de windows bak terug krijg vele malen sneller

heeft iemand ervaring met de ESX VDI versie ?
is dit een addon bovenop normale ESX, dus is de licentie gewoon te gebruiken voor een normale ESX machine ?
Ik vraag dit omdat we de laatste keer bij het aanschaffen van een ESX enterprise licentie een ESX VDI licentie hebben als extratje erbij hebben gehad

quote:

With your purchase of qualifying VMware Virtual Infrastructure 3 products between December 29, 2007 and February 28, 2008, you have qualified for a free VMware Virtual Desktop Infrastructure (VDI) Starter Kit with one year of complimentary VMware Gold Support and Subscription. This promotional offer of product and support cannot be exchanged or used as credit. Full promotion terms and conditions can be found at

http://www.vmware.com/vmw...tarterkitpromo_terms.html.

ik heb vandaag de gratis licentie toegevoegd aan onze license server en het lijkt gewoon te gebruiken als iedere andere ESX enterprise license
(ik krijg ook netjes 2 Vmotion en 2 HA licenses erbij)

alleen :

quote:

total commercial list price value of the VDI Starter Kit is $1500

dan vraag ik mij af waarom ik voortaan niet gewoon VDI startkits koop, stuk goedkoper als de normale ESX Enterprise.
Dus volgens mij mis ik een detail oid

quote:

Audi-Addict schreef op donderdag 06 maart 2008 @ 07:52:
Nog even een vraag, is het verstandig om in een vmware machine extra nics mee te pakken voor elke i/o gevoelige VM?

Maakt het dan nog wat uit of ik 2 in 1 nics pak (gbit) of losse van 1?

Had je inmiddels al extra NICs toegevoegd? Ben benieuwd naar je ervaringen, omdat ik ook met hetzelfde idee rondloop. Sommige VM's worden erg traaaaaag als er flink netwerkverkeer is namelijk.

quote:

nose schreef op zondag 11 mei 2008 @ 10:08:
[...]

Had je inmiddels al extra NICs toegevoegd? Ben benieuwd naar je ervaringen, omdat ik ook met hetzelfde idee rondloop. Sommige VM's worden erg traaaaaag als er flink netwerkverkeer is namelijk.

in de performance guide van vmware staat wel het eea uitgelegd over netwerkkaartjes (en welke je moet hebben)

http://www.vmware.com/pdf/vi_performance_tuning.pdf

ikzelf prik altijd extra nics in (idd van die 4 in 1 dingen, maar poortjes per slot immers)

Okee dan, staan inderdaad wel handige dingetjes in. Gebruik zelf (nog) geen ESX maar de "gewone" VMware Server, maar ik denk dat de meeste tips daar ook wel op van toepassing zijn.

quote:

nose schreef op zondag 11 mei 2008 @ 19:48:
Okee dan, staan inderdaad wel handige dingetjes in. Gebruik zelf (nog) geen ESX maar de "gewone" VMware Server, maar ik denk dat de meeste tips daar ook wel op van toepassing zijn.

ESX en vmware server is een complete wereld van verschil....

vmware=windows/linux host gebaseerde virtualisatie, esx=baremetal

quote:

DDX schreef op vrijdag 09 mei 2008 @ 17:49:
dan vraag ik mij af waarom ik voortaan niet gewoon VDI startkits koop, stuk goedkoper als de normale ESX Enterprise.
Dus volgens mij mis ik een detail oid

Je mag op een VDI licentie alleen maar werkstation OS'en draaien. Daarom kunnen ze hem goedkoper aanbieden dan een gewone ESX. Overigens kan je met de VDI licentie inderdaad alle Enterprise functies van ESX gebruiken zodat je ook voor je virtuele werkstations dezelfde VMWare functies kan gebruiken als dat je voor je servers al gewend bent (als je VI Enterprise gebruikt althans).

Hou ook even rekening met het feit dat de Starter Kit uitgaat van VMWare VirtualCenter Server Foundation dus maximaal 3 hosts en je mag bij een Starter Kit maar maximaal 10 concurrent desktops hebben draaien in tegenstelling tot 100 concurrent desktops bij de standaard Bundle.

quote:

nzyme schreef op donderdag 08 mei 2008 @ 15:04:
[...]

nieuwe poging met beter hardware (gbit oa.) geeft inderdaad maar een paar ms downtime en dat is niet hinderlijk natuurlijk werkt perfect dus, met Xen 3.0.3 rpm op CentOS 5.

Ik zou nog niet helemaal tevreden zijn met een paar ms downtime. Ik heb namelijk helemaal geen downtime. Dus ook geen ping, hapering in remote desktop of SSH, enzovoort. Ik denk dus wel dat er iets nog niet goed is.

De andere problemen herken ik niet, maar we werken al een tijdje niet meer met de open source versie. Daarbij hadden we ook best wel een hoop gedoe moet ik zeggen.