Hoofdcategorieën
Device Settings

[RSS] [quick] Index » Nieuws » Pro » Software » Virtualisatie » Bug in licentiecomponent maakt Vmware ESX 3.5 onbruikbaar

Bug in licentiecomponent maakt Vmware ESX 3.5 onbruikbaar

Door Harm Hilvers, dinsdag 12 augustus 2008 13:51
Submitter: LeNNy, views: 12.970

Een bug in de licentiemodule van Vmware ESX 3.5 zorgt ervoor dat het virtualisatiepakket niet meer wil opstarten. Vmware heeft de fout erkend en werkt nog aan een definitieve oplossing. Een workaround is reeds beschikbaar.

Sinds dinsdag geeft versie 3.5 Update 2 van Vmware ESX en ESXi een foutmelding. Uit nader onderzoek bleek dat deze melding wordt gegeven omdat de licentie volgens het systeem onbruikbaar is. De fout treedt op bij het opstarten, het uit de slaapstand laten komen en het via Vmotion verplaatsen van een virtuele machine. Alleen reeds opgestarte virtuele machines kunnen daardoor nog gebruikt worden.

Vmware heeft het probleem in zijn zakelijke virtualisatieproduct bevestigd, maar het bedrijf heeft nog geen tijdelijke of definitieve oplossing beschikbaar gesteld. Gebruikers van Vmware ESX hebben echter zelf een workaround ontwikkeld: door de datum binnen de virtualisatiesoftware in te stellen op een datum voor 12 augustus zou het probleem worden omzeild. Dit zorgt er echter ook voor dat de tijd in de gevirtualiseerde servers wordt teruggedraaid, wat voor grote problemen in de draaiende software kan zorgen.

Volgende 14:16 Videostreams Olympische Spelen scoren goed
Vorige 13:18 Opengl 3.0 met gemengde gevoelens ontvangen
Advertentie

Categorieën

Lees meer over

Gerelateerde content

Reacties

Flat modeFlat mode Sorteer aflopendSorteer aflopend Moderatie FAQModfaq
Niveaufilter: -1 Ongewenst: 53 reacties zichtbaar530 Off-topic / Irrelevant: 52 reacties zichtbaar52+1 On-topic: 17 reacties zichtbaar17+2 Informatief: 13 reacties zichtbaar13+3 Spotlight: 0 reacties zichtbaar0
«  1  2  3  »

Door intGod, dinsdag 12 augustus 2008 13:52

Score: 0
Lijkt wel een verlate Y2K bug.

Volgens mij zit er nu een team programmeurs peentjes te zweten :)

[Reactie gewijzigd door intGod op dinsdag 12 augustus 2008 13:53]

Door rammes, dinsdag 12 augustus 2008 13:58

Score: 0
lekker in een Active Directory. deze gaat volgens mij dan ook op z'n gat.

Door BVGorp, dinsdag 12 augustus 2008 14:08

Score: 2
Als je in VMWare Tools op de server de time synch met de onderliggende ESX server aan hebt staan gaat dat inderdaad mis :) Als je deze niet aan hebt staan is er niets aan de hand

[Reactie gewijzigd door BVGorp op dinsdag 12 augustus 2008 14:09]

Door brompot758, dinsdag 12 augustus 2008 14:55

Score: 1
Dat klopt niet helemaal. Als een virtuele machine opstart dan neemt hij de datum/tijd over van de host machine. De time sync in VMware tools zorgt ervoor dat het OS in sync blijft met de host.

Wil je structureel afwijken van de host tijd dan moet je de time sync in vmware tools uitzetten en in de opstart scripts syncen aan een andere tijdbron, zoals een NTP server. Het is bovendien verstandig om periodiek opnieuw te syncen met deze externe tijdbron.

Door LordPan, dinsdag 12 augustus 2008 14:06

Score: 1
we hebben het net voorgehad. Geen printen meer mogelijk, mails lijken van een week terug te komen, etc. Maar geen ergere dingen (tot nu toe) tegen gekomen
Waren op 1 esx server vergeten af te zetten dat hij de tijd met zijn hosts mag syncroniseren. Er stond natuurlijk onze PDC op...
Datum manueel terug gezet, en de clients rondgegaan, maar goed dat we hier nog in halve verlof zijn en 70 à 80% van de mensen werken nog niet. Hierna geen problemen meer. Morgen om 22u zou er een update moeten zijn volgens VMWare.

Door AlBundy, dinsdag 12 augustus 2008 15:45

Score: 0
Daarom heb je ook een testomgeving voor. Volgens mij is dat de basisles van elke systeembeheerder, dat je eerst test voordat je een patch in productie brengt.

Door siepeltjuh, dinsdag 12 augustus 2008 15:48

Score: 0
Echter als het hele bedrijf plat ligt, je weet wat het probleem is ga je niet een test omgeving opzetten, testen en dan uitrollen.

In zo`n geval wil je wel eens direct actie ondernemen. Natuurlijk kan het dan voorkomen dat je een vinkje hier of daar vergeet...

Alles beter dan je baas te moeten uitleggen dat er een bug zit in de zojuist aangeschafte systemen van 100.000 + euro.

Door WPN, dinsdag 12 augustus 2008 16:05

Score: 0
ik leg liever uit aan mn baas dat er een bug in de software zit en dat we NIET live gaan
dan dat we live gaan en servers plat gaan wanneer ze verplaatst worden en dat met een omweg nu de tijden niet kloppen waardoor xx pakket over hun nek gaan

dan maar test omgeving ook al ligt het halve bedrijf plat door vakantie :)

Door TheTeek, dinsdag 12 augustus 2008 16:24

Score: 2
Als alles voorkoombaar zou zijn wat zou het leven dan mooi zijn.

je kan nog zoveel testen in een test omgeving, maar je test niet dat iets niet werkt vanaf 12 augustus of 13 augustus of....

Gelukkig kwamen we dit probleem tegen in een omgeving die nog niet life is, maar wel life moet eind deze week... _/-\o_

Door arjankoole, dinsdag 12 augustus 2008 22:19

Score: 2
de ESX update was getest, en was goed, alleen zat er vanuit de beta nog een 'expire' in van 12 augustus. Hoe ga je dat testen?

dus, op alle ESX doosjes netjes de update uitgerold, hij was harstikke goed per slot van rekening, en BOOM 12 augustus feest.

Je principe van testen is leuk, maar werkt niet altijd in de echte wereld :) en als je eenmaal last hebt op al je productie omgevingen, dan wil je wel gaan truuken zodat men tenminste nog 'wat' kan doen.

Door scsirob, dinsdag 12 augustus 2008 22:29

Score: 2
Als het een moedwillige beta expire was dan zou je toch verwachten dat de logs een paar dagen van tevoren een waarschuwing zouden beginnen te spugen??

Door arjankoole, dinsdag 12 augustus 2008 22:54

Score: 2
Nee, want met de beta wist je dat toen je hem downloade, en waren logmeldingen vooraf overbodig. (dat is althans de filosofie gok ik). Bij de productie versie was dat natuurlijk niet ter sprake, en heb je een hele stille nare bug.

De productie versie expired namelijk niet, behalve met een tijdelijke license. (maar iedereen die productie draait heeft een full-license zonder expire)

Door Random Hajile, woensdag 13 augustus 2008 09:52

Score: 0
Het ontgaat je wellicht dat hij de update met deze bug bedoelde, en niet de update met een fix op dit probleem.

Ik snap dan ook niet wanneer men kritieke systemen virtueel draait, men een update niet eerst in een testomgeving uitprobeert. Grove beginnersfout door wellicht iets te veel vertrouwen, maar goed, dat vertrouwen zou ook moeten kunnen vind ik. Helaas is dat niet de werkelijkheid.

Door Arfman, dinsdag 12 augustus 2008 16:01

Score: 0
De patch is al weken beschikbaar, dit is echt een hele gemene bug.

Door Clueless, dinsdag 12 augustus 2008 17:02

Score: 0
De workaround bedoel je. De officiele binairies komen als het goed is morgen pas naar wat ik vernomen heb van VMware zelf.

Door freaky, woensdag 13 augustus 2008 12:54

Score: 0
Geen van beiden lijkt me he, de bug bestaat pas 2 dagen. Update 2, of de patch die daarin zit, is inderdaad al weken uit, door velen getest en door niemand fout bevonden.

De forums op vmware lopen en van over, vele threads groeien met meerdere pagina's per uur, met name van enterprise gebruikers die dit onvergevelijk vinden.

Door Magnum1982, dinsdag 12 augustus 2008 14:06

Score: 0
Mits externe NTP server niet ;-)

Door thalantis, dinsdag 12 augustus 2008 14:06

Score: 1
gaat om de tijd op de esx servers, zolang jij de virtuele machines via andere ntp van de juiste tijd voorziet en niet tijd synct vanaf de esx server is er niks aan de hand

Door wasted247, dinsdag 12 augustus 2008 14:12

Score: 0
Wel apart, hier een datacenter die gebruik maakt van 3 ESX 3.5 servers, lijken er geen last van te hebben. Kan mn VMetjes nog netjes starten en stoppen...

Datums veranderen ga ik idd niet aan beginnen, ook niet als workaround... Slordig van VMware dat dit soort cruciale componenten fouten bevatten.

Helemaal gezien de aard van het product. Zullen heel wat productie omgevingen de dupe zijn van dit soort bugjes. Gelukkig hier niet _/-\o_

Edit: Hmmm, linkje naar de KB van VMware lijkt een beetje overbelast.... Hoe zou dat komen ;)

[Reactie gewijzigd door wasted247 op dinsdag 12 augustus 2008 14:14]

Door MAX3400, dinsdag 12 augustus 2008 14:14

Score: 0
Gelukkig hier niet _/-\o_
Heb je Update2 wel draaien of draai je nog een versie daarvoor?

Collega hier heeft wel problemen met VM's en Update2 namelijk.

Door pistole, dinsdag 12 augustus 2008 14:22

Score: 0
Die collega ben ik dus ;)
Question info: This product has expired.
Be sure that your host machine's date and time are set correctly.
There is a more recent version available at the VMware Web site: "http://www.vmware.com/info?id=4".
:'(

Beetje ranzige oplossing om de tijd op de ESX hosts terug te gaan zetten, maar als er geen andere workaround is....

[Reactie gewijzigd door pistole op dinsdag 12 augustus 2008 14:22]

Door Mark, dinsdag 12 augustus 2008 14:16

Score: 1
Het gaat hier alleen maar om ESX servers welke draaien op de laatste release (3.5 update 2) welke uitgekomen is op 25 juli. Oudere gepatchte versies hebben dus geen last van dit probleem.

Door wasted247, dinsdag 12 augustus 2008 14:21

Score: 0
Ah, kijk, dan kan ik dan weer niet opmaken uit het verhaal ;)

KB linkje deed het nog steeds niet, en maar met een half oog aan het lezen. Maar zijn idd oudere 3.5 servers welke naar de laatste build gepatcht zijn...

Mooi dus :Y)

Door Niemand_Anders, dinsdag 12 augustus 2008 14:41

Score: 2
Ik hoop eerlijk gezegd dat het aantal productie omgevingen welke hiervan last heeft enigsinds beperkt zal zijn. Ik weet niet wat voor update procedures andere hosting bedrijven aanhouden, waar wij hebben de policy om updates betreffende core infrastructuur (loadbalancers, routers, gateways, power switches, etc) minimaal 21 dagen op een shadow systeem (omgeving) te testen.

Elk bedrijf kan fouten maken, maar een workaround welke vmware snel had kunnen uitrollen was een licentie module welke tot de structurele update geen licentie controle uitvoert. Die module zou je eventueel nog wel een houdbaarheids datum kunnen geven zoals maximaal 3 maanden. Mocht dat niet voldoende tijd geven, zou zouden ze eventueel een update kunnen uitbrengen welke nog eens 3 maanden toevoegt.

Persoonlijk denk ik dat deze datum een overblijfsel is van eerdere 'test' releases. Die hebben vaak een datum hard ingebakken. Voorlopig blijven wij dus nog op ESXi 3.5 update 1 draaien.

Door Jabadakkas, dinsdag 12 augustus 2008 14:56

Score: 0
Kwam vannochtend ook achter deze bug. Gelukkig slechts omdat ik een testserver net had geüpgrade. Dacht eerst dat het aan mijn virtuele license server lag die ook op diezelfde ESX host stond. Maar na een clean-install had ik in evaluatie modus dezelfde problemen.

Door arjankoole, dinsdag 12 augustus 2008 22:57

Score: 0
zei vmware niet iets dat je nooit je license server virtueel moet draaien? ;)

Door LeNNy, dinsdag 12 augustus 2008 15:04

Score: 0
Vanochtend net de laatste van de 8 ESX Server gepatched naar de 3.5u2 versie. Kwam er daarna achter dat het starten van een VM niet meer lukte.

En ik maar zoeken waarom het niet lukte. Later zag ik deze ENORME blunder van VMware ergens op een weblog staan.

Lekker weer dit.... 8)7

[Reactie gewijzigd door LeNNy op dinsdag 12 augustus 2008 15:06]

Door Mark, dinsdag 12 augustus 2008 15:16

Score: 2
Wij waren hier net begonnen met de upgrade naar 3.5 update 2, gelukkig nog een aantal ESX servers welke nog op update 1 zitten. Mochten we nu VM's in de lucht moeten brengen dan vmotion naar een server met oudere ESX versie en starten maar.

Een andere oplossing is om de VM's te starten vanuit het service console:
- stop NTP (service ntpd stop)
- Zet de datum terug (date -s 08/10/2008)
- Start de VM (vmware-cmd /pad/naar/vm/vm.vmx start)
- Start NTP (service ntpd start)
Zo loop je maar een klein risico dat lopende VM's tijds problemen krijgen, probleem is echter dat dit alleen werkt in ESX en niet in ESXi .

Mensen met voldoende machines en shared storage kunnen natuurlijk een machine downgraden, echter levert hier een "upgrade" van ESX 3.5 Update 2 naar ESX 3.5 Update 1 met de installer (dus een downgrade) een mooie PSOD (Purple screen of Death) op, zo eens een volledige herinstallatie testen.

Dit probleem komt voor VMWare trouwens op een vrij lullig moment, ik begreep van mensen binnen VMWare dat er veel interesse was in de zojuist gratis geworden ESXi versie (gratis tot aan bepaalde limieten). De bedrijven met interesse gaan nu direct tegen dit probleem aan lopen omdat deze update 2 versie ook de eerste vrij downloadbare versie was van ESXi.......

[Reactie gewijzigd door Mark op dinsdag 12 augustus 2008 15:30]

«  1  2  3  »

Op dit item kan niet meer gereageerd worden.

Volgende 14:16 Videostreams Olympische Spelen scoren goed
Vorige 13:18 Opengl 3.0 met gemengde gevoelens ontvangen
VNU Media logo Hosted by True

© 1998 - 2012 Tweakers.net B.V. - Alle rechten voorbehouden - Contact - Jouw privacy - Algemene Voorwaarden

Uitgever van:

Website van het jaar 2011