На простой вопрос ведь есть простой ответ – посмотреть HCL!

Открываю HCL, смотрю Supported Virtual Hardware Versions: 15,17,18,19,20,21,22.

Всё! Расходимся! Или кто-то недоговаривает?

Начинаю вспоминать, что под 7-ой были какие-то заморочки с выбором ОСи при создании ВМ-ки с MS WS 2022 – Windows Server 2022 guest operating system option is not available during virtual machine creation.

После перехода на 8-ку стали прорабатывать вопрос перехода на NVMe End2End. Открываем историю функционала vHW на virten.net, а там написано, что лучше бы на 21-ую версию глянуть для NVMe 1.3  – Virtual Machine Hardware Versions. А на сам Windows Server надо патч KB5029250 накатить –
Hot add/remove disk on vNVMe controller doesn’t work properly with Window guest OS.

Другие известные косяки с MS WS 2022 (выбрал самые интересные):

• Update of VMware tools 12.5.1 on a Windows 2022 Server, domain network connectivity issue is seen
• Windows Server 2022 Virtual Machine Loses Network Connectivity When Using E1000E Adapter
• Guest OS in-place upgrade to Windows Server 2022 or Windows 11 failed after upgrading VMware Tools to 12.0.5 or later on vSphere
• Application-Consistent Quiescing snapshot is not enabled by default for Windows Server 2022
• Unable to enable Fault Tolerance on a Windows Server 2022 or 2025 VM when VBS is enabled
• Customers implementing MS November 2024 patches causes VCSA (and potentially other products) to fail authentication
• Virtual Machines on AMD platforms with Windows Guest OS encounter BSOD after enabling Virtualization-Based Security (VBS)

Так что могут рекомендовать для 7-ки использовать для Windows Server 2022 vHW 18+ на Intel, vHW 19 на AMD c VBS, для 8-ки с NVMe vHW 21.

0:00 – Старт
1:00 – Представление экспертов
2:00 – Что такое виртуализация? Какие виды бывают?
11:33 – Как изменился рынок в 2023 году
17:17 – Насколько востребованы в России бесплатные Open Source платформы (Xen, KVM)?
19:52 – Результаты опроса «Какая система виртуализации используется в вашей компании»?
36:25 – Кадровый вопрос
46:05 – Результат опроса «Какова ваша стратегия относительно систем виртуализации»?
52:12 – Что стало после введения санкций с инсталляциями VMware ESXi и Microsoft Hyper-V? Насколько востребованы в России бесплатные Open Source платформы (Xen, KVM)?
59:14 – Какие сертификаты нужны для российских систем виртуализации?
1:01:57 – Зачем нужно платить за российские аналоги, если можно получить ту же функциональность бесплатно на KVM?
1:25:28 – На какие параметры смотреть при выборе коммерческой российской системы виртуализации?
1:31:54 – Результаты опроса «Основной сценарий использования систем виртуализации»
1:33:00 – Результаты опроса «Что вас останавливает от перехода на российские системы виртуализации»?
1:44:14 – Какие аппаратные платформы поддерживаются? Какие серверные операционные системы можно виртуализировать на российских платформах? Есть ли российские системы для виртуализации рабочих мест (VDI)? (ведущий решил задать три темы сразу)
1:53:49 – Какими компетенциями нужно обладать ИТ-специалистам на стороне заказчика?
2:03:32 – ТОП-10 распространенных ошибок при внедрении и эксплуатации?
2:25:07 – Результаты опроса «Каково ваше мнение о российских системах виртуализации после эфира»?

Для индивидуальной миграции есть простые варианты.

Самые простой вариант – встроенное в менеджер виртуализации средство. Для продуктов на базе OVirt оно представляет собой virt-v2v или virt-p2v.

Метод посложнее, но, на мой взгляд, более универсальный – использовать СРК и ВД для создания резервного копии из одной среды виртуализации и восстановления в другой. Из российских СРК и ВД самый рабочий вариант – КиберПротект КиберБэкап.

Но также на рынке представлены средства массовой миграции:

ХайСтекс Акура aka Hystax Acura. Позволяет выполняет переезд и в облака Yandex Cloud, SberCloud, VK Cloud, CROC Cloud, а также работать с локальной инфраструктурой на базе VMware и OpenStack.

Mind Migration. Позволяет менять среды виртуализации и облачные решения VMware -> Базис, Private -> Public, AWS -> Яндекс.Облако, VK Cloud -> Sbercloud. Поддерживает большой стек технологий виртуализации.

После 2-3 сбросов я смог попасть в безопасный режим и удалить компонент в оснастке, но при следующей же перезагрузке Windows сказала, что доудалять не может и восстановила Hyper-V  – и система ушла в цикл.

На просторах Интернета нашёл команду, запрещающую старт Hyper-V (запустить в командной строке от имени администратора):

bcdedit /set hypervisorlaunchtype off

обратная (если понадобится):

bcdedit /set hypervisorlaunchtype auto

Как-то мне довелось админить большой домен на несколько тысяч пользователей. После того как база NTDS.DIT выросла до 14ГБ, поднятие нового контроллера домена без использования функционала Install From Media (IFM) стало занимать несколько часов.

Я создал новый тестовый домен, создал в нем сходное количество пользователей, групп и компьютеров. Назначил каждому пользователю картинку на 100к и…

Получил размер базы меньше 1ГБ. Это «Ж-ж-ж» неспроста! – подумал я и обратился в MS Premier Support.

Те проанализировали количество объектов с помощью утилиты DBAnalyzer и ничего криминального не нашли.

После этого с помощью esentutl они посмотрели размер базы:

«Ух ты» – сказали суровые сибирские мужики инженеры MS – «да у вас индексов многовато». А не эта ли у вас проблема?

После включения Credentials Roaming и сохранения закрытых ключей в AD на Windows7/Windows 2008R2 был баг: «левые» закрытые DPAPI-ключи продолжают сохраняться в AD. В результате, у пользователя может быть несколько тысяч закрытых DPAPI-ключей, попутно значительно растет размер базы AD. Хотите решить проблему – удалите все ключи! Выборочно? Нет, выборочно нельзя – необходимо вычистить все три атрибута, относящиеся к PKI, при этом пользователю все сертификаты, хранящиеся в AD, необходимо перевыпускать.

Мы грустно вздохнули. «Мы ж ключи используем во всяких документооборотах и 1Сках через терминальную ферму», и закопали стюардессу.

Прошел год, я развернул еще несколько контроллеров домена (часов за 6 каждый без IFM) и подумал, что, пожалуй, стоит выкопать стюардессу.

Мы начали разбираться, что можно сделать.

Во-первых, мы пропатчили 100500 терминальных серверов. Это помогло остановить дальнейший рост AD, но зачистить базу не помогло.

Во-вторых, мы включили на всех контроллерах домена информацию о процессе сборщике мусора. Для этого в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics надо найти параметр Garbage Collection и задать ему значение 1.

После этого в журнале Active Directory каждые 12 часов будет появляться событие с кодом 1646, содержащее текущие размеры базы:

Free hard disk space (megabytes), также известный как whitespace:

948

Total allocated hard disk space (megabytes):

14967

В-третьих, нам потребовался вывод утилиты repadmin /showobjmeta по пользователям, указанным через DN. Это дало нам возможность понять – сколько ключей есть у пользователя (и осознать масштаб проблемы).

В выводе также указывается статус ключа: ABSENT или PRESENT.

Инженеры MS Premier Support Инопланетяне подготовили скрипт dumpLVR.cmd, выгружающий список ключей пользователя в файл. Отсортировав список файлов по размеру, стало возможно охватить взором масштаб проблемы.

dsquery user -limit 0 > %temp%\userDN.txt
md %temp%\LVRs
md %temp%\LVRs\Statistics

FOR /F "tokens=*" %%i IN (%temp%\userDN.txt) DO (
CMD /C echo > "%temp%\LVRs\%%~i.txt"
IF EXIST "%temp%\LVRs\%%~i.txt" Repadmin /showobjmeta . %%i | findstr "PRESENT ABSENT" > "%temp%\LVRs\%%~i.txt"
)

FOR /F "tokens=*" %%i IN ('DIR /b %temp%\LVRs\*.txt') DO (
FIND /c "PRESENT" "%temp%\LVRs\%%i" >> %temp%\LVRs\Statistics\All_PRESENT_LVRs.txt
FIND /c "ABSENT" "%temp%\LVRs\%%i" >> %temp%\LVRs\Statistics\All_ABSENT_LVRs.txt
FIND /c "msPKIDPAPIMasterKeys" "%temp%\LVRs\%%i" >> %temp%\LVRs\Statistics\All_msPKIDPAPIMasterKeys.txt
FIND /c "msPKIRoamingTimeStamp" "%temp%\LVRs\%%i" >> %temp%\LVRs\Statistics\All_msPKIRoamingTimeStamp.txt
FIND /c "msPKIAccountCredentials" "%temp%\LVRs\%%i" >> %temp%\LVRs\Statistics\All_msPKIAccountCredentials.txt
)

start %temp%\LVRs\Statistics\
Echo Done.
PAUSE

В принципе, вы просто можете выполнить по всем пользователям дамп в текстовый файл команды repadmin /showobjmeta. Будет то же самое, что в скрипте.

После этого я зачистил сотруднику ключи и… увидел то же, что и вы на скриншоте:

– ключей стало вдвое больше;

– часть ключей получили статус ABSENT (т. е. в учетке их нет, но они лежат на кладбище и продолжают занимать место);

– база подросла.

Зато мы поняли – ключи возвращаются назад, если их удаление произошло при активном сеансе на терминальном сервере, так как включен Credentials Roaming, который при выходе из системы выгружает все актуальные ключи в базу AD.

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

В-четвертых, мы снизили до 9 дней срок хранения объектов на «кладбище», чтобы ускорить их удаление из базы.

Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=firstbank,DC=local” -Partition “CN=Configuration ,DC =COM” -Replace @{tombstoneLifetime=’9′}

Обратите внимание: удаленный объект сначала хранится в корзине, а потом на кладбище, вследствие чего срок хранения объекта составляет 2*Tomb.

Как я увидел дальше – Garbage Collection не всегда успевал зачистить все объекты за один проход, иногда приходилось ждать несколько дней.

В-пятых, мы занялись инвентаризацией используемых систем. Взяли отключенных пользователей и тех, кто 100% не пользуется системами с PKI. А инженеры MS инопланетяне составили очередной скрипт по зачистке ключей по списку пользователей – delete_credentails_From_File.vbs. Мы зачистили эти ключи (предварительно завершив терминальные сессии) и через 18 дней получили рост свободного места в базе.

'Option Explicit

Dim adoCommand, adoConnection, strFilter, strAttributes
Dim resRecSet, strSrchPath, strDefNamCont, objRootDSE, strQuery
Dim strdstName, objUser

' Setup ADO objects.
Set adoCommand = CreateObject("ADODB.Command")
Set adoConnection = CreateObject("ADODB.Connection")
adoConnection.Provider = "ADsDSOObject"
adoConnection.Open "Active Directory Provider"
adoCommand.ActiveConnection = adoConnection

' Search entire Active Directory 
Set objRootDSE = GetObject("LDAP://RootDSE")
strDefNamCont = objRootDSE.Get("defaultNamingContext")
strSrchPath = "<LDAP://" & strDefNamCont & ">"
i = 0
l = 0
Set objFSO = CreateObject("Scripting.FileSystemObject") 
Set objFile = objFSO.OpenTextFile("c:\tmp\testfile.txt", 1, True) 

Set Donefile = objFSO.OpenTextFile("c:\tmp\Del_Cred_Result_log.txt", 8, True) 
DoneFile.Writeline "==================================="
DoneFile.Writeline Now
DoneFile.Writeline "_______________________________________"
Do Until objFile.AtEndOfStream
ReDim Preserve FileLine(i)
FileLine(i) = objFile.ReadLine
i = i + 1
Loop
objFile.Close


For l = LBound(FileLine) to UBound(FileLine) Step +1

UserFromList = FileLine(l)

strFilter = "(&(objectCategory=person)(objectClass=user)(samAccountName="&UserFromList &"))"
' Comma delimited list of attribute values to retrieve.
strAttributes = "distinguishedName"
' Construct the LDAP syntax query.
strQuery = strSrchPath & ";" & strFilter & ";" & strAttributes & ";subtree"
adoCommand.CommandText = strQuery
' Run the query.
Set resRecSet = adoCommand.Execute

Do Until resRecSet.EOF

strdstName = resRecSet.Fields("distinguishedName").value
WScript.Echo "User Distinguished Name: " & strdstName
Set objUser = GetObject("LDAP://" & strdstName)
objUser.PutEx 1,"msPKIAccountCredentials",NULL
objUser.PutEx 1,"msPKIRoamingTimeStamp",NULL
objUser.PutEx 1,"msPKIDPAPIMasterKeys",NULL

objUser.SetInfo

'''WScript.Echo "============================================================================"
'''WScript.Echo "The user properties msPKIAccountCredentials, msPKIRoamingTimeStamp and msPKIDPAPIMasterKeys cleared for the user accout " & strdstName
'''WScript.Echo "============================================================================" & vblf
DoneFile.Writeline strdstName

resRecSet.MoveNext
Loop

Next
WScript.Echo "Done!!!"
Wscript.Quit(0)

Это был прямо успех-успех!
В принципе, вместо этого скрипта вы можете использовать свой. Смысл – зачистка атрибутов msPKIAccountCredentials, msPKIRoamingTimeStamp и msPKIDPAPIMasterKeys у заранее указанного списка пользователей.

В-шестых, началась грустная рутина. Сначала мы еще раз прошерстили пользователей 1С и смогли вычистить еще ряд пользователей. Но оставался документооборот (ДО), в котором были ключи у 40% пользователей – толстячков

К счастью, админы документооборота предложили отличную идею: просмотреть логи приложения на предмет исходного IP-адреса. Если адрес был локальный (т. е. пользователь запускал клиента ДО на своем ПК), то его ключ можно было смело чистить.

Таким образом, мы смогли зачистить эти ключи примерно у 90% учетных записей и освободить в базе 8820МБ. Ииихаа.

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

• Net stop ntds
• Ntdsutil
• Activate instance ntds
• Files
• Compact to c:\temp
• Q
• Q
• copy “c:\temp\ntds.dit” “C:\Windows\NTDS\ntds.dit”
• del C:\Windows\NTDS\*.log
• net start ntds

Как вы думаете, сколько будет 14967–8820?

3900МБ, да-да. В старой таблице индексов было много ссылок на удаленные объекты. Так как офлайн-дефрагментация пересоздала таблицу индексов, размер базы стал еще меньше, чем мы рассчитывали!

И вот это уже был прям успешище!

Ну и надо было вернуть назад срок хранения удаленных объектов.

Столь малый размер БД позволил нам не только уменьшить время на развертывание (развертывание через IFM занимало примерно столько же времени), но и добиться ряда других бонусов:

– при полномочном восстановлении и последующей репликации AD процесс увеличения USN уже бы не занял несколько часов;

– для оптимальной производительности AD базу требовалось кэшировать в памяти. Снижение на 10ГБ размера базы на каждом RWDC и на 12ГБ на каждом RODC позволило сэкономить только на памяти пару десятков тысяч долларов.

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

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

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

В один прекрасный день дошла очередь до серверов с ролью 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 минут.

Как знают почти все активно работающие с 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. Единственное, что мне было непонятно – почему снапшот выключенной машины не прошел? Но тут я сделал большую ошибку – не проверил процедуру с хоста и не сохранил логи хоста для дальнейшего анализа.

С чего все началось

Недавно у наших коллег появилось осознание, что:

1. самым старым серверам в продуктивной среде уже 8 и больше лет,
2. поддержки и запчастей на них нет,
3. нагрузка по памяти под 90%, но ее там очень немного,
4. установлена максимально возможная для этих серверов ESXi 6.5 , на тот момент 17477841 (сейчас 18071574).

Поэтому  было решено:

1. начать закупку новых серверов,
2. обновить, где  возможно, до ESXi 7.0 для единообразия.

Серверы, в основном, производства HPE и Huawei, на каких-то задачах используются серверы Supermicro. Предлагают закупать Dell, HPE, Lenovo. У Huawei сейчас все сложно, а присматриваться к линейке Kunpeng на Arm сейчас нет времени. Хотя под Arm есть и MS Server, и ESXi.

Почему ESXi, а не что-то еще

Все достаточно прозаично – сложившийся опыт эксплуатации и «люди со знанием в наличии». Мгновенно перейти «на что-то еще» нельзя, поддерживать две разные системы (например, ESXi и KVM) – потребует увеличить бюджет отдела на:

1. Людей, которые могут, умеют и практикуют KVM – то есть утроить штат  – оставить старые кадры, набрать (не мгновенно) новые кадры, и выделить людей со стороны сервисов / разработки, которые вместо текущей работы будут заниматься тестами «вообще». Автотестов у нас маловато и не все вылезает так быстро, как хотелось бы.
2. Тестовые стенды сначала под «посмотреть», потом под пробную миграцию, замеры скорости и тому подобное(а на KVM может быть больно в дисковых операциях).

Затем – после решения вопроса денег и людей (новые люди – новое штатное расписание – новые начальники), придется:

3. Долго и нудно искать подходящий оркестратор и разбираться в нем (Openstack, а еще? Если Openstack, то какой – ванильный или вендорский? Если вендорский, то чей? FusionSphere OpenStack, например – плюсы, минусы?
4. Искать и пробовать – как работает бекап и восстановление?
5. Поиметь проблемы со скоростью, как описанные, так и не очень.
6. Я не перечисляю вопросы с импортозамещением у кого оно есть (в данном случае – нет), регуляторами (сертификацией средств защиты инофрмации) и прочей отраслевой спецификой. Граждане, попадающие под требования 187-2017-КИИ и ГОСТ Р 57580 знают, о чем речь.

Отдельно придется рассмотреть новые процедуры «поибэ», сбор и хранение логов и удаленный доступ для поддержки. В ESXi процесс понятен и передача support bundle «наружу» согласована с ИБ, а как быть с новыми системами?

Тоже самое придется тестировать и учить при выборе Hyper-V. Да, он надежен, совместим с массой программ резервного копирования, диски переедут без особых усилий, но все равно это требует времени и ресурсов, в том числе на изучение счётчиков производительности \Hyper-V Hypervisor Logical Processor(_total)\% Guest Run Time, Total Run Time, % Hypervisor Run Time, или же, если у вас некролаба – HKLM\SYSTEM\CurrentControlSet\Services\VMSMP\Parameters /v BelowTenGigVmqEnabled /t REG_DWORD /d 1 /f, сверху (если хорошая лаба) – все обмазать RoCEv2 в смеси с Dynamic Virtual Machine Multi-Queue (Dynamic VMMQ or d.VMMQ)  и заполировать Switch Embedded Teaming (SET) и так далее.

В остатке – переезд ради переезда ценой в удвоение бюджета ИТ ради снижения стоимости лицензий? На общем фоне даже временная аренда новых площадей для руководства и хотя бы трети нового штата (2/3 на удаленке) обойдется ООО «Скрудж и Марли» чуть дороже лицензий.

Отличия ESXi 7.0 от 6.7 и процедуры подготовки

Такие очевидные вещи, как обновление прошивок и проверку пары прошивка-драйвер пропущу, но напомню про инструменты. Как показывает недавний опыт – не все с этим знакомы. Для Huawei – это раздел Intelligent Servers, FusionServer iDriver и SmartKit, для HPE ситуация традиционна – обязательная подписка, доступ к Service Pack for ProLiant (SPP), Oneview,  OpenView, HPE Smart Update Manager (SUM), для Dell – работа с OpenManage. Даже у Supermicro есть – Supermicro Update Manager (SUM). Пропущу и рассказ про обязательную проверку старых серверов и процессоров через HCL.

Особое внимание надо уделить следующему:

Сети, которые Ethernet. В 7.0 и далее сменилась модель использования драйверов, и просто так поставить в дистрибутив  старые линуксовые драйвера больше нельзя. Проверяйте HCL, проверяйте прошивки, смотрите в Community Networking Driver for ESXi.

Сети, которые storage area network (SAN). В связи с очень, очень странной политикой (почти монопольной) Brocade – оценивайте санкционные риски при использовании FC-Brocade (да и Cisco тоже). Возможно, со сменой серверов – можно рассмотреть и смену SAN с FC на Ethernet 10/25/100 G. Плюсы – меньшая привязка к вендору. Минусы – придется изучить массу нововведений для разгрузки центрального процессора и такую же массу дополнений к самому Ethernet. Тут и старые DCB,  TSO-LRO, и lossless Ethernet, и RDMA м SR-IOV и RoCE (RDMA over Converged Ethernet) – много новых терминов, некоторые из них могут вызвать абсолютно неожиданные проблемы.

Сети вообще. Уже много лет идет переход на10/25 сети, а люди все равно умудряются собирать Etherchannel, совершенно не понимаю никак он работает, ни зачем он нужен, ни что такое beacon, ни его применимость. Потом получают проблемы в сети и страдают. Граждане, грамотно планируйте сеть, не усложняйте ее без существенных обоснований. Читайте официальную открытую бесплатную документацию.

Диски или новая боль. Много лет у ESXi был огромный плюс –гипервизор отлично работал с 4-8 Гб USB флешки или SD. USB/SD была нужна только на запуске, затем гипервизор жил в памяти – и настроить надо было только логирование, дампы, бекап и профили. Умерла флешка – не беда, поставили новую, обновили, восстановили из бекапа или из профиля. Но они особо и не умирали (кроме как в случае перегрева). В ESXi 7.0 ситуация изменилась – USB все еще можно, но лучше не надо: The recommended ESXi 7.0 install options are the following:    A local disk of 138 GB or larger. The disk contains the boot partition, ESX-OSData volume and a VMFS datastore. A device that supports the minimum of 128 Terabytes Written (TBW) (ссылка).

Резервное копирование. При планировании перехода, проверяйте, что ваше ПО резервного копирования работает с новыми ESXi и vCenter до начала любых работ.

TLS. Тоже имейте в виду, что 1.0 и 1.1 уже не модно – You can use the TLS Configuration utility to enable or disable TLS versions on vCenter Server systems. As part of the process, you can disable TLS 1.0, and enable TLS 1.1 and TLS 1.2. Or, you can disable TLS 1.0 and TLS 1.1, and enable only TLS 1.2. (документация)

Ansible / Terraform / etc. Если вы работаете с этими инструментами, сразу смотрите «что изменилось».

Опыт коллег, или с чем столкнулись в тестах при обновлениях на vCenter 7.0

Сначала еще раз – почему нельзя обновить только хосты до ESXi 7 – и оставить старый вцентр 6.7? Потому! Смотрите VMware Product Interoperability Matrix.

Что нового, кроме отсутствия Flash? Вот обзорная статья, от себя добавлю , что не все функции 1:1 перенесли из Flash клиента. Я не записал, с чем коллеги столкнулись – то ли с монтированием FDD image, то ли с захватом сетевого трафика, какие-то не очень типичные операции. Проверять надо все ручные операции, надеюсь у вас есть их каталог.

vCenter 7 добавляет vSphere Cluster Services (vCLS). Это минимально возможные виртуальные машины «для служебных задач». Вот эта фраза в документации – ESXi host can be of any older version that is compatible with vCenter server 7.0 Update 1 – немного расходится с практикой, иногда эти VM отрабатывают нормально, иногда не могут запуститься. На этот счет есть заметка Demo Time: How to delete the vCLS VMs. Вопрос можно начать изучать отсюда – Workaround for ESXi-Arm in vSphere 7.0 Update 1.

В чистой установке vCenter 7.0 проблем вроде бы меньше, но это субъективное мнение – на vmware полно kb со словами “no workaround” и “will be fixed soon”.

Обновление – VUM / vLCM. Согласно сайту, все сделали только более лучше – We greatly improved lifecycle management in vSphere 7. The new innovations for lifecycle management in vSphere 7 make it easy for customers to have consistent and up-to-date systems. На практике в тестовом сегменте VUM вообще умер, и далее пришлось выполнять kb 2147284 Resetting VMware Update Manager Database on a vCenter Server Appliance 6.5/6.7/7.0 . Вместе с ним умерли задачи с проверкой Baseline хостов по расписанию, точнее задачи в расписании остались – а baseline уже нет. Пересоздали, конечно.

Бекап средствами vCenter. При последнем срочном обновлении до vCenter Server 7.0 U2b (17958471) умер встроенный бекап. Проблема «умирания» была связана с порядком запуска служб, состоянием VMware Directory Service (vmdir), проверкой «кто там запустился и в каком статусе», лечение связано с исправлениями в конфиге – куда не стоит заходить без наличия активной поддержки (потому что, бекапа, фактически, уже нет).

Проблемы могут быть и при самом апгрейде, например описанные в статье VCSA 7.0 Update 2 Upgrade Issue – Exception occurred in install precheck phase, с ручным НЕ РЕКОМЕНДОВАННЫМ исправлением через shell.