PowerCLI. Использование Get-View. Часть 1.

У меня накопилось определенное количество информации об использовании Get-View. И чтобы все это систематизировать, в том числе и для себя, пишу данный цикл статей.

Get-View - это более продвинутая функция PowerCLI, которая позволяет получить большую гибкость в управлении виртуальной инфраструктурой. Кроме того, скорость выполнения Get-View выше, чем аналогичных командлетов PowerCLI. 

Использование PowerCLI для установки "Сheck and upgrade vmware tools before each power on"

Настройка проверки и обновления vmware tools перед каждым включением ВМ возможна в том числе и с помощью Update Manager. Поэтому прежде чем перейти собственно к вопросу, обозначенному в заголовке, рассмотрю некоторые моменты, касающиеся самого процесса обновления VMware Tools, не затронутые в прошлой статье Обновление VMware Tools с использованием VUM (Update Manager). Там не все так просто, поэтому остановлюсь на них поподробнее сейчас.

Обновление VMware Tools с использованием VUM (Update Manager)

Также в данной статье будут приведены некоторые команды PowerCLI для получения статуса VMware Tools.

Я как-то всегда надеялся на  VMware vSphere Update Manager (VUM), в том числе и при обновлении VMware Tools. До сегодняшнего дня.

Еще 14.12.2017 вышла версия VMware Tools 10.2.0. В статье VMware обновила пакет VMware Tools до версии 10.2.0 пишут: "Кстати, в онлайн-репозитории VMware версии 10.2 на момент написания заметки еще не было, но скоро он должен обновиться."

И вот я собственно сижу, жду. Сегодня задумался над тем, а где собственно обновления?

Время выполнения команды в VMware vSphere PowerCLI

Для того, чтобы узнать время выполнения команды в VMware vSphere PowerCLI, необходимо заключить ее в Measure-Command -Expression {КОМАНДА}. Например:

Measure-Command -Expression {Move-VM -VM VM-CLI -Datastore Huawei-1} 

Таким образом можно узнать время миграции ВМ с одного стораджа на другой.

Следует отметить, что данная команда, показывая время выполнения, не выводит сам результат выполнения исходной команды. 

Еще один способ - это использование методов "StartExecutionTime" и "EndExecutionTime" уже после выполнения замеряемой команды 

$command = Get-History -Count 1  
$command.EndExecutionTime - $command.StartExecutionTime



Однако использование StartExecutionTime" и "EndExecutionTime" дает более грубые результаты. 

PowerCLI: включение SSH на хостах ESXi

Мою шпаргалку по использованию PowerCLI начну со статьи о SSH (включение, отключение, статус). 

Попробую охватить различные сценарии, в частности включение доступа по SSH:
- на всех хостах ESXi;
- на определенном хосте ESXi;
- на определенных нескольких хостах ESXi;
- для определенного кластера;
а также получение статуса SSH на хостах ESXi.

VMware ESXi 6.0. Влияние балансировки NUMA на производительность. Часть 2.

Первую статью в новом 2018 году начну с продолжения рассмотрения NUMA.
В прошлой статье VMware ESXi 6.0. Влияние балансировки NUMA на производительность. Оптимальное число VPD я рассматривал тяжелые условия работы виртуальных машин. Одним из показателей "тяжелости" - это количество свободной памяти в NUMA узле. Проводя множество экспериментов, я пришел к выводу, что имеется своеобразный порог свободного объема на NUMA узле: 12-15 Гб. Причем этот порог не жесткий. Рассмотрим как этот порог возникает.

VMware ESXi 6.0. Влияние балансировки NUMA на производительность. Оптимальное число VPD.

На тему NUMA в vmware написано относительно много статей, где даны рекомендации по конфигурированию виртуальной машины. В основном они касаются настройки процессора и даны соответствующие рекомендации. Однако когда я приступил к практическим тестам то выяснил, что не все так однозначно. Даже если все сделано согласно рекомендациям, и у вас достаточно свободных ресурсов (CPU, память), то производительность wide vm (виртуальная машина, которая выходит за пределы узла NUMA) может проседать. Виной тому - балансировка NUMA. Вернее - память, несбалансированная между NUMA-узлами. Да и прочитанные рекомендации по "ядро-на-сокет" тоже оказались не универсальными.
Сразу оговорюсь - по сути это не такая большая проблема, поскольку просадка производительности наблюдается лишь для приложений, которые умеют задействовать многопоточность. А вот например Corona Renderer не зависит от балансировки NUMA. Более того, тест, сделанный программой Corona 1.3 Benchmark не зависел также и от конфигурации "ядро-на-сокет".
Данная статья написана для тех, кто знаком с технологией NUMA и знает правила конфигурования ВМ. Если кто-то не ориентируется в данной технологии, но ему все же интересны мои эксперименты с конфигурацией "двухпроцессорный сервер с 12 ядрами" то предварительно рекомендую прочитать соответствующие материалы, на некоторые приведены ссылки в низу моей статьи.
Итак, что пишет про балансировку сама VMware: The intelligent, adaptive NUMA scheduling and memory placement policies in ESXi can manage all virtual machines transparently, so that administrators don’t need to deal with the complexity of balancing virtual
machines between nodes by hand (Performance Best Practices for VMware vSphere® 6.0). Если по-русски, то: NUMA сама знает как балансировать виртуальные машины и размещать их память между узлами NUMA, вмешиваться не надо. На мой взгляд - нужно было добавить "в большинстве случаев".