Замена STS сертификата на vCenter

Менял я недавно vCenter сертификат с названием «STS Signing Certificate». Делал этот через веб-интерфейс клиента .
После нажатия на «Actions» — «Refresh with vCenter certificate» сертификат в интерфейсе успешно обновился, но появилось уведомление о необходимости всех систем. Я на всякий случай перезагрузил весь vCenter.  Сертификат как видно на скриншоте выдался на 8 лет до 2033 года. После этого я зашел по ssh на vCenter и запустил скрипт vCert.sh , с помощью которого проверил статус сертификатов.  В отчете  работы скрипта показывалось несколько ошибок. Путем некоторых манипуляций я перевыпустил еще раз «STS Signing Certificate». При такой манипуляции скрипт выпустил сертификат уже только на 2 года, при этом некоторые ошибки все еще висели:
«Checking VMDir certificate» и «Check STS VECS store configuration»

Для решения проблемы с «Checking VMDir certificate» я для начала выгрузил  отчет, который может сгенерировать скрипт vCert. В нем нашел такой сертификат:
Service Principal (Solution User) Certificates
Service Principal: WebClient_2014.05.19_021659
Issuer: O=VMware, Inc., OU=LogBrowser_2014.05.19_021659, CN=VMWARE/emailAddress=support@vmware.com
Subject: O=VMware, Inc., OU=LogBrowser_2014.05.19_021659, CN=VMware default certificate/emailAddress=support@vmware.com
Not Before: May 18 09:18:50 2014 GMT
Not After : May 16 09:18:57 2024 GMT
SHA1 Fingerprint : C6:7A:73:97:5C:CB:42:AC:48:55:72:0B:5E:8D:C7:5E:7B:0B:D9:FD
Signature Algorithm: sha256WithRSAEncryption
Subject Key Identifier:
Key Usage:
|_Digital Signature
|_Key Encipherment
|_Data Encipherment
Extended Key Usage:
|_TLS Web Server Authentication
Subject Alternative Name entries:
|_DNS:VMWARE
Other Information:
|_Is a Certificate Authority: No
|_Issuing CA in VMware Directory/VECS: No

Из-за него и возникала эта ошибка. Для его удаления я зашел в пункты меню 3 и затем 10, где скрипт vCert ругался на неиспользуемый сертификат (смотри скриншот ниже).  Я его удалил и после этого ошибка «Checking VMDir certificate» пропала

С ошибкой «Check STS VECS store configuration LEGACY» побороться оказалось также просто,  необходимо выполнить  команды
sed -i 's/STS_INTERNAL_SSL_CERT/MACHINE_SSL_CERT/' /usr/lib/vmware-sso/vmware-sts/conf/server.xml
/usr/lib/vmware-vmafd/bin/vecs-cli store delete --name STS_INTERNAL_SSL_CERT

и затем рестартовать одну из служб

service-control --restart vmware-stsd

Если закончилось место на vCenter

В случае, если место на одном из разделов  vCenter заканчивается или оно закончилось, то, логично, надо попробовать его очистить. Но у меня дело в том, что раздел /storage/log заполнился только на 80% при этом он занимает только 10 ГБ, поэтому проще его увеличить в 2 раза. Что для этого нужно?
1) определяем какие логические тома у нас сигнализируют о нехватке места
df -h
2) сопоставляем диски с точками монтирования
lsblk
3) сопоставляем диски и шины SCSI
lsscsi
4) расширяем диск виртуальной машины, у которой номер шины совпадает с найденным командой lsscsi (скриншот я сделал уже после расширения диска)

5) скриптом /usr/lib/applmgmt/support/scripts/autogrow.sh расширяем диск vCenter. После выполнения скрипта df -h убеждаемся, что диск расширился

vROPS не синхронизирует Metadata (vSphere Tags) из VMware vSphere

Боролся с такой проблемой — перестал получать обновления vSphere Tags  в систему VMware Aria Operations (vRops).  Нашел статью у вендора, где решается подобная проблема. В логах я не нашел такую ошибку как указано в статье, но мне помогла рекомендация рестартовать службу. В 7 версии Vsphere она называется «vAPI Endpoint». Её перезагрузка мне и помогла.

Ошибка при обновлении ESXi «Error while waiting for untar process»

Столкнулся с очередной ошибкой при установке патча VMware-ESXi-7.0U3q-23794027:

esxupdate: ERROR: esximage.Errors.InstallationError: VMware_locker_tools-light_12.3.5.22544099-23794019: Error while waiting for untar process ‘[‘/bin/tar’, ‘xzf’, ‘-‘, ‘-C’, ‘/locker/packages/’]’: Timeout (30 seconds) expired waiting for output from command ‘[‘/bin/tar’, ‘xzf’, ‘-‘, ‘-C’, ‘/locker/packages/’]’

На сайте Broadcom появилась свежая статья с описанием и решением данной проблемы. Повторять ее не вижу смысла, хотелось лишь только добавить, что после последнего шага
vsish -e set /config/VisorFS/intOpts/VisorFSPristineTardisk 1
необходимо установить проблемный vib вручную (в статье это сказано по моему не однозначно)
esxcli software vib install -v /vmfs/volumes/../VMware_locker_tools-light_12.3.5.22544099-23794019.vib
Пакет VMware_locker_tools-light_12.3.5.22544099-23794019.vib скачивается отсюда.

Ошибка «Vmkernel module necessary for this vsi call not loaded» при добавлении NFS-датастора на ESXi

Привет! Если после перезагрузки у вас на ESXi пропали датасторы или не добавляются с ошибкой
An error occurred during host configuration.
Operation failed, diagnostics report: Unable to complete Sysinfo operation. Please see the VMkernel log file for more details.: Vmkernel module necessary for this vsi call not loaded


проделайте следующие действия:

  1. Зайдите на проблемный ESXi-хост по SSH и выполните команду:
    esxcli storage nfs list если ошибка аналогичная, то это скорее все наш случай, переходим к следующим шагам
  2. Проверяем что модули nfs не загружены в ядро
    vmkload_mod -l | grep 'nfs'
  3. Загружаем модули NFS в ядро
    vmkload_mod nfs41client
    vmkload_mod nfsclient
  4. Включаем загрузку модуля при включении ESXi
    esxcfg-module -e nfs41client
    esxcfg-module -e nfsclient
  5. Выполняем команду
    esxcli storage nfs list, теперь она должна выполниться успешно. Если там есть NFS-датасторы в отключенном состоянии, то удаляем их командой esxcli storage nfs remove -v "Volume Name"
  6. Перезагружаем ESXi
    reboot
  7. После перезагрузки добавляем NFS-датасторы, ошибок теперь быть не должно.

Скрипт вывода информации о занятом и выделенном дисковом пространстве в кластере vSphere

Get-Module -ListAvailable VMware* | Import-Module
$vcservers = "адрес сервера vSphere"
$username = "имя пользователя"
$report = @()
$Used = 0
$Unused = 0
$AllUsed = 0
$AllAllocated = 0
Connect-VIServer $vcservers -User $username -Password 'пароль пользователя'

$allvms = Get-Cluster -name ‘имя кластера‘ | Get-VM
foreach ($VMName in $allvms){
$Server = Get-VM $VMName | Get-View
foreach ($size_com in $($Server.Storage.PerDatastoreUsage).Committed) {
$Used += $size_com
}
foreach ($size_uncom in $($Server.Storage.PerDatastoreUsage).Uncommitted) {
$Unused += $size_uncom
}
$Used = [math]::Round((($Used)/1024/1024/1024),2)
$Unused = [math]::Round((($Unused)/1024/1024/1024),2)
$Allocated = $Used + $Unused
$row = «» | select ‘Имя сервера’, ‘Занято(ГБ)’, ‘Выделено(ГБ)’
$row.’Имя сервера’ = $VMName
$row.’Занято(ГБ)’ = $Used
$row.’Выделено(ГБ)’ = $Allocated
$report += $row
$AllUsed += $Used
$AllAllocated += $Allocated
}
$report | ft
Write-Host «Всего занято дискового пространства (ГБ): $AllUsed»
Write-Host «Всего выделено дискового пространства (ГБ): $AllAllocated»
Disconnect-VIServer $vcservers -Confirm:$False

Проблема с Zabbix Appliance

Проблема:
Скачал и установил готовый appliance от zabbix . Но с ним есть проблемы — при создании снапшота виртуальная машина перестает работать, а при запуске ее вновь ошибка Object type requires hosted I/O Failed to start the virtual machine. Module Disk power on failed. Cannot open the disk ‘/vmfs/volumes/5bcda19c-7fdf91a6-d95f-2c768aae1eb8/zabbix/zabbix_appliance-6.4.10-disk1.vmdk’ or one of the snapshot disks it depends on. После этого ее удается запустить только после исправления виртуального диска командой vmkfstools -x repair. Пытался изменить настройки виртуальной машины, вместо ide контроллера для диска выбирал SCSI, ошибка Unsupported or invalid disk type 7 for ‘scsi0:0’. Ensure that the disk has been imported. Failed to start the virtual machine. Module DevicePowerOn power on failed. Unable to create virtual SCSI device for scsi0:0, ‘/vmfs/volumes/5bcda19c-7fdf91a6-d95f-2c768aae1eb8/zabbix/zabbix_appliance-6.4.10-disk1.vmdk’. Снапшот на выключенной виртуальной машине делается без ошибок.
VMware ESXi, 7.0.3, 21424296
vCenter 7.0.3 22357613
Решение:
Смотрим что творится с дисками виртуальной машины:

Открываем содержимое диска, которое занимает меньше всего пространства и видим:


Видим, что тип диска Sparse, который имеет формат split, делящий диск на 2ГБ куски. Такой тип диска поддерживается  в работе Vmware Workstation. Чтобы корректно работать с ним на VMware Esxi необходимо выполнить конвертацию  диска:

vmkfstools -i zabbix_appliance-6.4.10-disk1.vmdk zabbix_appliance-6.4.10-disk1_new.vmdk

Добавляем новый диск к ВМ, вместо старого
Удаляем старый диск вместе с дескриптором:

vmkfstools -U zabbix_appliance-6.4.10-disk1.vmdk

Скрипт вывода в CSV занятого пространства на каждом датасторе для всех включенных виртуальных машин в кластере VMware

$VCServer = 'fqdn vcenter сервера'
$VC = Connect-VIServer $VCServer -User 'учетная запись vCenter' -Password 'пароль для учетной записи'
$report = @()
$allvms = Get-Cluster VM-Cluster05 | Get-VM | where {$_.PowerState -eq "PoweredOn"}
foreach ($vm in $allvms) {
$vmview = $vm | Get-View
foreach($disk in $vmview.Storage.PerDatastoreUsage){
$dsview = (Get-View $disk.Datastore)
$dsview.RefreshDatastoreStorageInfo()
$row = "" | select VMNAME, DATASTORE, VMUSED_GB
$row.VMNAME = $vmview.Config.Name
$row.DATASTORE = $dsview.Name
$row.VMUSED_GB = [math]::round((($disk.Committed)/1024/1024/1024),0)
$report += $row
}
}
$report | Export-Csv "C:\Temp\vm_ds.csv" -NoTypeInformation
Disconnect-VIServer $VC -Confirm:$False

После восстановления vSphere не работает на нем сеть или ошибка Setting ip/ipv6 configuration failed: (‘ IP configuration not allowed’,)

Привет!
После восстановления из бекапа vCenter 7 вы можете попасть в такое состояние, когда на нем не работает интерфейс  управления, то есть vCenter не доступен по сети. Зайдя в его настройки можно увидеть, что в нем не задан шлюз по-умолчанию, а при попытке его задать и сохранить возникает ошибка:
Setting ip/ipv6 configuration failed: (‘ IP configuration not allowed’,).
Такая ошибка возникла у меня в ситуации, когда vCenter был подключен к порт-группе без эфемерных портов в распределенном коммутаторе. Так как этот коммутатор был создан на том же vCenter, который и был восстановлен, то он, по существу, не позволял подключить новый интерфейс в порт-группе на этом коммутаторе. Чтобы такого не было, надо заранее создавать порт-группу с эфемерными портами. Ну а если уже поздно, то надо действовать по инструкции  с сайта VMware и временно настроить обычный виртуальный коммутатор и подключать сеть виртуальной машины с vCenter к нему. После этого перезагружаем восстановленный Vcenter и шлюз по-умолчанию появится сам в настройках,  сетка на нем заработает.

Если недоступна миграция виртуальной машины в vCenter после ее восстановления

Привет!
Столкнулся с проблемой, что после восстановления из бекапа виртуальной машины в vCenter нет возможности ее мигрировать на другой хост или массив. Соответствующий пункт меню просто на просто недоступен. Не понятна причина такого поведения, т.к. с этим сталкиваются не все виртуальные машины, которые были восстановлены. Но есть способ как это починить, вот официальный мануал от VMware — https://kb.vmware.com/s/article/1029926