Слетают настройки ESXi после его перезагрузки

Недавно столкнулся с такой проблемой: ставлю на ProLiant BL460c Gen9 VMware ESXi версии 6.5.0 из образа VMware-ESXi-6.5.0-Update3-18678235-HPE-Gen9plus-650.U3.10.8.0.36-Oct2021.iso. Операционная система успешно ставится, я делаю первоначальные настройки: сети, имени хоста и т.п. и после хост перезагружаю. После перезагрузки все внесённые мной настройки слетают.
Нашел KB от VMware, где описывается похожая на мою проблема, правда с более старым билдом. Начал выполнять инструкцию по этой статье, Выполняю команду на ESXi: grep storage-path-claim /var/log/sysboot.log а затем grep 'mounted.*rw' /var/run/log/vobd.log|tail -1 и нужно определить разницу времени между первым и вторым событием. В статье упоминается про несколько секунд. У меня же это время было в районе 20-30 минут. Значит продолжение этой статьи нам не подходит. Что же делать? Так как ESXi у меня поставлен был на RAID-массив, то выясняем что за массив, какая версия прошивки и драйвера в ОС у него.
С помощью команды esxcli storage san sas list узнаем название адаптера, версию его прошивки и драйвера.  У меня он оказался RAID-контроллер Smart Array P244br, версия прошивки 7.20 и версия драйвера 65.0072.0.149. Если посмотреть на VMware Compatibility Guide для этого адаптера, то увидим, что
версия прошивки у нас стоит новее, чем требуется 🙂 Делаем downgrade прошивки. Я это делаю с помощью старого isо-образа ServicePack for Proliant для G9 серверов — P35938_001_spp-2021.05.0-SPP2021050.2021_0504.129.iso. После отката прошивки пробуем делать изменения в настройках ESXi и перезагружать его — настройки сохраняются. Ура!

VMware ESX unrecoverable error. EPT misconfiguration

Столкнулись с проблемой на одном из хостов виртуализации. При миграции с него виртуальных машин на другой хост виртуальная машина с большой долей вероятности перезагружалась. В логах хоста были подобные сообщения:
Error message on <VM_Name> on <HOST_Name> in <Datacenter_Name>: VMware ESX unrecoverable error: (vcpu-2) vcpu-3:EPT misconfiguration: PA 14f11e7f8
Поддержка Vmware обратила внимание, что в логе /var/run/log/vmkernel.log упоминается постоянно одно и тоже виртуальное ядро:
2023-06-02T17:51:18.058Z cpu24:527386)WARNING: World: vm 527386: 8726: vmm0:<VM_Name>:vcpu-0:EPT misconfiguration: PA 2020eb000
2023-06-02T17:51:57.933Z cpu24:527362)WARNING: World: vm 527362: 8726: vmm6:<VM_Name>:vcpu-6:EPT misconfiguration: PA 1a53f87f8
2023-06-02T19:07:30.107Z cpu24:525206)WARNING: World: vm 525206: 8726: vmm1:<VM_Name>:vcpu-1:EPT misconfiguration: PA bf13bf80
2023-06-02T23:10:06.672Z cpu24:535256)WARNING: World: vm 535256: 8726: vmm0:<VM_Name>:vcpu-0:EPT misconfiguration: PA 80578f7f8
2023-06-02T23:11:37.296Z cpu24:535777)WARNING: World: vm 535777: 8726: vmm2:<VM_Name>:vcpu-2:EPT misconfiguration: PA 3651f558
2023-06-03T00:45:52.563Z cpu24:527569)WARNING: World: vm 527569: 8726: vmm3:<VM_Name>:vcpu-3:EPT misconfiguration: PA 14f11e7f8

Оказывается есть  KB от Vmware с аналогичной ситуацией. Что делать?
1) Меняем физически процессорные сокеты местами (если у вас конечно 2 физ. сокета) и переусаживаем планки ОЗУ. Я поменял, в логах стали ошибки уже на ядре cpu56. Значит все верно, проблема в процессоре.
2) Меняем процессор (сокет). Мы заменили и ошибка после этого пропала. Проблема решена.

VMware VCSA «dracut: FATAL: FIPS integrity test failed»

Привет!
Вчера на ровном месте начала возникать ошибка в самом начале  загрузки appliance с VMware vSphere 7 (7.0.3.01500)
dracut: FATAL: FIPS integrity test failed

Временное решение, чтобы система загрузилась: нажать клавишу «E» в момент загрузки GRUB меню и в конце строки с параметрами загрузки системы написать:
fips=0

После этого система загрузится как обычно.
При следующей перезагрузке надо будет повторить данную манипуляцию. Пока проблема, получается, полностью не устранена. Буду в ближайшее время обновлять VCSA
P.S. После загрузки системы я проверял официальным методом — FIPS не включен.
Update от 13.09.2023 года: для решения проблемы необходимо:
1) зайти на vcenter под учеткой root
cd /boot/grub2/
vi grub.cfg
Добавить значение fips=0 после systemd_cmdline
2) При следующем обновлении vcenter, после перезагрузки выполнить команду "mkinitrd -q" в консоли vcenter и удалить параметр "fips=0" из загрузчика

Недоступность HBA-адаптера HP LPe1605 16Gb после обновления ESXi с версии 6.5 до 7.0.3, билд 21424296

Привет! Столкнулся с проблемой при обновлении некоторых  ESXi хостов до версии 7.0.3, билд 21424296. После обновления не виден HBA-адаптер HP LPe1605 16Gb и соответственно все датасторы, подключенные по оптическим линиям, перестали быть доступными. В чем же дело? Смотрим на сайте VMware какая версия драйвера HBA-адаптера поддерживается. Видим, что это версия lpfc version 14.0.169.25-5vmw. Смотрим какая версия драйвера используется для HBA-адаптера в нашем обновленном хосте командой esxcli software vib list. Видим что там более новая версия 14.0.543.0. Начинаем искать в интернете про эту  версию и находим официальную информацию. Что делать? Нам нужен vib-пакет с версией драйвера 14.0.169.25. Где взять? Заходим на сайт https://esxi-patches.v-front.de/ESXi-7.0.0.html Через поиск находим нужную версию драйвера, качаем его. Не нужно логиниться на сайт VMware под своими неработающими учетками)). Далее закидываем этот vib-пакет на ESXi-хост через WinSCP на постоянное хранилище, желательно доступное со всех других проблемных узлов. Командой esxcli software vib remove -n lpfc удаляем старый пакет драйвера. Перезагружаем хост. Далее командой esxcli software vib install -v /vmfs/volumes/<ваш датастор>/VMW_bootbank_lpfc_14.0.169.25-5vmw.703.0.35.19482537.vib ставим новый (старый) драйвер. Перезагружаемся и, вуаля, HBA-адаптер снова работает.

Ошибка при in-place upgrade Windows Server

Привет!
Если в процессе обновления до новой редакции Windows Server вы столкнетесь с ошибкой «Windows could not configure one or more system  components»in-place upgrade error

а после отката система покажет ошибку 0xC1900101 — 0x30018error in-place upgrade

то знайте, что проблема скорее всего в одной из установленных программ. В моем случае это был Crypto Pro CSP. После ее удаления и перезагрузки запускаем обновление заново и ошибки уже не будет. Проверено.

Windows cannot find Microsoft Software License Terms

Если при in-place upgrade операционной системы Windows у вас возникла ошибка «Windows cannot find Microsoft Software License Terms» сразу после этапа выбора операционной системы. Проверьте файл C:\$Windows.~BT\Sources\Panther\setuperr.log (путь может отличаться) на наличие номера ошибки. В моем случае ошибка была с номером 0x060613. Мне помогло, то что нашел решение на сайте technet.microsoft.com, где посоветовали проверить политики безопасности а точнее политику «Manage auditing and security log» узкому кругу лиц, в группу которых не входила учетная запись, которая запускала установщик системы. Я поменял учетку на ту, что имеет более расширенные привилегии и установка прошла успешно.

«Произошла внутренняя ошибка подключения к удаленному рабочему столу» или «An internal error has occurred»

Привет!
Если после установки на сервер программного обеспечения «СКЗИ СКАД Сигнатура» или «ViPNet CSP» у вас возникает ошибка при подключении по RDP к этому серверу: «Произошла внутренняя ошибка подключения к удаленному рабочему столу» или «An internal error has occurred», значит эта заметка для вас. Чтобы исправить эту ошибку, нужно отключить соответствующие dll:
regsvr32 /u vdcng.dll — на сервере «СКЗИ СКАД Сигнатура»
regsvr32 /u Itccng.Dll — на сервере с «ViPNet CSP»

Контролируем доступ по RDP с помощью Telegram и Powershell

Решил я тут на днях  немного упростить жизнь и заодно вспомнить что такое написание скриптов. Не буду хвалиться,  скажу сразу, что за образец взял готовую статью с habr.com. Мне понадобилось с помощью телеграмм и его бота управлять правилом встроенного в windows server брандмауэра. На нём настроено ограничение на вход по RDP с конкретных подсетей (сами знаете что будет, если RDP сервис выставить в интернет без какой-либо защиты). Вот готовый скрипт, осталось только в нем вставить идентификатор бота, аккаунта с которого можно будет отправлять ему сообщения и возможно поменять название правил файервола (у меня они со стандартными именами в русской локализации). После этого добавляйте его в планировщик задач.
Читать далее «Контролируем доступ по RDP с помощью Telegram и Powershell»

Скрипт переноса общей папки на сервере с Windows

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

# Cоздание копии папки $NameFolder находящейся в $FolderPath1 в директорию $FolderPath2 и копирование ее содержимого со всеми атрибутами.
# Проверка есть ли подключения к общей папке. Если нет, то производится остановка расшаривания и докопирование содержимого. Исходная папка рекурсивно удаляется
# Логи сохраняются в папку $LogsFolderPath

$NameFolder = ‘Общая папка отдела’ #название исходной папки
$FolderSource= ‘F:\Общие папки\’ #путь к исходной папке (обязателен обратный слэш в конце пути)
$FolderDest = ‘D:\Общие папки\’ #путь к папке назначения (обязателен обратный слэш в конце пути)
$LogFolder = ‘C:\MoveFolderLogs\’ #путь к папке с логами (должна быть создана вручную)

$notshare = $false #определяем, что по-умолчанию исходная папка расшарена
$LogFile = $LogFolder + «sync-$NameFolder.log»
$FolderPath1 = $FolderSource+$NameFolder
$FolderPath2 = $FolderDest+$NameFolder

if (!(Test-Path -Path $LogFolder)){
Write-Host «Не создана папка для логов!» -ForegroundColor Yellow }

$SmbShare = Get-SmbShare | where {$_.Path -eq «$FolderPath1» }
if (!(Test-Path -Path $FolderPath2)){
$ACL = Get-Acl $FolderPath1 -Audit
Write-Host «Создание папки назначения» -ForegroundColor Green
New-Item -name $NameFolder -Path $FolderDest -ItemType Directory 1>$null
Set-Acl -AclObject $ACL -Path $FolderPath2
} else
{ Write-Host «Папка назначения уже создана» -ForegroundColor Green }
if (!($SmbShare)){
Write-Host «Исходная папка не расшарена» -ForegroundColor Yellow
$notshare = $true;
$NewSmbShareName = $NameFolder
}
if ((($SmbShare).CurrentUsers -eq «0») -or ($notshare -eq $true)){
if ($notshare -eq $false){
Write-Host «Зашаривание общей папки» -ForegroundColor Green
Remove-SmbShare -Name ($SmbShare).Name -Force
Write-Host «Начинаем копировать файлы общей папки…» -ForegroundColor Yellow -NoNewline
robocopy.exe $FolderPath1 $FolderPath2 /COPYALL /E /DCOPY:DAT /R:3 /W:5 /V /NP /NS /LOG+:$LogFile 1>$null
Write-Host «Завершено» -ForegroundColor Green
Write-Host «Расшаривание общей папки по новому расположению» -ForegroundColor Green
New-SmbShare -Name ($SmbShare).Name -Path $FolderPath2 -CachingMode None -ChangeAccess «Everyone» 1>$null
Write-Host «Удаление исходной папки» -ForegroundColor Green
Remove-Item -Path $FolderPath1 -Force -Recurse
}
else {
Write-Host «Начинаем копировать файлы общей папки…» -ForegroundColor Yellow -NoNewline
robocopy.exe $FolderPath1 $FolderPath2 /COPYALL /E /DCOPY:DAT /R:3 /W:5 /V /NP /NS /LOG+:$LogFile 1>$null
Write-Host «Завершено» -ForegroundColor Green
Write-Host «Расшаривание общей папки по новому расположению» -ForegroundColor Green
New-SmbShare -Name $NewSmbShareName -Path $FolderPath2 -CachingMode None -ChangeAccess «Everyone» 1>$null
Write-Host «Удаление исходной папки» -ForegroundColor Green
Remove-Item -Path $FolderPath1 -Force -Recurse
}
}
else {
Write-Host «Подключений к общей папке»($SmbShare).Name»:»($SmbShare).CurrentUsers -ForegroundColor Yellow
Write-Host «Начинаем копировать файлы общей папки…» -ForegroundColor Yellow -NoNewline
robocopy.exe $FolderPath1 $FolderPath2 /COPYALL /E /DCOPY:DAT /R:3 /W:5 /V /NP /NS /LOG+:$LogFile 1>$null
Write-Host «Завершено» -ForegroundColor Green
Write-Host «Запустите этот скрипт повторно после завершения активных SMB-подключений» -ForegroundColor Red
}

Veeam. Проблема с бекапом на ленту

В случае если у вас Veeam Backup выдает ошибку «Failed to start new tape backup session: Failed to get last session number, sessions map is empty» или «Failed to get last session number, sessions map is empty. Failed to get last session number, sessions map is empty.«, знайте, что нужно найти последнюю использованную кассету и очистить ее.  После этого можно запускать бекап на ленту вновь и он должен успешно начаться.
У меня эта ошибка началась после того как база Veeam Backup перестала быть доступной в момент бекапа на ленту. Бекап аварийно завершился и больше не запускался, выпадая с ошибкой, указанной выше.