вторник, 12 августа 2008 г.

Серьезный баг в VMware VI 3.5 Update 2

Коллеги, внимание!

по всей видимости, в Update 2 VMware допустила ошибку.
Из за нее, начиная с 12 августа, ВМ не запускаются примерно с таким сообщением:

“A general system error occurred: Internal Error”.


А в hostd.log можно найти такое:

Aug 12 10:40:10.792: vmx| http://msg.License.product.expired This product has expired.
Aug 12 10:40:10.792: vmx| Be sure that your host machine's date and time are set correctly.

Aug 12 10:40:10.792: vmx| There is a more recent version available at the VMware Web site: "http://www.vmware.com/info?id=4".

или такое

Aug 12 10:40:10.792: vmx| [msg.License.product.expired] This product has expired.
Aug 12 10:40:10.792: vmx| Be sure that your host machine's date and time are set correctly.

Aug 12 10:40:10.792: vmx| There is a more recent version available at the VMware Web site: "http://www.vmware.com/info?id=4".


Эта проблема не затронет работающие ВМ, но при перезагрузке, или при включении ВМ вылезет - и не даст включить.


Для решения проблемы - отключаем NTP для ESX, ручками ставим дату ДО 12 августа.
И ждем патча.
Не забудьте, что если у вас настроена синхронизация времени через VMware tools - на ВМ время собьется после этих действий.


Ужос :((

http://communities.vmware.com/thread/162377?tstart=0

UPD. из комментариев советуют:
http://kb.vmware.com/kb/1006716

Статья указывает что workaround оутсутствует именно потому, что неумелый пользователь, переводя часы назад, может наделать больше вреда, чем пользы.
Кстати, если у хостов время будет сильно различаться, HA кластер может тоже прекратить функционировать.
Пока что самый верный способ
- отключить DRS
- не использовать VMotion
- не выключать машины
- не замораживать (suspend) машины
ну и ждать завтрашнего дня.
Как поётся в песне "Завтра будет лучше чем вчера"
С Уважением
Аноним Доброжелатель


42 комментария:

  1. вот же зараза какая, а! Сижу вчера, переношу машины с хоста на хост. Одна, вторая, третья… Четвёртая не запускается. Потому что после нуля уже. Всё перерыл, плюнул, пошёл спать. Спасибо за пост, а то бы так и сидел на измене.

    ОтветитьУдалить
  2. чёрт, опять два раза отправилось. Грохни один, пожалуйста.

    ЗЫ. А где пост по ESX 3.0.3? ;)

    ОтветитьУдалить
  3. http://kb.vmware.com/kb/1006716

    Статья указывает что workaround оутсутствует именно потому, что неумелый пользователь, переводя часы назад, может наделать больше вреда, чем пользы.
    Кстати, если у хостов время будет сильно различаться, HA кластер может тоже прекратить функционировать.
    Пока что самый верный способ
    - отключить DRS
    - не использовать VMotion
    - не выключать машины
    - не замораживать (suspend) машины
    ну и ждать завтрашнего дня.
    Как поётся в песне "Завтра будет лучше чем вчера"
    С Уважением
    Аноним Доброжелатель

    ОтветитьУдалить
  4. посмотрел я на описание 3.0.3 и подумал - а зачем про него писать?

    ОтветитьУдалить
  5. я тоже вчера долго смотрел на описание 3.0.3 и думал, зачем его вообще выпустили. Надо полагать — именно для тех, кто по каким-то причинам не хочет переходить на 3.5. Например, смотрит человек на баги вроде сегодняшнего и думает — «от добра добра не ищут». Ну вот наверное таким людям будет полезно узнать, что вышел 3.0.3. Не все же получают (и читают) рассылку.

    ОтветитьУдалить
  6. Анониму:

    спасибо за информацию. Но если попытаться отключить DRS, оно грозится удалить все пулы ресурсов. Это правда? Что-то не хочется экспериментировать.

    ОтветитьУдалить
  7. Правда.
    Поэтому, я думаю, "Выключит DRS" следует читать как "Перевести DRS в режим manual"

    ОтветитьУдалить
  8. В VMware саппорте мне пообещали, что выпустят патч в ближайшие часы.

    Проблема связана с забывчивостью программистов. 12 августа должна была заэкспайриться бета, а в релизе просто забыли выключить код.

    ОтветитьУдалить
  9. Ух... счас читал в комьюнити вопли админчего которые дату назад превели... и хосты синхронизовали время с гостями... и виндовые машины из доменов повылетали(всмысле керберос перестал аутентифицировать)... жесть 8-)

    ОтветитьУдалить
  10. ага. Я поэтому всегда отключаю синхронизацию. Если гости и должны брать откуда-то время — так это со своего контроллера АД, а не с хоста. Ибо, на мой взгляд, это дискредитирует саму идею виртуализации — изоляцию гостей и максимальное приближение их к физическим аналогам.

    К тому же механизм работы часов на ESX, может быть, понятен закоренелым линуксоидам, но только не мне. Виндовому админу очень сложно понять, почему часы наблюдаются в двух экземплярах — программные и аппаратные. Чёрт побери, кого надо синхронизировать и с кем? Зачем весь этот геморрой? Почему при выключении хоста оно пытается синхронизировать программные часы с аппаратными (или наоборот)? И почему это реже получается, чем не?..

    ОтветитьУдалить
  11. а если АД виртуализирован?

    для виндовых админов достаточно понимания того, что у вм просто нет аппаратных часиков (собственно, где же еще хранить время, если пропадает питание), которые они могут наблюдать, например, в биос

    ОтветитьУдалить
  12. АД, разумеется, виртуализирован. Но берёт время из надёжного источника — например, из Интернета. Здесь, собственно, нет никакой разницы с аналогичной инфраструктурой, реализованной на физических сервера.

    А хосты берут время с этого самого АД, если они находятся в одной сети. Если в разных — то, конечно, надо позаботиться о том, чтобы у них был свой надёжный источник. Ибо, действительно, после выключения ВМ ей всё-таки негде больше взять время, кроме как с хоста.

    ОтветитьУдалить
  13. интернет, конечно, очень надежный источник..

    где то был док по времени у vmware, даже с картинками ;)

    ОтветитьУдалить
  14. Интернет Интернету рознь =)
    можно брать время по незащищённому NTP с циски районного провадера, а можно прикрутить к тому же NTP аутентификацию и брать время с каких-нибудь атомных часов типа ntp-a.boulder.nist.gov. Вы знаете какой-то принципиально другой способ, более заслуживающий доверия?

    ОтветитьУдалить
  15. http://www.vmware.com/pdf/vmware_timekeeping.pdf

    вот интересно - w32time при запуске на контроллере подтягивает время с ntp сразу? например если время в биосе обнулилось?

    боюсь даже предположить что будет если это не так, или, если надежность источника не оправдалась

    ОтветитьУдалить
  16. Извините, за "выключить DRS" первый комментарий писал в спешке. Спасибо за коррекцию.

    Проблемы с Керберос можно "отрегулировать, если изменить политику Windows "Maximum toleraqnce by computer clock synchronisation" - поставить на undefined.

    Если какая-нибудь важная машина "пострадала", можно попробовать "нырнуть" на пару секунд в прошлое с помощью скрипта

    service ntpd stop
    date -s 08/01/2008[время]
    vmware-cmd [фаил виртуальной машины] start
    date -s 08/12/2008[время]
    service ntpd start

    но перед этим лучше всего отключить все машины на хосте от внешней сети LAN, т.е. вставить в скрипт команды

    esxcfg-vswitch --unlink vmnic??? [Вам лучше знать как ваш vSwitch называется] # в начале скрипта для каждого vmnic'а

    esxcfg-vswitch --link vmnic??? [Вам лучше знать как ваш vSwitch называется] # в конце скрипта для каждого vmnic'а

    и Керберос отключить тоже, бережённого Бог бережёт.
    Файлы виртуальных машин можнои найти вот так vmware-cmd -l

    И учтите, это пока не протестировано, так что на свой страх и риск.

    С Уважением

    Аноним Доброжелатель

    ОтветитьУдалить
  17. неа, не сразу, конечно. Т.е. сначала контроллер поднимается, запускает все свои службы, может даже попробует реплицироваться. Только вот реплицироваться никто с ним не станет, раз время не будет соспадать. Но клиенты неправильное время с него всё-таки получат. А что делать?

    Я вообще-то не отрицал того, что на хосте по возможности *должно* быть правильное время. Именно для таких вот случаев — когда машины запускаются после периода бездействия.

    Но вот помимо этого, синхронизировать время у включённых машин при помощи VMware Tools — это, я считаю, действительно лишнее. Ибо во-первых это «костыль» — т.е. ничем особенно себя не оправдывающая «дыра» в слое виртуализации. А во-вторых, хост ведь не безгрешен.

    Если он откуда-то берёт время, значит у нас есть внешний (или не очень) источник, надёжности которого мы доверяем. И разве не логичнее было бы избавиться от «костыля», подключив гостевые ОС к этому источнику напрямую? А что это будет за источник — уже другой вопрос.

    ОтветитьУдалить
  18. Дополнение

    и если стартовать так одну машину - её надо отделить от внешней сети надолго - т.е. отделить до старта от виртуального коммутатора. После старта подключится к консоли и вручную проверить, как установилось время и только потом снова пускать назад в сеть, т.е. подключать к коммутатору

    А.Д.

    ОтветитьУдалить
  19. 2 Артем

    конечно, не думаю, что DC перезагружаются изо дня в день по 10 раз, но если перезагрузятся - то проблема возникнет серьезная при таком решении, именно поэтому и считается лучшей практикой получение времени от хоста ESX.

    и именно поэтому мы все скорбим..

    это не "костыль", это свойство, особенность реализации, тут никуда не денешься - нету часиков..

    ОтветитьУдалить
  20. Какой-то прямо спор получился в лучших традициях «что было раньше — яйцо или курица».

    «никуда не денешься» — это при включении ВМ. Тут, да, это не костыль, а особенность реализации. Собственно, и выбора никакого нет. И поэтому, повторюсь, на хосте по возможности должно быть правильное время.

    но после включения выбор уже есть. Грубо говоря, вариант (а) — продолжать брать время с хоста (т.е. периодически синхронизировать его при помощи VMware Tools). Вариант (б) — брать время из внешнего источника. (Напоминаю, что сам факт существования такого источника подразумевается, ибо должен ведь к нему обращаться как минимум хост).

    И вот здесь я считаю вариант (б) более предпочтительным. Причины были также описаны выше:

    * это спрямляет «костыль», так как мы пользуемся не дырой в абстракции, а вполне легитимным даже в физической инфраструктуре путём — то есть, через сеть.
    * это повышает надёжность, так как даже в случае, если на хосте установлено неправильное время, ВМ всё-таки сможет «исправиться», пусть и не сразу после включения. (В то же время, если на хосте установлено правильное время, то мы ничего и не теряем).

    Насчёт «лучшей практики» почитаю сегодня WP по вашей ссылке, возможно что-то уточню в своей позиции.

    ОтветитьУдалить
  21. А если у меня не использузуется синхронизация времени с хостом, другие причины не переводить время есть?

    ОтветитьУдалить
  22. Иван,
    думаю наиболее правильным решением будет
    - переключить врс в ручной режим
    - ничего не делать с виртуальными машинам
    - ждать патча.

    Это в случае, если не надо ничего перезагружать или создавать новые ВМ...

    ОтветитьУдалить
  23. В том то и проблема, что надо перегружать. Вобщем перевел время - пока полет нормальный. На одном из узлов кластера только переконфигурировал HA агента (стандартными средствами).

    ОтветитьУдалить
  24. Патч вышел уже или нет ???? Просветите :(

    ОтветитьУдалить
  25. По моей информации, патч обещают на неделе.
    А уже или вот вот станут доступны для скачивания обновленные iso с дистрибутивами.

    ОтветитьУдалить
  26. Ндяяяяяяя :( iso - это жестко ..... У меня 20 машинок крутится, некоторые из них требуют перегрузки ... Накатывать поверху, не стремно, но .....

    ОтветитьУдалить
  27. Как было обещано: завтра будет лучше, чем вчера:
    Аноним Доброжелатель

    ETA - Estimated Time Availability
    PDT - Pacific Daylight Time (Московское - 11 часов, т.е. 6 вечера в притонах Сан-Франциско = 5 Утра на Красной Площади )


    1. ETA for express patch release is 6 pm PDT (fairly solid at this point), this will be for customers who have already upgraded to 3.5 U2
    2. Should be able to use Update Manager to apply patch to affected servers
    3. This is an "express" patch only and targets the module containing the erroneous code only
    4. Should not require a reboot of the host
    5. Full corrected U2 update should be released on web site tomorrow evening, this will be for customers who have not installed U2 and they should download this version and use it going forward

    ОтветитьУдалить
  28. "Пока верстался номер"
    Однако, быстро всё развивается. Неуспел написать - надо всё обновлять.
    Извините за неточность -
    VUM-овский патч будет готов 13 августа в 5 утра по московскому времени (12 августа 6 вечера в Сан-Франциско)
    Полные ISO для тех, кто еще не осчастливился U2 будут выпущены примерно в 5 утра московского времени 14 августа.

    Аноним Доброжелатель

    1. ETA for express patch release still on track for 6pm PDT
    2. Confirmed Update Manager can be used to distribute/update affected hosts
    3. Confirmed there will be no need to reboot hosts or take down VMs
    4. There will not be an "unload" or revert option, once applied the patch is not reversible
    5. Thorough step-by-step instructions will be included with the express patch
    6. New full U2 builds will be available tomorrow evening at roughly 6pm PDT on the web site for download

    ОтветитьУдалить
  29. Это совсем старьё (т.е. 2 часа почти прошло) но всё ещё актуально
    Аноним Доброжелатель

    Dear VMware Customers,

    Please find the latest update about the product expiration issue. From this point on, we’ll provide an update every two hours. Thanks.

    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.

    Affected Products:
    - VMware ESX 3.5 Update 2 & ESXi 3.5 Update 2
    - Reports of problems with ESX 3.5 U1 with the following 3.5 Update 2 patch applied.
    1. ESX350-200806201-UG
    - No other VMware products are affected.

    What has been done?

    - Product and Web teams pulled the ESX 3.5 Update 2 bits from the download pages last night so no more customers will be able to download the broken build.
    - VMware Engineering teams have isolated the cause of the problem and are working around the clock to deliver updated builds and patches for impacted customers.
    - A Knowledgebase article has been published (http://kb.vmware.com/kb/1006716), but traffic to the knowledgebase is causing time outs. A new static page has been published at http://www.vmware.com/support/esx35u2_supportalert.html that customers and partners will be able to view.
    - The phone system has been updated to advise customers of the problem
    - Vmware partners have been notified of the issue.

    Workarounds:
    1) Do not install ESX 3.5 U2 if it has been downloaded from VMware’s website or elsewhere prior to August 12, 2008.
    2) Set the host time to a date prior to August 12, 2008. This workaround has a number of very serious side affects that could impact product environments. Any Virtual Machines that sync time with the ESX host and serve time sensitive applications would be broken. These include, but are not limited to database servers, mail servers, & domain administration systems.

    Next Steps:
    VMware to notify customers who have downloaded this version and provide an update every two hours.

    Resolution:

    VMware Engineering has isolated the root cause and is working to produce an express patch for impacted customers today. The target timeframe is 6pm, August 12, 2008 PST.

    FAQ:

    1. What would this express patch do?

    More information will be provided in subsequent communication updates.

    2. Will VMware still reissue the upgrade media and patch bundles in the timeframe that has been communicated?

    Yes. We still plan to reissue upgrade media by 6pm, August 13 PST (instead of noon, August 13 PST) and all update patch bundles later in the week. We will provide an ETA for the update patch bundles subsequently. NOTE: the "patch bundles" referred to here are for the patches listed above under "Affected Products" and the other bundles released at GA. They are not the same as the express patch which is targeted for 6pm, August 12, 2008 PST as stated above.

    3. Why does VMware plan to reissue the upgrade media before the patch bundles? That is a wrong priority call!

    This is not a matter of priority. Since we can get done building and testing the upgrade media before the patch bundles, we want to make that available to customers first instead of reissuing all the binaries later in the week.

    4. Can VMware issue a patch that opens the licensing backdoor in the next hour as a critical measure?

    There is no licensing backdoor in our code.

    5. Does this issue affect VC 2.5 Update 2?

    No.

    6. What is VMware doing to make sure that the problem won’t happen again?

    We are making improvements on all fronts. The product team had endeavored to deliver a release with support customers deem important. But we fell short and we are deeply sorry about all the disruption and inconveniences we have caused. We have identified where the holes are and they will be addressed to restore customers’ confidence.

    ОтветитьУдалить
  30. Dear VMware Customers,

    Please find the latest update about the product expiration issue. We have stated that 6pm, August 12, 2008 PST is the target timeframe for us to deliver an express patch. However, it is possible that the final delivery time will be sometime later in the evening. We know that this patch is critical and will continue to provide a status update.

    Complete information on the ESX/ESXi 3.5 Update 2 issue follows:

    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.

    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.

    What has been done?

    - Product and Web teams pulled the ESX 3.5 Update 2 bits from the download pages last night so no more customers will be able to download the broken build.
    - VMware Engineering teams have isolated the cause of the problem and are working around the clock to deliver updated builds and patches for impacted customers.
    - A Knowledgebase article has been published (http://kb.vmware.com/kb/1006716) and will be updated as new information becomes available.
    - The phone system has been updated to advise customers of the problem
    - VMware partners have been notified of the issue.

    Workarounds:
    1) Do not install ESX 3.5 U2 if it has been downloaded from VMware’s website or elsewhere prior to August 12, 2008.
    2) Set the host time to a date prior to August 12, 2008. This workaround has a number of very serious side affects that could impact product environments. Any Virtual Machines that sync time with the ESX host and serve time sensitive applications would be broken. These include, but are not limited to database servers, mail servers, & domain administration systems.

    Next Steps:
    VMware to update customers every two hours until the fix is released.

    Resolution:

    VMware Engineering has isolated the root cause and is working to produce an express patch for impacted customers that will resolve the issue. The target timeframe is 6pm, August 12, 2008 PST.

    FAQ:

    1. What will the express patches do?

    The express patches are specifically targeted for customers who have installed or upgraded to ESX/ESXi 3.5 Update 2, one for ESX 3.5 Update 2 and one for ESXi 3.5 Update 2. To apply the patches, no reboot of ESX/ESXi hosts is required. One can VMotoin off running VMs, apply the patches and VMotion the VMs back. If VMotion capability is not available, VMs need to be powered off before the patches are applied and powered back on afterwards.

    2. Will VMware still reissue the upgrade media and patch bundles in the timeframe that has been communicated?

    Yes. We still plan to reissue upgrade media by 6pm, August 13 PST (instead of noon, August 13 PST) and all update patch bundles later in the week. We will provide an ETA for the update patch bundles subsequently. NOTE: the "patch bundles" referred to here are for the patch listed above under "Affected Products" and the other bundles released at GA. There are for customers who wish to stay with ESX/ESXi 3.5 or ESX/ESXi 3.5 Update 1 and not do a full upgrade to ESX/ESXi 3.5 Update 2. They are not the same as the express patch which is targeted for 6pm, August 12, 2008 PST as stated above.

    3. Why does VMware plan to reissue the upgrade media before the patch bundles?

    Since we can complete building and testing of the upgrade media before the patch bundles, we want to make that available to customers right away instead of reissuing all the binaries later in the week.

    4. Can VMware issue a patch that opens the licensing backdoor in the next hour as a critical measure?

    There is no licensing backdoor in our code.

    5. Does this issue affect VC 2.5 Update 2?

    No.

    6. What is VMware doing to make sure that the problem won’t happen again?

    We are making improvements on all fronts. The product team had endeavored to deliver a release with support customers deem important. But we fell short and we are deeply sorry about all the disruption and inconveniences we have caused. We have identified where the holes are and they will be addressed to restore customers’ confidence.

    ОтветитьУдалить
  31. http://www.deploylinux.net/matt/2008/08/all-your-vms-belong-to-us.html
    PS:

    PATCH AVAILABLE (00:04h GMT-03)

    http://kb.vmware.com/selfservice/dynamickc.do?externalId=1006721&sliceId=1&command=show&forward=nonthreadedKC&kcId=1006721

    ОтветитьУдалить
  32. The patch
    http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006721

    ОтветитьУдалить
  33. Кто нибудь уже накатил патчик ????

    ОтветитьУдалить
  34. да, на 2 сервера, помогло - после reboot-а хоста все VM поднялись.

    ОтветитьУдалить
  35. А без ребута хоста никак ??? Вродже же написано
    VM Shutdown & No Host Reboot !!!!

    ОтветитьУдалить
  36. Restart hostd Required
    service mgmt-vmware restart

    ОтветитьУдалить
  37. подскажите, как применить это обновление?

    ОтветитьУдалить
  38. Есть инструкция по применению патча на ESXi без использования платного ПО?

    ОтветитьУдалить
  39. сейчас полез на KB VMware - не доступна почему то.
    Поэтому по памяти - насколько я помню, в описании патча для ESXi было указано что его можно накатывать с помощью VMware Update Manager. Он попадает под определение "Платное ПО"?

    ОтветитьУдалить
  40. ага, вот сейчас открылось - http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=1006670&sliceId=1&docTypeID=DT_KB_1_1&dialogID=22574999&stateId=1%200%2022576281

    там все достаточно внятно описано.
    Есть какой то offline patch, который можно применить сам по себе.

    ОтветитьУдалить
  41. KB почему-то не открывается из России. С прокси США открывается нормально.

    ОтветитьУдалить
  42. Коллеги, столкнулись с подобной проблемой на VMware 5.0
    Есть варианты решения проблемы?

    Особенность: 2 виртуалки - кластер майкрософт.
    Последовательность действий: потушили главную ноду, начали процесс миграции дисков. Процесс не увенчался успехом.
    Включаем назад - ошибка, как в названии темы. Вторая нода - так же. Виртуалки не поднять.

    ОтветитьУдалить