Bug in licentiecomponent maakt Vmware ESX 3.5 onbruikbaar

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.

Reacties (53)

[Mark]

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 23 juli 2024 08:31]

[scorelord]

Vmotion krijg ik wel aan de praat als je met een ntpd server werkt. (zo niet, vast ook wel) Je moet alleen wel even snel zijn en VC foppen dat alles APK is voor HA als je aan je klokje zit. Sowieso moet je snel werken om zo klokproblemen op vm's te voorkomen.

Workaround voor vmotion:

service ntpd stop
date -s 08/01/2008

VMotion-en maar.

Mocht VC miepen over HA agent error (en dat gaat ie doen) even:

service ntpd start

intikken, dan reconfigure for HA waarna je weer kan beginnen bij Workaround.

Ik kon tot 2 te gelijk. Meer wordt gequeued. VC checkt op bepaalde intervallen op HA en ziet dat de klok er uit ligt en kapt dan de vmotion af. Gewoon weer stapjes opnieuw doen.

as for de personen opmerkingen over "lekker dom dat je niet eerst test met zo'n patch" : dan hoef je dus nooit te upgraden. 2 weken vind ik genoeg om te testen.

/update: Er wordt morgen een nieuwe versie online gezet (by noon, August 13, PST)

[Reactie gewijzigd door scorelord op 23 juli 2024 08:31]

[eth0stack]

Idd, je gaat er toch meestal vanuit dat ze de patch ook zelf testen. Dit mag eigelijk gewoon niet kunnen.

[Radiant]

Zet jij je tijd altijd vooruit bij het testen van je programma's?

Vervelende bug, maar denk niet dat VMware dit had kunnen zien aankomen.

[arjankoole]

Vervelende bug, maar denk niet dat VMware dit had kunnen zien aankomen.

dat ben ik niet geheel met je eens, maar ik heb weinig behoefte er veel stampij over te maken. Foutjes kunnen nou eenmaal gebeuren helaas, ben d'r niet blij mee, maar als dit een eenmalige stunt blijft... ach.

[Verwijderd]

Als je in je programma iets inbouwt wat datum-afhankelijk is, ja, dan moet je de datum van je computer gaan verzetten als je dat wil testen. Lijkt me nogal logisch.

VMware had dit ook zeker kunnen zien aankomen. Er is een stukje code achtergebleven wat normaliter alleen in testversies zit, om te voorkomen dat testversies gebruikt gaan worden in produktieomgevingen. Het stukje code is moedwillig geschreven, en per ongeluk niet verwijderd voor de release build.

[Verwijderd]

Veel applicaties zijn tijdafhankelijk en raken gecorrumpeerd als er getijdreisdwordt naar het verleden. (voorbeeldje: dubbel uitsturen facturen)
Er moet bij de fixes waarbij de datum tijdelijk verzet wordt wel goed opgelet worden dat niet de datum binnen de VM's in het verleden terecht komt.

Dat kan echt enorm dramatische fouten opleveren.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 08:31]

[paella]

Je kan de host terugzetten, en bij het starten van de VM in de BIOS van de VM de tijd weer goed zetten.

[BVGorp]

Dear VMware Customers,

We have released the express patches for the product expiration issue. Please go to http://www.vmware.com/go/esxexpresspatches for more information.

Problem:

An issue has been discovered by many VMware customers and partners with ESX/ESXi 3.5 Update 2 where Virtual Machines fail to power on or VMotion successfully. This problem began to occur on August 12, 2008 for customers that had upgraded to ESX 3.5 Update 2. The problem is caused by a build timeout that was mistakenly left enabled for the release build.

The following message is displayed in the vmware.log file for the virtual machine:

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.
--------------
Module License Power on failed.

Affected Products:
- VMware ESX 3.5 Update 2 & ESXi 3.5 Update 2.
- The problem will be seen if ESX350-200806201-UG is applied to a system.
- No other VMware products are affected.

Resolution:

VMware Engineering has produced express patches for impacted customers to resolve the issue

[AlBundy]

Ook lekker dom van die bedrijven die gewoon die patch direct op hun productiesystemen geïnstalleerd hebben en nu met problemen zitten.
Bewijst wel weer het nut van een testomgeving

-edit: had eerst otap staan, maar dat is voor ontwikkelomgevingen

[Reactie gewijzigd door AlBundy op 23 juli 2024 08:31]

[Mark]

Wat als deze tijdlimiet niet op 12 augustus had gestaan maar op 12 juli 2009 ? Niet dat een testomgeving voor dit soort upgrades niet van belang is, maar dat had dit probleem voor hetzelfde geld niet kunnen voorkomen

[Reactie gewijzigd door Mark op 23 juli 2024 08:31]

[lammert]

Ook lekker dom van die bedrijven die gewoon die patch direct op hun productiesystemen geïnstalleerd hebben en nu met problemen zitten.
Bewijst wel weer het nut van een testomgeving

Lekker kort door de bocht ga jij: als je dit vorige week uitgebreid had getest dan was je hoogstwaarschijnlijk niet achter deze bug gekomen (weinig testprocedures die ook testen of iets op toekomstige tijden werkt) en had je alsnog vanaf vandaag met de gebakken peren gezeten. Dit is klanten echt niet te verwijten, de fout ligt 100% bij VMWare.

[wasted247]

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

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

[Reactie gewijzigd door wasted247 op 23 juli 2024 08:31]

[Niemand_Anders]

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.

[Mark]

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.

[wasted247]

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

[MAX3400]

Gelukkig hier niet

Heb je Update2 wel draaien of draai je nog een versie daarvoor?

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

[pistole]

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 23 juli 2024 08:31]

[rammes]

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

[BVGorp]

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 23 juli 2024 08:31]

[brompot758]

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.

[metalant]

De bug doet zich alleen voor met ESX 3.5 machines die gepatched zijn met Update 2.

Op het bestaan van deze bug (en dit soort) is alleen te testen als je in je testomgeving alles op een een datum in de toekomst zet. En dat is bij een heleboel testomgevingen niet het geval .

Inmiddels is er ook al een fix beschikbaar.

[LeNNy]

Da's niet helemaal waar. Ook ESX 3.5 Update 1 met patch ESX350-200806201-UG heeft het betreffende probleem.

[Clueless]

Officiele patches zijn inmiddels gereleased:

http://www.vmware.com/download/vi/

en specifieker:
ESXi en ESX 3.5

[LordPan]

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.

[AlBundy]

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.

[siepeltjuh]

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.

[WPN]

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

[arjankoole]

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.

[scsirob]

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??

[arjankoole]

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)

[TheTeek]

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...

[Random Hajile]

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.

[Arfman]

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

[Clueless]

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

[freaky]

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.

[thalantis]

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