An error occurred while applying security settings. Authenticated Users is not a valid user or group. This could be a problem with the package, or a problem connecting to a domain controller on the network. Check your network connection and click Retry, or Cancel to end the install.
Проблема появляется на тех системах, которые работают не в нативной локали en-us (а значит тестировщики тупо не протестировали другие локали).
Обходной путь для установки версии 17.6 на неанглоязычные версии Windows 11 выглядит так:
При установке 17.6 требуется работа с группами "Users" и "Authenticated Users", что вызывает сбой на неанглийских версиях Windows, где у этих групп локальные названия. Чтобы решить проблему, можно вручную добавить группы с именами "Users" и "Authenticated Users" в разделе Computer Administration / Local Users and Groups. В эти группы нужно добавить локальные эквиваленты, например, "Авторизованные пользователи" (или другую версию на вашем языке).
В ближайшее время VMware должна исправить эту ошибку, поэтому следите за обновлениями на портале загрузок Broadcom.
Наверняка вы слышали о недавнем обновлении программного обеспечения CrowdStrike для Microsoft Windows, которое вызвало беспрецедентный глобальный сбой по всему миру (а может даже вы были непосредственно им затронуты). Несколько дней назад ИТ-администраторы работали круглосуточно, чтобы восстановить работоспособность тысяч, если не десятков тысяч систем Windows.
Текущий рекомендуемый процесс восстановления от CrowdStrike определенно болезненный, так как он требует от пользователей перехода в безопасный режим Windows для удаления проблемного файла. Большинство организаций используют Microsoft Bitlocker, что добавляет дополнительный шаг к уже и так болезненному ручному процессу восстановления, так как теперь необходимо найти ключи восстановления перед тем, как войти в систему и применить исправление.
Вильям Лам написал об этой ситуации. В течение нескольких часов после новостей от CrowdStrike он уже увидел ряд запросов от клиентов и сотрудников на предмет наличия автоматизированных решений или скриптов, которые могли бы помочь в их восстановлении, так как требование к любой организации вручную восстанавливать системы неприемлемо из-за масштабов развертываний в большинстве предприятий. Ознакомившись с шагами по восстановлению и размышляя о том, как платформа vSphere может помочь пользователям автоматизировать то, что обычно является ручной задачей, у него возникло несколько идей, которые могут быть полезны.
Скрипты, предоставленные в этой статье, являются примерами. Пожалуйста, тестируйте и адаптируйте их в соответствии с вашей собственной средой, так как они не были протестированы официально, и их поведение может варьироваться в зависимости от среды. Используйте их на свой страх и риск.
Платформа vSphere обладает одной полезной возможностью, которая до сих пор не всем известна, позволяющей пользователям автоматизировать отправку нажатий клавиш в виртуальную машину (VM), что не требует наличия VMware Tools или даже запущенной гостевой операционной системы.
Чтобы продемонстрировать, как может выглядеть автоматизированное решение для устранения проблемы CrowdStrike, Вильям создал прототип PowerCLI-скрипта под названием crowdstrike-example-prototype-remediation-script.ps1, который зависит от функции Set-VMKeystrokes. В настройке автора работает Windows Server 2019 с включенным Bitlocker, и он "смоделировал" директорию и конфигурационный файл CrowdStrike, которые должны быть удалены в рамках процесса восстановления. Вместо загрузки в безопасный режим, что немного сложнее, автор решил просто загрузиться в установщик Windows Server 2019 и перейти в режим восстановления, что позволило ему применить тот же процесс восстановления.
Ниже представлено видео, демонстрирующее автоматизацию и шаги, происходящие между PowerCLI-скриптом и тем, что происходит в консоли виртуальной машины. Вручную никакие действия не выполнялись:
В зависимости от вашей среды и масштаба, вам может потребоваться настроить различные значения задержек, и это следует делать в тестовой или разработческой среде перед развертыванием поэтапно.
В качестве альтернативы, автор также рекомендует и немного другой подход. Один из клиентов создал кастомный WindowsPE ISO, который содержал скрипт для удаления проблемного файла CrowdStrike, и всё, что им нужно было сделать, это смонтировать ISO, изменить порядок загрузки с жесткого диска на CDROM, после чего ISO автоматически выполнил бы процесс восстановления, вместо использования безопасного режима, что является довольно умным решением.
В любом случае, вот пример фрагмента PowerCLI-кода, который реконфигурирует виртуальную машину (поддерживается, когда ВМ выключена) для монтирования нужного ISO из хранилища vSphere и обновляет порядок загрузки так, чтобы машина автоматически загружалась с ISO, а не с жесткого диска.
$vmName = "CrowdStrike-VM"
$isoPath = "[nfs-datastore-synology] ISO/en_windows_server_version_1903_x64_dvd_58ddff4b.iso"
$primaryDisk = "Hard disk 1"
$vm = Get-VM $vmName
$vmDevices = $vm.ExtensionData.Config.Hardware.Device
$cdromDevice = $vmDevices | where {$_.getType().name -eq "VirtualCdrom"}
$bootDevice = $vmDevices | where {$_.getType().name -eq "VirtualDisk" -and $_.DeviceInfo.Label -eq $primaryDisk}
# Configure Boot Order to boot from ISO and then Hard Disk
$cdromBootDevice = New-Object VMware.Vim.VirtualMachineBootOptionsBootableCdromDevice
$diskBootDevice = New-Object VMware.Vim.VirtualMachineBootOptionsBootableDiskDevice
$diskBootDevice.DeviceKey = $bootDevice.key
$bootOptions = New-Object VMware.Vim.VirtualMachineBootOptions
$bootOptions.bootOrder = @($cdromBootDevice,$diskBootDevice)
# Mount ISO from vSphere Datastore
$cdromBacking = New-Object VMware.Vim.VirtualCdromIsoBackingInfo
$cdromBacking.FileName = $isoPath
$deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec
$deviceChange.operation = "edit"
$deviceChange.device = $cdromDevice
$deviceChange.device.Backing = $cdromBacking
$deviceChange.device.Connectable.StartConnected = $true
$deviceChange.device.Connectable.Connected = $true
$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.deviceChange = @($deviceChange)
$spec.bootOptions = $bootOptions
$task = $vm.ExtensionData.ReconfigVM_Task($spec)
$task1 = Get-Task -Id ("Task-$($task.value)")
$task1 | Wait-Task | Out-Null
Чтобы подтвердить, что изменения были успешно применены, вы можете использовать интерфейс vSphere или следующий фрагмент PowerCLI-кода:
Остается только запустить виртуальную машину, а затем, после завершения восстановления, можно отменить операцию, размонтировав ISO и удалив конфигурацию порядка загрузки, чтобы вернуть исходное поведение виртуальной машины.
После неудачного развертывания VCF 5.0 у автора блога vronin.nl остался vSAN Datastore на первом хосте в кластере, что блокировало повторную попытку развертывания.
В этом состоянии vSAN Datastore не может быть удален. Если попытаться его удалить через ESXi Host Client, опция будет неактивна:
Чтобы удалить хранилище данных vSAN и разделы дисков, сначала нужно подключиться по SSH к хосту и получить Sub-Cluster Master UUID кластера:
Далее копируем этот Sub-Cluster Master UUID в следующую команду:
В ESXi Host Client будет показываться, что датастора больше нет:
Для двойной проверки выполняем следующие команды в консоли ESXi:
esxcli vsan cluster list
esxcli vsan storage list
По результатам вывода команд, на хосте не настроены кластеры или хранилища vSAN. После этого повторная попытка развертывания кластера управления VCF будет успешной.
Выглядит это как-то так (только вместо vpxd написано vmidentity):
При этом некоторые пользователи могут откатиться (Rollback) к исходному дистрибутиву, а у кого-то этот селектор неактивен (загреен). При обращении в техподдержку VMware пользователям было сказано, что на эту тему готовится KB, а пока можно воспользоваться приведенным ниже воркэраундом.
Проблема связана с некорневым сертификатом с псевдонимом ssoserver. В VMware есть внутренний документ по этой проблеме, но он пока не доступен публично. Вот шаги, которые VMware предоставляет для исправления:
1. Подключитесь по SSH к серверу vCenter
2. Выведите список сертификатов и определите псевдоним некорневого (Non-CA) сертификата с CN=ssoserver
/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'
3. Сделайте резервную копию сертификата, который показывает CN=ssoserver
Примечание: замените <Alias> на идентификатор псевдонима, определенный на предыдущем шаге.
5. Повторно выведите список сертификатов и убедитесь, что сертификат удален
/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'
Теперь можно продолжить обновление vCenter.
Правда у некоторых пользователей после удаления сертификата возникает ошибка, и неясно, нужно ли вручную восстанавливать сертификат после наката обновления. Ждем разъяснений VMware на эту тему.
В этом случае необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли производить запись в файл VMDK одновременно с нескольких хостов ESXi (можно также организовать и запись от нескольких ВМ на одном хосте). Этот режим со стороны VMware поддерживается только для некоторых кластерных решений, таких как Oracle RAC, и для технологии Fault Tolerance, у которой техника vLockstep требует одновременного доступа к диску с обоих хостов ESXi.
В статье, на которую мы сослались выше, хоть и неявно, но было указано, что режим "Multi-writer" используется и для кластеров Microsoft Windows Server Failover Clustering (WSFC, ранее они назывались Microsoft Cluster Service, MSCS), однако это была неверная информация - он никогда не поддерживался для кластеров Microsoft.
Мало того, использовать режим "Multi-writer" для WSFC не только не рекомендуется, но и опасно - это может привести к потере данных. Кроме того, возможности поддержки VMware в этом случае будут очень ограничены.
Информация о поддержке "Multi-writer" и общих дисков VMDK
Использование файлов VMDK в качестве общих дисков для виртуальных машин Windows в среде vSphere возможно, но только когда файлы VMDK хранятся в кластеризованном хранилище данных с включенной поддержкой Clustered VMDK, как описано в статье Clustered VMDK support for WSFC, или ниже в этой статье.
Сначала предупреждения и предостережения - прежде чем предпринимать любые из описанных в этой статье шагов, администратору очень важно понять и принять, что VMware не гарантирует, что эти конфигурации не приведут к потере данных или их повреждению.
Итак, какие варианты предлагает VMware, если вы уже используете кластеры WSFC в режиме multi-writer:
Переконфигурирование общих дисков на основе файлов VMDK для кластеризованных виртуальных машин Windows, которые были настроены с использованием опции флага multi-writer.
Перемещение файлов VMDK в одно или несколько официально поддерживаемых хранилищ данных с поддержкой Clustered VMDK.
Представление файлов VMDK обратно виртуальным машинам таким образом, чтобы минимизировать или избежать необходимости перенастройки внутри гостевой операционной системы или на уровне приложений.
VMware настоятельно рекомендует клиентам, выполняющим эти задачи, убедиться в наличии проверенного и повторяемого плана отката в случае сбоя во время выполнения этих операций. Предполагается и ожидается, что у клиентов имеются проверенные резервные копии всех данных и информации о конфигурации всех виртуальных машин, которые будут участвовать в этом процессе переконфигурации.
Как минимум, клиенты должны выполнить (или отметить) следующее перед началом этих процедур:
Имена и расположение файлов для КАЖДОГО диска VMDK.
Номер SCSI и SCSI ID, к которому подключен КАЖДЫЙ диск. Мы должны присоединить диск к ТОМУ ЖЕ SCSI ID при повторном подключении.
В Windows - текущий владелец ресурсов диска (проверить это можно в конфигурации WSFC).
Если владение ресурсами WSFC разделено между узлами, ПЕРЕКЛЮЧИТЕ ВСЕ РЕСУРСЫ на один узел. Это упрощает процесс реконфигурации и очень полезно, чтобы избежать путаницы. Выключите все пассивные узлы ПЕРЕД выключением активного узла. После завершения настройки необходимо включить сначала активный узел, а затем остальные узлы.
Переконфигурация кластера WSFC с Multi-Writer на режим Clustered VMDK
Давайте начнем с рассмотрения нашей текущей конфигурации, посмотрим на узлы (кликабельно):
И на диски:
Протестируем WSFC путем переключения ресурсов диска - в данном случае мы выключаем активный узел и наблюдаем, как кластерные ресурсы становятся доступными на пассивном узле. Этот тест очень важен для проверки работоспособности WSFC перед внесением изменений.
Текущая конфигурация общих дисков (отображение распространенной неправильной конфигурации с включенным multi-writer, где общие диски принадлежат выключенной третьей виртуальной машине).
Вот узел WSFC Node-1 и его расшаренные диски (флаг Multi-Writer установлен в Enabled):
При попытке запустить такую ВМ она не включится, а в логе vmware.log в папке с ВМ вы увидите такие записи:
2023-02-15T05:34:31.379Z In(05) vcpu-0 - SECUREBOOT: Signature: 0 in db, 0 in dbx, 1 unrecognized, 0 unsupported alg.
2023-02-15T05:34:31.379Z In(05) vcpu-0 - Hash: 0 in db, 0 in dbx.
2023-02-15T05:34:31.379Z In(05) vcpu-0 - SECUREBOOT: Image DENIED.
Ситуация была исправлена со стороны VMware в патче обновлений vSphere 7 Update 3k (KB 90947), который предлагается установить всем пользователям, затронутых этой ситуацией.
Отметим, что с виртуальными машинами на vSphere 8 никаких неприятностей не произошло.
Скачать VMware vSphere 7 Update 3k можно по этой ссылке. Release Notes находятся тут.
Иногда при работе администратора с виртуальными машинами VMware vSphere происходит ошибка при работе с дескрипторными файлами дисков VMDK, которая проявляет себя следующим образом:
Диск ВМ показывается в Datastore Browser, но иконка для него отсутствует
При включении ВМ вы получаете ошибку " File not found"
Сам файл ВМ вида <имя ВМ>-flat.vmdk есть в директории с машиной, но файла <имя ВМ>.vmdk вы не видите
Сам файл <имя ВМ>.vmdk отсутствует, либо он есть, но его содержимое повреждено
Эти симптомы могут возникать по разным причинам, но суть их одна - дескрипторный файл ВМ поврежден или отсутствует. Ситуация поправима, если у вас есть основный диск с данными - <имя ВМ>-flat.vmdk, и он сохранился в целости.
В 2012 году мы писали о том, как быть, если у вас возникла проблема с дескрипторным файлом виртуальной машины в среде VMware vSphere. В целом, с тех времен ничего особо не поменялось. Процесс этот довольно простой и описан в KB 1002511, также он детально разобран в видео ниже:
Часть 1 - восстановление основного VMDK виртуальной машины
Перед выполнением операций ниже обязательно сохраните полную копию папки виртуальной машины, и только после этого проводите все описанные ниже операции. Если у вас есть резервная копия виртуальной машины, и ее восстановление вас устраивает - то лучше сделать эту операцию вместо описанной ниже процедуры исправления дисков, так как вероятность ошибиться в ней велика.
Если вкратце, то для восстановления вам нужно выполнить следующие шаги:
1. Соединяемся с хостом VMware ESXi по SSH как root. Либо операции можно проводить непосредственно в консоли DCUI.
2. Переходим в папку с ВМ и определяем геометрию основного диска VMDK с данными <имя ВМ>-flat.vmdk
Делается это командой:
# ls -l <имя диска>-flat.vmdk
На выходе мы получим размер диска в байтах. Вывод будет выглядеть примерно так:
-rw------- 1 root root 4294967296 Oct 11 12:30 vmdisk0-flat.vmdk
3. Теперь нужно пересоздать заголовочный файл VMDK (<имя ВМ>.vmdk), чтобы он соответствовал диску с данными, используя тот же размер диска, полученный на предыдущем шаге:
# vmkfstools -c 4294967296 -a lsilogic -d thin temp.vmdk
После этого переименовываем дескрипторный VMDK-файл созданного диска в тот файл, который нам нужен для исходного диска. Затем удаляем только что созданный пустой диск данных нового диска, который уже не нужен (temp-flat.vmdk).
Если у изначальной машины диск был не растущим по мере наполнения (thin disk), то последнюю строчку, выделенную красным, можно не добавлять.
Вы также можете поменять тип адаптера ddb.adapterType = lsilogic на ddb.adapterType = pvscsi, если вы использовали паравиртуализованный SCSI-контроллер для исходной ВМ.
Консистентность виртуальной машины можно проверить командой:
vmkfstools -e filename.vmdk
Если все в порядке, то в ответе команды вы получите вот такую строчку:
Disk chain is consistent.
Если же исправить ситуацию не получилось, то будет вот такой текст:
Disk chain is not consistent : The parent virtual disk has been modified since the child was created. The content ID of the parent virtual disk does not match the corresponding parent content ID in the child (18).
После этого можно запускать виртуальную машину, добавив ее повторно в окружение vSphere Client.
Часть 2 - исправление дескрипторов файлов снапшотов ВМ (delta-файлы)
Ситуация усложняется, когда у исходной виртуальной машины были снапшоты, тогда папка с ней выглядит следующим образом (красным выделены важные для нас в дальнейших шагах файлы):
drwxr-xr-x 1 root root 1400 Aug 16 09:39 .
drwxr-xr-t 1 root root 2520 Aug 16 09:32 ..
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002-delta.vmdk
-rw------- 1 root root 32768 Aug 17 19:11 examplevm-000002.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001-delta.vmdk
-rw------- 1 root root 32768 Aug 16 14:39 examplevm-000001.vmdk
-rw------- 1 root root 16106127360 Aug 16 09:32 examplevm-flat.vmdk
-rw------- 1 root root 469 Aug 16 09:32 examplevm.vmdk
-rw------- 1 root root 18396 Aug 16 14:39 examplevm-Snapshot1.vmsn
-rw------- 1 root root 18396 Aug 17 19:11 examplevm-Snapshot2.vmsn
-rw------- 1 root root 397 Aug 16 09:39 examplevm.vmsn
-rwxr-xr-x 1 root root 1626 Aug 16 09:39 examplevm.vmx
-rw------- 1 root root 259 Aug 16 09:36 examplevm.vmxf
Основной порядок действий в этой ситуации приведен в KB 1026353, здесь же мы опишем его вкратце (кстати, напомним про необходимость сделать полный бэкап всех файлов ВМ перед любыми операциями):
1. Определяем нужные нам файлы
Итак, заголовочные файлы снапшотов ВМ хранятся в так называемых файлах типа vmfsSparse, они же работают в связке с так называемым delta extent file, который непосредственно содержит данные (выше это, например, examplevm-000001-delta.vmdk).
Таким образом, опираясь на пример выше, нам интересны заголовочные файлы снапшотов examplevm-000001.vmdk и examplevm-000002.vmdk. Помните также, что диски и их снапшоты могут находиться в разных папках на разных датасторах, поэтому сначала вам нужно понять, где и что у вас хранится. Если у вас есть сомнения касательно имен нужных вам файлов, вы можете заглянуть в лог-файл vmware.log, чтобы увидеть там нужные пути к датасторам.
2. Создаем новый дескриптор снапшота
Итак, представим теперь, что файл examplevm-000001.vmdk у нас поврежден или отсутствует. Создадим новый дескриптор снапшота из исходного заголовочного файла examplevm.vmdk простым его копированием:
# cp examplevm.vmdk examplevm-000001.vmdk
3. Меняем указатели на файл с данными для снапшота
Теперь нужно открыть созданный файл в текстовом редакторе и начать его исправлять. Пусть он выглядит вот так:
# Disk DescriptorFile
version=1
encoding="UTF-8" CID=19741890
parentCID=ffffffff
createType="vmfs"
Красным мы выделили то, что будем в этом файле изменять, а синим - то, что будем удалять.
С данным файлом нужно сделать следующие манипуляции:
Строчку CID=19741890 заменяем на случайное восьмизначное значение (это идентификатор диска)
Строчку parentCID=ffffffff заменяем на parentCID=19741890 (идентификатор родительского диска, им может быть не только родительский основной диск, но и родительский снапшот, то есть его дескриптор)
Строчку createType="vmfs" заменяем на createType="vmfsSparse"
Строчку RW 31457280 VMFS "examplevm-flat.vmdk" заменяем на RW 31457280 VMFSSPARSE "examplevm-000001-delta.vmdk" (обратите внимание, что номер 31457280 остается тем же - он должен быть тем же самым для всей цепочки дочерних дисков)
4. Добавляем данные специфичные для снапшота
Теперь нам надо добавить в указатель снапшота кое-что новое:
Под строчкой createType="vmfsSparse" добавляем строчку
parentFileNameHint="examplevm.vmdk"
Ну и теперь надо убрать лишнее. Удаляем из файла следующие строчки, которые нужны только для основного родительского диска:
После этого вы можете попробовать запустить машину с дочерним снапшотом. Но перед этим также проверьте интеграцию дескриптора командой:
vmkfstools -e filename.vmdk
Ну и помните, что все эти действия по цепочке вы можете провернуть для следующих уровней дочерних снапшотов, если их диски с данными в порядке. Главное - не забывайте делать резервные копии перед любыми операциями!
Как написали коллеги с сайта virten.net, при установке платформы VMware ESXi 7 или 8 на сервер с процессорами Intel Core 12 поколения возникает розовый экран смерти (PSOD), содержащий следующие сообщения:
HW feature incompatibility detected; cannot start
Fatal CPU mismatch on feature "Hyperthreads per core" Fatal CPU mismatch on feature "Cores per package" Fatal CPU mismatch on feature "Cores per die"
Проблема здесь заключается в том, что новая архитектура процессоров Intel идет с ядрами двух типов - Performance-cores и Efficient-cores. Начиная с vSphere 7.0 Update 2, в ядро гипервизора был добавлен параметр cpuUniformityHardCheckPanic для того, чтобы избежать подобной проблемы, которая проявляется в следующих версиях платформы виртуализации:
vSphere / ESXi 8.0 или более поздние
vSphere / ESXi 7.0 Update 2 или более поздние
1. Итак, в самом начале установки ESXi нажимаете SHIFT+O, чтобы изменить параметры загрузки. Далее в появившейся строке вводите:
cpuUniformityHardCheckPanic=FALSE
2. После этого нажимаете Enter и дожидаетесь окончания установки.
3. Затем во время первой загрузки опять нажимаете SHIFT+O и вводите ту же самую строчку.
4. А уже когда гипервизор загрузится, нужно добавить следующую строчку в параметры ядра, чтобы отключить проверку, а ESXi не вылетал в розовый экран при каждой загрузке:
# esxcli system settings kernel set -s cpuUniformityHardCheckPanic -v FALSE
Также есть метод, описанный для установки через механизм автоматизированного развертывания Kickstart:
1. Создаем флэшку USB с ISO-образом ESXi, как написано здесь.
2. Открываем файл /efi/boot/boot.cfg в редакторе и добавляем следующую опцию в строчку kernelopt= параметров ядра:
ks=usb:/KS.CFG cpuUniformityHardCheckPanic=FALSE
3. Далее вам надо создать файл /KS.CFG для конфигурации Kickstart и в секциях %post (пост-параметры установки, но до первой загрузки) и %firstboot (первая загрузка) добавить следующее:
# NTP
esxcli system ntp set -s pool.ntp.org
esxcli system ntp set -e 1
4. Далее можете провести установку с USB-флэшки, а через пару минут вы уже сможете получить доступ к ESXi через консоль или по SSH.
5. Если вы используете механизм Secure Boot, то обычно секция %firstboot не применяется (так работает по умолчанию на большинстве систем). Поэтому вам потребоваться ввести команды этой секции вручную или отключить Secure Boot. С командами раздела %post все будет в порядке.
6. По окончании установки через Kickstart все будет работать:
Мы уже писали о том, что на сервере VMware ESXi может возникать ошибка "No space left on device" при выполнении различных операций. Тогда мы объясняли, что такая ситуация может произойти из-за исчерпания числа свободных объектов inodes.
Причина такого поведения может заключаться не только в отсутствии свободных нод. Для начала надо проверить, что проблема действительно не в них. Делается это с помощью команды:
stat -f /
Либо можно использовать также команду df -i.
Если все в порядке с айнодами, то проблема может заключаться в так называемых "small file blocks" (SFB) и "large file blocks" (LFB), которые на VMFS создаются под нужды файловой системы для разных типов файлов. Суть самой проблемы в том, что иногда SFB кончаются, и VMFS запускает механизм конвертации LFB в SFB, но получившиеся SFB не становятся доступными сразу. Подробнее об этой механике рассказано в KB 87482.
Как многие из вас знают, в ноябре прошлого года компания VMware отозвала обновление платформы vSphere 7 Update 3 из-за критических ошибок. Это были проблемы с выпадением в PSOD, трудности при апгрейде с прошлых версий, неполадки в плане стабильности vSphere HA и другое.
В конце декабря мы напомнили о том, что проблема существует уже месяц, а VMware все никак не может решить ее. Основная информация о возникшей ситуации с последним пакетом обновлений публиковалась в KB 86398. Там же можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281.
Теперь VMware объявила о выпуске окончательной версии VMware vSphere 7 Update 3c, где все должно работать как надо (однако бежать обновляться прямо сейчас мы бы не рекомендовали:)
Также сообщается, что в новом релизе решены все проблемы с безопасностью, касающиеся уязвимости Log4j, которая затронула большое количество систем. Эта уязвимость позволяла злоумышленнику, который имел доступ к отсылке логов (самих сообщений или к настройке их параметров), исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена.
Наконец-то были обновлены основные компоненты продукта, ESXi и vCenter, а также опубликован список известных проблем и их обхода:
О новых возможностях основного vSphere 7 Update 3 вы можете почитать у нас тут, их список не изменился. Скачать все компоненты платформы, включая ESXi 7 Update 3c и vCenter Server 7 Update 3c, вы можете по этой ссылке.
Основная информация о возникшей ситуации с последним пакетом обновлений приведена в KB 86398. Там можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281. На странице загрузки VMware vSphere, по-прежнему, висит красный баннер и релиз Update 2a от апреля этого года:
Среди найденных багов - и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и многое другое, судя по заметкам в некоторых блогах:
18 ноября зачеркнутые в таблице релизы были удалены из VMware Customer Connect, а новостей по поводу сроков исправления проблем с этого времени не было. Сама VMware пишет в KB вот так:
Надо отметить, что VMware vCenter 7 Update 3 и Update 3a сейчас доступны для скачивания и использования в производственной среде.
В самом интересном положении оказались пользователи, которые уже прошли процедуру апгрейда своей инфраструктуры на Update 3. Им не рекомендуют откатывать все назад (это и не так просто, к тому же), если они не сталкиваются с критичными проблемами, такими как PSOD. Однако и сроков по доступности исправлений Update 3 тоже не дают.
Многие из вас заметили, что на сайте VMware обновление vSphere 7 Update 3 пока не скачать. При входе на страницу загрузки VMware vSphere показывают красное предупреждение, которое говорит о том, что проблема нового апдейта весьма серьезная:
Скачать VMware vSphere 7 Update 3 и ее компоненты сейчас нельзя.
Ситуация продолжается уже 5 дней, а VMware не дает конкретных сроков устранения проблемы. При этом пользователям, которые уже провели апгрейд до vSphere 7 Update 3, 3a или 3b - неясно пока, что делать. Нам в комментариях уже писали о том, что сталкиваются с серьезными проблемами при апгрейде на U3 и после этого.
Основная информация о возникшей проблеме приведена в KB 86398. Там можно узнать, что вся линейка Update 3 была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281.
Прямо скажем - проблем этих много, и просто удивительно, как все это прошло выходной контроль при выпуске релизов третьего пакета обновлений. Это и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и другое:
Следим за развитием событий, FAQ в KB 86398 не дает никакой ясности по планируемому времени исправления проблемы. Пользователям, обновившимся до vSphere 7 Update 3, не рекомендуют откатываться до предыдущей версии, если они не сталкиваются с серьезными проблемами в функционировании инфраструктуры.
Помните, любое обновление продуктов VMware надо проводить только по прошествии нескольких недель, в течение которых нужно следить за появившимися сообщениями о серьезных багах. Эта ситуация повторяется из релиза в релиз, а опытные пользователи vSphere к такому образу действий уже привыкли.
На днях компания VMware выпустила минорное обновление vCenter 7 Update 2c, которое из нового содержит только багофиксы и исправления в подсистеме безопасности (рекомендуется его накатить в связи с участившимися случаями нахождения и эксплуатации уязвимостей).
Дункан Эппинг рассказал о том, как побороть ошибку, которая иногда возникает при обновлении сервера vCenter на версию vCenter Server 7.0 Update 2c:
Test RPM transaction failed. Collect the logs for diagnostics
Нажатие на кнопку "Resume" ни к чему не приводит, ошибка возникает циклически. Чтобы эту ошибку устранить, нужно удалить файл software_update_state.conf на сервере vCenter Server Appliance. Для этого зайдите туда по SSH и выполните команду:
Дункан Эппинг обратил внимание на довольно частую проблему у пользователей VMware vSphere 7, которые делают апгрейд с Update 1 на Update 2. Если вы используете подключение к хранилищам по iSCSI и рандомные имена IQN для инициаторов, то после апгрейда хранилища могут перестать быть доступными, если вы используете контроль доступа на базе IQN.
Проблема проявляется, только если вы создавали подключения по iSCSI именно в vSphere 7 Update 1 на свежей установке. Причина проста - изменился стандарт случайного именования IQN для iSCSI-инициаторов. Если для Update 1 он выглядит так:
iqn.1998-01.com.vmware:labesx06-4ff17c83
То для Update 2 уже так:
iqn.1998-01.com.vmware:labesx07:38717532:64
Соответственно, после апгрейда имя инициатора у вас изменится. Чтобы сделать хранилища iSCSI вновь доступными, надо пойти на дисковый массив или виртуальный модуль (Virtual Appliance) и вбить туда новое имя инициатора. Либо вы можете сделать имя инициатора вручную и вбить его также и на массиве для нужных LUN.
Кстати, при апгрейде с версии vSphere 6.7 или vSphere 7 сразу на Update 2 проблема не возникает, так как настройки iSCSI корректно переезжают сразу в configstore.
Чтобы изменить имя iSCSI-адаптера, можно использовать вот эту команду, чтобы это имя получить:
Весной этого года мы писали о двух критических ошибках безопасности в сервисах VMware Carbon Black и VMware vCenter - тут и тут, соответственно. В свое время для них были выпущены патчи, закрывающие эти уязвимости. Но, надо сказать, что это далеко не единственные критические моменты в инфраструктуре безопасности vCenter - на днях VMware опубликовала патчи к VMSA-2021-0010 (сообщения CVE-2021-21985 и CVE-2021-21986).
Суть уязвимости заключается в том, что в плагине Virtual SAN Health Check есть дыра в процедуре валидации ввода данных, которая позволяет злоумышленнику получить доступ к удаленному исполнению кода через vSphere Client. CVSSv3 base score этой уязвимости максимальный - 9.8, поэтому нужно обновлять серверы vCenter прямо сейчас.
Если вы не используете VMware vSAN, у вас все равно эта дырка есть, так как плагин vSAN идет вместе с установкой vCenter по умолчанию. Затронуты, кстати, vCenter версий 6.5, 6.7 и 7.0 и их обновления, то есть все самые актуальные на текущий момент. Компания VMware создала по данной уязвимости специальный FAQ.
Если вы не пользователь vSAN, то плагин вы можете просто отключить, но вот если вы используете vSAN для хралищ на базе серверов ESXi, то отключение плагина приведет к невозможности пользоваться консолью управления vSAN.
Также по данной уязвимости на VMware Communities есть специальный трэд.
Итак, теперь, собственно, какие патчи вам надо накатить (полное описание находится здесь):
Для vCenrer 6.7 накатываем vCenter 6.7 Update 3n (вот тут)
Для vCenrer 6.5 накатываем vCenter 6.5 Update 3p (вот тут)
VMware настойчиво рекомендует сделать обновление прямо сейчас, чтобы злоумышленники и всякое ransomware не добавили вам проблем, например, перед летним отпуском:)
Недавно мы писали о новой службе Virtual Machine Service, которая появилась в последней версии VMware vCenter 7 Update 2a, вышедшей несколько дней назад. Через некоторое время компания VMware обновила и свою основную платформу виртуализации до версии ESXi 7 Update 2a, обновив таким образом оба компонента VMware vSphere 7 до Update 2a.
Основным нововведением ESXi 7 Update 2a (он же билд 17867351) является исправление бага с апгрейдом с прошлых версий vSphere. Пользователи, у которых был настроен кастомный бейслайн vSphere Lifecycle Manager (vLCM), после апгрейда получали вот такую ошибку (для билда 17630552 в комплекте Update 2):
Failed to load crypto64.efi
Теперь старый билд Update 2 был убран из репозитория, а все обновления будут уже до версии 2a.
Также в U2a появилось немало нововведений для VMware vSphere with Tanzu:
Supervisor Cluster
Управление ресурсами Kubernetes через Virtual Machine Service. Об этом мы подробно писали тут.
Самостоятельное создание пространств имен со стороны разработчиков (по шаблону, заданному администратором, который определяет лимиты и права доступа).
Tanzu Kubernetes Grid Service for vSphere
Сервер Kubernetes metrics-server включен по умолчанию. Основные параметры узлов и Pod'ов можно смотреть командой kubectl top.
Система обработки webhooks теперь поддерживает dry-run mode. Теперь такие популярные утилиты, как, например, Terraform Kubernetes provider можно интегрировать с Tanzu Kubernetes Grid Service.
Кастомные классы виртуальных машин (Virtual Machine Classes), которые потребляются через службы VM Service. Это позволяет пользователям выделить различные параметры CPU и памяти, которая выделена виртуальным машинам в кластере Tanzu Kubernetes Cluster.
Обновить инфраструктуру на vSphere 7 Update 2a можно следующими командами в консоли:
Не так давно мы писали о технологии vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Делается это за счет того, что на хостах есть агентские виртуальные машины служб vCLS.
Дункан Эппинг описал ситуацию, когда эти виртуальные машины просто не включаются с ошибкой в консоли vSphere Cleint:
Insufficient resources
Если посмотреть в детали сообщения об ошибке, то там будет примерно следующее:
The target host does not support the virtual machine's current hardware requirements.
Также может быть показано следующее сообщение:
Feature 'MWAIT' was absent, but must be present.
Выходов из этой ситуации может быть два - так как они могут быть обусловлены разными причинами. Причем первый вариант - это официально поддерживаемый со стороны VMware путь устранения проблемы для кластера в целом, а второй - "народный способ" для отдельных ВМ.
Вариант 1:
Для устранения ошибки про Feature 'MWAIT' нужно убедиться, что опция Monitor/MWAIT включена в BIOS (Enabled). vCLS включает EVC на базе виртуальных машин для каждой ВМ. Если же это не помогло или вы не можете это сделать, то нужно использовать метод, описанный ниже.
Вариант 2:
Апгрейдим ВМ в плане "Compatibility" до последней версии виртуального железа “VM version 14” (меню апгрейда есть по правой кнопке в vSphere Client).
Выбираем нужную ВМ, переходим на вкладку Configure и идем в VMware EVC.
Нажимаем "Edit" и выбираем “Yes” для подтверждения изменения настроек
На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.
Симптомы переполнения кучи, как правило, следующие:
Датасторы на хостах показывают статус "Not consumed"
Виртуальные машины не могут выполнить vMotion
Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."
В логе vmkernel.log могут появляться следующие сообщения об ошибках:
Heap vmfs3 already at its maximum size. Cannot expand
Heap vmfs3: Maximum allowed growth (#) too small for size (#)
Failed to initialize VMFS distributed locking on volume #: Out of memory
Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory
Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:
Проблема только в том, что нужно выполнить эту операцию на каждом датасторе каждого хоста. Поэтому есть вот такая команда для всех датасторов и хостов:
# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done
Результат будет примерно таким:
Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:
Maximum allowed growth * too small for size
Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.
VMware на днях выпустила патч VMSA-2020-0023, который окончательно закрывает уязвимость CVE-2020-3992, имевшуюся в сервисе OpenSLP хоста ESXi. Эта уязвимость типа Use-After-Free позволяла злоумышленнику, имевшему доступ к 427 порту, получить возможность удаленного исполнения кода (эта уязвимость имела критический статус и CVS score 9.8 из 10).
VMware заявляет, что данные патчи, выпущенные 20 октября, не закрывают уязвимость полностью, поэтому нужно скачивать самые последние версии патчей:
IMPORTANT: The ESXi patches released on October 20, 2020 did not address CVE-2020-3992 completely, see section (3a) Notes for an update.
Вот сами обновления, которые были выпущены:
ESXi 7.0 - ESXi70U1a-17119627. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi_7.0.1-0.0.16850804
ESXi 6.7 - ESXi670-202011301-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi670-202010401-SG
ESXi 6.5 - ESXi650-202011401-SG. Полностью закрывает CVE-2020-3992. Заменяет собой херовый патч ESXi650-202010401-SG
Воркэраунд, описанный в статье базы знаний KB 76372, все еще актуален. Его суть заключается в полном отключении сервиса SLP с помощью следующих команд:
/etc/init.d/slpd stop
esxcli network firewall ruleset set -r CIMSLP -e 0
chkconfig slpd off
Суть ее заключается в том, что при удалении снапшота ВМ, по завершении ее резервного копирования, она замирает примерно на 30 секунд, не принимая никакой ввод-вывод. Происходит это на некоторых NFS-хранилищах, в частности HPE SimpliVity. В итоге - приложения, чувствительные ко времени, работают плохо, ну и в целом такое поведение не очень приятно для производственных систем.
Проблема проявилась при использовании платформы VMware vSphere 6.7, текущей версии Veeam Backup and Replication и хранилища HPE SimpliVity, которое поддерживает презентацию томов только в режиме NFS v3.
При этом в такой же комбинации продуктов, но на блочных хранилищах удаление снапшота занимало 1-2 секунды.
После общения с поддержкой нашлись следующие workaround'ы, которые не подошли:
Использовать NFS v4 вместо v3 (доступно не на всех хранилищах)
Использовать другой транспорт (transport mode), например, Direct access или NBD (Network Block Device). Но Direct access доступен не всегда, а NBD - медленный режим.
Можно использовать режим hot-add с виртуальным модулем backup appliance, но тогда он должен быть на каждом хосте (см. KB 201095).
Можно отключить синхронизацию времени с хостом для ВМ с приложениями, которые страдают из-за замирания времени в гостевой ОС. Об этом можно почитать в KB 1189. Но это так себе решение.
На текущий момент получается, что это проблема именно VMware ESXi, см. статью KB 2010953. Также она описана и в базе знаний Veeam - KB 1681 (там же указаны и обходные пути). Таким образом, выходит, что в некоторых случаях ни одно из решений не подходит на 100%.
Иногда в кластере хранилищ VMware vSAN случается такая ситуация, что один из хостов ESXi оказывается "пустым", то есть не содержит компонентов виртуальных машин. При этом хранилища остальных хостов в кластере могут быть загружены почти полностью.
В этом случае надо посмотреть на интерфейс vSphere Client в разделе vSAN health check - там может быть такое сообщение для проблемного хоста:
vSAN node decommission state
Означает это, что хост находится в режиме обслуживания с точки зрения vSAN (Node Decommission State). При этом, например, с точки зрения хостов ESXi кластера VMware vSphere / HA он может не быть в maintenance mode. Поэтому может сложиться впечатление, что хост просто не принимает дисковые объекты по каким-то причинам.
Это состояние рассинхрона кластера vSphere и кластера vSAN. Лечится следующей командой по SSH, которая выведет узел vSAN из режима обслуживания, после чего он оживет на прием компонентов:
localcli vsan maintenancemode cancel
Также вы можете кликнуть правой кнопкой на хосте ESXi, перевести его в режим обслуживания, а потом вернуть обратно:
Это отменит и перевод в режим обслуживания vSAN, после чего хост сможет размещать дисковые объекты виртуальных машин (для этого надо запустить операцию Rebalance). Более подробно об этом в KB 51464.
Обновление: вышел патч с исправлением ошибки, доступен тут.
Те из вас, кто поставил обновление VMware vCenter Server 7.0.0c, могли столкнуться с проблемой высокой загрузки CPU в виртуальном модуле (почти до 100%). Данная проблема обсуждается вот в этой ветке форумов VMware.
Выглядит это примерно так при выполнении команды top в ОС модуля vCSA:
Также во время этого компонент vAPI Endpoint показывает следующее предупреждение:
Failed to connect to 1da6ff8a-0bfd-4605-b4cc-c18ba520e95b\com.vmware.vcenter.nsxd.vapi vAPI provider.
Пока VMware работает над решением данной проблемы, ну а в случае ее появления нужно пойти в vCenter Appliance Management (https://vcenter:5480) и там завершить службу Workload Control Plane. Эффект от этого сохранится только до перезагрузки.
Дункан Эппинг пишет, что сейчас идет работа над фиксом этого бага:
Возможно, некоторые администраторы VMware vSphere попадали в ситуацию, когда один из датасторов в виртуальной инфраструктуре оказывался не привязанным ни к какому хосту ESXi, но при этом у него также была неактивна опция Delete Datastore из контекстного меню:
Такой зомби-датастор можно удалить только из базы данных vCenter Server Appliance (vCSA), поэтому вы полностью должны быть уверены в том, что он не используется никаким из хостов, а также в том, что он не презентует никакое физическое устройство в вашей инфраструктуре.
Первое что вам надо сделать - это включить доступ к vCSA по SSH (картинки - отсюда):
Далее нужно зайти по SSH на vCSA, запустить там шелл командой shell и далее запустить утилиту psql для работы с базой данных следующей командой:
После этого нужно найти id датастора следующей командой:
VCDB=# SELECT id FROM vpx_entity WHERE name = 'MyStubbornDatastore';
Когда вы нашли id, нужно удалить упоминание об этом датасторе из таблиц базы данных vCSA следующими командами:
DELETE FROM vpx_ds_assignment WHERE ds_id=3089;
DELETE FROM vpx_datastore WHERE id=3089;
DELETE FROM vpx_vm_ds_space WHERE ds_id=3089;
При выполнении второй операции вы получите следующую ошибку:
ERROR: update or delete on table "vpx_datastore" violates foreign key constraing "fk_vpxspace"
DETAIL: Key (id)=(3089) is still referenced from table "vpx_vm_ds_space".
Не обращайте на нее внимания и выполняйте третью. Затем нужно перезагрузить vCSA и снова выполнить второй DELETE, который в этот раз должен завершиться успешно. После этого датастор пропадет из списка в vSphere Client.
Помните, что выполняя данную операцию, вы должны понимать, что именно делаете:)
Некоторые пользователи виртуальной инфраструктуры VMware vSphere после недавнего обновления браузера Google Chrome (а недавно вышел Chrome 80) заметили, что через vSphere Client 6.7 больше не получается подключиться:
В консоли браузера Chrome можно увидеть вот такую ошибку:
Error in connection establishment: net:: ERR_CERT_AUTHORITY_INVALID
Проблему эту подсветили наши коллеги с Reddit. Связана она с тем, что новый Chrome 80 имеет повышенные требования к безопасности и требует повторной генерации и установки сертификата с хоста ESXi. Решается проблема, как отметили в комментариях, следующим образом:
1. Идем на хост ESXi, открываем Networking -> TCP/IP stacks -> Default TCP/IP stack по ссылке:
Устанавливаем Host-name (например: esx1) и Domain-name (например: my.local) и сохраняем файл.
3. Идем по ssh на хост ESXi и выполняем там следующие команды:
cd /etc/vmware/ssl
/sbin/generate-certificates
Копируем файл castore.pem на клиентский комьютер и устанавливаем его в раздел "Trusted Root Certification Authorities". Для Windows переименовываем файл castore.pem в castore.pem.cer и просто устанавливаем его двойным кликом. Выбираем Local Machine->Manual->Browse->выбираем Trusted Root Certification Authorities.
4. Перезапускаем службу хоста ESXi:
/etc/init.d/hostd restart
После этого vSphere Client через Chrome 80 должен работать без проблем.
Интересная проблема появилась у автора блога nerdynate.life - в один из моментов на сервере VMware vCenter появились вот такие алармы:
Самая настораживающая ошибка тут - это PostgreSQL Archiver Service Health Alarm на сервере vCenter. Автор пошел в лог vCenter для сервиса PostgreSQL Archiver:
2018-05-22T10:27:36.133Z ERROR pg_archiver could not receive data from WAL stream: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
Погуглив статьи KB, автор понял, что проблема связана с тем, что сервис Watchdog не стартовал. Догадка подкрепилась вот этим постом. Результатом запуска команды:
/etc/init.d/sfcbd-watchdog status
стал вывод:
sfcbd is not running
То есть сервис sfcbd-watchdog не запустился. А запустить его можно командой:
/etc/init.d/sfcbd-watchdog start
Если запуск не удался, то нужно выполнить следующую команду:
esxcli system wbem set –-enable true
Это должно было помочь, но автору не особо помогло (а точнее помогло лишь временно). Погуглив еще, он нашел статью базы знаний, где говорилось, что причина незапуска сервиса заключается в некорректно настроенной синхронизации времени сервера vCenter и хоста ESXi, где он исполнялся в виртуальной машине. При этом как на vCenter, так и на ESXi, где он находился, синхронизация времени была настроена через внешний NTP.
В итоге автору помогло отключение синхронизации через NTP и включение синхронизации времени с хостом через VMware Tools. После этого алармы перестали появляться.
Казалось бы, это очень частная ситуация, и что о ней рассказывать у нас на сайте? А это просто очень хорошая иллюстрация к простому факту: если у вас что-то сломалось, что раньше работало, или не логинится туда, куда раньше логинилось, проверьте следующие вещи в первую очередь:
Синхронизацию времени
Доступность дискового пространства (привет, скайп!)
Интересный баг обнаружил Matt для своей виртуальной инфраструктуры, когда пытался клонировать виртуальные машины с выставленной опцией "customize this virtual machine’s hardware":
Оказалось, что после создания клона его VMDK-диск указывал на VMDK клонируемой машины, что, само собой, является серьезнейшим багом. После работы с техподдержкой оказалось, что баг не такой и частый, так как проявляется только когда в VMX-файле исходной машины параметр disk.enableuuid выставлен в значение TRUE (по умолчанию он отсутствует и применяется как FALSE).
Данный параметр иногда добавляется пользователями в соответствии с рекомендациями вендоров решений для резервного копирования и управления виртуальной средой - он позволяет убедиться в том, что VMDK диск предоставляет машине консистентный UUID для корректного монтирования.
Workaround для этого бага - это либо использовать для операций клонирования старый vSphere Web Client, либо делать это через PowerCLI. Можно также не использовать опцию "customize this virtual machine’s hardware", а настроить железо ВМ после выполнения клонирования. Также баг не проявляется если делать клонирование выключенной машины.
Некоторые пользователи сталкиваются с проблемой при обновлении сервера VMware vCenter Server Appliance (vCSA). После накатывания апдейта на vCSA (в частности, здесь пишут про билд 6.5.0.30100) администратор идет по адресу:
https://<vCenter_FQDN>:5480
И видит, что страница не открывается, браузер не находит веб-сервер.
Это происходит потому, что иногда после обновления vCSA не поднимается служба vami-lighttp, которая отвечает за веб-интерфейс VAMI (Virtual Appliance Management Infrastructure). Нужно пойти в консоль vCSA и там выполнить следующую команду для вывода статуса этой службы:
ps -ef | grep vami-lighttp
Если вы увидите, что данный процесс лежит, то есть его нет в списке запущенных, то можно запустить его следующей командой:
/etc/init.d/vami-lighttp start
После этого VAMI должен начать работать. Также у vCSA есть загадочная зависимость от протокола IPv6, которая описана здесь.
Ну и посмотрите нашу статью, в которой описывается ситуация, когда страница VAMI на vCSA открывается, но при вводе учетных данных выводится сообщение "Unable to login".
Некоторые пользователи, особенно после апгрейда сервера VMware vCenter Server Appliance 6.5 на версию 6.7, получают вот такое сообщение при попытке входа через интерфейс VAMI (Virtual Appliance Management Infrastructure):
Напомним, что интерфейс VAMI для управления виртуальным модулем vCSA доступен по ссылке:
https://<vCenter_FQDN>:5480
Причин проблемы может быть 2:
1. Пароль пользователя root устарел (кстати, помните, что в пароле нельзя использовать двоеточие). Для этого надо зайти в консоль vCSA и проверить это командой:
chage -l root
2. Не поднялась служба VMware Appliance Management Service.
Эта служба также кратко называется "applmgmt". Чтобы запустить ее через vSphere Client, зайдите в administrator@vsphere.local > Administration > Deployment > System Configuration > Services, выделите Appliance Management Service и нажмите Start.
Также можно сделать это из командной строки шелла vCSA:
service-control --start applmgmt
Далее нужно проверить, что служба действительно запустилась:
service-control --Status
Можно также поднять все сервисы vCSA одной командой:
service-control --start --all
Кстати, иногда после апгрейда хостов ESXi 6.5 на версию 6.7 внешний сервер Syslog может перестать принимать логи от vCSA из-за того, что правило фаервола ESXi для Syslog почему-то перестает быть активным. Можно снова включить это правило через интерфейс vSphere Client, либо вот такой командой PowerCLI:
Get-VMHost | Get-VMHostFirewallException | where {$_.Name.StartsWith(‘syslog’)} | Set-VMHostFirewallException -Enabled $true
Те, кто используют серверы HPE ProLiant с гипервизором VMware ESXi и пакетом управления HPE Agentless Management (AMS) для кастомизированных образов ESXi от HP, могут столкнуться со следующим сообщением об ошибке в клиенте vSphere Client:
The ramdisk 'tmp' is full
Выглядит это чаще всего вот так:
Проблема актуальна для всех версий VMware ESXi 6.0, VMware ESXi 6.5 и VMware ESXi 6.7 с пакетом Agentless Management Service (AMS) версии 11.4.0.
Если зайти в консоль ESXi и выполнить там команду vdf, то можно увидеть, что раздел /tmp заполнен на 99%:
В самом же разделе tmp есть файлик ams-bbUsg.txt, который и является источником проблем:
Для временного решения этой проблемы нужно просто удалить этот файлик, и сообщения об ошибке прекратятся. Но чтобы этого не происходило, надо обновить ваш пакет HPE Agentless Management (AMS) версии 11.4.0, где проявляется данная проблема, на версию 11.4.2. О том, как это сделать написано в статье базы знаний HP:
RSS
