Грабли: апгрейд VMware Tools не проходит

Проблема:
1. "Правый клик / Guest / Install/Upgrade VMware Tools / Automated" практически сразу выдает ошибку "Error upgrading VMware Tools"
2. При апгрейде через интерфейс VMware Tools в гостевой Windows (кнопка "Upgrade") ничего не происходит.
3. Апгрейд в интерактивном режиме проходит нормально.

Существует статья в KB: Upgrading VMware Tools may fail when using Automatic Tools Upgrade in the vSphere Client

Решение: удалить VMwareToolsUpgrader.exe из %Temp% (обычно C:\Windows\Temp) и перезапустить апгрейд.

Алексей Тараненко любезно помог с PowerShell скриптом для автоматизации процесса.

HA/DRS и нормализованные Shares

Неделю назад я уже упомянул о важном нововведении в vSphere 4.1, нормализованных shares.

Что же это такое?

При failover'е HA помещает ВМ в корневой ресурс-пул, и если при этом ВМ сама находилась в ресурс-пуле и имела высокое значение shares, то она будет иметь то же самое значение shares и после failover'а.

Предположим, что у нас есть 3 ВМ, 2 из которых находятся в специальном ресурс-пуле Resource Pool A. У VM1 1000 shares, у Resource Pool A - 2000. При этом в ресурс пуле находятся еще 2 ВМ, каждая из которых имеет по 10000 shares. Напомню, что shares в данном случае действуют только в пределах ресурс-пула, и обе ВМ имеют соотв. по 50%. Т.е. VM1 имеет 33% ресурсов, VM2 и VM3 по 50% от 66% ресурс-пула -> все три ВМ имеют по 33% ресурсов.

2 года в эфире

Вот так в летнем угаре 2010 года, в 36 градусов жары и не заметил, что блогу 9го июля исполнилось два года.

Хочется подвести итоги 2х лет активного участия в сообществе.

• Написано 260 постов в блоге
• 4500 комментариев на форуме VMware - общее 19е место и 1е в русскоязычном разделе
• Global User Moderator форума VMware
• дважды VMware vExpert
• VMware User Group Russia Leader (вместе с Михаилом Михеевым)
• Организовано 2 крупнейших встречи VMUG Russia, собравших в Москве почти по 100 человек
• Открыта первая региональная VMUG в Нижнем Новгороде

Ну что, ура мне! :)

HA: если не хватает ресурсов

Как вы, наверное, уже помните, при наступлении HA события агенты сначала проверяют наличие свободных ресурсов. Но что, если ресурсов недостаточно? Как все это работает?

А вот как:

Процесс vpxa слушает сообщения hostd об изменениях уровня доступности ресурсов (а именно изменениях незарезервированных ресурсов) и пересылает информацию процессу aam, принимающему решения о failover'е. Но чтобы не спамить aam, vpxa ждет пока изменение составит как минимум 5%. Получив сообщение об изменении доступности ресурсов aam проверяет, нет ли в очереди на failover виртуальных машин, ожидающих ресурсов, и если доступных ресурсов становится достаточно, то failover происходит - машина перезапускается.

Вопрос: а сколько ВМ будет ждать в очереди?
Ответ: пока не появятся свободные ресурсы.

Вопрос: как это сочетается с das.vmrestartcount?
Ответ: никак не сочетается, das.vmrestartcount отвечает за количество попыток перезапуска ВМ при достаточных ресурсах. В данном случае рассматривается ситуация с недостаточными ресурсами и перезапуска не происходит. Как только ресурсов станет достаточно - вступит в действие das.vmrestartcount.

vNetwork: Массовое переключение ВМ в другую портгруппу

Предположим, у вас меняется сетевая политика для виртуальных машин и вы создаете новые портгруппы. Или вы решили мигрировать на Distributed vSwitch. Соотв. есть много (поэтому вручную не вариант, или просто лень) ВМ, подключенных в одну портгруппу, и их надо переключить в другую.

Решение - PowerShell! :)

Как это сделал я для своего тестового кластера. Сначала создал Distributed vSwitch с одним аплинком (с каждого хоста) и на нем новую портгруппу для ВМ. Затем переключил пару включенных машин вручную, проверив, что они остались доступны. И оставшиеся N-цать выключенных переключил уже скриптом:

Get-Cluster "Cluster" | Get-VM | Where-Object {$_.PowerState -eq "PoweredOff"} | Get-NetworkAdapter | where { $_.Name -eq "Network Adapter 1" } | Set-NetworkAdapter -NetworkName "dv VM Network" -Confirm:$false

Строго говоря, можно переключать и включенные машины, проблем с ними не возникает.

Новые HA Maximums в vSphere 4.1 и интеграция с DRS

Есть несколько изменений в vSphere 4.1, на которые стоит обратить внимание. Одно из очень приятных изменений в Configuration Maximums.

Новые максимумы HA

• 32 хоста в кластере
• 320 ВМ на хост
• 3,000 ВМ на кластер

Иными словами:

• у вас может быть 10 хостов с 300 ВМ на каждом
• или 20 хостов со 150 ВМ
• или 32 с 93 ВМ

Выбор HA Primary Nodes в vSphere 4.1

В VMware HA есть очень важная вещь, называемая Primary Nodes. Проблема с Primary Nodes заключается в том, что нельзя контролировать какие именно хосты станут Primary, что соотв. негативным образом отражается на отказоустойчивости инфраструктуры, построенной на блейд серверах. Если все Primary хосты окажутся в одной блейд-корзине, то при падении этой корзины полностью ложится HA.

В vSphere 4.1 появилась новая тонкая настройка HA - предпочитаемые Primary Nodes.

das.preferredPrimaries = hostname1 hostname2 hostname3
или
das.preferredPrimaries = 192.168.1.1,192.168.1.2,192.168.1.3

Разделять список хостов можно пробелом или запятой. Также необязательно указывать обязательно пять хостов, можно меньше (тогда оставшиеся будут выбраны традиционным способом) или больше (тогда Primary станут первые 5 из них).

Внимание! Эта функциональность не является даже экспериментальной, она просто не поддерживается, и категорически не рекомендуется к использованию в продуктивной среде.

Источник: Duncan Epping (yellow-bricks.com)