На днях компания VMware обновила свой главный документ, касающийся обеспечению безопасности виртуальных сред и самой платформы виртуализации - VMware vSphere 7 Security Configuration Guide. Напомним, что о его прошлой версии осенью прошлого года мы писали вот тут.

Давайте посмотрим, что появилось нового в обновленном SCG для vSphere 7, который традиционно состоит из PDF-файла описания и XLS-файла настроек, рекомендаций и пояснений:

• Исправлены ошибки в рекомендациях PowerCLI для аудита виртуальных машин.
• Добавлена вкладка "Deprecated" - там теперь будут те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

• Настройка svga.vgaOnly перемещена в Deprecated. Она ограничивает ВМ на использование только VGA-разрешений, а многие современные ОС этого очень не любят (могут даже отключить отображение картинки в этом случае).
• Добавлены и обновлены рекомендации по отключению сервисных служб SLP и CIM на сервере ESXi. Эти протоколы часто не используются (их не используют и продукты VMware), поэтому лучше их отключить.
• Добавлены рекомендации по изоляции сети. Раньше как-то само собой подразумевалось, что нужно разделять сети управления, vMotion и vSAN, теперь же это формализовано в документе. Там же рекомендовано и физическое разделение сетей.
• Добавлена рекомендация по использованию только тех продуктов, старые версии которых еще официально поддерживаются со стороны VMware (например, вы можете выполнить все рекомендации и накатить все обновления, но использовать старый ESXi 5, что по понятным причинам небезопасно).
• Добавлено руководство по использованию модулей Trusted Platform Modules 2.0 (TPM).
• Снова возвращена рекомендация vm-7.pci-passthrough, касающаяся прямого доступа виртуальных машин к оборудованию, в частности шине PCIe.
• Добавлено руководство по отключению интерфейсов DCLI, если вы не используете его на vCenter Server. Также вам не нужно держать SSH постоянно открытым, так как в vSphere широкий и защищенный API, который вы можете использовать в разных фреймворках и утилитах.

Скачать VMware vSphere 7 Security Configuration Guide (как и руководства для других версий vSphere) можно по этой ссылке. Подробнее о документе также можно почитать тут.

Многие администраторы VMware vSphere знают, что для организации кластеров Windows Server Failover Clusters (WSFC) нужен эксклюзивный доступ к LUN, а значит на уровне виртуальной инфраструктуры подходили только RDM-диски. Ранее эти кластеры назывались MSCS, мы писали об их организации в виртуальной среде вот тут.

Такая ситуация была из-за того, что WSFC использует механизм резервация SCSI-3 Persistent Reservations, который координирует доступ к общему дисковому ресурсы. С другой стороны, VMFS использует собственный механизм блокировки LUN, поэтому команды WSFC перехватываются и отменяются, если используются диски VMDK. Поэтому RDM-устройства и использовались как средство маппинга дисков виртуальных машин к физическому устройству LUN.

Оказывается, ситуация поменялась с выпуском VMware vSphere 7, где появился механизм Clustered VMDK. Он позволяет командам SCSI3-PR выполняться и применяться к виртуальному диску VMDK, поэтому вам не нужен отдельный LUN.

К сожалению, все это работает только на хранилищах Fibre Channel.

Чтобы это начать использовать, на уровне датастора надо установить параметр "Clustered VMDK Supported":

Далее нужно понимать следующие условия и ограничения:

• Параметр кластера Windows Cluster "QuorumArbitrationTimeMax" должен быть выставлен в значение 60.
• LUN за этим датастором должен поддерживать команды ATS SCSI (как правило, это всегда поддерживается).
• LUN должен поддерживать резервации типа Write Exclusive All Resgistrants (WEAR).
• VMDK-диски должны быть типа Eager Zeroed Thick и виртуальные машины должны быть как минимум в режиме совместимости с vSphere.
• Не презентуйте LUN, которые используются как кластерные VMDK, для хостов ESXi версий ниже 7.0.
• Не комбинируйте датасторы для clustered и non-clustered VMDK на одном общем кластерном хранилище.
• Выделяйте один датастор на один кластер WSFC, не шарьте один датастор между несколькими инстансами кластеров WSFC.

Максимумы конфигураций для таких кластеров WSFC следующие:

Надо помнить еще о следующих ограничениях (более подробно тут):

• Конфигурация Cluster in a Box (CIB) не поддерживается. То есть надо настроить правила anti-affinity DRS Rules, чтобы разделить узлы кластера / виртуальные машины по разным хостам ESXi. Если вы попробуете такую ВМ с помощью vMotion переместить, то миграция завершится неудачно.
• Горячее расширение VMDK кластерной ВМ не поддерживается.
• Не поддерживается Storage vMotion и снапшоты.
• VMFS 5 и более ранние версии не поддерживаются.

На сайте VMware Labs появился интересный инструмент Virtualized High Performance Computing Toolkit, который может оказаться полезен компаниям, использующим VMware vSphere для организации высокопроизводительных вычислений (High Performance Computing, HPC). Такие комплексные вычислительные задачи, как правило, вовлекают параллельные вычисления, аппаратное ускорение (такое как GPU и FPGA), а также используют высокоскоростные каналы, такие как RDMA.

Все это требует определенных конфигураций VMware vSphere, для настройки которых и нужно данное средство. С помощью него, используя vSphere API, можно дать администраторам инструменты по сопровождению задач HPC, таких как клонирование ВМ, настройка Latency Sensitivity, сайзинг виртуальных машин по CPU и памяти и многое другое.

Основные возможности тулкита:

• Настройка устройств PCIe в режиме DirectPath I/O, таких как GPGPU, FPGA и RDMA
• Настройка NVIDIA vGPU
• Настройка RDMA SR-IOV (Single Root I/O Virtualization)
• Настройка PVRDMA (Paravirtualized RDMA)
• Простое создание и уничтожение кластеров HPC с помощью файлов конфигураций
• Выполнение задач vSphere, таких как клонирование, настройка vCPU, памяти, резерваций, shares, Latency Sensitivity, обычного и распределенного виртуального коммутатора, сетевых адаптеров и конфигураций

Например, клонирование 4 виртуальных машин с заданными кастомизациями CPU и памяти, а также добавлением NVIDIA vGPU с профилем grid_p100-4q выглядит так:

vhpc_toolkit> clone --template vhpc_clone --datacenter HPC_Datacenter --cluster COMPUTE_GPU_Cluster --datastore COMPUTE01_vsanDatastore --memory 8 --cpu 8 –-file VM-file
vhpc_toolkit> vgpu --add --profile grid_p100-4q --file VM-file

Для использования тулкита вам понадобится ОС Linux или Mac. Скачать Virtualized High Performance Computing Toolkit можно по этой ссылке.

На сайте проекта VMware Labs очередная новая утилита - SDDC Import/Export for VMware Cloud on AWS. С ее помощью можно сохранять конфигурацию виртуального датацентра SDDC в облаке VMConAWS, а также импортировать ее из сохраненной копии.

Иногда пользователи по разным причинам хотять мигрировать из одного SDDC-датацентра в другой. Для миграции виртуальных машин есть решение VMware HCX, а вот для переноса конфигурации среды до текущего момента не было. Теперь же можно сохранить конфигурацию исходного SDDC и развернуть ее на целевом, не тратя много времени на повторную настройку.

Это может вам, например, пригодиться для проведения миграций в следующих случаях:

• Миграция с одного на другой SDDC с разным типом железа (например, с i3 на i3en)
• Миграция с одного на другой SDDC с VMware-based организации на AWS-based
• Миграция с одного на другой SDDC в другом регионе (например, из Дублина в Лондон)

Также есть вот такие полезные юзкейсы:

• Сохранение бэкапов конфигураций SDDC
• Быстрое развертывание преднастроенного SDDC для тестовых целей
• Развертывание конфигурации на DR-площадке в связке с VMware Site Recovery Manager или VMware Cloud Disaster Recovery

Вот небольшое видео о том, как работает утилита:

Скачать SDDC Import/Export for VMware Cloud on AWS можно по этой ссылке.

Наш постоянный читатель Сергей обратил внимание на то, что на днях компания VMware выпустила обновление своего главного фреймворка для управления виртуальной инфраструктурой с помощью сценариев - PowerCLI 12.2. Напомним, что о прошлой версии PowerCLI 12.1 осенью прошлого года мы писали вот тут.

Давайте посмотрим, что нового появилось в обновленном PowerCLI 12.2:

1. Поддержка VMware Horizon

Модуль PowerCLI для управления инфраструктурой Horizon теперь поддерживается для macOS и Linux OS.

2. Инфраструктура VMware Cloud

Появилась поддержка одного из самых популярных сервисов для обеспечения катастрофоустойчивости датацентров - DRaaS. Новые командлеты позволяют включать/отключать DRaaS в виртуальном датацентре VMC SDDC, а также добавлять и удалять инстансы SRM (Site Recovery Manager).

Вот так выглядит включение DRaaS:

Управление инстансами SRM происходит с помощью командлетов:

• Get-VmcSddcSiteRecoveryInstance
• New-VmcSddcSiteRecoveryInstance
• Remove-VmcSddcSiteRecoveryInstance

3. Поддержка VMware vSphere

• Расширенная поддержка vSphere Lifecycle Manager (vLCM)
  • Новые командлеты для экспорта и импорта состояния кластера
  • Новые командлеты для получения рекомендаций vLCM (Get-LcmClusterDesiredStateRecommendation)
  • Новые командлеты для получения аппаратной совместимости компонентов со стороны vLCM
  • Улучшенный командлет Set-Cluster для добавления кастомного репозитория ROBO-окружений
• Расширенная поддержка параметров OVF для объектов Content Library
• Добавлена поддержка шаблонов ВМ в Content Library
• Операция Foreach-object -Parallel теперь поддерживается

Вот так выглядит экспорт состояния кластера:

А вот так импорт:

4. Управление рабочими нагрузками

• Новые командлеты для управления лимитами пространств имен:
• Get-WMNamespaceLimits
• Set-WMNamespaceLimits

5. Поддержка NSX-T

• Теперь поддерживаются API компонента NSX-T global manager

Больше подробностей и примеров использования новых фич вы можете найти вот в этой статье. Скачать VMware PowerCLI 12.2 можно по этой ссылке.

Компания VMware выпустила обновление продукта vRealize Log Insight 8.3, предназначенного для поиска любых данных в виртуальной инфраструктуре, анализа лог-файлов и визуализации аналитики. О прошлой версии Log Insight 8.2 мы упоминали вот тут.

Давайте посмотрим, что нового появилось в Log Insight 8.3:

1. Поддержка стандарта Federal Information Processing Standard (FIPS) 140-2

В новой версии реализована поддержка стандарта от National Institute of Standards and Technology (NIST), который регулирует использование криптографических модулей в программных продуктах, используемых в государственных организациях.

После того, как вы включите режим FIPS, его нельзя уже будет отключить. После включения потребуется перезагрузка хостов кластера, поэтому он будет переведен в режим обслуживания.

Можно настроить предупреждающее сообщение:

Можно добавить кнопку I agree в конце диалогового окна:

2. Поддержка аутентификации cross-domain group-based authentication для пользователей vIDM

Пользователи продукта для единой аутентификации VMware Identity Manager теперь могут использовать группы из разных доменов Active Directory, между которыми есть траст.

3. Возможность загрузки LI Agent без аутентификации

Агент решения Log Insight (LI Agent) теперь можно скачивать напрямую и через API по ссылке https://<server>/api/v1/agent/install-packages/msi (можно использовать окончание пути для разных форматов /msi, /bin, /deb и /rpm).

Скачать VMware vRealize Log Insight 8.3 можно по этой ссылке.

Недавно появилась новость о том, что некое Ransomware использует уязвимости на хостах с гипервизором VMware ESXi для того, чтобы получить контроль над виртуальными машинами и зашифровать их диски VMDK, после чего злоумышленники просят выкуп у компаний за их расшифровку.

Речь идет об эксплуатации уязвимостей CVE-2019-5544 и CVE-2020-3992, касающихся недоработок протокола Service Location Protocol (SLP) и удаленного исполнения кода в ESXi и VMware Horizon DaaS (десктопы как услуга).

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

Сообщается, что в атаке, которая произошла в прошлом году, группировка RansomExx (они же Defray777) смогла получить доступ к серверам ESXi инфраструктуры нескольких компаний и зашифровать диски виртуальных машин, которые были доступны этому ESXi. Информация об этом инциденте есть в ветке на Reddit.

По шагам атака выглядела так:

• Три пользователя в компании установили троян, который послали по почте.
• Атакующие получили привилегии, используя уязвимость CVE-2020-1472. На рабочих станциях стоял антивирус Касперского, который на тот момент не имел сигнатур этого трояна.
• Атакующие получили доступ к хостам, которые, в свою очередь, имели доступ к подсети управления ESXi, так как у злоумышленников были админские привилегии в AD.
• Без необходимости компрометации vCenter они просто запустили код на ESXi, используя две описанные выше уязвимости.
• Это привело к созданию скрипта на питоне, который шифровал диски VMDK. Вот тут приведено более детальное объяснение.

Избежать всего этого было просто - надо было вовремя пропатчить рабочие станции и серверы, ну и конечно не запускать трояны из письма:)

Администраторы VMware vSphere в больших инфраструктурах иногда используют кластеры Windows Server Failover Clusters (WSFC) на базе RDM-дисков, которые доступны для хостов VMware ESXi. Ранее они назывались Microsoft Cluster Service (MSCS). При использовании таких кластеров время загрузки хоста ESXi может вырасти аж до целого часа, если не поставить этим LUN статус Perennially reserved.

Суть проблемы в том, что WSFC ставит SCSI-3 reservations для своих LUN, используемых активным узлом, и если ESXi видит эти тома (то есть они не отмаскированы для него), то он безуспешно пытается получить к ним доступ. Для этого он делает несколько попыток при загрузке, пока не решает перейти к следующим томам. Статус этих операций вы можете увидеть, если нажмете Alt+F12 при загрузке хоста:

Xavier Avrillier написал статью о том, как с помощью esxicli/PowerCLI пометить такие тома как Perennially reserved, чтобы ESXi пропускал их при сканировании (об этом также рассказано в KB 1016106).

Сначала вам надо узнать LUN canonical name устройства. Делается это следующей командой PowerCLI:

PS> Get-VM MSCS-Node-1 | Get-HardDisk -DiskType RawPhysical | select scsicanonicalname
ScsiCanonicalName

  —————–

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbc

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbb

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacba

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacbd

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacb9

  naa.60001xxxxxxxxxxxxxxxxxxxxxxxacb8

Далее для нужного id-устройства устанавливается статус Perennially reserved через esxcli:

esxcli storage core device setconfig -d naa.id –perennially-reserved=true

Но удобнее это же сделать и через PowerCLI (ищем диски у машин по шаблону MSCS-Node-*):

PS> Set-PerenniallyReserved -PerenniallyReserved $True -VMHost (Get-VMHost) -HardDisk (Get-VM MSCS-Node-* | Get-HardDisk -DiskType RawPhysical)

Ну а для тех, кто хочет использовать vSphere Client, недавно появилась опция "Mark as Perennially Reserved" в разделе Storage Devices клиента:

Главное - не ошибитесь в выборе LUN, если вы отметите не то - это может привести к весьма печальным последствиям.

Источник.

Иногда администратор VMware vSphere задается вопросом о происхождении виртуальной машины - из какой родительской ВМ/шаблона она была клонирована? Вильям Лам разбирает это в своей статье, приведем вкратце его метод определения происхождения ВМ.

Как вы знаете, бывает три типа клонирования виртуальных машин в VMware vSphere:

• Full Clone - это полный клон, то есть независимая копия виртуальной машины, у которой нет ничего связанного с родительской ВМ, это просто ее полная копия.
• Linked Clone - это копия виртуальной машины, которая имеет общие диски с родительской, доступные на чтение (это экономит пространство и позволяет просто откатываться к родительскому образу). Уникальные данные эта машина хранит в собственных дельта-дисках.
• Instant Clone - это независимая копия виртуальной машины, которая начинает исполняться с какого-то момента и отделяется от основной машины. Для этого используются техники in-memory cloning и copy-on-write, которые используются также и для связанных клонов.

Чтобы найти источник клонированной машины, нужно проанализировать события vCenter Server Events. Вот какие они бывают касательно клонов:

• VmClonedEvent - появляется, когда происходит создание Full Clone или Linked Clone.
• com.vmware.vc.VmInstantClonedEvent - происходит при созданиии Instant Clone.
• VmDeployedEvent - вызывается, когда виртуальная машина развертывается из шаблона (vSphere Template или Content Library Template).

На базе анализа этих трех событий в истории vCenter Вильям Лам создал PowerCLI-функцию Get-VMCloneInfo, с помощью которой можно узнать родителя для виртуальной машины, если она была клонирована.

Устанавливаем ее простой командой:

Install-Script VMCloneInfo

На входе эта функция принимает имя ВМ, которую мы хотим проанализировать. Такой вывод мы получим, если машина не была клонирована:

> Get-VMCloneInfo -VMName "SourceVM"

Unable to find any cloning information for SourceVM, VM may not have been cloned or vCenter Events have rolled over

Так будет выглядеть вывод по полному клону:

> Get-VMCloneInfo -VMName "Full-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVM 1/3/2021 1:13:00 PM VSPHERE.LOCAL\Administrator

Так мы узнаем, что машина является связанным клоном:

> Get-VMCloneInfo -VMName "Linked-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Linked SourceVM 1/3/2021 1:13:14 PM VSPHERE.LOCAL\Administrator

Так - что Instant-клоном:

> Get-VMCloneInfo -VMName "Instant-Clone-VM"

  Type Source Date User

  ---- ------ ---- ----

Instant SourceVM2 1/3/2021 1:12:44 PM VSPHERE.LOCAL\Administrator

Вот пример того, что машина была клонирована из шаблона vSphere Template:

> Get-VMCloneInfo -VMName "VMTX-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVMTXTemplate 1/3/2021 2:20:31 PM VSPHERE.LOCAL\Administrator

А вот - что из шаблона Content Library VM Template:

> Get-VMCloneInfo -VMName "VMTemplate-VM"

  Type Source Date User

  ---- ------ ---- ----

Full SourceVMTemplate 1/3/2021 2:23:41 PM VSPHERE.LOCAL\Administrator

Компания VMware выпустила недавно интересный документ "VMware vSphere 7.0 U1 Tagging Best Practices", описывающий улучшения, которые были сделаны в VMware vSphere 7.0 U1 в плане производительности операций при работе с тэгами.

Вкратце, было сделано 3 основных улучшения:

• Увеличена производительность при создании тэгов и категорий по сравнению с vSphere 6.7 U3.
• Производительность вывода тэгов через API улучшилась по сравнению с vSphere 6.7 U3.
• Теперь доступна паджинация вывода API, что позволяет упростить и ускорить получение данных.

Для иллюстрации улучшений на рисунке ниже приведена картина задержек (latency) при привязывании 15 тэгов к 5 000 виртуальным машинам в vSphere 6.7 U3 (где время линейно увеличивалось с ростом числа тэгов) и vSphere 7.0 Update 1, где время оставалось практически неизменным.

Скачать отчет VMware vSphere 7.0 U1 Tagging Best Practices можно по этой ссылке.

На сайте проекта VMware Labs обновилась еще одна интересная штука - средство Python Client for VMware Cloud on AWS 1.2, с помощью которого пользователям публичного облака VMware Cloud on AWS можно автоматизировать операции с инфраструктурой виртуального датацентра VMConAWS SDDC.

Это средство представляет собой не клиент для работы с сервером vCenter, а средство удаленного исполнения задач в облаке, таких как создание сетей или настройка групп и правил безопасности на шлюзах Management и Compute Gateways.

Вот небольшой обзор работы утилиты от ее автора Nico Vibert:

Также у него есть подробная статья об использовании этого средства для запуска задач в облачной среде. Список доступных команд Python Client for VMware Cloud on AWS доступен в инструкции.

Вот что нового появилось в версиях 1.2 и 1.1:

• Добавлен Dockerfile для построения Docker-образа, в котором будет запускаться PyVMC
• Добавлена видимость счетчиков исходящего (Egress) трафика
• Добавлена видимость таблицы маршрутизации
• Появилась поддержка L2VPN
• Появилась поддержка Nested Group
• Появилась поддержка распределенного сетевого экрана (Distributed Firewall)

Скачать Python Client for VMware Cloud on AWS 1.2 можно по этой ссылке.

На сайте virten.net, как обычно, вышла замечательная статья о реальной боли некоторых администраторов VMware vSphere - уменьшении дисков vCenter Server Appliance (vCSA). Так как vCSA работает в виртуальной машине, то иногда возникает необходимость в уменьшении ее дисков в целях простоты перемещения и компактности хранения. Но основная ситуация, когда диски vCSA чрезмерно разрастаются - это апгрейд сервера vCenter - в этом случае его хранилище может увеличиться до 1 ТБ при реально занятом пространстве в 100 ГБ. Тут уже без шринка (shrink) не обойтись.

При апгрейде vCSA установщик смотрит на аллоцированное пространство, а не на занятое, поэтому исходная машина в 416 ГБ может быть преобразована только в целевую ВМ типа Small с 480 ГБ диска:

Метод, описанный ниже, стоит применять только для виртуального модуля vCSA, который вы планируете апгрейдить, поскольку меняется порядок его дисков. Это, в целом, не проблема, но могут возникнуть сложности при взаимодействии с поддержкой VMware, которая может посчитать эту конфигурацию неприемлемой.

Перво-наперво нужно сделать бэкап вашего vCSA или его клон, с которым вы и будете работать. Если что-то не получится, вы просто сможете удалить клон.

Итак, заходим на vCSA по SSH и останавливаем все службы:

# service-control --stop --all

Выбираем файловую систему, для которой будем делать shrink. Например, /storage/seat имеет размер 296 ГБ, но реально используется 67 МБ! Запоминаем файловую систему (/dev/mapper/seat_vg-seat) и точку монтирования хранилища (/storage/seat), которое будем уменьшать.

Также из файловой системы вы можете получить Volume Group (seat_vg) и Logical Volume (seat):

# df -h
Filesystem                                Size  Used Avail Use% Mounted on
devtmpfs                                  4.9G     0  4.9G   0% /dev
tmpfs                                     4.9G  588K  4.9G   1% /dev/shm
tmpfs                                     4.9G  696K  4.9G   1% /run
tmpfs                                     4.9G     0  4.9G   0% /sys/fs/cgroup
/dev/sda3                                  11G  4.4G  5.7G  44% /
tmpfs                                     4.9G  1.6M  4.9G   1% /tmp
/dev/sda1                                 120M   34M   78M  31% /boot
/dev/mapper/core_vg-core                   25G   44M   24G   1% /storage/core
/dev/mapper/log_vg-log                    9.8G   72M  9.2G   1% /storage/log
/dev/mapper/db_vg-db                      9.8G  101M  9.1G   2% /storage/db
/dev/mapper/dblog_vg-dblog                 15G   86M   14G   1% /storage/dblog
/dev/mapper/seat_vg-seat                  296G   67M  283G   1% /storage/seat   <--- This is going to be shrinked
/dev/mapper/netdump_vg-netdump            985M  1.3M  916M   1% /storage/netdump
/dev/mapper/autodeploy_vg-autodeploy      9.8G   23M  9.2G   1% /storage/autodeploy
/dev/mapper/imagebuilder_vg-imagebuilder  9.8G   23M  9.2G   1% /storage/imagebuilder
/dev/mapper/updatemgr_vg-updatemgr         99G   75M   94G   1% /storage/updatemgr
/dev/mapper/archive_vg-archive             50G   64M   47G   1% /storage/archive

Размонтируем файловую систему:

# umount /storage/seat/

Проверяем ее:

# e2fsck -f /dev/mapper/seat_vg-seat

Теперь попробуем уменьшить размер этого раздела до 20 ГБ. У нас будет еще небольшой оверхед, поэтому сначала сожмем файловую систему до 18 ГБ:

resize2fs /dev/mapper/seat_vg-seat 18G

Теперь изменим логический том до чуть большего размера в 19 ГБ:

lvreduce -L 19G /dev/seat_vg/seat

Добавляем виртуальной машине диск в 20 ГБ:

Делаем рескан SCSI-шины:

# echo "- - -" > /sys/class/scsi_host/host2/scan

В данном случае используется хост-адаптер с ID=2. Для выяснения вашего ID используйте команду lsscsi. Не используйте скрипт rescan-scsi-bus.sh.

Запускаем dmesg для выяснения для идентификации созданного устройства (у нас это sdn):

# dmesg
[...]
[ 7649.086349] sd 2:0:14:0: Attached scsi generic sg17 type 0
[ 7649.087607] sd 2:0:14:0: [sdn] Attached SCSI disk

Инициализируем устройство для использования со стороны LVM:

# pvcreate /dev/sdn

Добавляем устройство в Volume Group, которую мы определили ранее (seat_vg):

# vgextend seat_vg /dev/sdn

Теперь у вас должно быть 2 устройства в группе seat_vg - sdh (старый большой диск) и sdn (новый уменьшенный):

# pvs |grep seat_vg
/dev/sdh seat_vg lvm2 a-- 299.99g 279.99g
/dev/sdn seat_vg lvm2 a-- 24.99g 24.99g

Перемещаем все физические экстенты с sdh на sdn:

# pvmove /dev/sdh /dev/sdn

Когда миграция будет закончена, sdh должен остаться пустым (Allocated PE = 0 и нет физических сегментов, только FREE):

# pvdisplay -m /dev/sdh
  --- Physical volume ---
  PV Name               /dev/sdh
  VG Name               seat_vg
  PV Size               300.00 GiB / not usable 7.00 MiB
  Allocatable           yes
  PE Size               8.00 MiB
  Total PE              38399
  Free PE               38399
  Allocated PE          0
  PV UUID               V7lkDg-Fxyr-qX4x-d3oi-KhNO-XZyT-EHgibI

  --- Physical Segments ---
  Physical extent 0 to 38398:
    FREE

Удаляем sdh из Volume Group:

# vgreduce seat_vg /dev/sdh

Удаляем LVM-метки из sdh:

# pvremove /dev/sdh

Запускаем скрипт autogrow.sh для расширения файловой системы к размеру виртуального диска:

/usr/lib/applmgmt/support/scripts/autogrow.sh

Последний шаг очень важен - удаляем старый диск. Не удалите не тот! Для этого проверяем SCSI ID с помощью lsscsi:

# lsscsi |grep sdh
[2:0:8:0] disk VMware Virtual disk 1.0 /dev/sdh

Мы видим, что SCSI ID [2:0:8:0] нам нужно удалить. Помните, что номер диска не всегда совпадает с SCSI ID. Удалите правильный диск (в данном случае 8), не ошибитесь!

Это все, теперь можно перезагрузить виртуальную машину, после чего в качестве опции апгрейда будет доступен вариант апгрейда на Tiny:

Если вы хотите уменьшить другие разделы, то идентифицируйте соответствующие параметры Logical Volume, Volume Group и Virtual Disk, после чего повторите процедуру.

Выясняем точки монтирования:

# df -h
Filesystem                                Size  Used Avail Use% Mounted on
devtmpfs                                  4.9G     0  4.9G   0% /dev
tmpfs                                     4.9G  588K  4.9G   1% /dev/shm
tmpfs                                     4.9G  696K  4.9G   1% /run
tmpfs                                     4.9G     0  4.9G   0% /sys/fs/cgroup
/dev/sda3                                  11G  4.4G  5.7G  44% /
tmpfs                                     4.9G  1.6M  4.9G   1% /tmp
/dev/sda1                                 120M   34M   78M  31% /boot
/dev/mapper/core_vg-core                   25G   44M   24G   1% /storage/core
/dev/mapper/log_vg-log                    9.8G   72M  9.2G   1% /storage/log
/dev/mapper/db_vg-db                      9.8G  101M  9.1G   2% /storage/db
/dev/mapper/dblog_vg-dblog                 15G   86M   14G   1% /storage/dblog
/dev/mapper/seat_vg-seat                  296G   67M  283G   1% /storage/seat
/dev/mapper/netdump_vg-netdump            985M  1.3M  916M   1% /storage/netdump
/dev/mapper/autodeploy_vg-autodeploy      9.8G   23M  9.2G   1% /storage/autodeploy
/dev/mapper/imagebuilder_vg-imagebuilder  9.8G   23M  9.2G   1% /storage/imagebuilder
/dev/mapper/updatemgr_vg-updatemgr         99G   75M   94G   1% /storage/updatemgr
/dev/mapper/archive_vg-archive             50G   64M   47G   1% /storage/archive

Выясняем SCSI ID и имя устройства:

# lsscsi
[0:0:0:0]    cd/dvd  NECVMWar VMware IDE CDR00 1.00  /dev/sr0
[2:0:0:0]    disk    VMware   Virtual disk     1.0   /dev/sda
[2:0:1:0]    disk    VMware   Virtual disk     1.0   /dev/sdb
[2:0:2:0]    disk    VMware   Virtual disk     1.0   /dev/sdc
[2:0:3:0]    disk    VMware   Virtual disk     1.0   /dev/sdd
[2:0:4:0]    disk    VMware   Virtual disk     1.0   /dev/sde
[2:0:5:0]    disk    VMware   Virtual disk     1.0   /dev/sdf
[2:0:6:0]    disk    VMware   Virtual disk     1.0   /dev/sdg
[2:0:8:0]    disk    VMware   Virtual disk     1.0   /dev/sdh
[2:0:9:0]    disk    VMware   Virtual disk     1.0   /dev/sdi
[2:0:10:0]   disk    VMware   Virtual disk     1.0   /dev/sdj
[2:0:11:0]   disk    VMware   Virtual disk     1.0   /dev/sdk
[2:0:12:0]   disk    VMware   Virtual disk     1.0   /dev/sdl
[2:0:13:0]   disk    VMware   Virtual disk     1.0   /dev/sdm

Выводим Logical Volumes:

# lvs
  LV           VG              Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  archive      archive_vg      -wi-ao----   49.99g
  autodeploy   autodeploy_vg   -wi-ao----    9.99g
  core         core_vg         -wi-ao----   24.99g
  db           db_vg           -wi-ao----    9.99g
  dblog        dblog_vg        -wi-ao----   14.99g
  imagebuilder imagebuilder_vg -wi-ao----    9.99g
  log          log_vg          -wi-ao----    9.99g
  netdump      netdump_vg      -wi-ao---- 1016.00m
  seat         seat_vg         -wi-ao----   20.00g
  swap1        swap_vg         -wi-ao----   24.99g
  updatemgr    updatemgr_vg    -wi-ao----   99.99g

Выводим Volume Groups:

# vgs
  VG              #PV #LV #SN Attr   VSize    VFree
  archive_vg        1   1   0 wz--n-   49.99g      0
  autodeploy_vg     1   1   0 wz--n-    9.99g      0
  core_vg           1   1   0 wz--n-   24.99g      0
  db_vg             1   1   0 wz--n-    9.99g      0
  dblog_vg          1   1   0 wz--n-   14.99g      0
  imagebuilder_vg   1   1   0 wz--n-    9.99g      0
  log_vg            1   1   0 wz--n-    9.99g      0
  netdump_vg        1   1   0 wz--n- 1016.00m      0
  seat_vg           1   1   0 wz--n-  299.99g 279.99g  <--- THIS
  swap_vg           1   1   0 wz--n-   24.99g      0
  updatemgr_vg      1   1   0 wz--n-   99.99g      0

Выводим диски и их Volume Group:

# pvs
  PV         VG              Fmt  Attr PSize    PFree
  /dev/sdc   swap_vg         lvm2 a--    24.99g      0
  /dev/sdd   core_vg         lvm2 a--    24.99g      0
  /dev/sde   log_vg          lvm2 a--     9.99g      0
  /dev/sdf   db_vg           lvm2 a--     9.99g      0
  /dev/sdg   dblog_vg        lvm2 a--    14.99g      0
  /dev/sdh   seat_vg         lvm2 a--   299.99g 279.99g
  /dev/sdi   netdump_vg      lvm2 a--  1016.00m      0
  /dev/sdj   autodeploy_vg   lvm2 a--     9.99g      0
  /dev/sdk   imagebuilder_vg lvm2 a--     9.99g      0
  /dev/sdl   updatemgr_vg    lvm2 a--    99.99g      0
  /dev/sdm   archive_vg      lvm2 a--    49.99g      0

Находим все диски в нашей Volume Group:

# pvs |grep seat_vg
  /dev/sdh   seat_vg         lvm2 a--   299.99g 279.99g
  /dev/sdn   seat_vg         lvm2 a--    24.99g  24.99g

Выводим информацию об LVM с точки зрения диска:

# pvdisplay -m /dev/sdh
  --- Physical volume ---
  PV Name               /dev/sdh
  VG Name               seat_vg
  PV Size               300.00 GiB / not usable 7.00 MiB
  Allocatable           yes
  PE Size               8.00 MiB
  Total PE              38399
  Free PE               35839
  Allocated PE          2560
  PV UUID               V7lkDg-Fxyr-qX4x-d3oi-KhNO-XZyT-EHgibI

  --- Physical Segments ---
  Physical extent 0 to 2559:
    Logical volume      /dev/seat_vg/seat
    Logical extents     0 to 2559
  Physical extent 2560 to 38398:
    FREE

На сайте проекта VMware Labs появилась новая штука - утилита Desktop Container Tools. Она позволяет использовать графический интерфейс управления для vctl (работает как сниппет для VMware Fusion) для контейнерного движка на macOS, где работают кластеры Kubernetes.

Возможности Desktop Container Tools:

• Простое управление движком контейнеров vctl через графический интерфейс и тач-бар. Можно настроить виртуальные машины для использования контейнеров без интерфейса командной строки.
• Поддержка нескольких языков (пока только английский и китайский).
• Полностью бесплатная утилита и, к тому же, легковесная (36 килобайт).

Скачать Desktop Container Tools можно по этой ссылке. Работает на Intel-маках с macOS Catalina или Big Sur. Рекомендуется использовать VMware Fusion 12.1.0 с поддержкой Kubernetes.

Компания VMware опубликовала полезный FAQ, ссылка на который может в любой момент понадобиться администратору VMware vSphere для понимания различных аспектов системного хранилища серверов VMware ESXi.

Давайте посмотрим, на какие вопросы там можно найти ответы:

• Что изменилось в системном хранилище ESXi 7 по сравнению с прошлыми версиями? Мы об этом подробно писали тут.
• Что случится с разметкой системного хранилища при апгрейде на vSphere 7? Ответ тут и на этой картинке:

• Какое хранилище рекомендуется в качестве системного для ESXi?
• Что насчет устройств USB/SD? Можно ли использовать SD-карту для системного хранилища? (Спойлер: лучше не надо).
• Почему вы можете увидеть ситуацию, что хосты ESXi в "Degraded Mode"?
• Что вообще означает Degraded Mode?
• Можно ли добавлять локальное хранилище после апгрейда на ESXi 7? (Спойлер: да)
• Что делать, если хост в Degraded Mode, а хранилища вообще не видно? (Спойлер: смотреть External Syslog, NetDump Collector или Core Dump Partition)
• Если вы используете vSphere AutoDeploy, то как работает развертывание системного хранилища? Подробнее об этом вот тут

На днях компания VMware выпустила обновление виртуального модуля Horizon Cloud Connector 1.9, который позволяет соединить ваш Horizon Connection Server с облачным средством управления VMware Horizon Control Plane для создания гибридной среды виртуализации и доставки настольных ПК и приложений. О том, что нового было в прошлом релизе, можно почитать вот тут.

1. Улучшения интерфейса конфигурации сети

Раньше для настройки возможности автоматического обновления администраторам приходилось указывать все параметры сети (DNS, gateway, маску и IP). Теперь же нужно указать статический IP, который будет временно использован для обновления виртуального модуля. Все остальные параметры подтянутся автоматически из конфигурации Virtual Appliance.

2. Улучшения SSH

Доступ по SSH теперь отключен для пользователей root. Теперь для доступа по SSH есть специальный пользователь "ccadmin". Ему уже можно дать возможность повышения привилегий после логина. Поддерживается аутентификация как по ключу, так и по паре логин-пароль, но лучше использовать первый способ.

Ну и, пользуясь случаем, приведем ссылки на полезные статьи серии "Horizon Cloud Connector Know-How Series":

• Horizon Cloud Connector Know-How Series
• Onboarding Horizon Cloud Connector
• Auto-Upgrade
• Troubleshooting Horizon Universal License Status

Скачать Horizon Cloud Connector 1.9 можно по этой ссылке.

Это статья нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего в аренду виртуальные машины из облака по модели IaaS.

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

В традиционной физической вычислительной среде ПО, такое как операционные системы или корпоративные приложения, имеет прямой доступ к базовому компьютерному оборудованию и компонентам, включая процессор, память, хранилище, некоторые чипсеты драйверы ОС. Ранее это создавало серьезные проблемы в настройке программного обеспечения, а также существенно затрудняло перемещение или переустановку приложений на другое оборудование — например при восстановлении из резервных копий после аварии.

Об истоках виртуализации

Термин «виртуализация» был придуман в конце 1960-х - начале 1970-х годов в ходе исследовательских проектов IBM и MIT в области совместного использования вычислительных ресурсов группами пользователей. Подробнее об этом вы можете почитать в нашем блоге на Хабре: [ССЫЛКИ на IBM/360 и истоки виртуализации].

В настоящее время виртуализация широко распространена в ИТ. В сфере облачных сервисов лидируют продукты компаний VMware, Microsoft, Citrix и Oracle.

Как работает аппаратная виртуализация

Процесс аппаратной виртуализации включает в себя установку гипервизора или диспетчера виртуальных машин (VMM). Именно они создают уровень абстракции между программным обеспечением и непосредственным «железом». После установки гипервизора программное обеспечение полагается на виртуальные представления вычислительных компонентов — то есть, к примеру, на виртуальные CPU вместо физических. К наиболее популярным гипервизорам можно отнести решения VMware vSphere на основе ESXi и Microsoft Hyper-V.

Виртуализированные вычислительные ресурсы объединяются в изолированные «группы», называемые виртуальными машинами (ВМ). На подготовленную ВМ можно установить операционную системы, а затем требуемые приложения. Виртуализированные системы могут иметь сразу несколько виртуальных машин одновременно, при этом каждая виртуальная машина логически изолирована от своих «соседей». Таким образом, если одна из ВМ подвергнется атаке вируса, будет перегружена или взломана, это никак не скажется на других машинах внутри системы.

Виртуализация позволяет бизнесу сократить издержки, связанные с приобретением серверного оборудования. К примеру, вместо покупки 10 разных серверов для размещения 10 приложений, каждому из которых для работы требуется отдельная ОС, достаточно построить виртуализированную систему, которая будет содержать требуемое количество ВМ, в рамках всего одного достаточно мощного сервера.

Традиционная архитектура в сравнении с виртуальной
https://searchservervirtualization.techtarget.com/definition/hardware-virtualization

Поскольку гипервизор устанавливается непосредственно на сервер, а операционные системы и ПО добавляются позже, такой подход часто называют виртуализацией «на голом железе». В последние годы гипервизоры стали самостоятельными узко заточенными ОС. Есть и альтернативный подход, работающий в случае, если вы не можете/не желаете работать с «голым железом» — сперва устанавливается главная операционная система, а уже в ней разворачивается гипервизор и все ВМ. Этот метод часто называют виртуализацией с хост-системой. Сейчас он чаще всего используется для виртуализации контейнеров.

Типы аппаратной виртуализации

Существует несколько типов аппаратной виртуализации. Среди них — полная виртуализация, паравиртуализация и виртуализация с аппаратной поддержкой. Кратко поговорим о каждом из них.

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

Паравиртуализацией называется подход, при котором на ВМ запускается особым образом подготовленная (измененная и/или перекомпилированная) версия гостевой ОС. Иными словами, системные администраторы должны соблюдать исходные требования ОС к железу лишь частично.

Виртуализация с аппаратной поддержкой использует аппаратное обеспечение компьютера в качестве «архитектурной поддержки» для создания полностью виртуализированной ВМ и управления ею. Виртуализация с аппаратной поддержкой была впервые представлена ??IBM в 1972 году с IBM System / 370. Виртуализация с аппаратной поддержкой на сегодняшний день является наиболее распространенной формой виртуализации.

Технология виртуализации дала жизнь популярным сейчас облачным сервисам, таким как:

• виртуальные VDS/VPS-серверы;
• IaaS, инфраструктура как услуга;
• терминальные серверы в облаке;
• VDI, виртуальная инфраструктура рабочих столов;
• cloud gaming и многим другим.

Компания VMware выпустила обновление средства vRealize Network Insight 6.1. Напомним, что оно предназначено для мониторинга и защиты сетевой инфраструктуры виртуальной среды на уровне приложений. О прошлой версии vRNI 6.0 мы писали вот тут.

Давайте посмотрим, что нового в vRNI 6.1:

Функции Network Assurance and Verification

• Для определения несоответствия native VLAN и native VLAN tagging были добавлены цели (Intents)
• Поддержка сетевого экрана Supports Palo Alto Networks (PAN) Firewall в представлении Network Map
• Поддержка устройств Juniper в Network Map через утилиту Netconf (SSH не требуется)
• Улучшения юзабилити (поиск путей, включая данные о конфигурации)

Аналитика на базе целей (Intent based analytics) - поддержка Link Metering для VMware SD-WAN

• Создание цели для отслеживания использования канала (bandwidth) на соединениях (LTE/MPLS), которые находятся на обслуживании у сервис-провайдеров
• Проактивные алерты помогают избежать дополнительных затрат за использование канала при превышении лимита провайдера
• Поддержка возможности оптимизации или экономии полосы канала по этим соединениям

Intent based analytics для мониторинга использования Edge Uplink

• Возможность создания целей для мониторинга использования аплинков на VMware SD-WAN Edges, для того чтобы оптимизировать использования канала, отслеживать проблемы и планировать увеличение емкостей каналов
• Поддержка возможности выбора типа аплинка для генерации алертов и нотификаций

Сервисная информация Layer 7 от движка NSX Intelligence

• Возможность получить видимость на уровне 7, когда включен движок NSX Intelligence через NSX-T Manager
• Улучшенные дэшборды, включая VM, Hosts и Application - там теперь есть информация на уровне 7 OSI

Мониторинг и траблшутинг NSX-T

• Алерты можно фильтровать на базе сущностей и конфигураций
• Графики метрик для визуализации взаимодействия
• Метрики для объектов NSX-T теперь показываются на странице NSX-T Manager Topology
• Для маскирования правил сетевого экрана были добавлены события
• Метрика Flow retransmit count поменялась на flow retransmit percentage

Функции VMware Cloud on AWS (VMC on AWS)

• Поддержка статистик VMC T0 Router Interface, включая Rx Total Bytes, Rx Total Packets, Rx Dropped Packets, Tx Total Bytes, Tx Total Packets и Tx Dropped Packets для соединений Public, Cross-VPC и Direct Connect

Мониторинг и траблшутинг физических устройств

• Графики метрик для визуализации взаимодействия

Функции поиска

• Альтернативные предложения запросов, когда ничего не найдено

Pinboard

• При прикреплении нового фильтра состояние фильтра сохраняется
• Возможность прикреплять пустые результаты поиска (могут стать непустыми потом)
• Возможность видеть другие пинборды под пользователем с ролью Auditor

Алерты

• Определения алертов (раньше это были события) теперь классифицированы по категориям и по-разному организованы в интерфейсе для упрощения управления ими
• Определение алерта используется для отсылки к проблеме или изменения условия срабатывания

Улучшения платформы

• Поддержка веб-прокси для data sources (SD-WAN, AWS, Azure, ServiceNow, VMC NSX Manager)
• Показ информации о машинах Platform и Collector на одной странице (IP, активность, статус и т.п.)
• Возможность добавления и обновления data sources
• Страница информации обо всех Web Proxies, а также использования ими ресурсов
• Страница Infrastructure and Support

Прочие улучшения

• VMware vRealize Network Insight Cloud доступен в Австралии
• vRealize Suite Lifecycle Manager 8.2 Product Support Pack 1 поддерживает установку vRealize Network Insight 6.1

Скачать VMware vRealize Network Insight 6.1 можно по этой ссылке. Release Notes доступны тут.

Многие администраторы VMware vSAN задаются вопросом - а сколько прослужат диски в кластере хранилищ? Сегодня для vSAN уже имеет смысл использовать только SSD-диски, так как их стоимость уже вполне стала приемлемой для построения All-Flash хранилищ.

Как известно, в кластере vSAN есть 2 типа дисков - Cache (кэширование данных перед записью на постоянное хранение) и Capacity (постоянное хранилище). В первом случае, конечно же, использование ресурса диска идет в разы быстрее, чем для Capacity Tier.

Florian Grehl в своем блоге провел замер использования дисков обоих ярусов в плане записанных гигабайт в сутки в тестовой лаборатории. Вы сами сможете сделать это с помощью его PowerCLI-сценария, а также визуализовав данные в Graphite.

У него получилась вот такая картина:

В день у него получилось:

• 300 ГБ на диски Caching tier
• 20 ГБ на диски Capacity tier

Надо понимать, что объем записанных данных на каждый диск зависит от числа дисков в группе, а также развернутого типа RAID и политики FTT.

Когда вы покупаете SSD-диск, гарантия на него идет как на машину: время (обычно 5 лет), либо пробег (а в случае с диском это "TBW" = Terabytes Written, то есть записанный объем в ТБ) - в зависимости от того, что наступит раньше.

Как правило, для Capacity tier ресурс TBW за 5 лет на практике выработать не получится, а вот для Caching tier неплохо бы этот параметр замерить и сопоставить с характеристиками дисков. Например, 300 ГБ в день дает 535 ТБ за 5 лет.

Ну а вот параметры TBW, например, для устройств Samsung:

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

Интересно, что продукты VMware vSphere и VMware vSAN имеют разные списки совместимости оборудования (HCL - Hardware Compatibility Lists). Ronald de Jong в своем блоге описал ситуацию, когда у него драйвер SCSI-контроллера подошел для vSphere, но не подошел для vSAN.

После установки обновления драйвера для VMware vSphere через VMware Lifecycle Manager он получил вот такие ворнинги для vSAN в vSphere Client:

Драйвер smartpqi (70.4000.0.100-4vmw.701.0.0.17325551) уже подходит для vSphere, но еще не провалидирован для решения vSAN. В этом можно убедиться в списке совместимости для vSAN по этой ссылке, где есть только старый драйвер (3vmw):

Если же заглянуть в список совместимости для vSphere, то там будет обозначена поддержка старого и нового драйверов:

Таким образом, нужно провести даунгрейд драйвера, чтобы он подходил и для vSphere, и для vSAN. Сначала идем на Patch Portal и находим там нужное обновление в виде VIB-пакета:

Вот этот драйвер:

После загрузки в консоли ESXi запускаем установщик VIB-пакета командой:

esxcli software vib install -d /vmfs/volumes/vsanDatastore/tmp/VMware-ESXi-7.0U1-16850804-depot.zip -n=smartpqi

После этого все ворнинги по совместимости драйвера исчезнут:

Но в Lifecycle Manager все еще будут висеть предупреждения о необходимости поставить последнюю версию драйвера и проапдейтить ESXi:

Некоторое время назад мы писали об улучшении технологии горячей миграции vMotion (тут и тут) в последней версии VMware vSphere 7 Update 1. Сегодня мы вкратце расскажем о вариантах переноса рабочих нагрузок в кластер хранилищ VMware vSAN на базе вот этой заметки.

Первое, что вы должны решить - это в каком рабочем процессе вы будете мигрировать виртуальные машины с помощью vMotion: за один шаг (хранилище+сервер) или за два (сначала сервер, потом хранилище).

1. Миграция в два шага (Two-Step Migrations)

При выборе миграции виртуальной машины у нас есть опция изменения либо сервера ESXi машины, либо ее хранилища, либо и того, и другого:

• Change compute resource only - это первый шаг миграции для случая, когда не-vSAN хранилище может быть презентовано существующему кластеру vSAN. Также это может быть востребовано в рамках топологии VMware vSAN HCI Mesh, где хранилище монтируется удаленному кластеру vSAN.
• Change storage only - это второй шаг миграции, когда машина на хосте ESXi уже находится в кластере vSAN, и мы выполняем перенос ее VMDK уже на собственные хранилища кластера.

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

2. Миграция в один шаг

Этот способ миграции реализуется, когда вы выбираете опцию Change both compute resource and storage или Cross vCenter Server export. Надо понимать, что процесс этот весьма затратный, и выбирать этот вариант можно, когда у вас есть большой запас по ресурсам и времени для вычислительных ресурсов и ресурсов хранилищ. Ну или когда вы не можете расшарить хранилище между двумя разными кластерами vSphere / vSAN.

Удобство это способа еще и в том, что если у вас есть много времени на миграцию, то можно просто поставить vMotion для нужных нагрузок, и все будет постепенно переезжать без участия администратора.

Также для переноса нагрузок между разными инфраструктурами есть опция Cross vCenter Server export. В обновлении VMware vSphere 7 Update 1c главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.

Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.

Если вы решили сделать пакетную миграцию виртуальных машин в vSphere Client, то нужно для кластера или пула ресурсов перейти на вкладку VMs и с шифтом выбрать группу ВМ для миграции, после чего из контекстного меню выбрать Migrate...:

Надо сказать, что машины одной группы можно мигрировать только в одинаковом состоянии (Powered on или Powered off), поэтому удобно отсортировать их по колонке State.

Ну и в заключение - картинка об улучшении технологии vMotion с момента ее появления в 2003 году:

На сайте проекта VMware Labs обновились четыре полезные утилиты, про которые мы уже не раз писали. Давайте посмотрим, что именно в них появилось нового:

1. VMware OS Optimization Tool билд b2001

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

Что появилось нового:

• Все записи оптимизаций снова добавили в шаблон main user template, теперь можно их тюнинговать вручную.
• Исправлены два параметра аппаратных оптимизаций и ускорения, которые ранее настраивались в одной опции.
• Во время фазы Optimize оптимизации экспортируются в файл json (%ProgramData%\VMware\OSOT\OptimizedTemplateData.json).
• Во время фазы Analyze, если дефолтный файл json существует (то есть образ уже оптимизирован), то он импортируется и используется при выборе оптимизаций с прошлым выбором параметров. Также если выбор дефолтных состояний обязателен, то перед каждым запуском утилиты нужно удалять этот файл.
• Файл OptimizedTemplateData.json можно использовать в командной строке с параметром -applyoptimization.
• Улучшена работа с параметрами для служб Hyper-V, которые требуются для облачного сервиса Azure.

Скачать VMware OS Optimization Tool можно по этой ссылке.

2. vSphere Software Asset Management Tool версии 1.3

Напомним, что Software Asset Management Tool предназначен для сбора подробной информации об инсталляции VMware vSphere на вашей площадке, касающуюся лицензирования - инвентаря и доступности лицензий.

О прошлой версии этой утилиты мы писали вот тут, а вот что появилось нового в версии 1.3:

• Отображение продуктов семейства Tanzu в генерируемых отчетах
• Несколько исправлений ошибок

Скачать Software Asset Management Tool 1.3 можно по этой ссылке.

3. DRS Dump Insight версии 2.0

Напомним, что о прошлой версии Dump Insight 1.1 мы писали здесь. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. 

Давайте посмотрим, что появилось нового:

• Добавлена поддержка дампов vSphere 7.0 и 7.0 Update 1
• Доступен выбор нескольких отдельных дампов для анализа из общего списка
• Исправления ошибок и доработки бэкенда

Скачать DRS Dump Insight можно здесь.

4. Workspace ONE Discovery версии 1.1

Об этой утилите мы писали вот тут. Она позволяет показывать различную информацию об оконечных устройствах на рабочих станциях (Certificate Management, Application Deployment, Profile Management).

Что появилось нового:

• Обновлена иконка приложения
• Появился мониторинг компонентов VMware Horizon Client, VMware Digital Experience Telemetry и VMware Hub Health services

Скачать Workspace ONE Discovery 1.1 можно по этой ссылке.

Компания VMware обновила свое руководство для быстрого старта с инфраструктурой виртуализации настольных ПК и приложений - Quick-Start Tutorial for VMware Horizon 8. Это один из самых популярных материалов на VMware TechZone на сегодняшний день, он позволяет начинающим администраторам VMware vSphere и Horizon развернуть тестовую VDI-среду в своей компании за пару часов.

VMware проделала значительную работу по оптимизации руководства, и теперь его объем сокращен с 222 страниц (для Horizon 7) до 63 страниц (Horizon 8). Все это позволяет быстро начать развертывание решения, а уже потом постигать детали.

То, что вы будете делать, в рамках прочтения руководства и развертывания продукта, будет выглядеть так:

Основные фазы будут следующего содержания:

• Install - начнете с установки Horizon Connection Server, который управляет сессиями пользователей для десктопов и приложений на базе веб-консоли Horizon Administrative Console.
• Prep - с использованием vSphere Client вы создадите образы Windows-десктопов, а также сервера RDSH для виртуализованных приложений. Кроме того, вы поставите Horizon Agent в гостевые ОС.
• Configure - создадите пул виртуальных ПК и ферму серверов с виртуализованными приложениями, а также назначите для них права доступа.
• Output - из iOS, Android, Chromebook, Windows, macOS или Linux подключитесь к виртуальным ПК, загрузив соответствующую версию Horizon Client или зайдя через браузер (HTML Access web client).

После выполнения всех описанных задач вы получите готовую инфраструктуру Horizon с несколькими опубликованными приложениями (на базе сервисов Microsoft Remote Desktop Session Host, RDSH), а также пул виртуальных десктопов на базе Windows 10.

Руководство Quick-Start Tutorial for VMware Horizon 8 доступно по этой ссылке.

Недавно компания VMware полностью переработала портал документации для разработчиков. Там произошел редизайн интерфейса, была улучшена категоризация, а также юзабилити в целом. При этом ранее документация по PowerCLI существовала отдельно от этого портала.

Теперь домашняя страница VMware PowerCLI полностью интегрирована в портал документации, а также получила много новых фич. Давайте на них взглянем:

1. Компоновка домашней страницы

Теперь с нее вы можете перейти на:

• Сообщество разработчиков
• Пример репозитория на GitHub
• Фиче-реквесты
• Блог PowerCLI
• Release notes
• Сhangelog
• Руководство пользователя

То есть это теперь простая и удобная, но функциональная стартовая страница.

2. Организация командлетов по продуктам

Ранее все командлеты были организованы по модулям, что было неудобно для пользователей. Теперь стало намного удобнее, потому что можно проваливаться в каталог командлетов по продуктам:

3. Глобальный поиск

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

4. Вкладка структуры данных

Разделы помощи ориентированы на объекты PowerCLI. Теперь на отдельной вкладке Data Structure можно увидеть, как эти объекты обрабатываются со стороны командлетов.

5. Категории

В рамках разделов по продуктам можно искать командлеты по понятным категориям из меню слева:

6. Страница CMDLET Reference

Эта страница позволяет понять как устроен командлет, и как он используется. Работает подсветка кода, и приведены простые примеры использования, которые вы можете скачать и уже самостоятельно изменять для получения наглядного результата. Вот пример такой страницы для командлета Connect-VIServer.

В общем - пользуйтесь.

Если вы хотели бы узнать, какие продукты есть у VMware, кроме тех, что у всех на слуху (вроде vSphere, vSAN и Horizon), то мы можем порекомендовать отличный документ - "VMware Product Guide". Там на ста страницах говорится обо всех продуктах, актуальных на декабрь 2020 года. Основная цель этого документа - рассказать об условиях использования и лицензирования, но из общей таблицы вы узнаете, что вообще есть в портфолио у VMware:

Ну а для тех, кто хочет увидеть весь список сразу со всеми ссылками на продукты, vCendra опубликовала вот такой интересный слайд от Ezzeldin Hussein, на котором можно увидеть все доступное на сегодня портфолио решений (кликабельно):

Скачать слайд в формате PPTX можно по этой ссылке.

Не все администраторы VMware vSphere и vSAN знают, что в версии vSAN 6.7 Update 3 появилась утилита vsantop, которая по аналогии с esxtop, используемой для получения метрик с хостов ESXi, позволяет получать метрики с устройств и хранилищ vSAN.

Запускается утилита просто: vsantop

По умолчанию она отображает метрики для сущности host-domclient. Чтобы выбрать нужную вам сущность - устройства, хост или кластер, нужно нажать большую клавишу <E> с шифтом:

После того, как вы выберете нужную сущность, будут отображаться метрики для нее с дефолтными колонками в данной категории. Чтобы выбрать колонки, нужно нажать клавишу <f>:

Для отображения можно выбрать только 10 полей, если хотите добавить какое-то поле, то какое-то из текущих придется убрать.

Также esxtop может работать в пакетном режиме с заданным интервалом и записывать метрики в CSV-файл:

vsantop -b -d [delay] -n [iterations] > [file location & name]

usage: vsantop [-h] [-v] [-b] [-d delay] [-n iterations]
    -h prints this help menu.
    -v prints version.
    -b enables batch mode.
    -d sets the delay between updates in seconds.
    -n runs vsantop for only n iterations. Use "-n infinity" to run forever.

Например, вот такая команда запустит сбор метрик с 10-секундным интервалом, всего будет 20 таких итераций, а результаты будут записаны в файл CSV:

vsantop -b -d 10 -n 20 > /vmfs/volumes/vsanDatastore/vsantop/result.csv

VMware выпустила 2 новых экзамена VMware Certified Advanced Professional (VCAP)

На днях компания VMware объявила о релизе обновленных версий экзаменов VMware Certified Advanced Professional (VCAP). Первый - Advanced Design VMware vSphere 7.x (3V0-21.21) - подтверждает знание кандидатами принципов разработки концептуальной архитектуры VMware vSphere 7.x с учетом требований заказчика, возможность определения функциональных и нефункциональных требований для создания логического дизайна инфраструктуры, а также создания физической архитектуры с учетом всего этого.

Этот экзамен ведет к сертификации VMware Certified Advanced Professional – Data Center Virtualization Design 2021:

Экзамен содержит 60 вопросов и заданий, 300 очков проходной балл и 150 минут на сдачу. Описание экзамена (Blueprint) находится вот тут.

Второй выпущенный экзамен - это  Advanced Deploy VMware vSphere 7.x (3V0-22.21). Он проверяет знания по планированию и развертыванию решения vSphere 7.x, включая задачи по администрированию, оптимизации и траблшутингу. Тут уже больше про Day-2 Operations.

Экзамен требуется для сертификации VMware Certified Advanced Professional – Data Center Virtualization 2021 Deploy:

Здесь уже 17 заданий на базе лабораторных работ, 300 очков проходной балл и 205 минут на сдачу. Руководство по экзамену доступно тут.

Многие администраторы решения для создания отказоустойчивых хранилищ VMware vSAN иногда задумываются, чем отличаются политики хранилищ виртуальных машин (Storage Policies) для растянутых кластеров в плане Disaster Tolerance.

Дункан Эппинг написал об этом полезную заметку. Если вы не хотите, чтобы ваша виртуальная машина участвовала в растянутом кластере, то вам следует выбрать один из двух вариантов для настройки Site Disaster Tolerance: хранить все данные на основном сайте или все на резервном:

• None – Keep data on preferred (stretched cluster)
• None – Keep data on non-preferred (stretched cluster)

Между тем, в интерфейсе есть несколько схожих вариантов:

Например, есть еще два, казалось бы, подходящих:

• None – Stretched Cluster
• None – Standard Cluster

Но оба этих варианта политик хранилищ для растянутых кластеров не подходят. В первом случае (None – Stretched Cluster) виртуальная машина будет обрабатываться на уровне дисковых объектов, и vSAN будет решать, куда их поместить в растянутом кластере. Вполне может получиться такая ситуация, что один VMDK находится на одной площадке, а второй - на другой. При этом сама машина же может исполняться только на одном ESXi:

Такая ситуация очевидно очень плоха с точки зрения производительности.

Во втором же случае (None – Standard Cluster), если ваша машина настроена с точки зрения хранилищ на RAID-1 и FTT=1, то в растянутом кластере это превращается в SFTT=0 (Stretched FTT), что означает, что данные с одной площадки будут зеркалироваться на другую, но на уровне одной площадки будет храниться только одна копия данных дисковых объектов, что плохо с точки зрения надежности и отказоустойчивости.

Поэтому в растянутых кластерах для машин, которым не нужна "растянутость", используйте настройки Keep data on preferred или Keep data on non-preferred.

Решение для виртуализации сетей VMware NSX-T, в отличие от его vSphere-версии NSX-V, не имеет графического интерфейса для настройки отсылки логов на серверы Syslog.

Graham Smith написал краткую заметку о настройке Syslog для решения VMware NSX-T, включая NSX-T Manager, узлы Edge Nodes и серверы ESXi.

Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware Log Insight. Сначала заходим по SSH на NSX-T Manager и выполняем там следующую команду, указав IP-адрес сервера Log Insight:

MulNSXT01> set logging-server 192.168.10.8 proto udp level info 
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На узлах Edge Nodes также нужно выполнить такую же команду, зайдя по SSH:

DCA-MulNSXT-ESG01> set logging-server 192.168.10.8 proto udp level info
        WARNING - You are configuring udp-based log forwarding. This will send sensitive information unencrypted over the network. The Splunk App for NSX-T only accepts TLS connections.

На серверах ESXi процесс выглядит несколько иначе. Нужно выполнить вот такую последовательность команд:

[root@DCA-MulComp01:~] esxcli network firewall ruleset set -r syslog -e true
[root@DCA-MulComp01:~] esxcli system syslog config set --loghost=udp://192.168.10.8:514
[root@DCA-MulComp01:~] esxcli system syslog reload
[root@DCA-MulComp01:~] esxcli system syslog mark -s "This is a test message"

Первая команда разрешает в фаерволе трафик Syslog, вторая - настраивает сервер адрес сервера, третья - подхватывает настройки, ну а четвертая - отсылает тестовое сообщение, чтобы можно было проверить работоспособность механизма Syslog со стороны Log Insight.

Там это тестовое сообщение можно увидеть в разделе Events:

Чтобы проверить логирование на стороне фаервола, можно создать простое правило с тестовым тэгом:

Далее в Log Insight можно увидеть это событие, поискав по этому тегу:

Чтобы проверить конфигурацию Syslog на стороне сервера ESXi, нужно выполнить следующую команду:

[root@DCA-MulComp01:~] esxcli system syslog config get
   Check Certificate Revocation: false
   Default Network Retry Timeout: 180
   Dropped Log File Rotation Size: 100
   Dropped Log File Rotations: 10
   Enforce SSLCertificates: true
   Local Log Output: /scratch/log
   Local Log Output Is Configured: false
   Local Log Output Is Persistent: true
   Local Logging Default Rotation Size: 1024
   Local Logging Default Rotations: 8
   Log To Unique Subdirectory: false
   Message Queue Drop Mark: 90
   Remote Host: udp://192.168.10.8:514
   Strict X509Compliance: false

На стороне NSX-T Manager и на узлах Edge Nodes конфигурацию Syslog можно проверить такой командой:

DCA-MulNSXT-ESG01> get logging-servers 
Mon Dec 28 2020 UTC 17:37:16.600
192.168.10.8:514 proto udp level info

Если вы когда-нибудь изучали вопрос, почему дискета в 1.44 МБ дает на самом деле 1.38 МБ дискового пространства, то знаете, что это происходит потому, что мегабайт производителей дискет равен 1024х1000 байт. Поэтому дискета на «1,44 Мб» на самом деле имеет ёмкость в 1,44х1024х1000 байт = 1440 Кб или 1.38 Мб (где 1 Мб = 1024х1024 байт). Подробнее об этом вы можете прочитать вот тут.

"Неправильные" килобайты и мегабайты используют префиксы системы СИ (кило, мега, гига), что сложилось исторически, но неверно по сути. "Правильные" (бинарные) килобайты, мегабайты и гигабайты называются кибибайтами, мебибайтами и гибибайтами, соответственно - эти префиксы определены стандартом IEC. При написании они выглядят как KiB, MiB, GiB, TiB и т.д.

Из-за путаницы (или сознательного преуменьшения) производителей систем хранения данных и операционных систем на сегодняшний день иногда трудно понять, какой объем дискового пространства доступен в байтах и не является ли 1 ТБ емкости на самом деле 931 гигабайтом. Например, Microsoft по-прежнему использует систему СИ для отображения мегабайтов/гигабайтов.

VMware приступила к прояснению этого вопроса, начав со своей облачной инфраструктуры VMware Cloud on AWS. Теперь для отображения доступной емкости в консоли используется бинарная нотация IEC:

В данном случае емкость равно 20.74 тебибайта, что в байтах равняется:

1 TiB = 1 024 GiB = 1 048 576 MiB = 1 073 741 824 KiB = 1 099 511 627 776 байтов

Эту же цифру мы будем видеть и во всех разделах, касающихся хранилищ:

Интересно, сервер VMware vCenter и управляющий клиент vSphere Client будут показывать обозначения в системе СИ:

Но! Вычисляться все эти значения будут по системе IEC, то есть:

1 TB = 1 024 GB = 1 048 576 MB = 1 073 741 824 KB = 1 099 511 627 776 байтов

Это не изменяли в vCenter, чтобы не вводить пользователей в заблуждение - ведь гостевые ОС отображают данные о емкости в системе СИ. Но имейте в виду, что из-за этого вы можете видеть разные емкости внутри и снаружи ОС при отображении общего и свободного пространства.