«Migrate to a physical computer with a different processor version» — отлично, сняли\поставили. А что это? Зачем? И главное чем грозит?»

Если галочка снята и процессоры разные (а производитель один) — не будут работать Live Migration и Quick Migration.

С этим никто не спорит. Как и в случае установки сторонних агентов на ESX

> А BSOD'ы после обновления драйверов лучше?

Я последний раз видел BSOD году так в 2000—2001 из-за кривых дров USB-модема. На серверах же, особенно на брэндовых — я ни разу не видел BSOD из-за дров. Крупные вендоры обычно очень серьезно подходят к написанию дров и к тестированию дров и железа, и при этом очень тесно сотрудничают с самой MS. Конечно, если Вы решите собрать сервер из нонеймовского китайско-корейского железа — то вы ССЗБ.

От ща придет Жбанков, да задаст тебе перцу!))))

А BSOD'ы после обновления драйверов лучше?

Да, расскажите нам, что майкрософт тут ни при чем, что драйверы пишутся сторонними разработчиками. А потом прочитайте свой пост еще раз:

> необходимо отключить все сторонние агенты на ESX перед обновлением

Шок в крупном бизнесе — очень плохая примета. Берегите нервы.

Как уже сообщалось, компания VMware выпустила Update 1 для виртуальной инфраструктуры VMware vSphere 4.0 в части хостов VMware ESX и сервера VMware vCenter. Обновить хост-серверы ESX можно с помощью продукта VMware Update Manager, однако это чревато негативными последствиями, описанными в KB 1016070.

Проблема касается хост-серверов ESX с установленными сторонними агентами производителей оборудования и описывается следующими симптомами:

1. VMware Update Manager прекращает обновление на ESX 4 Update 1 и останавливается на 33%.

2. После перезагрузки VMware ESX выпадает в purple screen с сообщением:

COS Panic: Int3 @ mp_register_ioapic

Проблема в том, что после перезагрузки хоста VMware ESX 4 с неудачным обновлением Update 1, вам придется переустанавливать ESX, что приведет к потере виртуальных машин на локальных datastores. Чтобы этого не произошло, необходимо отключить все сторонние агенты на ESX перед обновлением до Update 1. Если вы уже обновились, но не перезагружали хост — обратитесь в техническую поддержку VMware.

И это пропагандируется как платформа виртуализации для крупного бизнеса ??? Я в шоке.

Это как бы настоятельная рекомендация. Потому что если между узлами будет 10-мегабитный линк, да еще и забитый напрочь — процесс миграции может занять больше времени, а может и вообще не пройти (вспоминаем про 10 итераций).

Что касается миграции нагруженных серверов — ведь синхронизация памяти проходит инкрементно, и с каждой итерацией копируется все меньше и меньше инфы. Так что 10 хватает практически всегда, я еще ни разу не видел чтобы не хватило. Теоретически, если на виртуалке будет какая-нить бооольшая БД, и будет запущен какой-нить суперсложный OLAP-отчет... Но такие сервера вообще не рекомендуют виртуализировать

to Ruslan V. Karmanov:

Уважаемый Руслан!

Продолжение вашего сериала про AD будет или все умерло

1) «Следует создать между узлами отдельную независимую сеть для трафика Live Migration с пропускной способностью 1Gbps и выше.» — я еще не экспериментировал с конфигурацией без отдельной сетки, но вроде читал что это только рекомендуемая конфигурация, но должно работать и с одной. Поправьте если не так.

2) Насчет 10 итераций для памяти при переносе VM — это для меня была практически единственная новая инфо из статьи. Так вот, по личному опыту — достаточно сильно нагруженный Sharepoint-портал (примерно 60% average CPU для 4-х ядер и кушает около 6 Гб памяти из 8 выделенных) — переезжал уже несколько раз, и вроде пока успешно всегда.