Февральские патчи ESXi 2022 года

Статья прислана читателем бложика.

Занимались аудитом и обслуживанием очередной пары фирм, попутно обновляли VMware  — увидели много интересного.

Первая фирма, обновления 7.0.1 — 7.0 Update 2e build 19290878.

Опять какие-то проблемы с iSCSI. На одном сервере полностью поменялся IQN, причем с изменением даже имени. После этого по возвращении сервер не увидел СХД, пришлось настраивать. На аналогичном втором сервере потерялся target, но IQN остался тот же.

Как оказалось, проблема описана в интернете, НО что-то не находится в VMware release notes: Читать далее «Февральские патчи ESXi 2022 года»

Hyper-V Deep Dive

Недавно зашло обсуждение c друзьями про возможности Hyper-V и собеседник дал ссылку на подробную документацию Верхнеуровневая функциональная спецификация гипервизора:

Hypervisor Top Level Functional Specification Windows Server 2019 v6.0b

Дополнительно рекомендую ознакомиться со статьёй What happens if I don’t upgrade the virtual machine configuration version?

Обновление Microsoft Windows Server с ролью VMware Horizon Connection Server

В связи с выходом новых версий Microsoft Windows Server (MS WS) приходится старые обновлять.

В один прекрасный день дошла очередь до серверов с ролью VMware Horizon Connection Server. С установленной MS WS 2012 R2 решили обновляться до 2016/2019/2022.

Запустили установку в режиме in-place upgrade и стали смотреть на проценты прогресса, а они встали в районе 40-50% и дальше не идут — подождали 3 часа, 6 часов, 12 часов, 20 часов… Поняли, что терпение наше кончилось и мы откатили ОС взад.

Анализ содержимого диска указал, что на сервере созданы профили для всех пользователей VDI — сотни и сотни.

Скачали и запустили любимую у владельцев терминальных ферм утилиту Profile Deletion Utility, исключив служебные и административные профили.

Заново запустили обновление и оно прошло штатно — за 30-40 минут.

Сбой расширения диска в Windows в VMware vSphere

Статья прислана читателем бложика.

Как знают почти все активно работающие с VMware, расширение дисков в VM Windows не представляет собой каких-то супер-сложностей – берется kb Increasing the size of a disk partition (1004071), удаляются снапшоты (со снапшотами диск не расширить, это ж придется не только файл дельту писать, но и дельту геометрии учитывать). Открываем статью MS Extend a data volume in Windows, далее-далее – готово. Если когда-то, давным-давно, сделали диск MBR или не с тем размером кластера NTFS, то страдаем – для размера по умолчанию в 4к – максимальный размер диска 16 ТБ — это много, но диски «под бекап» бывают и побольше.

Иногда ситуация идет иначе – Windows при попытке расширения диска выдает табличку «не шмогла», и машина встает в странное положение.

Проблема

Управление дисками показывает, что все сделано — Disk Managements (diskmgmt.msc) displays the correct, increased disk size.

Управление томами и просто проводник показывают старый размер — Share and Storage Management (storagemgmt.msc) does not show increased size of the disk.

В добавлении к этому перестают создаваться снапшоты (и включенной, и, главное, выключенной VM). Клон тоже не работает. Но все читается и копируется.

Проблема описана в kb — After running diskpart.exe to extend the disk size in Windows, the partition size does not get updated (1000630).

Лечение

Конечно, необходимо иметь бекап «на всякий случай», и, лучше всего, – проверенный бекап. Неплохо иметь и свободное место под клон, на котором попробовать решение из kb

Указанное по второй ссылке решение на PS – НЕ работает, и даже делает в чем-то хуже (то, которое Resize-Partition -DriveLetter $drive_letter -Size $size.SizeMax).

В остальном, лечение из kb помогает – diskpart – show disk – select disk – show volume – select volume и далее по kb. Главное не удивляться, что столкнуться с этим можно даже в конце 2021 года, даже на последних патчах до сих пор поддерживаемых версий Windows. Единственное, что мне было непонятно – почему снапшот выключенной машины не прошел? Но тут я сделал большую ошибку – не проверил процедуру с хоста и не сохранил логи хоста для дальнейшего анализа.

Veeam Ready

Многие знают, что для проверки совместимости оборудования с VMware vSphere существует VMware Compatibility Guide, размещенный по адресу https://www.vmware.com/go/hcl.

Но мало кто знает, что у Veeam запущена похожая программа для квалификации партнерских решений для обеспечения стандартов высокой производительности, функциональности и совместимости.

Имеет 4 категории Veeam Ready для участников Veeam Alliance Program (VAP)

  1. Veeam Ready — Repository (репозиторий)
    Партнеры VAP с первичными решениями для хранения резервных копий проходят квалификацию, выполнив или превысив функциональные тесты и тесты производительности для операций резервного копирования и восстановления.
  2. Veeam Ready — Object (объектное хранение)
    VAP-партнеры с S3-совместимыми решениями для хранения объектов проходят квалификацию, подтвердив совместимость с возможностями хранения объектов Veeam Backup & Replication.
  3. Veeam Ready — Object Immutability (неизменность объекта)
    VAP-партнеры с S3-совместимыми решениями для хранения объектов проходят квалификацию, подтвердив совместимость с использованием Veeam Backup & Replication возможностей S3 Object Lock в хранилищах объектов.
  4. Veeam Ready — Tape (хранение на лентах)
    Партнеры VAP с автономными решениями для хранения данных проходят квалификацию, проверив совместимость с функциями и операциями с лентой Veeam Backup & Replication.

Также имеется 4 программы для интеграционных решений:

  1. Veeam Integrated — «with Veeam»
    VAP-партнеры, которые разрабатывают решение для хранения данных для DR-нагрузок с использованием Veeam.
  2. Veeam Integrated — Object
    Партнеры VAP, предлагающие объектные системы хранения данных, для улучшения совместной работы с клиентами требуются определенные протоколы или настройки.
  3. Veeam Integrated — Deduplicating Storage
    VAP-партнеры с дедуплицирующими хранилищами для повышения эффективности совместной работы с клиентами необходимы определенные протоколы или настройки.
  4. Veeam Integrated — Universal Storage API
    Партнеры VAP с предложениями первичных систем хранения данных для виртуализации, физических серверов и рабочих нагрузок NAS  для совместной разработки интеграции моментальных снимков с Veeam.

Конечные заказчики легко и быстро могут узнать результат проверок на странице Veeam Alliance Technical Programs (переключайтесь между Veeam Ready и Veeam Integrated, пролистывайте примерно один экран до таблицы с фильтрами).

Заметки в базе знаний VMware по платформе vSphere 7.0 Update 3

Выпущено много новых заметок в базе знаний по проблемам, планам, принятым решениям по платформе VMware vSphere 7.0 Update 3 (либо описывается текущая проблема во всех версиях):

  • vSphere 7.0 Update 3 Critical Known Issues and Workarounds (86287)
  • vSphere 7.0 Update 3 Known Issues and Workarounds (86281)
  • vSphere Back-in-time release upgrade restriction (67077)
  • Virtual machine hardware versions (1003746)
  • Build numbers and versions of VMware vCenter Server (2143838)
  • Removal of Windows Update published PVSCSI driver version 1.3.18.0 (86053)
  • Understanding vSAN on-disk format versions and compatibility (2148493)
  • Interactive/Scripted ISO upgrade to 7.0 U3 failed with message about live VIB installation (85859)
  • ToolsRamdisk option is not available with ESXi 7.0.x releases (83782)
  • Failed to create a new Virtual Machine with virtual Trusted Platform Module (vTPM) device (85974)
  • /etc/hosts and /etc/resolv.conf do not support direct update from 7.0 U3. The content of the files are saved to configstore. They can only be updated by public cli or API (86015)
  • «Authentication failed, Lifecycle Manager server could not be contacted», Access to Lifecycle Manager fails in vCenter 7.0 Update 3 when logged in with an Active Directory account (85962)
  • Intermittent 100% CPU Usage spikes on hosts with AMD EPYC Zen3 (Milan) CPUs (85071)
  • HPE Serviceguard for Linux Clustering (SGLX) with shared disks on VMware vSphere 7.x: Guidelines for supported configuration (Partner Verified and Supported) (85910)
  • Intel VMD is support plus additional support for RAID 1 for boot volumes (85889)
  • Backup speed are slow over NBD transport mode for VMs on high-latency storage (83401)
  • Intel NVM update tools do not work on Intel 1G igbn adapters (85983)
  • DRS Advanced option «MaxMemMBHeadroomPerHost» for Memory Headroom (86013)
  • vSphere Lifecycle Manager can show non-compliant status after rollup Remediation, new cluster creation or transition from Baseline-managed cluster to Image-managed cluster for few upgrade paths due to i40en/i40enu driver name change (85982)
  • «vSAN network alarm ‘RDMA Configuration Health'» warning is seen in vSAN over RDMA cluster when using async Intel icen driver (85947)
  • vSAN Health Service — vSAN HCL Health – NVMe device can be identified (85782)
  • vSAN Health Service — vSAN Network Health – Hosts with LACP issues (85886)
  • vSAN Health Service — vSAN Network Health – Hosts with duplicate IP addresses (85883)
  • vSAN Health Service — vSAN HCL Health – NVMe device is VMware certified (85852)
  • Unable to change vSAN File service configuration after creation (80028)
  • vSAN iSCSI first-time enablement with CHAP authentication fails with an internal error (86019)
  • vSphere Support for Intel’s Optane Persistent Memory (PMEM) (67645)
  • vCenter Server /storage/log filling up due to localhost_access.log and catalina.log in sso and lookupsvc log directories (85475)
  • «Error in method invocation Exception occurred while unzipping patch script, please retry after sometime» while patching VC 7.x (85797)
  • Clearing BACKUP_STORES certificates in the VCSA via shell script (82560)
  • File-based Backups via SFTP in vCenter 7.0 Update 2d failing with «General system error reported by backup server.» (85966)
  • WCP service fails to start in vCenter Server 7.x (82507)
  • Enabling and disabling vSAN over RDMA with unsupported driver/firmware versions for Intel E810* family NIC may lead to vSAN core dumps or ESXi Host PSOD (86077)
  • VMkernel might shut down virtual machines due to a vCPU timer issue (86075)
  • vCenter has a large number of localhost_access log files generated under /storage/log/vmware/eam/web/ (85249)
  • ESXi host fails with a backtrace NMI IPI: Panic requested by another PCPU (86100)
  • Workaround Instructions for CVE-2021-22048 (86292)
  • Guest OS Customization for Rocky Linux is not fully supported (86163)
  • vCenter upgrade from 7.0 update 2 to update 3.0 fails with could not find function «archive_build_segment_list» in file «/opt/vmware/vpostgres/13/lib/pg_addons.so» (86073)

Падучая ESXi или возвращение блудного хоста

И снова статья от участника телеграм-канала VMware User Group Rus.

Третьего дня в чат опять пришли коллеги с стандартной проблемой – хост отвалился от vCenter  — ШТО ДЕЛАТЬ?

Правильный ответ – писать сценарии отказа и отрабатывать их, это один из таких случаев, с которыми надо быть знакомыми до начала эксплуатации.

Вводные

Есть некий хост с VMware (разумеется, с последними патчами – а то было тут как-то PR 2412475: You see Sensor -1 type hardware health alarms on ESXi hosts and receive excessive mail alerts). Хост отвалился от VCenter (разумеется, тоже с последними патчами – особенно это касается линейки 7.0). Виртуальные машины на хосте продолжают работать, отказоустойчивости на уровне сервисов (Oracle real application clusters, database availability group, MS SQL Always On и так далее) нет, но и просто так перезагрузить хост – не вариант. Нет никаких гарантий, что хост поднимется, что есть ресурсы на других хостах.

В данном случае имеет смысл обратиться в поддержку — если, конечно, у вас система работает на поддерживаемой конфигурации, куплены лицензии и куплена эта самая поддержка. Поддержку можно купить «поштучно» — VMware Per Incident Support.

Шаг 1. Что было, то и будет; и что делалось, то и будет делаться, и нет ничего нового под солнцем

Читать далее «Падучая ESXi или возвращение блудного хоста»

Veeam Backup&Replication и восстановление тонких дисков

После виртуального посещения VeeamONTour 2021, решил пересмотреть доклад Никиты Козленко «10 рекомендаций для ускорения процессов резервного копирования и восстановления».

И на совете #10 залип — оказывается, что при восстановлении тонких дисков ВМ из резервных копий через транспорт DirectSAN получаем толстые диски. А мы после полноценной поддержки vSphere’ой команды UNMAP перешли на тонкие диски.

Админы СРК и ВД знали про этот нюанс и фигачили толстые диски, так как не знали как заменить транспорт и на какой (cиняя ссылка «Pick proxy to use»). Проведя консилиум и тесты, решили при восстановление выбирать прокси с транспортом hot-add (vSphere 7,  350+52+40 ГБ):

VBR NBD VBR DirectSAN VBR Hot-Add (2 теста) Acronis (Hot-Add?)
11:30:04 0:27:20 0:22:23/00:27:39 1:30:00

Время восстановления получилось сопоставимо с DirectSAN, при этом диски остаются тонкими.

P.S. Чё-то NBD на 10 GbE у нас медленноват…

Порядок восстановления ИТ-инфраструктуры

Однажды поручили разработать нам DRP (Disaster Recovery Plan) — План восстановления деятельности после кризисной ситуации. План как план, таких мильон.

Но один раздел запал мне в душу — Порядок восстановления ИТ-инфраструктуры.

В моём видении, базирующемся на опыте переездов ЦОДов, порядок получился таким: Читать далее «Порядок восстановления ИТ-инфраструктуры»

Veeam BR V11 поиск сессий с NBD

Для ускорения копирования данных VBR умеет использовать механизмы разгрузки сети: подключение дисков к проксирующим виртуальным машинам (ВМ) — hotadd, передачу по сети хранения данных — san, без разгрузки используется сетевой механизм nbd. При определенных изменениях (смена прокси, недоступность хранилищ по FC и прочие) в  инфраструктуре разгрузочные механизма могут отказать и будут заменены механизмом nbd. Пример поломки описан в базе знаний Veeam https://www.veeam.com/kb3204. Для диагностики проблемы в журнале задания VBR необходимо убедиться в наличие тэга [hotadd/san] либо появление тэга [nbd] при переключении механизма.

Поиск запроса для обнаружения заданий с NBD выдал скрипт, опубликованный на форуме Veeam — Find Sessions with specific transport mode.

Для запуска в версии V11 мы заменили импорт модуля  (How to Install Veeam PowerShell Snapin?):

Пример выдачи: