Релиз RVTools 4.4.1

Rob de Veij выпустил обновление своей отличной утилиты инвентаризации VMware vSphere — RVTools версии 4.4.1.

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

  • Теперь для разработки используется Visual Studio 2022, VMware vSphere Management SDK 8.0
  • Log4net обновлен до версии 2.0.15
  • RVToolsPasswordEncryption теперь использует mac-адрес вместо фиксированной строки для шифрования пароля
  • На странице вкладки vInfo появились новые колонки: Total Disk capacity MiB, Folder ID, FT role, Reboot powerOff, EFI Secure boot option и SMBIOS UUID.
  • На вкладке vCPU новый столбец: “Numa Hotadd Exposed” – раскрывается ли виртуальная топология NUMA при включенном горячем добавлении процессора.
  • На странице вкладки vDisk новые колонки: Disk UUID, Sharing mode
  • На всех связанных страницах вкладок VM столбцы тегов перемещены непосредственно перед столбцом “Datacenter”
  • На всех страницах вкладок, связанных с ВМ: Изменен текст всплывающей подсказки VM UUID на “VirtualCenter-specific 128-bit UUID of a virtual machine”
  • На странице вкладки vSource добавлены новые столбцы: Version, Patch level и VI SDK Server
  • На странице вкладки vHealth: /storage/archive исключен для проверки “free disk capacity”, так как раздел /storage/archive может быть заполнен by design 
  • Исправление ошибки на странице вкладки vInfo: колонка “Primary IP Address” не показывала правильное значение
  • Исправление ошибки на странице вкладки vNetwork: определение того, является ли ip-адрес ipv4 или ipv6, не всегда проходило успешно

Релиз RVTools 4.3.2

Rob de Veij выпустил обновление своей отличной утилиты инвентаризации VMware vSphere — RVTools версии 4.3.2.

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

  • используется .NET Framework версии 4.6.2 вместо 4.6.1.
  • используется Newtonsoft.Json версии 13.0.1 вместо 12.0.3.
  • исправлена ошибка: таймаут соединения для огромных сред vSphere.
  • исправлена ошибка: изменена целевая платформа для RVToolsMergeExcelFiles на “Any CPU”, что позволило использовать платформу X64 и избежать исключения System.OutOfMemoryException для огромных сред vSphere.
  • исправлена ошибка: удаленные выходные строки для отладки из RVToolsMergeExcelFiles.

Доступность инструкций процессора в зависимости от версии vHW

Ранее на бложике публиковались две статьи о разном поведении виртуальных машин при разном vHW и EVC

  1. Минимальная рекомендуемая версия vHW
  2. EVC Mode и vHW

Один из участников сообщества VMUG провел анализ доступных инструкций процессора в зависимости от версии виртуального железа с помощью утилиты /proc/cpuinfo. В результат появилась занимательная таблица:
vHW CPU flags Исходник в Google Таблицы.

P.S. Комментарий автора:

После обсуждения CPUID решил проверить зависимость доступных инструкций от vHW, но основной вывод уже был сделан в КВ по процессорным уязвимостям: “безопасной” версией является 9, а тормозить оно перестаёт на 11. Также выяснилось:
1. vHW режет флаги не так сильно, как EVC. Например, на vHW=8 доступны fma и movbe (Haswell), а на vHW=13 доступны xsavec и xsaves (Skylake).
2. Между 13-16 версиями без NVDIMM и гостевой виртуализации нет разницы.

Настройка разрешений на vCenter

Как-то потребовалось мне решить задачу “сосуществования” в рамках vCenter нескольких команд администраторов, обслуживающих свои кластера vSphere.

В vSphere есть достаточно гибкий механизм предоставления полномочий вплоть до отдельной виртуальной машины, однако выяснилось, что есть ряд полномочий, задающихся не на уровне кластера хостов или папки виртуальных машин.

Continue reading “Настройка разрешений на vCenter”

VMware PSC replication

Компонент Single Sign On, выполняющий проверку подлинности, появился в VMware vSphere 5.1. К vSphere 5.5 он стал “адекватнее” и стабильнее.

Его можно было поставить как на отдельный сервер, так и совместить вместе с vCenter Server.

В vSphere 6 этот компонент был объединен с другими сервисами в роли Platform Service Controller.

С тех пор и до vSphere 6.7 (или 6.7 Update 1) рекомендуемой схемой высокодоступного размещения PSC была следующая:

  1. Несколько внешних/отдельных PSC-серверов. Размещать PSC совместно с vCenter и реплицировать данные не некомендовалось.
  2. Требовался балансировщик между PSC и vCenter-серверами (хотя я видел скрипты, переключающие vCenter на резервный psc при недоступности основного).

Наверное, особенно круто было заниматься обновлением этого зоопарка из 4+ систем.

Особенно я прослезился со следующего KB – правила репликации PSC, рассказавшего о том, что репликация происходит в том порядке, в каком ранее добавлялись PSC (если развернули первый, на него нацелили второй, на второй – третий, то и репликация пойдет по такой схеме). Все связи между SSO-службами добавляются и удаляются только вручную.

Попутно узнал, что рекомендуемая топология – c центральным PSC.

Еще несколько KB:

А теперь к хорошим новостям: забудьте все, что только что прочитали 🙂

Начиная с vCenter 6.7 рекомендуемой топологией является встроенный PSC для любой топологии. Вы даже можете сделать vCenter HA (vCenter High Availability) для встроенного PSC, если хотите его защитить.

Ну и к вопросу резервной копии – в v6.7 появился ручной File-Based Backup, позволяющий сделать бэкап системы vCenter+PSC, восстанавливаемой с нуля с помощью этих файлов.

А в v6.7 Update 1 – возможность запуска бэкапа по расписанию.

В общем, администрирование нескольких vCenter-серверов в v6.7 стало значительно легче.

VMFS vs NFS in vSphere

Как-то Diz задал вопрос: “правда ли, что NFS гораздо лучше, чем SCSI для хранилищ в случае одного большого хранилища? Как ситуация изменилась в 6.x?”

Наше путешествие будет включать в себя следующие пункты:

  • SCSI-очереди.
  • А что там с NFS?
  • Решает ли скорость протокола?
  • vSphere 6.x?
  • Рекомендации.

SCSI-очереди

Отлично тема очередей раскрыта тут. Continue reading “VMFS vs NFS in vSphere”

Изменение имени хоста VMware ESXi

Иногда возникают простые задачи, при решении которых возникают странные эффекты.

В нашей организации есть требование именовать все серверы по FQDN имени с указанием суффикса домена.

Но, как обычно, часть работничков на это дело забивает.

При инвентаризации хостов ESXi несколько таких замечаний было обнаружено. Для переименования воспользовались заметкой Changing the name of an ESX or ESXi host (1010821) и подали команды в SSH:

В результате получили esxi-01.domain.local.domain.local ;). Ошибка была простая – указали параметру host имя с суффиксом домена.

Проверить каждый параметр можно одной командой:

Исправить ошибку можно двумя способами – задать fqdn или домен:

PowerCLI – CloneVM

Понадобилось наполнить объект vAPP однотипными клонами одной и той же ВМ.

Клонировать ее вручную показалось трудоемко – изучил возможности PowerCLI и написал себе шпаргалку:

После подключения к vCenter запускаем подобный скрипт:

После запуска данного скрипта у вас появится 67 однотипных клонов виртуальной машины vm01_bi.

Вместо параметра VApp рекомендуется использовать параметр “ResourcePool”

VMware – возможна потеря данных в SEsparse

Благодаря подписке на рассылку от Veeam Community Forums, углядел наличие одной прелестной проблемы с vSphere.

При использовании SEsparse-снапшотов могут наблюдаться следующие симптомы:

  • СУБД могут репортовать о несогласованности блоков данных внутри БД;
  • гостевые операционные системы могут сообщить о сбоях блоков данных;
  • виртуальные машины могут перестать загружаться.

Continue reading “VMware – возможна потеря данных в SEsparse”

Балансировка хранилищ Round Robin в VMware vSphere и iops=1

В одном ЦОДе нашей компании используется VMware vSphere и HP EVA 6400. Так получилось, что техподдержка HPE ткнула нас носом в “Best Practice Guide” и посоветовала применить рекомендации по RoundRobin-балансировке и переключению путей на каждый iops.

Я был настроен скептически, так как я прекрасно помню статью Duncan Epping о том, что это (iops=1) – бесполезный совет. Однако я перечитал комментарии и решил, что я был неправ. Если вкратце – то у каждого порта HP EVA (равно как и других массивов) своя очередь в 1000 команд. И, оставив параметр по умолчанию (или вообще используя MRU), легко упереться в эту очередь.

Continue reading “Балансировка хранилищ Round Robin в VMware vSphere и iops=1”