Давайте для начала разберёмся с терминологией. Что такое роли NSX-менеджера? Роли NSX-менеджера позволяют управлять правами доступа к объектам NSX с помощью присвоения той или иной роли отдельному пользователю или группе. В UI эти настройки находятся в Networking & Security -> System -> Users and Domains.

Как пишет Kalle в своем блоге, если вы используете платформу VMware Workstation в серверной ОС Windows Server 2019, то виртуальные машины у вас могут валиться с ошибками, если для дисков, на которых они размещены, включена дедупликация. При этом диски могут быть как NTFS, так и ReFS, а в журнале событий у процессов vmware-vmx.exe можно найти следующее:

Faulting application name: vmware-vmx.exe, version: 15.0.2.40550, time stamp: 0x5bf5251a

Faulting module name: vmware-vmx.exe, version: 15.0.2.40550, time stamp: 0x5bf5251a

Exception code: 0xc0000005

Fault offset: 0x000000000049db36

Faulting process id: 0x2a9c

Faulting application start time: 0x01d48a67966e2ea4

Faulting application path: C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe

Faulting module path: C:\Program Files (x86)\VMware\VMware Workstation\x64\vmware-vmx.exe

Report Id: 7dd5aa8c-2f51-471d-b9e4-e04d0caf099b

Faulting package full name: 

Faulting package-relative application ID:

При этом на Windows Server 2012 R2 при точно таких же настройках дедупликации все работает вполне нормально:

Он также пробовал различные настройки дедупликации на Windows Server 2019 (General purpose file server и Virtualized Backup Server), но машины на VMware Workstation 15 все равно валятся с ошибкой случайным образом.

Недавно компания VMware объявила о выпуске обновленной версии решения VMware PKS 1.3 (Pivotal Container Service), предназначенного для управления гибридными средами Kubernetes в онпремизных и публичных облаках. Напомним, что об анонсах на VMworld Europe 2018, касающихся этого продукта, мы писали вот тут.

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

Теперь кое-что из этого было добавлено в VMware PKS, который стал поддерживать облачную среду Microsoft Azure. Кроме того, в продукте были улучшены функции контроля сетевого взаимодействия, безопасности и управления.

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

1. Поддержка публичного облака Microsoft Azure.

Ранее PKS поддерживал облачные среды VMware vSphere, Google Cloud Platform и Amazon EC2. Теперь он работает и в Azure:

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

2. Улучшения гибкости и средств настройки сетевой среды и инфраструктуры безопасности.

Теперь сетевые профили кластеров, которые появились еще в версии 1.2, получили еще больше параметров настройки.

• Поддержка нескольких Tier 0 маршрутизаторов для лучшей изоляции контейнерных сред. Один экземпляр VMware NSX-T может обслуживать несколько Tier 0 маршрутизаторов, что дает не только функции безопасности, но и возможности настройки отдельных диапазонов IP для каждого роутера и его клиентов.

• Маршрутизируемые IP-адреса, назначаемые группам узлов (Pods), что позволяет обеспечить их прозрачную коммуникацию с внешним миром (а также достучаться к ним из внешнего мира). Если необходимо, можно использовать и NAT-схему. Более подробно об этом написано здесь.
• Для групп Pods можно перекрыть глобальные настройки диапазона IP-адресов и размера подсети, задав их для отдельных групп. Это дает больше гибкости в плане использования глобального диапазона адресов.
• Поддержка больших (large) балансировщиков в дополнение к small и medium. Это увеличивает число предоставляемых сервисов, число групп на бэкенде в расчете на сервис, а также количество транзакций в секунду на сервис.
• Лучшая изоляция окружений за счет размещения нескольких VMware PKS Control Planes в рамках одного экземпляра NSX-T. Каждый управляющий объект VMware PKS control plane можно разместить на выделенном маршрутизаторе NSX-T Tier 0. Это позволяет лучше разделить окружения и, например, обновлять тестовую среду независимо от производственной, работая с двумя экземплярами PKS.

3. Улучшенные операции управления.

Здесь произошли следующие улучшения:

• Средства резервного копирования и восстановления кластеров Kubernetes. Теперь, помимо бэкапа средств управления Control Planes, появилась возможность бэкапа и stateless-нагрузок в контейнерах средствами тулсета BOSH Backup and Restore (BBR).
• Возможность проведения смоук-тестов. С помощью PKS 1.3 возможно создание специализированной тестовой среды, которую можно использовать для проверки апгрейда кластера, чтобы убедиться, что на производственной среде апгрейд пройдет нормально. После окончания теста тестовый кластер удаляется, после чего можно спокойно апгрейдить продакшен.

4. Поддержка Kubernetes 1.12 и другие возможности.

VMware PKS 1.3 поддерживает все стабильные физи релиза Kubernetes 1.12. Со стороны VMware они прошли тесты Cloud Native Computing Foundation (CNCF) Kubernetes conformance tests.

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

Кроме того, компоненты NSX-T и другие управляющие элементы, такие как VMware vCenter, можно разместить за HTTP proxy, требующим аутентификации. Ну и VMware PKS 1.3 включает решение Harbor 1.7 с новыми возможностями, такими как управление диаграммами Helm, улучшенная поддержка LDAP, репликация образов и миграции базы данных.

Более подробно о VMware PKS 1.3 написано по этой ссылке. Также больше подробностей об обновлении можно узнать тут, а вот тут можно пройти практическую лабораторную работу по решению PKS.

Недавно компания VMware выпустила обновление контент-пака решения Log Insight для инфраструктуры кластеров хранилищ - vRealize Log Insight Content Pack for vSAN. Новая версия 2.1 представляет функции, которые соотносятся с новыми возможностями дэшбордов в Log Insight и механизма алертинга.

Напомним, что продукт позволяет получить следующие возможности в рамках функционала Log Insight:

• Быстрая идентификация проблем за счет специализированных дэшбордов, отображающих состояние кластеров vSAN.
• Возможность использования различных комплексных фильтров для поиска нужной информации в логах vSAN.
• Визуализация необходимых параметров и запросов, что позволяет определить аномалии в различных аспектах инфраструктуры.
• Мощный движок алертинга, который позволяет мониторить логи vSAN на предмет возможных проблем и оповещать администраторов.
• Помощь администраторам - каждый виджет включает информацию о его назначении со ссылками на документацию и базу знаний VMware, что позволяет понять характер и назначение отображаемых данных.

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

В новом контент-паке были скорректированы виджеты "Maximum memory congestion reached" и "Maximum SSD congestion reached", чтобы соответствовать пороговым значениям и алертам, представленным в vSAN health service для сервера vCenter.

Ассоциированные с ними алерты по нагрузке на память и носители SSD также были доработаны. Включением/выключением алертов можно управлять прямо из дэшборда Log Insight:

Также из списка алертов убрали "Operations took too long" и "Object component state changes – Absent.", потому что они слишком часто срабатывали при нормальной, в общем-то, эксплуатации виртуальной инфраструктуры и кластера vSAN.

Обновить контент-пак вы можете прямо из консоли решения Log Insight (он подходит для Log Insight версий 4.0-4.7 и работает для vSAN версий 6.0 - 6.7 U1):

Либо можно скачать VMware vRealize Log Insight Content Pack for vSAN по этой ссылке.

На сайте проекта VMware Labs очередное интересное обновление - утилита Policy Enforcer. Она позволяет проверять пользовательские настройки политик на их машинах под управлением Workspace ONE и возвращать эти настройки к заданным параметрам.

Policy Enforcer проверяет политики Content Security Policy (CSP, политики защиты контента) в ОС Windows 10 на соответствие заданным в консоли Mobile Device Management (MDM) решения Workspace ONE, и, если пользователь их изменил через редактор реестра, возвращает их к нужным значениям ключей реестра.

Policy Enforcer можно развернуть на машинах пользователей с помощью MSI-пакета PolicyEnforcerInstaller.msi через консоль UEM (User Environment Manager) и установить как внутреннее приложение (internal app) в разделе Apps & Books (Applications > Native).

При развертывании этого сервиса настройку App delivery method нужно выставить в Auto.

Далее на машине пользователя специальная служба будет следить за изменением ключей реестра для политик MDM:

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

После апгрейда виртуальной инфраструктуры на версию VMware vSphere 6.7 Update 1, а также при ее регулярном обновлении и эксплуатации, нужно поддерживать актуальные версии VMware Tools в виртуальных машинах.

Для начала напомним, что самую последнюю версию VMware Tools для ваших виртуальных машин всегда можно скачать по этой ссылке:

https://www.vmware.com/go/tools

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

/vmfs/volumes/vsanDatastore/vmtools

Далее нужно скачать последнюю версию VMware Tools по ссылке выше и положить ее в созданную папку (включая папки "vmtools" и "floppies").

Теперь на каждом хосте ESXi нужно обновить указатель ProductLocker через интерфейс MOB (Managed Object Browser). Для этого надо зайти по ссылке:

https://VCSA_FQDN/mob

И там перейти в:

Content > rootFolder > childEntity > hostFolder > host 

Далее нужно выбрать хост ESXi, для которого вы хотите обновить этот указатель. Здесь есть два API вызова, которые вам понадобятся:

Вызов QueryProductLockerLocation покажет вам текущий указатель на папку с VMware Tools на хосте (ProductLocker):

Метод UpdateProductLockerLocation_Task позволит вам обновить размещение для пакетов VMware Tools для этого хоста, добавив путь к нужной папке в параметр path:

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

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

В мае прошлого года компания VMware выпустила обновление vSphere Integrated Containers 1.4 (VIC), а в июле мы писали про апдейт VIC 1.4.2. В январе этого года VMware выпустила новую версию vSphere Integrated Containers 1.5 - давайте посмотрим, что в ней нового.

1. Квоты хранилищ (Storage Quotas).

Квоты хранилищ позволяют администратору vSphere задавать лимиты хранения, которые доступны объектам Docker Endpoint, с помощью опции --storage-quota для команды vic-machine create. Квоты можно задавать для каждого из объектов Virtual Container Host (VCH), они срабатывают при создании контейнера или загрузке образа. В примере ниже видно, что квота задана на уровне 15 ГБ и при попытке завести еще один контейнер busybox возникает ошибка о превышении квоты по хранилищу.

~$ docker –H :2376 –tls info

vSphere Integrated Containers v1

Backend Engine: RUNNING

VCH storage limit: 15 GiB

VCH storage usage: 9.542 GiB

VCH image storage usage: 1.656 MiB

VCH containers storage usage: 9.451 GiB
~$ docker -H :2376 --tls run --id busybox

  docker: Error response from daemon: Storage quota exceeded. Storage quota: 15GB; image storage usage: 0.002GB, container storage usage: 9.451GB, storage reservations: 9.541GB.

2. Возможность загрузки альтернативного ядра Linux Kernel.

Photon OS дает массу возможностей для загрузки контейнеров, однако некоторым пользователям требуется собственная конфигурация ядра или вообще другой Linux-дистрибутив. Для них сделана возможность загружать собственное ядро, например, ниже приведена команда для запуска ядра CentOS 6.9, в среде которого будут работать контейнеры:

~$ bin/vic-machine-linux create --target 10.161.187.116 --image-store nfs0-1 –user 'administrator@vsphere.local' --bridge-network bridge --public-network management --container-network vm-network --compute-resource cls --no tlsverify --force --name=centos6.9-demo --bootstrap-iso=bin/boostrap-centos-6.9.iso

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

Помимо поддержки решения VMware NSX-V, которая была введена в прошлых версиях, теперь VIC 1.5 поддерживает и решение NSX-T для обеспечения прозрачной коммуникации между контейнерами, с управлением на основе политик и микросегментацией трафика. Делается это с помощью команды vic-machine create –container-network.

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

4. Поддержка Photon OS.

vSphere Integrated Containers 1.5 поставляется со всеми необходимыми компонентами для работы с Photon OS версии 2.0. Этот релиз предоставляет расширенные возможности обеспечения безопасности, а также поддерживает все новые функции второй версии Photon OS.

Получить больше информации о VIC 1.5 можно на этой странице.

Больше 7 лет назад мы писали о резервном копировании конфигурации решения для виртуализации настольных ПК предприятия VMware View. С тех пор многое изменилось, поэтому пора актуализировать процедуру, которая стала с тех пор несколько проще (но не кардинально).

Чтобы создать консистентную резервную копию конфигурации инфраструктуры VMware Horizon, нужно в одно время и в следующем порядке создать бэкап следующих компонентов, составляющих конфигурацию View Manager:

• База данных View Manager ADAM (база Connection Server)
• База данных View Composer
• База данных VMware vCenter

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

1. Резервное копирование и восстановление View Manager: база данных Connection Server.

Резервное копирование конфигурации Connection Server

Сначала нужно убедиться, что в данный момент нет активных операций create, recompose или delete. Также надо остановить развертывание новых виртуальных машин, чтобы избежать проблем, связанных с процессами синхронизации. Для этого во View Administrator идем в View Configuration > Servers. Там выбираем сервер vCenter и в разделе Settings нажимаем Disable provisioning (не забудьте это включить назад после окончания резервного копирования).

В графическом интерфейсе View Manager резервную копию базы данных можно сделать в разделе View Configuration > Servers, где на вкладке Connection Servers нужно выбрать любой сервер реплицируемой группы и нажать кнопку "Backup Now...". Это сохранит базы данных серверов Connection Server и Composer.

Помните, что даже если у вас несколько серверов Connection Server в одной реплицируемой группе, то делать регулярные бэкапы все равно нужно. Если у вас испортится конфигурация на одном из серверов - она будет отреплицирована на все серверы группы.

Все бэкапы будут по умолчанию сохраняться по следующему пути:

C:\ProgramData\VMware\VDM\backups

Если нажать "Edit..." для настроек сервера Connection Server, то можно увидеть настройки регулярного запланированного резервного копирования с опциями периодичности (от 1 часа до 2 недель), политики хранения и возможность задания пароля для выходного файла.

Также экспорт базы данных View Connection Server LDAP можно сделать с помощью консольной утилиты vdmexport, которая находится вот тут:

C:\Program Files\VMware\VMware View\Server\tools\bin\vdmexport.exe

Файлы будут экспортированы в формат LDAP data interchange format (LDIF). Возможно 3 варианта использования утилиты:

• vdmexport -f configuration_data.LDF (по умолчанию этот файл зашифрован паролем, см. скриншот выше)
• vdmexport -f configuration_data.LDF -v (экспорт данных в формате plain text)
• vdmexport -f configuration_data.LDF -c (cleansed, экспорт данных в открытом текстовом формате, но без чувствительной информации - пароли и т.п.)

Бэкап конфигурации в формате cleansed делать не рекомендуется, так как при его восстановлении вы лишитесь критичной части информации в восстановленной конфигурации.

Делаем бэкап базы Connection Server (эта команда не делает бэкап базы Composer):

vdmexport -f C:\conn_server_backups\Backup_1.LDF

Восстановление конфигурации Connection Server

Перед восстановлением конфигурации серверов Connection Server нужно убедиться, что у вас есть все необходимые файлы для восстановления конфигурации и сделать следующее:

• Остановить службы VMware Horizon Security Server на серверах Security Server.
• Остановить службы View Composer на серверах Composer/vCenter.
• Удалить на серверах компоненты VMware Horizon Connection Server и AD LDS Instance VMwareVDMDS.
• Установить один экземпляр Connection Server и остановить там службу VMware Horizon Connection Server.

Восстановление базы View Connection Server выглядит следующим образом:

1. Расшифровываем файл бэкапа (если вы делали бэкап как plain text, этого делать не нужно):

vdmimport -d -p mypassword -f C:\conn_server_backups\Backup_1.LDF > Decrypted_Backup_1.LDF

2. Импортируем конфигурацию View Manager (Connection Server):

vdmimport -f Decrypted_Backup_1.LDF

3. После этого можно удалить только компонент VMware Horizon Connection Server и переустановить его для новой конфигурации базы данных. Далее в Horizon Administrator нужно убедиться, что настройки восстановлены.

4. Затем нужно запустить серверы View Composer, а также установить и настроить все реплики серверов Connection Server.

5. Последним шагом надо запустить все экземпляры Security Servers.

Если после восстановления серверов Connection Servers серверы Security Servers окажутся в неконсистентном состоянии, то последние придется переустановить.

Также все эти шаги можно посмотреть в видео ниже:

Ну и об этом процессе подробно написано в KB 1008046, а также в документе Horizon 7 Administration Guide.

2. Резервное копирование и восстановление View Manager: база данных Composer.

Резервное копирование конфигурации Composer

Перед резервным копированием восстановлением View Composer нужно убедиться, что у вас нет активных операций recompose/refresh и остановить его службы (Start > Administrative Tools > Services, далее остановить службу VMware View Composer).

Файлы бэкапов View Composer имеют расширение *.svi и по умолчанию лежат в той же папке, что и для Connection Server:

C:\ProgramData\VMware\VDM\backups

Выглядят они подобным образом:

Backup-YearMonthDayCount-vCenter Server Name_Domain_Name.svi

Для бэкапа базы View Composer нужно выполнить следующую команду (поробнее - тут, утилита sviconfig.exe находится в папке установки Composer):

sviconfig -operation=exportdata -DsnName=LinkedClone -username=Admin -password=Pass -outputfilepath="C:\Program Files\VMware\VMware View Composer\backup_1.svi"

Параметр DsnName - это DSN-имя, которое используется для соединения с базой данных.

Операция sviconfig exportdata возвращает один из следующих кодов:

После создания резервной копии запустите Composer.

Восстановление конфигурации Composer

Для восстановления базы View Composer нужно выполнить следующую команду (поробнее - тут):

sviconfig -operation=restoredata -DsnName=LinkedClone -username=Admin -password=Pass -backupfilepath="C:\Program Files\VMware\VMware View Composer\backup_1.svi"

Операция sviconfig restoredata возвращает один из следующих кодов:

После этого можно запустить службу View Composer. Надо понимать, что после восстановления базы View Composer могут быть некоторые расхождения с конфигурацией View Connection Server, которые надо будет устранять вручную.

3. Резервное копирование и восстановление БД vCenter Server.

Для резервного копирования и восстановления баз данных виртуального модуля VMware vCenter Server Appliance (vCSA) и vCenter Server for Windows используйте инструкцию, приведенную в KB 2091961.

В видео ниже вы можете посмотреть как делать бэкап и восстановление БД vCenter для vCSA:

А вот так делается резервная копия и восстанавливается БД vCenter Server for Windows (Embedded database):

Помните, что при восстановлении конфигурации Connection Server и Composer она должна соответствовать конфигурации виртуальной инфраструктуры на сервере vCenter (имена виртуальных машин, объектов и т.п.), поэтому не пренебрегайте процессом восстановления конфигурации vCenter.

На днях компания VMware выпустила небольшое обновление своей платформы виртуализации vSphere 6.7 - вышел апдейт vCenter Server 6.7 Update 1b, а также патч к ESXi 6.7.

Обновление к vCenter не содержит никакого нового функционала, однако закрывает несколько серьезных проблем и багов, которые были обнаружены с момента релиза платформы в октябре прошлого года в компонентах vCenter и vSAN.

Например, как вам вот такой баг:

In the vSphere Client, if you right-click on a folder and select Remove from Inventory from the drop-down menu, the action might delete all virtual machines in that folder from the disk and underlying datastore, and cause data loss.

То есть вместо убирания машины из инвентори в vSphere Client, происходит удаление всех виртуальных машин из этой папки с диска. Так что лучше обновите свой vCenter уже сегодня. Надо еще помнить, что, по-прежнему, не поддерживается прямое обновление vCenter Server 6.5 Update 2d и 2e на этот релиз. Странно, но VMware никак не может это починить.

Кроме этого VMware выпустила важные патчи к ESXi 6.7, которые содержат исправления ошибок и апдейт подсистемы безопасности.

Тут ничего особенно критичного, но все равно лучше обновиться, особенно если вы используете решение NSX-T.

Компания VMware, прислушавшись к фидбэку пользователей, сделала несколько улучшений в онлайн-утилите VMware Compatibility Guide в плане поиска поддержки VVols (кстати, почитайте нашу статью о политиках SPBM на томах VVols).

Теперь новый VCG позволяет получить ответы на следующие вопросы:

• Какой дисковый массив поддерживает технологию VVols?
• Какую версию ESXi поддерживает тот или иной вендор оборудования?
• Какая есть сертификация VASA?
• Какие возможности VVols поддерживает устройство?
• Какие проблемы или ограничения имее реализация VASA Provider на устройстве?

Кликнув на производителя (Partner Name), вы увидите какие типы VASA Provider он поддерживает и на каких моделях дисковых массивов.

Также, выбрав нужную вам фичу VVols, например, VVols Storage Replication, вы можете вывести всех производителей, кто ее поддерживает:

Раскрыв категорию Partner Name для нужного производителя, вы увидите какие версии ESXi какие функции поддерживают:

Обратите внимание, что справа в таблице есть ссылка "VASA Provider Download", которая позволяет вам загрузить актуальную версию компонента-провайдера интерфейса VASA.

Также есть еще один полезный раздел, который открывается по клику на "Click here for more Details":

Тут уже можно найти детальную информацию о поддерживаемых протоколах, статьях базы знаний (KB), версии VASA provider и VASA VVol Spec, а также многое другое.

На сайте проекта VMware Labs появился апдейт основного средства управления виртуальной инфраструктурой - VMware vSphere Client 4.0. Напомним, что, начиная с версии vSphere 6.7 Update 1, vSphere Client является официально поддерживаемым средством управления для всех рабочих процессов платформы vSphere. О последней версии vSphere Client 3.42 мы писали осенью прошлого года вот тут.

Теперь VMware в обновленной версии клиента исправила несколько ошибок, а также отключила поддержку старых версий VMware vSphere. Новый клиент работает, начиная с vSphere 6.5 и более поздними версиями. То есть, если у вас vSphere 6.0, то не обновляйте ваш клиент (тем более, что линка на загрузку прошлой версии уже нет), а используйте версию 3.42, которая реализует весь функционал.

Также надо помнить, что если вы используете vSphere 6.5, то у вас будет недоступен плагин к VMware vSphere Update Manager (VUM). Интересно, что в Changelog написано о том, что в клиенте есть некоторые New Features, но не написано, какие именно)

UPD. Новый клиент vSphere Client 4.0 предоставляет следующие новые возможности:

• Поддержка VMware vCenter 6.7, браузер просмотра файлов и папок стал работать заметно быстрее.
• Графический интерфейс ESX Agent Manager.
• Настройки MxN Convergence в разделе System Configuration
• Возможность импорта сертификатов и генерации запроса CSR.
• Функции Code Capture: кнопка записи может быть нажата между состояниями hidden и shown.
• Возможность удалить бандлы скриптов (Script Bundles) в механизме Autodeploy для vCenter 6.7.
• Возможность удалить Discovered hosts в механизме Autodeploy для vCenter 6.7.
• Экспорт данных о лицензиях в формате CSV для всех представлений, связанных с просмотром лицензий.
• Добавление и назначение лицензий в рамках одной операции.
• Настройка аутентификации на прокси-сервере для VC 6.5+ (раздел VC > Configure  > Settings > Authentication Proxy).

При обновлении клиента на версию vSphere Client 4.0 с 3.x вам нужно будет повторно подключить его к инфраструктуре vSphere и ввести учетные данные.

Скачать VMware vSphere Client 4.0 можно по этой ссылке.

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

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

• Консольная утилита esxtop (представление network)
• ping / vmkping
• traceroute

Но если хочется углубиться дальше в сетевое взаимодействие на хосте, то тут могут оказаться полезными следующие утилиты:

• net-stats
• pktcap-uw
• nc
• iperf

1. Net-stats.

Чтобы вывести весь список флагов этой команды, используйте net-stats -h, а вот для вывода детальной информации о номерах портов и MAC-адресах всех интерфейсов используйте команду:

net-stats -l

С помощью net-stats можно делать огромное количество всяких вещей, например, проверить включены ли на интерфейсе vmnic функции NetQueue или Receive Side Scaling (RSS) с помощью команды:

net-stats -A -t vW

Далее нужно сопоставить вывод блока sys для нужного интерфейса и вывода команды:

vsish -e cat /world/<world id>/name

2. Pktcap-uw.

Эта утилита совместно с tcpdump-uw захватывать пакеты на различных уровнях. Если tcpdump-uw позволяет захватывать пакеты только с интерфейсов VMkernel, то pktcap-uw умеет захватывать фреймы на уровне виртуального порта, коммутатора vSwitch или аплинка.

В KB 2051814 подробно описано, как можно использовать утилиту pktcap-uw. На картинке ниже представлен синтаксис использования команды, в зависимости от того, на каком уровне мы хотим ее применить:

• Фильтрация пакетов для выбранного MAC-адреса:

pktcap-uw --mac xx:xx:xx:xx:xx:xx

• Фильтрация пакетов для выбранного IP-адреса:

pktcap-uw --ip x.x.x.x

• Автоматическое исполнение и завершение pktcap-uw с использованием параметра sleep:

pktcap-uw $sleep 120; pkill pktcap-uw

• Ограничить захват заданным числом пакетов:

pktcap-uw -c 100

• Перенаправить вывод в файл:

pktcap-uw -P -o /tmp/example.pcap

3. NC

NC - это олдскульная Linux-команда NetCat. Она позволяет проверить соединение по указанному порту, так как telnet недоступен на ESXi. Например, так можно проверить, что можно достучаться через интерфейс iSCSI по порту 3260 до системы хранения:

nc -z <destination IP> 3260

В KB 2020669 вы можете найти больше информации об этой команде.

4. Iperf

Эта утилита предназначена для контроля пропускной способности на интерфейсе. Она используется механизмом vSAN proactive network performance test, который доступен в интерфейсе vSAN. Поэтому при ее запуске вы получите сообщение "Operation not permitted". Чтобы она заработала, нужно создать ее копию:

cp /usr/lib/vmware/vsan/bin/iperf3 /usr/lib/vmware/vsan/bin/iperf3.copy

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

esxcli network firewall set --enabled false

Теперь можно использовать эту утилиту для замера производительности канала (флаг -s - это сервер, -c - клиент):

/usr/lib/vmware/vsan/bin/iperf3.copy -s -B 192.168.200.91

/usr/lib/vmware/vsan/bin/iperf3.copy -c 192.168.200.91

Результат будет похожим на это:

Больше об использовании утилиты iperf3 вы можете узнать вот тут.

Как вы знаете, в VMware vSphere 6.7 Update 1 средство обновления vSphere Update Manager (VUM) получило множество новых возможностей, в том числе функцию обновления микрокода (firmware) I/O-адаптеров серверов, входящих в состав кластера vSAN. Эта функциональность как раз перекочевала туда из интерфейса vSAN (называлось это раньше Configuration Assist).

VUM использует утилиту обновления драйверов от вендора оборудования (сервера). Таким образом, обновление драйвера I/O-устройства (HBA-адаптера) можно включить в двухступенчатый цикл обновления хоста и не заниматься этим отдельно, что уменьшает общее время обновления.

Если VUM не нашел утилиты обновления от вендора, он предлагает загрузить ее. Для этого он анализирует Release Catalog, учитывая информацию из HCL (Hardware Compatibility List). При этом поддерживаются и кастомные ISO-образы от OEM-производителей (версия билда ESXi также распознается).

Когда вы зайдете в Host Updates в VUM, вы увидите вот такое сообщение:

Firmware engine needs to download hardware vendor’s firmware tool to vCenter.

Если вы нажмете "Download vendor firmware tool", то увидите, что для загрузки утилиты обновления микрокода можно использовать как дефолтный, так и свой репозиторий:

Как это известно по ситуации с драйверами Windows, установщик не найдет нужный драйвер, поэтому, скорее всего, придется указать свой путь к утилите обновления, например для контроллера Dell PERC путь может выглядеть как-то так:

http://downloads.dell.com/FOLDER03037799M/1/vmware-esx-perccli-1.05.08.zip

Обратите внимание, что по кнопке Browse можно указать свой файл, если у вас нет подключения к интернету:

Кстати, проверки состояния vSAN health checks интегрированы с рабочими процессами Update Manager, что позволяет приостановить процесс обновления хостов кластера в случае, если после обновление с одним из них пошло что-то не так. Также есть возможность загрузить на сервер vCenter файл HCL-манифеста в формате JSON, чтобы указать соответствия билдов ESXi и оборудования, если вы обновляетесь через VUM в офлайн-режиме.

На сайте проекта VMware Labs появилось превью технологии PowerCLI for VMware Cloud on AWS, которая представляет собой расширение фреймворка PowerCLI на публичное облако от Amazon и VMware. Расширение поставляется как отдельный модуль PowerCLI (VMware.VimAutomation.VmcPreview), который интегрируется с остальными модулями.

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

Для начала работы вам понадобится PowerCLI 11.0.0 или более старшей версии. Установить модуль можно автоматически из PowerShell Gallery с помощью команды:

Install-Module -Name VMware.VimAutomation.VmcPreview -RequiredVersion 1.0.0.11171858

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

Connect-Vmc -RefreshToken xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Далее получим информацию о нашей организации:

Get-Organization

С помощью Select-Object можно отфильтровать вывод по свойствам:

Get-Organization | Select-Object -Property Id, DisplayName

Также можно получить объект SDDC, используя Organization ID:

Далее с объектом SDDC можно работать как в привычной среде PowerCLI, например, получить AWS Region, какие зоны Availability Zones используются, информацию об NSX (например, Manager URL), а также vCenter URL:

Скачать VMware vCloud on AWS можно по этой ссылке.

Давно мы не писали о новостях сертификации VMware Certified Professionall (VCP), тем более, что с этого года несколько меняются принципы наименования и прохождения сертификации.

Для начала отметим, что по-прежнему для получения сертификации требуется прохождение курса (очно или онлайн) в одном из авторизованных центров (например - такого) и сдача двух экзаменов - VMware vSphere Foundations для соответствующей версии и специализированного экзамена для выбранного направления сертификации, например, VMware Certified Professional 6.5 – Data Center Virtualization.

С 16 января этого года VMware переходит от системы сертификаций по номеру версии продукта к системе с привязкой к году сертификации (то есть, если вы сдадите экзамен после 16 января, вы уже будете VCP 2019). Например:

• Было: VMware Certified Professional – Desktop and Mobility 7 (VCP7-DTM)
• Стало: VMware Certified Professional – Desktop and Mobility 2019 (VCP-DTM 2019)

Более подробно об этой системе для сертификаций VCP и VCAP написано здесь. Такая схема, во-первых, позволит работодателю или заказчику понять реальную актуальность сертификации (например, VCP6.5-DCV - полностью актуальная сертификация на данный момент, но сама платформа vSphere 6.5 вышла еще в 2016 году).

Второй момент - с 24 января будет доступен новый экзамен на базе VMware vSphere 6.7, что позволит получить актуальную сертификацию VCP 2019 для актуальной версии платформы.

Таким образом, вот так теперь выглядят планируемые сертификации VMware VCP для 2019 года:

Согласно политикам VMware, после выпуска новой версии экзамена старый объявляется устаревшим в течение 4 месяцев. Для тех, кто прошел сертификацию по прошлым версиям (не более двух версий назад), есть 3 варианта апгрейда:

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

Вот так выглядит путь апгрейда для VCP на данный момент:

А вот так - список бридж-путей для ресертификации от прошлых версий:

На сайте проекта VMware Labs появилась новая утилита, которая может оказаться полезной пользователям решения Workspace ONE в крупной инфраструктуре. С помощью Workspace ONE Provisioning Tool можно развернуть приложения на тестовой виртуальной машине, чтобы убедиться в том, что их можно развертывать в производственной среде Dell Factory. Эта утилита имеет в себе часть функционала средства Workspace ONE Configuration Tool for Provisioning, о котором мы писали совсем недавно.

В качестве исходных параметров утилита принимает файлы упакованных приложений в формате .ppkg, а также специальный файл unattend.xml как часть процесса развертывания Dell Provisioning.

Основные возможности Workspace ONE Provisioning Tool:

• Простой интерфейс, позволяющий администратору валидировать работоспособность файлов ppkg и unattend.xml по аналогии с тем, как это происходит в Dell factory.
• Поддержка пакетов PPKG и unattend.xmls, сгенерированных в Workspace ONE UEM Console 1811 или более поздней версии.
• Гибкость - например, можно в текстовом файле указывать параметры конфигурации утилиты, такие как таймаут операций или размещение отчета о работе.
• Генерация детального суммарного отчета с данными о клиентском окружении и результатами установки приложений. Он сохраняется в C:\ProgramData\Airwatch\UnifiedAgent\Logs\PPKGFinalSummary.log после нажатия кнопки "Apply Full Process".
• Приостановка процесса, если какой-либо из шагов завершился неудачно, что позволяет администраторам найти причину в текущем состоянии приложений и самой машины.
  

Утилита работает в двух режимах:

• Apply Apps Only - установка только приложений на тестовой Windows-машине.
• Apply Full process - установка приложений и применение файлов конфигурации xml на тестовой машине, где исполняется Sysprep и включение ее в среду Workspace ONE (enrollment).

Статус развертывания можно наблюдать в правой панели, а детали будут приведены в отчете:

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

В конце декабря компания VMware сделала доступной для скачивания новую версию vRealize Network Insight 4.0 (vRNI). Напомним, что о прошлой версии vRNI 3.9 мы писали в сентябре прошлого года вот тут.

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

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

1. Поддержка VMware Cloud on AWS.

Новая большая версия vRNI представляет поддержку облачной среды VMware Cloud on AWS (правда пока в режиме Preview). Администраторы могут смотреть метрики для NSX и vCenter, а также потоки IPFIX flows между виртуальными машинами в облаке VMware Cloud on AWS и вашей онпремизной инфраструктурой NSX и vSphere.

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

На этой схеме по клику на компонент можно увидеть облачные виртуальные машины, хосты, настройки сети и безопасности, конфигурацию сетей, VPN-соединения, а также все то же самое на онпремизной стороне. Также на картинке видны маршрутизаторы NSX T0/T1 с примененными к ним правилами фаерволов для путей.

2. Возможность Plan Security и микросегментация.

Для VMware Cloud on AWS можно использовать функцию Plan Security, которая позволяет распознавать паттерны трафика приложений, визуализовывать его и дать исходные данные для его оптимизации с точки зрения приложений.

Все это работает в рамках общего подхода по микросегментации трафика:

3. Возможность просмотра путей VM-to-VM и сущностей Cisco ACI.

Теперь Network Insight может отображать сущности Cisco ACI. Просто укажите vRNI адрес контроллера APIC и вы получите детали конфигурации, такие как фабрика ACI, EPG и их маппинги, Bridge Domains, пути L2 к leaf-узлам, а также схемы VRF для путей ВМ-ВМ.

Помимо этого, для коммутаторов и APIC поддерживаются метрики на базе SNMP. На каждый из элементов фабрики можно нажать, чтобы посмотреть дополнительную информацию (показан дэшборд для фабрики Leaf and Spine):

Индивидуальные дэшборды доступны для следующих объектов:

• Leaf and Spine fabric
• Switches
• EPG
• Application profile

Также для сущностей ACI доступен мощный поиск, который позволяет добавить результаты на pinboard и к ним привязать алармы, если это необходимо.

4. Детали фаерволов Cisco ASA.

Для ASA поддержка со стороны vRNI включает в себя видимость контекста безопасности (security context), прав доступа, групп доступа, сетевых и сервисных объектов или групп, обнаружение и изменение событий, а также правил фаервола в рамках пути VM-to-VM.

На картинке ниже показано представление для VRF на фаерволе ASA с таблицами маршрутизации и другими деталями интерфейсов маршрутизаторов (они показываются для конкретного пути VM-to-VM):

5. Динамические и статические пороги для собираемых метрик (thresholds).

vRNI позволяет добавлять статические пороги для метрик (аларм срабатывает, когда значение больше указанного в течение какого-то времени) и динамические (когда значение отклоняется от предыдущего на определенное значение, например, произошло изменение паттерна трафика):

6. Обновленный NSX-T datasource.

Теперь для NSX-T можно получать такую информацию, как проблемы связности между компонентами NSX, число вызовов NSX API, количество packet drops, flow count, network rate и byte count. Эти метрики доступны для логических коммутаторов и портов, интерфейсов маршрутизаторов и правил фаерволов.

Также поддерживается и NAT с возможностью просмотра правил SNAT, DNAT и Reflexive (stateless). Здесь можно увидеть оригинальные и транслируемые IP-адреса, сервисное соединение, а также входные и выходные интерфейсы:

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

Полный список новых возможностей vRealize Network Insight 4.0 доступен в Release Notes.

Попробовать VMware vRNI можно также как облачный сервис VMware Cloud Service по этой ссылке. Для онпремизных инсталляций поддерживается прямое обновление с версий vRNI 3.8 и 3.9.

Недавно компания VMware сделала доступной онлайн интересную утилиту - VMware Configuration Maximums Tool. Она позволяет быстро и просто найти максимальные параметры конфигураций для различных продуктов VMware:

На данный момент поддерживаются решения NSX Data Center for vSphere, vSphere (правда пока еще нет vSphere 6.7 Update 1), VMware NSX-T, vRealize Operations Manager и VMware Site Recovery Manager, но, скорее всего, этот список будет быстро пополняться.

Помимо продукта VMware и его версии, можно также выбрать и категории максимумов, которые хочется посмотреть (хосты ESXi, виртуальные машины и т.п.). Также полученные результаты можно экспортировать в PDF.

Если в верхней части страницы перейти на вкладку Compare Limits, то мы увидим функционал сравнения максимумов в различных версиях продуктов. Например, выберем слева VMware vSphere 6.7 и сравним с ней две предыдущих версии платформы - vSphere 6.5 Update 1 и vSphere 6.5:

Результаты будут приведены в таблице (обратите внимание, что их можно экспортировать в CSV):

В общем, полезная штука - пользуйтесь.

Сегодня Алексей расскажет про две тонкости с которыми пришлось повозиться на следующем этапе установки – обе относятся к подготовке образа для установки.

Первая – выбор места для установки. Если в вашем сервере на момент загрузки присутствует один диск, и вы планируете его использовать для установки, то проблем нет. А если их несколько, и вам нужно использовать какой-то определенный, то придется указать на желаемый диск с помощью команды:

install --disk=diskname или install –-firstdisk=disk-type

что и прекрасно описано в документации здесь: https://kb.vmware.com/s/article/2004582.

В моем же случае в системе имелся маленький SSD (так называемый BOSS card, в случае Dell – RAID1 массив из двух SATA m.2 SSD) для установки системы и большой RAID-массив, на котором теоретически могли располагаться виртуальные машины (в случае если производится переустановка хоста).

Что в вышеприведенной статье не упомянуто – так это как найти diskname или disk-type для искомого диска/массива.
А сделать это можно следующим образом:

• Проведите тестовую установку в ручном режиме.
• Запустите SSH сервис и подключитесь к серверу по SSH.
• Используйте команду esxcli storage core device list для того, чтобы получить список всех контроллеров в системе.

Искомая информация для вашего контроллера будет в поле Model:

Итоговая команда в моем случае:

install --firstdisk="DELLBOSS VD" --overwritevmfs --novmfsondisk

Вторая тонкость выяснилась, когда я начал тестировать загрузочный диск. Сервер из другой поставки наотрез игнорировал содержимое kickstart файла. Выяснилось что один из серверов был сконфигурирован использовать EFI для загрузки, другой же - классический BIOS. ISO-образ ESXi содержит два различных BOOT.CFG файла для этих двух типов загрузки:

• для BIOS - в корне образа
• для EFI - соответственно, в папке /EFI/BOOT

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

Надеюсь, это сэкономит кому-то время.

В конце декабря ушедшего года компания VMware выпустила обновление своего консольного фреймворка для управления виртуальной инфраструктурой - PowerCLI 11.1.0. Напомним, что прошлая мажорная версия (PowerCLI 11.0) была выпущена в октябре прошлого года.

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

1. Улучшения Site Recovery Manager Module.

Теперь средствами модуля VMware.VimAutomation.SRM для PowerCLI обеспечивается мультиплатформенная поддержка в плане управления инфраструктурой Site Recovery Manager. Этот модуль можно использовать с PowerShell Core на платформах MacOS и Linux. Он стал одним из первых специализированных модулей, сконвертированных на другие платформы.

Также теперь поддерживается последняя версия Site Recovery Manager 8.1.

2. Обновления Storage Module.

В модуле Storage (VMware.VimAutomation.Storage) было сделано несколько исправлений ошибок и улучшений. Теперь командлет Get-VsanDisk выводит диск vSAN, где находится Witness Component. Также для командлета Start-SpbmReplicationTestFailover больше не нужен параметр VvolId.

Скачать PowerCLI 11.1 можно по этой ссылке. Напомним, что традиционно PowerCLI обновляется следующей командой:

Update-Module -Name VMware.PowerCLI

В прошлом году мы писали о выпуске обновленной версии решения VMware Horizon 7.7, а также о его компонентах - VMware App Volumes 2.15 и VMware User Environment Manager 9.6, а сегодня расскажем о последнем из важных компонентов для создания инфраструктуры виртуальных ПК - новой версии VMware Unified Access Gateway 3.4.

VMware UAG представляет собой шлюз для доступа к инфраструктуре Workspace ONE и Horizon. Шлюз используется для безопасного доступа внешних авторизованных пользователей ко внутренним ресурсам рабочей области Workspace ONE, а также виртуальным десктопам и приложениям Horizon.

Напомним, что о прошлой версии Unified Access Gateway 3.3 мы писали вот тут.

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

1. Обеспечение собственной высокой доступности (High Availability).

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

Делается это средствами виртуального IP-адреса и Group ID, что позволяет балансировать трафик на порту 443 для более чем 10 тысяч одновременных подключений. Это позволяет снизить операционные затраты на обслуживание таких сервисов, как VMware Horizon 7, Web Reverse Proxy, Per-App Tunnel и VMware Content Gateway.

2. Механизм мониторинга Session Statistic Monitoring для оконечных сервисов.

Теперь с помощью этих функций в административной консоли UAG можно в реальном времени наблюдать за статистиками активных и неактивных сессий, неудачными попытками входа, сессиями протоколов Blast и PCoIP, туннелями и прочими параметрами. Это позволит грамотнее планировать балансировку пользовательских сессий.

3. Режим Cascade Mode для поддержки Horizon 7.

Для организаций, где требуется использование двухслойного DMZ, сервер UAG может работать в каскадном режиме (Cascade Mode). В этом случае внешний сервер UAG работает как Web Reverse Proxy для интернет-соединений пользователей, а внутренний - как Horizon Edge Service.

4. Ограничение доступа к службам Amazon Web Services.

Теперь с помощью UAG можно лимитировать доступ к облачным ресурсам AWS в целях разграничения доступа. В этом случае Unified Access Gateway можно импортировать в облако Amazon EC2, зарегистрировать как Amazon Image Machine (AMI) и развернуть с помощью сценария PowerShell.

5. Поддержка custom thumbprints.

Custom thumbprints позволяют использовать разные сертификаты для соединений Blast TCP и VMware Tunnel. Это можно сделать в консоли UAG или через PowerShell INI.

6. Нативная поддержка Horizon 7.

В консоли Horizon Administrator в дэшборде System Health теперь отображаются детали о зарегистрированных модулях VMware Unified Access Gateway для версии 3.4 и более поздних:

Скачать VMware Unified Access Gateway 3.4 можно по этой ссылке.

Недавно мы писали про то, как работает механизм регулирования полосы канала Network I/O Control (NIOC) в VMware vSphere, который позволяет приоритизировать различные типы трафика на одном сетевом адаптере, а сегодня взглянем на сам механизм прохождения трафика по уровням абстракции виртуального коммутатора изнутри.

Цепочка прохождения пакетов по сетевому стеку гипервизора ESXi через различные уровни называется Network IOChain. Это фреймворк, который позволяет на пути следования данных от виртуальной машины к физическому сетевому адаптеру производить различную модификацию данных и передачу их на следующий уровень.

IOChain обеспечивает связность виртуального коммутатора vSphere Standard Switch (VSS) или vSphere Distributed Switch (VDS) от групп портов на них к портам физических сетевым адаптеров (uplikns) в процессе передачи и обработки пакетов между этими сущностями. Для каждого из виртуальных коммутаторов есть 2 интерфейса IOChain (для входящего и исходящего трафика). Это дает большую гибкость по настройке политик каналов трафика Ingress и Egress.

Примерами таких политик служат поддержка сетей VLAN, механизма группировки NIC teaming и шейпинг трафика (traffic shaping). Работают эти политики на трех уровнях абстракции (в порядке следования от виртуальной машины):

• Группа портов виртуального коммутатора (port group).

На этом уровне работает фильтрация VLAN, а также политики безопасности, такие как Promiscuous mode, MAC address changes и Forged transmits. Пользователи также могут настроить политики шейпинга исходящего трафика (для VSS) или в обоих направлениях (только для VDS).

• Обычный или распределенный виртуальный коммутатор (VSS или VDS).

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

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

• Порт (uplink).

Этот уровень отвечает за передачу трафика к драйверу сетевого адаптера. На этом уровне работают функции hardware offloading, облегчающие работу с обработкой пакетов за счет ресурсов сетевой карты. Доступные возможности hardware offloading зависят от конкретной модели карты и ее драйвера. Примерами таких возможностей являются TCP Segment Offload (TSO), Large Receive Offload (LRO) и Checksum Offload (CSO). Также здесь обеспечивается поддержка оверлейных протоколов VXLAN и Geneve, которые используются в решениях NSX-v и NSX-T соответственно (эта поддержка есть во многих современных сетевых картах).

Помимо этого на уровне аплинка работают механизмы буфферизации пакетов при всплесках нагрузки (ring buffers), после чего пакеты передаются на DMA-контроллер, чтобы быть обработанными процессором карты и перенаправлены уже в сеть передачи данных.

Для обычного виртуального коммутатора (VSS) схема прохождения трафика через уровни абстракции IOChain выглядит так:

Если же у вас распределенный виртуальный коммутатор VDS, то вы можете использовать механизм Network I/O Control (NIOC) для резервирования и приоритизации трафика внутри канала аплинков. Также VDS предоставляет множество дополнительных возможностей, таких как LBT (Load Balanced Teaming) и LACP (Link Aggregation Control Protocol).

В случае с VDS схема с IOChain выглядит следующим образом:

Обратите внимание, что на этой диаграмме есть дополнительный модуль DVfilter. Это API-фреймворк, который есть в VDS и требуется для работы решения NSX. Когда компоненты NSX устанавливаются в ядро ESXi, они взаимодействуют с трафиком именно через этот модуль.

С помощью команды summarize-dvfilter можно вывести все загруженные агенты DVfilter и фильтры. Вот так это выглядит без установленного решения NSX:

Если вы посмотрите информацию по компонентам NSX, когда он установлен, то увидите модули nxst-switch-security, nsxt-vsip и nsxt-vdrb.

Вообще, весь стек IOChain является модульным, что позволяет добавлять новую функциональность его компонентов на различных уровнях абстракции. Например, компоненты DVfilter разделяются на Fastpaths, Slowpaths и Filters:

• Fastpaths – фильтры трафика на уровне ядра ESXi.
• Slowpaths – интеграция со сторонними продуктами для сетевой инфраструктуры.
• Filters – размещение фильтров в слоты для каждого из подходящих по модели сетевых адаптеров vNIC.

В VMware vSphere 6.7 в стеке IOChain появилось несколько улучшений, таких как поддержка MAC learning и функции IGMP snooping через интерфейс VNI (Virtual Network Interface), которые могут быть использованы в будущем.

Ну и напомним, что текущая версия распределенного виртуального коммутатора VDS - это 6.6, об их обновлении мы писали вот тут.

Недавно мы писали о выпуске обновленной платформы виртуализации настольных ПК предприятия VMware Horizon 7.7. Мы уже рассказали о новых возможностях продукта для развертывания приложений App Volumes 2.15, а сегодня приведем список новых функций решения VMware User Environment Manager (UEM) 9.6.

Напомним, что о версии Workspace ONE UEM 9.6 для мобильных устройств мы уже писали вот тут, а сегодня посмотрим, что нового появилось в версии UEM для инфраструктуры настольных компьютеров:

1. Улучшения механизма Folder Redirection.

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

Это позволяет, например, использовать имя папки Documents (и прочих) на языке операционной системы пользователя:

2. Логирование изменений, внесенных в конфигурационные файлы.

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

События можно отправлять как в лог событий Windows, так и в локальный Changelog (можно и в оба одновременно).

3. Улучшения механизма умных политик Horizon Smart Policy for Printing.

Об умных политиках мы писали детально вот тут. Политика Smart Policy for Printing контролирует, разрешено ли пользователю распечатывать документ из виртуального ПК на сетевом или USB-принтере, присоединенном к клиентскому компьютеру.

Ранее эта возможность была доступна только для механизма ThinPrint, а теперь она поддерживает и VMware Virtual Print redirection, анонсированный в Horizon 7.7. В зависимости от того, какой агент установлен на виртуальном ПК, умная политика выбирает нужный движок виртуальной печати.

VMware Virtual Print redirection позволяет:

• Печатать с виртуального ПК на любом локальном или сетевом принтере, установленном в клиентской системе.
• Использовать Location-based printing, то есть подключать устройства, которые ближе всего к пользователю физически.
• Сохранять настройки пользователя между сессиями к виртуальному ПК, например, опцию печати в черно-белом режиме.

4. Новая переменная окружения для архивов пользовательских профилей.

Теперь в UEM 9.6 появилась переменная UEMProfileArchives, которую могут использовать различные сценарии для нахождения папки с архивами пользовательского профиля.

5. Поддержка Using Conditions в ОС Windows Server 2019.

Теперь UEM 9.6 поддерживает обработку условий логина в Windows Server 2019, таких как местоположение пользователя, его группа или клиентское устройство. Этот механизм рассмотрен в видео выше.

Скачать VMware User Environment Manager 9.6 можно по этой ссылке.

Недавно мы писали о выпуске обновленной платформы для виртуализации настольных ПК предприятия VMware Horizon 7.7. Частью этого релиза стал апдейт продукта для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам или хостам RDSH - VMware App Volumes 2.15.

Напомним, что о прошлом релизе App Volumes 2.14 мы писали вот тут в рамках анонса позапрошлой версии платформы VMware Horizon 7.5.

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

1. Функция Profile-Only Writable Volumes.

Ранее администратор мог создавать один из двух типов шаблонов для writable volume:

• Только для пользовательских приложений
• Для пользовательских приложений и данных профиля

Теперь же появилась третья опция - возможность создать шаблон только для сохранения данных профиля ("Profile Only"). Это позволяет, например, сохранять файлы Outlook OST, которые кэшируются и не требуют их пересоздания при каждом логине пользователя. Это же относится и к остальным приложениям пакета Office 365 - Outlook, Word, Excel, PowerPoint, Skype for Business и OneDrive for Business - при логине пользователя не нужно заново тянуть их данные с серверов датацентра компании.

2. Поддержка облачных приложений для Writable Volumes.

Теперь загруженный контент приложений OneDrive for Business и Box Drive (версии старше 2.1.105) сохраняется между логинами пользователя. Это позволяет создавать неперсистентные десктопы, но сохранять кэш скачанного контента пользователя, чтобы после его логина данные сервисов хранения сразу оказывались ему доступны.

3. Возможность использовать переменные окружения Writable Volume Exclusions.

Администратор может добавить исключения, например, для папки C:\Users\%Username%\Downloads, чтобы скачанные любым пользователем файлы не сохранялись между его входами в десктоп:

exclude_uwv_file=\users\%USERNAME%\downloads

Также, помимо %Username%, можно использовать переменную окружения %UserProfile%, например, чтобы не загружать временные файлы прошлых сессий пользователей:

exclude_uwv_file=%USERPROFILE%\desktop\temp

4. Поддержка решения Horizon 7 on VMware Cloud on AWS.

Теперь App Volumes поддерживают облачную инфраструктуру десктопов Horizon 7 on VMware Cloud on AWS (SDDC версии 1.5). Механизм App Volumes версии 2.15 может быть использован совместно с облачной платформой Horizon, чтобы развертывать приложения при включении виртуальных машин в облачной инфраструктуре Amazon-VMware.

Более подробно о новых возможностях VMware App Volumes 2.15 смотрите в Release Notes, скачать компоненты App Volumes как часть решения VMware Horizon 7.7 можно по этой ссылке.

Недавно компания VMware опубликовала очередной набор практических упражнений Feature Walkthroughs по апгрейду VMware vCenter 6.7 с прошлых версий управляющего сервера. Они рассказывают об обновлении с помощью интерфейса командной строки vCenter Server Appliance (vCSA) CLI, а также средствами графического интерфейса мастера установки.

Напомним, что Feature Walkthroughs позволяют администратору пройти в интерфейсе тот или иной рабочий процесс виртуальной инфраструктуры без необходимости развертывания у себя тестовой среды.

1. Апгрейд vCenter через через vCSA CLI.

В рамках демо Upgrading vCenter Server 6.5 to vCenter Server 6.7 администратор может узнать, каким образом выглядит консольное обновление Embedded vCenter на последнюю версию. Вам покажут как создать и редактировать настроечный JSON-файл, а также правильно использовать параметры консольной утилиты vcsa-deploy.exe.

Кстати, обратите внимание, что обновление vSphere 6.5 Update 2d на vSphere 6.7 все еще не поддерживается.

2. Апгрейд через графический инсталлятор VMware vCSA.

С помощью демо Upgrading vCenter Server 6.5 to vCenter Server 6.7 using the GUI вы можете пройти по шагам процесса обновления vCenter на последнюю версию в рамках vCSA Installer и его рабочего процесса Upgrade:

Также советуем почитать наши посты о миграции с vCenter for Windows на виртуальный модуль vCSA:

• Миграция сервера VMware vCenter для Windows на виртуальный модуль vCenter Server Appliance 6.7 Update 1
• Функции VMware vCenter Server Appliance для миграции сервера vCenter под Windows

Мы много пишем о публичном облаке VMware vCloud on AWS, появившемся в результате совместных усилий Amazon и VMware. Например, недавно рассказывали, что vCloud on AWS будет не только облачным сервисом, но и появится возможность разместить его на собственной площадке (on-premises).

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

Основная страница прайсинга на VMware vCloud on AWS находится вот тут:

https://cloud.vmware.com/vmc-aws/pricing

Здесь мы можем увидеть вот такие цены за хост ESXi с сервисами vSphere/vSAN/NSX в час (на самом деле, это от $7 в час, а цены ниже указаны для новых клиентов в течение 3 первых месяцев):

Если вы подпишете контракт на год, скидка будет 30%, если на 3 года - 50%.

На этой же странице ниже расположен калькулятор стоимости аренды IaaS-инфраструктуры vCloud on AWS, где можно посчитать примерную цену аренды хостов SDDC (2 CPU, 36 ядер, 512 ГБ оперативной памяти, флэш-хранилище NVMe: 3.6 ТБ кэш, плюс 10.7 ТБ сырой емкости для ВМ).

Для четырех хостов ESXi на месяц у меня получилась стоимость 30 тысяч долларов, что как-то слишком дорого:

На данный момент также существует 2 онлайн-сервиса, которые позволяют оценить затраты на IaaS-инфраструктуру VMConAWS с точки зрения стоимости владения за 3 года:

1. Базовый калькулятор стоимости владения: VMware Cloud on AWS and Microsoft Azure: A Hybrid Cloud TCO Comparison.

https://cloud.vmware.com/vmc-aws-tco-pricing/

В левой панели вводите число виртуальных машин (как в облаке, так и на собственной площадке под управлением VMC) и длительность контракта (год, 3 года или по мере использования) и получаете оценку затрат за 3 года в виде совокупной стоимости владения TCO (total cost of ownership), а также стоимость машиночаса. Это все подается еще и в сравнении со стоимостью владения ресурсами публичного облака Microsoft Azure (насчет точности конкурентных расчетов есть определенные сомнения):

2. Расширенный калькулятор стоимости владения: VMware Cloud on AWS Sizer and TCO.

https://vmcsizer.vmware.com/

В этом средстве расчета вы уже задаете профили рабочей нагрузки с их назначением, указываете число виртуальных машин с их параметрами (диск/профиль операций ввода-вывода, память, процессор) и получаете расчет совокупной стоимости владения с детальной разбивкой по статьям затрат, а также детальным описанием планируемой IaaS-инфраструктуры:

Согласно калькулятору, 100 виртуальных машин с дефолтными настройками профиля нагрузки за 3 года обойдутся в 400 тысяч долларов.

Кстати, для тех, кому интересно - вот детальный FAQ про сервис VMware vCloud on AWS от Amazon на русском языке: https://aws.amazon.com/ru/vmware/faqs/. Ну а вот подобный FAQ со стороны VMware, но уже на английском: https://cloud.vmware.com/vmc-aws/faq.

Кстати, пользователи продукта VMware vRealize Business for Cloud могут в нем провести обследование своей инфраструктуры для оценки затрат на содержание такой же облачной среды, но на стороне vCloud on AWS:

На написание этого поста меня вдохновила достаточно старая, но лично мною обнаруженная совсем недавно статья Романа Гельмана "PowerShell скрипт для автоматической установки ESXi хостов на серверах IBM/Lenovo". Какое-то время назад появилась необходимость автоматизировать процесс развертывания новой инфраструктуры для vSphere для клиента...

Недавно мы писали о политиках хранилищ Storage Policy Based Management (SPBM) на базе тэгов, которые помогают использовать возможности платформы VMware vSphere для назначения виртуальным машинам хранилищ на томах VMFS/NFS с разными характеристиками, который работает на уровне отдельных виртуальных дисков.

Сегодня мы поговорим о политиках SPBM для виртуальных томов VVols на хранилищах, которые предоставляют различные возможности через интерфейс VASA (vSphere APIs for Storage Awareness). Механизм VASA реализуется производителем дисковой системы (storage provider) на программно-аппаратном уровне, при этом дисковый массив полностью отвечает за использование его возможностей, а со стороны vSphere возможно только управление ими средствами механизма SPBM.

Через интерфейс VASA Provider устройство хранения сообщает платформе vSphere, какие сервисы оно предоставляет, а через административный том на хранилище Protocol Endpoint (PE) происходит процессинг операций ESXi с массивом:

К таким возможностям в общем случае относятся:

• Шифрование
• Дедупликация данных на массиве
• Репликация данных внутри массива и на другие массивы
• Функции уровня обслуживания QoS (ограничения по IOPS и Latency)
• Выбор яруса хранения / типа дисков (регулирование уровня производительности)

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

Самое приятное в использовании механизма SPBM для хранилищ на основе VVols в том, что вам не требуется заботиться о томах LUN, дисковых группах и настройке их параметров - массив сам распорядится размещением данных по ярусам (Tiers) и датасторам, а также обеспечением уровня их производительности (Service levels).

Например, вот так просто выглядят правила (Rules) для первичного размещения виртуальных машин на массиве EMC Unity при выборе уровня обслуживания и производительности для новой политики SPBM:

В массивах может быть также реализован QoS в зависимости от критичности приложения (Mission Critical приложения всегда первыми получат ресурсы ввода-вывода):

Некоторые хранилища, например, HPE Nimble, могут предоставлять сразу большое число сервисов, для каждого из которых можно настроить свои правила:

Хранилище может предоставлять не только правила размещения виртуальных машин и обеспечения их функционирования, но и сервисы репликации, как например у Pure Storage (они позволяют, в том числе, настроить репликацию на уровне отдельных VMDK дисков машин):

Также создание политик SPBM для томов VVols можно посмотреть на видео ниже:

А вот так применяются политики SPBM, включая сервисы репликации:

Когда вы обновляете виртуальную инфраструктуру VMware vSphere, нужно также подумать и об обновлении виртуального коммутатора (vSphere Distributed Switch, VDS), который, в зависимости от версии, предоставляет те или иные возможности.

Если вы хотите обновить VMware vSphere 5.5 на последнуюю версию VMware vSphere 6.7 Update 1, то, как вы уже знаете, прямого апгрейда нет. Вам нужно будет обновиться на одну из версий - vSphere 6.0 или 6.5 - и потом уже накатить апгрейд до версии 6.7.

В этом процессе есть нюанс - если вы обновитесь с 5.5 на 6.x, то вам надо будет обновить и Distributed Switch, до того, как будете проводить апгрейд на версию 6.7. В противном случае процесс обновления до версии 6.7 завершится неудачно.

Обновить распределенный коммутатор очень просто: в vSphere Client нужно зайти в Networking, выбрать там ваш VDS-коммутатор и на вкладке "Summary" кликнуть на ссылку, где написано "Upgrades available":

Чтобы запустить процесс обновления VDS, нужно в меню "Actions" выбрать пункт "Upgrade":

В процессе обновления вам предложат выбрать версию VDS, если кликнуть на иконку <i>, то можно узнать какие фичи предоставляют соответствующие версии:

Обратите внимание, что соответствие версий VDS версиям vSphere следующее:

• vSphere 6.0 = VDS 6.0
• vSphere 6.5 = VDS 6.5
• vSphere 6.7 = VDS 6.6 (да, вот так странно)

После обновления убедитесь, что виртуальный коммутатор имеет ту версию, которую вы выбрали:

И еще вам может оказаться полезной информация о потенциальных проблемах при обновлении на VDS 6.6, описанная в KB 52621.

На сайте проекта VMware Labs появилась очередная полезность, на этот раз для пользователей инфраструктуры Workspace ONE. С помощью утилиты Android Device Pre-Verification Suite пользователи и партнеры VMware могут проверить Android-устройство (телефон/планшет/rugged device) на предмет предварительного соответствия условиям device verification program.

Проведение такой предварительной проверки уменьшает время включения устройств в инфраструктуру Workspace One Intelligent Hub (device verification program).

Для работы теста на телефоне должен быть установлен агент Workspace One Intelligent Hub (ранее он назывался Android Agent), который можно поставить из Google Play или с компьютера.

Более подробно об утилите Android Device Pre-Verification Suite можно почитать в документации. Скачать ее можно по этой ссылке.