Сообщения
Коллеги, внимание!
по всей видимости, в 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) машины
ну и ждать завтрашнего дня.
Как поётся в песне "Завтра будет лучше чем вчера"
С Уважением
Аноним Доброжелатель
вот же зараза какая, а! Сижу вчера, переношу машины с хоста на хост. Одна, вторая, третья… Четвёртая не запускается. Потому что после нуля уже. Всё перерыл, плюнул, пошёл спать. Спасибо за пост, а то бы так и сидел на измене.
ОтветитьУдалитьчёрт, опять два раза отправилось. Грохни один, пожалуйста.
ОтветитьУдалитьЗЫ. А где пост по ESX 3.0.3? ;)
http://kb.vmware.com/kb/1006716
ОтветитьУдалитьСтатья указывает что workaround оутсутствует именно потому, что неумелый пользователь, переводя часы назад, может наделать больше вреда, чем пользы.
Кстати, если у хостов время будет сильно различаться, HA кластер может тоже прекратить функционировать.
Пока что самый верный способ
- отключить DRS
- не использовать VMotion
- не выключать машины
- не замораживать (suspend) машины
ну и ждать завтрашнего дня.
Как поётся в песне "Завтра будет лучше чем вчера"
С Уважением
Аноним Доброжелатель
посмотрел я на описание 3.0.3 и подумал - а зачем про него писать?
ОтветитьУдалитья тоже вчера долго смотрел на описание 3.0.3 и думал, зачем его вообще выпустили. Надо полагать — именно для тех, кто по каким-то причинам не хочет переходить на 3.5. Например, смотрит человек на баги вроде сегодняшнего и думает — «от добра добра не ищут». Ну вот наверное таким людям будет полезно узнать, что вышел 3.0.3. Не все же получают (и читают) рассылку.
ОтветитьУдалитьАнониму:
ОтветитьУдалитьспасибо за информацию. Но если попытаться отключить DRS, оно грозится удалить все пулы ресурсов. Это правда? Что-то не хочется экспериментировать.
Правда.
ОтветитьУдалитьПоэтому, я думаю, "Выключит DRS" следует читать как "Перевести DRS в режим manual"
В VMware саппорте мне пообещали, что выпустят патч в ближайшие часы.
ОтветитьУдалитьПроблема связана с забывчивостью программистов. 12 августа должна была заэкспайриться бета, а в релизе просто забыли выключить код.
Ух... счас читал в комьюнити вопли админчего которые дату назад превели... и хосты синхронизовали время с гостями... и виндовые машины из доменов повылетали(всмысле керберос перестал аутентифицировать)... жесть 8-)
ОтветитьУдалитьага. Я поэтому всегда отключаю синхронизацию. Если гости и должны брать откуда-то время — так это со своего контроллера АД, а не с хоста. Ибо, на мой взгляд, это дискредитирует саму идею виртуализации — изоляцию гостей и максимальное приближение их к физическим аналогам.
ОтветитьУдалитьК тому же механизм работы часов на ESX, может быть, понятен закоренелым линуксоидам, но только не мне. Виндовому админу очень сложно понять, почему часы наблюдаются в двух экземплярах — программные и аппаратные. Чёрт побери, кого надо синхронизировать и с кем? Зачем весь этот геморрой? Почему при выключении хоста оно пытается синхронизировать программные часы с аппаратными (или наоборот)? И почему это реже получается, чем не?..
а если АД виртуализирован?
ОтветитьУдалитьдля виндовых админов достаточно понимания того, что у вм просто нет аппаратных часиков (собственно, где же еще хранить время, если пропадает питание), которые они могут наблюдать, например, в биос
АД, разумеется, виртуализирован. Но берёт время из надёжного источника — например, из Интернета. Здесь, собственно, нет никакой разницы с аналогичной инфраструктурой, реализованной на физических сервера.
ОтветитьУдалитьА хосты берут время с этого самого АД, если они находятся в одной сети. Если в разных — то, конечно, надо позаботиться о том, чтобы у них был свой надёжный источник. Ибо, действительно, после выключения ВМ ей всё-таки негде больше взять время, кроме как с хоста.
интернет, конечно, очень надежный источник..
ОтветитьУдалитьгде то был док по времени у vmware, даже с картинками ;)
Интернет Интернету рознь =)
ОтветитьУдалитьможно брать время по незащищённому NTP с циски районного провадера, а можно прикрутить к тому же NTP аутентификацию и брать время с каких-нибудь атомных часов типа ntp-a.boulder.nist.gov. Вы знаете какой-то принципиально другой способ, более заслуживающий доверия?
http://www.vmware.com/pdf/vmware_timekeeping.pdf
ОтветитьУдалитьвот интересно - w32time при запуске на контроллере подтягивает время с ntp сразу? например если время в биосе обнулилось?
боюсь даже предположить что будет если это не так, или, если надежность источника не оправдалась
Извините, за "выключить 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
И учтите, это пока не протестировано, так что на свой страх и риск.
С Уважением
Аноним Доброжелатель
неа, не сразу, конечно. Т.е. сначала контроллер поднимается, запускает все свои службы, может даже попробует реплицироваться. Только вот реплицироваться никто с ним не станет, раз время не будет соспадать. Но клиенты неправильное время с него всё-таки получат. А что делать?
ОтветитьУдалитьЯ вообще-то не отрицал того, что на хосте по возможности *должно* быть правильное время. Именно для таких вот случаев — когда машины запускаются после периода бездействия.
Но вот помимо этого, синхронизировать время у включённых машин при помощи VMware Tools — это, я считаю, действительно лишнее. Ибо во-первых это «костыль» — т.е. ничем особенно себя не оправдывающая «дыра» в слое виртуализации. А во-вторых, хост ведь не безгрешен.
Если он откуда-то берёт время, значит у нас есть внешний (или не очень) источник, надёжности которого мы доверяем. И разве не логичнее было бы избавиться от «костыля», подключив гостевые ОС к этому источнику напрямую? А что это будет за источник — уже другой вопрос.
Дополнение
ОтветитьУдалитьи если стартовать так одну машину - её надо отделить от внешней сети надолго - т.е. отделить до старта от виртуального коммутатора. После старта подключится к консоли и вручную проверить, как установилось время и только потом снова пускать назад в сеть, т.е. подключать к коммутатору
А.Д.
2 Артем
ОтветитьУдалитьконечно, не думаю, что DC перезагружаются изо дня в день по 10 раз, но если перезагрузятся - то проблема возникнет серьезная при таком решении, именно поэтому и считается лучшей практикой получение времени от хоста ESX.
и именно поэтому мы все скорбим..
это не "костыль", это свойство, особенность реализации, тут никуда не денешься - нету часиков..
Какой-то прямо спор получился в лучших традициях «что было раньше — яйцо или курица».
ОтветитьУдалить«никуда не денешься» — это при включении ВМ. Тут, да, это не костыль, а особенность реализации. Собственно, и выбора никакого нет. И поэтому, повторюсь, на хосте по возможности должно быть правильное время.
но после включения выбор уже есть. Грубо говоря, вариант (а) — продолжать брать время с хоста (т.е. периодически синхронизировать его при помощи VMware Tools). Вариант (б) — брать время из внешнего источника. (Напоминаю, что сам факт существования такого источника подразумевается, ибо должен ведь к нему обращаться как минимум хост).
И вот здесь я считаю вариант (б) более предпочтительным. Причины были также описаны выше:
* это спрямляет «костыль», так как мы пользуемся не дырой в абстракции, а вполне легитимным даже в физической инфраструктуре путём — то есть, через сеть.
* это повышает надёжность, так как даже в случае, если на хосте установлено неправильное время, ВМ всё-таки сможет «исправиться», пусть и не сразу после включения. (В то же время, если на хосте установлено правильное время, то мы ничего и не теряем).
Насчёт «лучшей практики» почитаю сегодня WP по вашей ссылке, возможно что-то уточню в своей позиции.
А если у меня не использузуется синхронизация времени с хостом, другие причины не переводить время есть?
ОтветитьУдалитьИван,
ОтветитьУдалитьдумаю наиболее правильным решением будет
- переключить врс в ручной режим
- ничего не делать с виртуальными машинам
- ждать патча.
Это в случае, если не надо ничего перезагружать или создавать новые ВМ...
В том то и проблема, что надо перегружать. Вобщем перевел время - пока полет нормальный. На одном из узлов кластера только переконфигурировал HA агента (стандартными средствами).
ОтветитьУдалитьПатч вышел уже или нет ???? Просветите :(
ОтветитьУдалитьПо моей информации, патч обещают на неделе.
ОтветитьУдалитьА уже или вот вот станут доступны для скачивания обновленные iso с дистрибутивами.
Ндяяяяяяя :( iso - это жестко ..... У меня 20 машинок крутится, некоторые из них требуют перегрузки ... Накатывать поверху, не стремно, но .....
ОтветитьУдалитьКак было обещано: завтра будет лучше, чем вчера:
ОтветитьУдалитьАноним Доброжелатель
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
"Пока верстался номер"
ОтветитьУдалитьОднако, быстро всё развивается. Неуспел написать - надо всё обновлять.
Извините за неточность -
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
Это совсем старьё (т.е. 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.
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.
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
The patch
ОтветитьУдалитьhttp://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006721
Кто нибудь уже накатил патчик ????
ОтветитьУдалитьда, на 2 сервера, помогло - после reboot-а хоста все VM поднялись.
ОтветитьУдалитьА без ребута хоста никак ??? Вродже же написано
ОтветитьУдалитьVM Shutdown & No Host Reboot !!!!
Restart hostd Required
ОтветитьУдалитьservice mgmt-vmware restart
подскажите, как применить это обновление?
ОтветитьУдалитьЕсть инструкция по применению патча на ESXi без использования платного ПО?
ОтветитьУдалитьсейчас полез на KB VMware - не доступна почему то.
ОтветитьУдалитьПоэтому по памяти - насколько я помню, в описании патча для ESXi было указано что его можно накатывать с помощью VMware Update Manager. Он попадает под определение "Платное ПО"?
ага, вот сейчас открылось - 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, который можно применить сам по себе.
KB почему-то не открывается из России. С прокси США открывается нормально.
ОтветитьУдалитьКоллеги, столкнулись с подобной проблемой на VMware 5.0
ОтветитьУдалитьЕсть варианты решения проблемы?
Особенность: 2 виртуалки - кластер майкрософт.
Последовательность действий: потушили главную ноду, начали процесс миграции дисков. Процесс не увенчался успехом.
Включаем назад - ошибка, как в названии темы. Вторая нода - так же. Виртуалки не поднять.