Vmware publiceert patch voor licentiebug in ESX

Vmware heeft een patch vrijgegeven voor de licentieproblemen in ESX en ESXi die dinsdag aan het licht kwamen. De fout blijkt te worden veroorzaakt door testcode die ten onrechte in het eindproduct is verwerkt.

Vanwege de licentieproblemen werd het dinsdag onmogelijk om nieuwe virtuele machines op te starten in versie 3.5 Update 2 van zowel ESX als ESXi. De problemen werden snel onderkend door Vmware en het bedrijf begon aan de ontwikkeling van een oplossing, die inmiddels is gepubliceerd. Deze patch is alleen bedoeld voor ESX- en ESXi-servers die al last hebben van het probleem. Later deze week zal een vernieuwde variant van de gewraakte Update 2 worden vrijgegeven, zodat ook nieuwe ESX- en ESXi-installaties geen last van het probleem meer zullen hebben.

De bug ontstond toen een stuk code, dat ervoor moest zorgen dat testversies van 3.5 Update 2 van ESX en ESXi na een bepaalde datum niet meer werken, per ongeluk in de definitieve release werd verwerkt. Softwareontwikkelaars maken veelvuldig gebruik van dit soort methoden om zeker te weten dat testers de overstap naar definitieve versies maken. Paul Maritz, ceo van Vmware, heeft op zijn weblog laten weten dat hij de problemen betreurt. Ook heeft hij maatregelen aangekondigd die moeten voorkomen dat zulke fouten opnieuw worden gemaakt.

Reacties (23)

fouten maken is menselijk,
Het is natuurlijk wel vervelend voor de gebruikers. en ik ben eigenlijk erg benieuwd welke maatregelen er genomen zullen worden om deze problemen in de toekomst te voorkomen.

fouten maken is menselijk,

Klopt, maar een goede acceptatie test had dit wel voorkomen. Dit hoort uiteindelijk ook bij het vrijgeven van code.

De fout had alleen naar voren gekomen als de machine waarom getest werd op een toekomstige datum wordt gezet.

ESX(i) 3.5 Update 2 zelf is op 25 juni gereleased, alleen de laatste test release zou blijven werken tot 11 augustus.

Dit had je met een acceptatie test nooit eruit kunnen halen omdat tot 11 augustus de update geen problemen gaf. SQL Server 2008 RC0 heeft eenzelfde beveiliging en blijft werken tot ergens in november. Als die code nog steeds in SQL2008 (final release) mocht zitten, ga je dat nu dus niet vinden, tenzij je de systeemdatum een jaar vooruit zet.

Aan de andere kant zou dit wel in de interne documentatie moeten staan.
Dus terug te vinden of te laten komen op een bepaalde tijd.

Je kan toch als standaard onderdeel v/d test meenemen dat de datum bijv. 1 week, 1 en 12 maanden vooruit wordt gezet. Dan was dit ondervangen.

Als er in je code een afhankelijkheid van de datum is geprogrammeerd (en dat is er en dat wisten ze en dat zou in de documentatie van de developers moeten staan), dan moet je dat ook testen door de datum te verzetten, ja.

Wij programmeren telefooncentrales, en daar zitten ook tijds-afhankelijke doorschakelingen in. Die testen we ook door de klok te verschuiven, en niet door koffie te drinken tot 6 uur om dan pas te testen. Dat is toch niet zo vreemd, of wel?

dat word altijd gezegd. we hebben maatregelingen genomen. zou ook niet best zijn als ze dat niet zeggen. maar welke dat word nog medegedeeld.

Dit kost ze in 1 keer meer dan het afvangen van de illegale versies met licensies.

Als ik VMware in een productieomgeving draaide (gebruik het wel, maar op werkstation, is goed product daar niet van) dan zou ik ongeveer nu gaan rondkijken naar vervanging. Ik denk niet dat ik de enige ben.

Daartegenover staat het beetje geld dat ze extra binnenkrijgen doordat het iets moeilijker is om een illegale versie te draaien, waardoor er net iets meer mensen een licentie zullen kopen ... ik denk niet dat dat opweegt tegen de imagoschade die je nu loopt, zeker nu er een grote concurrentiestrijd gaande is over wie de de facto standaard in virtualisatie gaat worden.

Die expire datum is er ingebouwd dat je testcode niet voor een langere tijd gebruikt. Niet om piraterij tegen te gaan.

Dus de keer dat jij een fout maakt, mogen ze jou in de etalage zetten>
Wat jij daar meldt is wel heel erg kort door de bocht.
En ik denk dat jij dus enige bent die daar dus zo over denkt.
Je vergeet dat fouten maken tot daar aan toe is, maar hoe je het oplost/behandeld/oppakt, is veel belangrijker en volgens mij doet vmware het in dat oogpunt het goed.

Noem eens een echte vervanger van VMware esx?

citrix Xenserver komt toch al aardig in de buurt, en hyperv na wat doorontwikkeling misschien ook

Illegale versies? Je weet dat ESXi tegenwoordig gratis is?

Bovendien hebben ze wel aangetoond dat ze erg snel met een oplossing komen in geval van dit soort issues.

Elke softwaremaker maakt fouten, de ene wat erger dan de ander. Wat ik belangrijker vind, is hoe ze met die fouten omgaan, hoe snel ze met een oplossing komen.

vertel meer ? gratis ESX ?

esxi en de gratis versie heeft geen ha enzoot. esxi heeft slechts een 32mb footprint en heeft geen service console. wordt ook embedded ingezet.

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

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

We hadden het probleem hier ook. We hebben het gelukkig tijdig weten te omzeilen door de datum van de servers 2 dagen terug te zetten.

Volgens mij kom je altijd zwaar in de problemen met logging en security als je de datum van servers verzet. Dus ik von dat echt een enorme non-oplossing.

Het was niet DE oplossing, maar een "workarround" en die kan je, na inschatting van de risico's, best inzetten.
Ik zelf zou een esx host, als het even kan, niet laten fungeren als "timeserver" voor vm's
daar zijn betere oplossingen voor.

En wat jij aanhaalt is ondergeschikt aan het goed laten werken van je VM's.

Ik zie het al voor me, eeh nee de vm's willen niet opstarten, als ik de tijd terug zet wel maar dat kloppen de loggings niet....dus dat doe ik niet...

Nee, tuurlijk is het niet DE oplossing, maar zoals q4ogizmo ook al zegt, heb ik liever dat de log niet helemaal klopt dan dat de server, waar zo'n 300 man op moet werken niet meer functioneert. Zo vaak hebben we die log niet nodig.

Het gaat ook alleen om de ESX hosts die een andere datum moeten hebben. Niet de VM's die daarop draaien.

Ik snap dat dit alles erg vervelend was...bij ons op kantoor had ik ook het probleem veroorzaakt door vlot de update 2 te installeren. Ik ben van mening dat ik dit probleem als klant nooit uit had kunnen testen. Ook al had deze update en poos in test gestaan, dan nog is van te voren nooit in te schatten wanneer deze release uit zou vallen.

Vmware heeft binnen 36 uur goed met partners en klanten gecommuniceerd, verder open en bloot op het internet aangegeven dat het door een blunder komt van hen EN de patch online gegooid die gewoon perfect werkt en met een beetje creativiteit niet al te veel downtime zou moeten veroorzaken.

Een fout is irritant en deze had nooit mogen gebeuren, maar noem me 1 leverancier van een OS dat niet eens een blunder maakt. En bovendien er zo netjes mee omgaat!

De effecten van het tijdreizen van je server als tijdelijke oplossing had geen grote effecten mogen hebben al alles goed was ingericht en de beheerders een beetje creatief waren...hebben de over een standaard windows omgeving.

Verder zijn Xen en MS nog niet zover als Vmware qua features en flexibiliteit. Xen komt een end in de buurt geloof ik, maar MS zeker nog lang niet. Ik zou zeggen minimaal een zelfde gat als Windows 2000 server en Novell 6. Toch wordt het de komende jaren spannend of het betere product beter bliift. Ook of het betere product overleefd, want dat gebeurt ook niet altijd...

@ backupdevice: I stand corrected. Het was ruim binnen de tijd inderdaad. Ook is inmiddels een brief van de CEO op het internet te vinden hierover: http://blogs.vmware.com/console/2008/08/letter-from-vmw.html

@ hoistu: Wanneer het een fout zo zijn geweest met dergelijke gevolgen, dan zou je gelijk hebben. Echter was dat in dit geval niet aan de hand. Alle servers zouden met wat hangen en wurgen opgestart kunnen worden (mochten ze helemaal down zijn gegaan). Het herstarten vanuit Windows ging bijvoorbeeld nog steeds goed, omdat de VM zelf daarvoor geen reset of power up aktie voor hoefde te doen.

[Reactie gewijzigd door Cheese_man op 14 augustus 2008 11:08]

Het klopt dat 36 uur vrij kort is. Maar eerlijk gezegd zou ik er niet aan moeten denken dat mijn gehele productie serverpark 36 uur down is, door zo'n fout. 36 uur al je productie machines down is gewoon een hele grote kostenpost.

36 uur is voor een nieuwe update2. Deze is voor mensen bedoelt die ESX fresh willen installeren. Voor mensen die dat niet willen, had VMware in 10 uur een patch beschikbaar.

Lompe fout, goed om te zien dat ze in 10 uur een oplossing kunnen bieden