VMware – Page 13

Останов VCSA при нехватке места

У нас неожиданно стал прекращать работать VCSA, а конкретно сервис VPXD.

Стартнёшь ручонками – работает то десяток часов, то 20 минут. Из warning’ов – мало места для базы данных (List of VMDKs/Partitions for a vCenter Server Appliance 6.7 – Size Mount point and Purpose (70625)). VAMI показывает, что места в SEAT занято 90%. Также не работает Update Manager даже при запущенном VPXD. Все логи vpxd.log перебрали – ничего не заметили, как будто штатный останов.

Написали в техподдержку – те попросили логи собрать, а как их соберёшь, если vCenter то потухнет, то погаснет. Кое-как собрали через VAMI, да и те оказались не полные, пришлось ручонками скопировать с помощью WinSCP папку логов VPXD.

Поддержка логи смотрела внимательнее и нашла:

2019-08-27T06:50:34.343Z error vpxd[102197] [Originator@6876 sub=vpxdVdb] Shutting down the VC as there is not enough free space for the Database(used: 95%; threshold: 95%).
2019-08-27T06:50:34.343Z info vpxd[102197] [Originator@6876 sub=Default] Initiating VMware VirtualCenter shutdown
2019-08-27T06:50:35.412Z error vpxd[102111] [Originator@6876 sub=vpxdVdb] Insufficient free space for the Database (used: 95%; threshold: 95%)

2019-08-27T06:50:34.343Z error vpxd[102197] [Originator@6876 sub=vpxdVdb] Shutting down the VC as there is not enough free space for the Database(used: 95%; threshold: 95%).

2019-08-27T06:50:34.343Z info vpxd[102197] [Originator@6876 sub=Default] Initiating VMware VirtualCenter shutdown

2019-08-27T06:50:35.412Z error vpxd[102111] [Originator@6876 sub=vpxdVdb] Insufficient free space for the Database (used: 95%; threshold: 95%)

Действительно, места не хватает и VPXD сам себя отправляет отдыхать. Описание поведения vCenter есть КБ-шечке “Shutting down the VC as there is not enough free space for the Database” error (67017). Вот только она про /storage/db, а про /storage/seat умалчивает.

Добавили место у диска SEAT по инструкции Increasing the disk space for the VMware vCenter Server Appliance in vSphere 6.5 and 6.7 (2145603). Перезагрузили VCSA и всё заработало.

P.S. Так и не понял – с каких пор 90%=>95%?

P.P.S. Андрей подсказал откуда разница в процентах (данные после увеличения диска):

Вывод в VAMI: seat Total space 54.0 GB Used space 32.4 GB Available space 21.6 GB 60.1% of 54.0 GB

Вывод в df -h: /dev/mapper/seat_vg-seat 55G 33G 19G 64% /storage/seat

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

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

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

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

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

Релиз платформы VMware vSphere 6.7 Update 3

Компания VMware выпустила обновление своей платформы виртуализации VMware vSphere 6.7 Update 3:

VMware ESXi 6.7 Update 3 Release Notes

VMware vCenter Server 6.7 Update 3 Release Notes

VMware vSAN 6.7 Update 3 Release Notes

vSAN 6.7 U3 Technical Overview

New Release: PowerCLI 11.4.0

vSphere Client Plugins: What’s New in 6.7 Update 3

Проблемы с VMware HA после обновления vCenter

Майское обновление vCenter 6.0 (U3i) и 6.5 (U2d) вывело из строя несколько кластеров vSphere HA. Симптомы были одинаковые: часть узлов кластера не может связаться с мастером. Лечение, увы, отличалось:

части узлов хватило переконфигурировать HA-агента;
часть узлов пришлось выводить в режим обслуживания и перезагружать.

Увидеть ситуацию помогли Alarms, сработавшие на хостах.

P.S. Не все обновления одинаково полезны…

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

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

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

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

Данные о ВМ в vMotion Wizard

Про полезняшки в новых версиях vSphere мы уже писали ранее: о флешовом клиенте в статье Фильтры, задания и снимки в VMware vSphere 6.7, о ESXi-ом клиенте в Просмотр логов на ESXi.

Сегодня заметка о новой фишке vMotion Wizard – VM origin.

Часто бывает, что запустил перемещение виртуальной машины со сменой хоста и хранилища и тут приходит мысль “а сейчас-то как машина размещена?”.

Разработчики HTML5-клиента решили это дело упростить и сделали подсказку – достаточно щёлкнуть VM origin:

Развертывание виртуальной машины vSphere через PowerSHell часть 1

Стал задаваться вопросом – как автоматизировать выполнение рутинных операций в vSphere?

~~Лучше бы не задавался 🙂~~

Начал с задачи “развернуть виртуальную машину из шаблона с указанной кастомизацией гостевой операционной системы”.

Основные проблемы, с которыми я столкнулся:

мною использовалась настройка кастомизации ОС “Prompt User”, спрашивающая только IP-адрес (подразумевается, что развертывание происходит в одно и то же адресное пространство). Как оказалось, проще использовать передачу “всех” параметров IP в скрипте;
перемещение учетной записи сервера после ее развертывания для применения групповых политик в другой контейнер Active Directory;
поле “Notes” получает строку. Как передать ей несколько строк, если потребуется перевод строки, я пока не разбирался;
за кадром остались процессы дальнейшей настройки сервера – установка обновлений и дополнительного ПО. Это будет рассмотрено в следующих частях статьи.

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

А вот что получил:

Get-OSCustomizationSpec -Name windows | New-OSCustomizationSpec -Name temp1 -Type NonPersistent
Get-OSCustomizationSpec -Name temp1 | Get-OSCustomizationNicMapping | Set-OSCustomizationNicMapping -IpMode UseStaticIP -IpAddress '10.0.0.1' -SubnetMask '255.255.255.0' -DefaultGateway '10.0.0.254' -Dns '10.0.0.254','10.0.0.253'
New-VM -Name 'new-vm' -Template (Get-Template windows_template) -OSCustomizationSpec (Get-OSCustomizationSpec 'temp1') -ResourcePool (Get-ResourcePool -Name 'Resources'-Location 'Cluster_Name') -Datastore (Get-DatastoreCluster -Name 'Datastore_Cluster') -Notes "Zdes mogla by byt vasha reklama"
Start-VM -VM new-vm
Do {Get-ADComputer -identity new-vm -ErrorAction SilentlyContinue;write-host "." -nonewline -f red;sleep 3} until(Get-ADComputer -identity new-vm -ErrorAction SilentlyContinue -warningaction silentlycontinue)
Move-ADObject -identity (Get-ADComputer -identity new-vm).distinguishedname -TargetPath "OU=Servers,DC=DOMAIN,DC=COM"
Do {$tools=(Get-VM -Name new-vm).ExtensionData.Guest.ToolsStatus;write-host "." -nonewline -f red;sleep 3} until(($tools -eq "toolsOk") -or($tools -eq "toolsOld"))
Restart-VMGuest -VM new-vm -Confirm:$false
Start-Sleep -Seconds 10
Do {$tools=(Get-VM -Name new-vm).ExtensionData.Guest.ToolsStatus;write-host "." -nonewline -f red;sleep 3} until(($tools -eq "toolsOk") -or($tools -eq "toolsOld"))
Write-Host("Server is ready!")

Get-OSCustomizationSpec -Name windows | New-OSCustomizationSpec -Name temp1 -Type NonPersistent

Get-OSCustomizationSpec -Name temp1 | Get-OSCustomizationNicMapping | Set-OSCustomizationNicMapping -IpMode UseStaticIP -IpAddress '10.0.0.1' -SubnetMask '255.255.255.0' -DefaultGateway '10.0.0.254' -Dns '10.0.0.254','10.0.0.253'

New-VM -Name 'new-vm' -Template (Get-Template windows_template) -OSCustomizationSpec (Get-OSCustomizationSpec 'temp1') -ResourcePool (Get-ResourcePool -Name 'Resources'-Location 'Cluster_Name') -Datastore (Get-DatastoreCluster -Name 'Datastore_Cluster') -Notes "Zdes mogla by byt vasha reklama"

Start-VM -VM new-vm

Do {Get-ADComputer -identity new-vm -ErrorAction SilentlyContinue;write-host "." -nonewline -f red;sleep 3} until(Get-ADComputer -identity new-vm -ErrorAction SilentlyContinue -warningaction silentlycontinue)

Move-ADObject -identity (Get-ADComputer -identity new-vm).distinguishedname -TargetPath "OU=Servers,DC=DOMAIN,DC=COM"

Do {$tools=(Get-VM -Name new-vm).ExtensionData.Guest.ToolsStatus;write-host "." -nonewline -f red;sleep 3} until(($tools -eq "toolsOk") -or($tools -eq "toolsOld"))

Restart-VMGuest -VM new-vm -Confirm:$false

Start-Sleep -Seconds 10

Do {$tools=(Get-VM -Name new-vm).ExtensionData.Guest.ToolsStatus;write-host "." -nonewline -f red;sleep 3} until(($tools -eq "toolsOk") -or($tools -eq "toolsOld"))

Write-Host("Server is ready!")

Данный скрипт берет гостевую кастомизацию “windows” (Guest Customization OS) и создает на ее основе временную кастомизацию “temp1”.

Затем скрипт задает настройки IP, которые должна будет получить новая ВМ.

Далее мы создаем виртуальную машину из шаблона “windows_template”, используя подготовленную кастомизацию “temp1”. Машина создается в кластере “Cluster_name” с примечанием о том, для чего нужна эта ВМ. Диски шаблона при этом клонируются на кластер хранилищ (Datastore Cluster) с названием “Datastore_Cluster”.

Затем мы включаем виртуальную машину и ждем.

Ждем мы до тех пор, пока в AD не появится учетная запись компьютера. А эта запись должна появиться там потому, что в гостевой кастомизации настроено автодобавление ПК в домен.

Как только мы этого дождались, мы перекладываем эту учетную запись ПК в соответствующую OU.

Проверяем статус VMware Tools и, если они работают, перезагружаем наш сервер для применения актуальных групповых политик.

Затем ждем 10 секунд пока VMware Tools 100% остановятся в ходе перезагрузки, ждем пока они будут запущены и выводим на экран сообщение о том, что сервер готов.

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 была следующая:

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

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

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

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

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

удаление PSC;
переключение на другой PSC;
резервное копирование и восстановление PSC.

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

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

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

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

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

Проблемы с бэкапом из-за нецелого размера vmdk-диска

Обратил внимание на то, что некоторые виртуальные машины не бэкапятся через штатный VADP API. Техническая поддержка NetBackup нашла в логах, что причиной этого является дробный (нецелый) размер VMDK-диска.

Создать такой диск очень просто – указать дробный размер для терабайт в “толстом” клиенте:

Если изменить единицы измерения с терабайт на гигабайты, вы увидите, что диск занимает нецелое количество гигабайт (и соответственно, мегабайт).

Веб-клиент в этом плане получше – он сразу показывает наличие проблемы:

Лечится проблема достаточно легко:

Меняете единицы измерения на мегабайты и увеличиваете размер диска в сторону ближайшего целого значения. В приведенном случае вместо 2’086’666,23925781 МБ у вас должно стать 2’086’667 МБ.
Растягиваете размер файловой системы на вновь появившееся место.

Для экспресс-проверки вашей инфраструктуры вы можете воспользоваться следующим PowerCLI-скриптом:

Get-VM | Get-HardDisk | where {($_.capacityGB-[math]::Truncate($_.capacityGB)) -gt 0} | ft capacityGB, parent -AutoSize

1	Get-VM \| Get-HardDisk \| where {($_.capacityGB-[math]::Truncate($_.capacityGB)) -gt 0} \| ft capacityGB, parent -AutoSize

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

Релиз VMware vSphere 6.7 Update 2

Недолго ждали и вот VMware vSphere 6.7 Update 2 стал доступен:

VMware ESXi 6.7 Update 2 Release Notes

VMware vCenter Server 6.7 Update 2 Release Notes

Обзоры:

Enhancements to Working with Plug-ins in the vSphere Client (vSphere 6.7 Update 2)