После установки ESXi 8 на новые сервера Yadro VEGMAN R220 G3, наш vRops, который мониторит состояние системы виртуализации, начал отображать сообщение об ошибке ESXi host has packet errors.
Если выполнить команду esxcli network nic list на таком хосте, то она покажет такую информацию:vmnic4 0000:17:00.2 icen Up Up 10000 Full 40:a6:b7:d2:1c:6a 1500 Intel(R) Ethernet Controller E810-C for SFPvmnic5 0000:17:00.3 icen Up Up 10000 Full 40:a6:b7:d2:1c:6b 1500 Intel(R) Ethernet Controller E810-C for SFP
Командой esxcli network nic stats get -n vmnic4 можно увидеть на что обращает внимание система мониторинга:Total receive errors: 2104311
Receive length errors: 2104311
Эти счетчики с каждой секундой нарастают большими значениями.
Далее смотрим на одной из сетевых карт командой esxcli network nic get -n vmnic4 версию драйвера и прошивки. Вывод весь не показываю, только то, что важно:Firmware Version: 4.90 0x80020ef3 1.3863.0
Version: 1.11.1.9
Как мы видим на хост вместе с ESXi ставится не самая свежая версия драйвера. Находим более новую версию, например, версию 1.15.4. Файл с драйвером называется Intel-icen_1.15.4.0-1OEM.800.1.0.20613240_24443371.zip. Ссылок тут не привожу.
После скачивание и заброса его на хост, драйвер можно установить командой esxcli software component apply -d /vmfs/volumes/<ваше имя датастора>/Intel-icen_1.15.4.0-1OEM.800.1.0.20613240_24443371.zip. После этого перезагружайте хост и ошибки на сетевой карте пропадут.
Замена 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
проделайте следующие действия:
- Зайдите на проблемный ESXi-хост по SSH и выполните команду:
esxcli storage nfs listесли ошибка аналогичная, то это скорее все наш случай, переходим к следующим шагам - Проверяем что модули nfs не загружены в ядро
vmkload_mod -l | grep 'nfs' - Загружаем модули NFS в ядро
vmkload_mod nfs41client
vmkload_mod nfsclient - Включаем загрузку модуля при включении ESXi
esxcfg-module -e nfs41client
esxcfg-module -e nfsclient - Выполняем команду
esxcli storage nfs list, теперь она должна выполниться успешно. Если там есть NFS-датасторы в отключенном состоянии, то удаляем их командойesxcli storage nfs remove -v "Volume Name" - Перезагружаем ESXi
reboot - После перезагрузки добавляем 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 и шлюз по-умолчанию появится сам в настройках, сетка на нем заработает.