Сбой расширения диска в 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?):

Import-Module Veeam.Backup.PowerShell
$NBDSessions = $Null
foreach ($Job in (Get-VBRJob | where {$_.JobType -eq "Backup"}))
{
$LastSession  = $Job.FindLastSession()
$NBDSessions = $NBDSessions + (Get-VBRTaskSession -Session $LastSession | where {$_.Logger.GetLog().updatedrecords.title -like "*nbd*"})
}
$NBDSessions | select @{N="Job Name";E={$_.JobName}}, @{N="VM Name";E={$_.Name}}, @{N="NBD diks";E={($_.Logger.GetLog().updatedrecords.title | where {$_ -like "*nbd*"})}} | ft -AutoSize

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

Job Name           VM Name          NBD diks                                                                                                                                                  
--------           -------          --------                                                                                                                                                  
Win2016_everyday   Win2016    Using backup proxy vbr-proxy-57 for disk Hard disk 1 [nbd]

Transport (VMDB) error -45: Failed to connect to peer process после обновления VMware ESXi

mr_orangeV прислал заметку о решение проблемы с VMDB transport.

После обновления ESXi до версии 6.7 сборка 17499825 и вывода хоста из режима обслуживания, виртуальные машины не мигрировали обратно на хост с ошибкой:

Transport (VMDB) error -45: Failed to connect to peer process

Поиск корневых причин привёл к нескольким вариантам:

  1. Опять кто-то где-то напутал в коде, такое уже было у HPE, можно поискать по фразе » had a bug that constantly wrote logs to the /tmp/vmware-root folder that eventually filled up the partition».
  2. Кончилось место, в том числе под swap.
  3. Mac OS Unlocker или в работе, или криво удален.

Как найти реальную причину?

Для начала прочитать все, что написано в комьюнити и БЗ: ссылка 01 и ссылка 02 kb 50113127.

Во второй KB указано, что  «Confirm the presence of the Unlocker installation on the ESXi host using one or more of the following commands».

В моём случае эти команды не показали ничего, а команды ls -l /bin/vmx в kb нет.

Подключаемся к хосту по SSH и GUI, смотрим:

  • Проверяем место: df –h
  • Проверяем Ramdisk: vdf –h
  • Проверяем snmp по kb 2040707 и inode: stat -f /vmfs/volumes
  • Проверяем что у нас с симлинками: ls -l /bin/vmx
  • Читаем (можно из GUI хоста) vmkernel и vpxd логи
    Ищем строки вида «vmx: Error in initial cartel setup: Failed to open /bin/vmx: Operation not permitted»

В моем случае, это оказался неудаленный полностью Unlocker.

Шаги решения

  • cd /bin
  • ls -l /bin/vmx и посмотреть куда он ведет
  • cd /куда ведет симлинк и
  • ls посмотреть на наличие vmx и unlocker
  • cd /bin
  • rm vmx – удалилить симлинк
  • cp /откуда)/vmx  /bin

Материалы для внеклассного чтения Читать далее «Transport (VMDB) error -45: Failed to connect to peer process после обновления VMware ESXi»

Get-ADUser и Organization Unit

Возник вопрос: как экспортировать список пользователей из AD с организационным подразделением (Organization Unit или OU).

Get-ADUser user -Properties * показал, что OU присутствует в двух атрибутах:

  • Distinguishedname: CN=user,ou=ou1,ou=ou2,dc=domain,dc=ru;
  • CanonicalName: domain.ru/ou2/ou1/user

В готовом виде OU нет, хотя для целей сортировки удобнее использовать CanonicalName.

Так родился «однострочник», позволяющий вытащить OU в качестве атрибута

get-aduser -filter * -SearchBase ou=ou1,ou=ou2,dc=domain,dc=ru" -Properties cn,canonicalname | select name,userprincipalname,@{Name="OU";expression={$_.Canonicalname.substring(0,$_.canonicalname.length-$_.cn.length)}}

Обновление ESXi до версии 7.0 update 1

После обновления пилотного VMware vCenter начали обновлять прочие управляющие серверы и гипервизоры.

Обновление VCSA 7.0 до update 1 или тренировка восстановления с резервной копии

Обновление Veeam Backup&Replication

Как раз на днях вышло обновление для Veeam Backup&Replication повышающий совместимость с vSphere 7.0 update 1 — Release notes for Veeam Backup & Replication 10a Cumulative Patch 20201202:

  • Поддержка VMware vSphere 7.0 U1, включая обновление  vSphere API; поддержка ВМ с vHW версии 18 и автоматического исключение служебных ВМ vSphere Clustering Service (vCLS), обеспечивающих работу DRS (почему-то в KB написано, что они нужны для High Availability, но в данный момент это не так).

Накопители на USB-флеш,  SD Card, дешёвые M.2

В ESXi 7.0 требования к загрузочным накопителям и раскладка томов изменились, советую ознакомиться со следующей документацией:

  1. vSphere 7 – ESXi System Storage Changes
  2. vSphere 7 – System Storage When Upgrading
  3. Installing ESXi on a supported USB flash drive or SD flash card (2004784)
  4. Running ESXi in “Degraded Mode”, what does that mean?
  5. ESXi Hardware Requirements

Теперь размещение ESXi рекомендуется только на надёжных носителях.

Мы продолжаем использовать ненадёжные, что привело к проблемам, например, к откату на резервный bootbank.

Для решения проблемы используем 2 решения:

  1. Bootbank loads in /tmp/ after reboot of ESXi 7.0 Update 1 host (2149444)
  2. Configuring ESXi coredump to file instead of partition (2077516)