На сайте проекта VMware Labs обновился нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Эта версия (1.8) драйверов сделана специально для VMware vSphere 7.0 Update 2. При скачивании драйверов убедитесь, что вы выбрали вариант для нужной версии ESXi:

Что нового появилось в драйверах:

• Полная поддержка ESXi 7.0 Update 2
• По умолчанию отключено сканирование шины USB (расширенная настройка usbBusFullScanOnBootEnabled=0) - это позволяет предотвратить розовый экран смерти (PSOD) для пользователей, использующих несколько сетевых карт на USB-портах

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

Загрузить USB Network Native Driver for ESXi для VMware vSphere 7.0 Update 1 и Update 2 можно по этой ссылке.

Аналитический департамент A16Z (они же венчурный фонд Andreesen Horowitz) провели исследование "The Cost of Cloud, a Trillion Dollar Paradox" среди 50 крупных компаний, проанализировав их отчетность и траты на облачную инфраструктуру. Вот эти компании:

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

Для выбранных 5 сервисов картинка по доле трат на облако в себестоимости сервисов выглядит так:

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

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

Например, компания Dropbox перешла из облачной инфраструктуры на свое железо и сэкономила $75M за двухлетний период перед IPO (а маржинальность увеличилась с 33% до 67%, что существенно повлияло на капитализацию).

Важным фактором является и оптимизация использования облака (контроль на публичными ресурсами, оптимизация затрат, использование гибридной модели - онпремизной и облачной инфраструктур). Например, компания Segment за счет таких оптимизаций сократила издержки на облака на 30%, при этом за тот же период трафик вырос на 25%.

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

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

Это гостевой пост нашего партнера - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины в аренду по модели IaaS. В рамках плана по поддержке ИТ-отрасли в России власти хотят запретить государственным структурам строить новые собственные дата-центры за счет бюджета — вместо этого им предложат пользоваться услугами cloud-провайдеров и коммерческих ЦОД.

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

В рамках новой инициативы для решения этой проблемы предлагается обязать различные структуры и ведомства пользоваться сервисами российских провайдеров облачных услуг. Если инициативу примут, строить новые ЦОД не смогут и региональные органы исполнительной власти. Новое предложение также предполагает перевод ГИС в коммерческие дата-центры.

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

Нужна надежная и защищенная виртуальная инфраструктура? Публичные, частные и гибридные облака, Облако ФЗ-152, PCI DSS хостинг, решения для систем SAP — арендуйте сервисы от проверенного облачного провайдера на нашем сайте.

Мы несколько раз писали об онлайн-сервисе VMware vSphere DRS Dump Insight, который позволяет показывать различную информацию по перемещению виртуальных машин в кластере DRS на портале самообслуживания, куда пользователи могут загружать файлы дампов.

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

• Какие рекомендации DRS сделал на основе анализа cost/benefit
• Почему DRS сделал именно эту рекомендацию
• Почему DRS вообще иногда не делает рекомендаци для балансировки кластера
• Как кастомное правило affinity/anti-affinity влияет на балансировку в кластере
• Где взять полный список рекомендаций DRS

На днях у VMware вышло руководство пользователя по этой утилите, которое будет интересно почитать всем администраторам кластеров VMware DRS, решившим начать анализировать дампы DRS:

DRS Dump Insight User Guide небольшой и занимает всего 20 страниц, но там есть очень конкретные рекомендации по работе с интерфейсом утилиты и по трактовке ее результатов:

Напомним, что DRS Dump Insight в целом может делать следующие вещи:

• Автоматизация воспроизведения дампов (с помощью встроенных кастомных DRS replayers)
• Предоставление и визуализация дополнительной информации, которая недоступна в обычных анализаторах логов
• Парсинг и анализ логов для понимания и наглядного отображения решений балансировщика DRS
• Генерация итогового результата в текстовом формате

Скачать VMware vSphere DRS Dump Insight User Guide можно по этой ссылке.

Недавно мы рассказывали про новую возможность KB Insights, которая появилась в решении VMware vRealize Log Insight Cloud. На днях VMware объявила о выпуске еще одного обновления этого облачного продукта для аналитики лог-файлов и мониторинга инфраструктуры.

Одной из новых возможностей июньского релиза Log Insight Cloud стала возможность Live Tail для логов, в которых вы ищете источники проблем. Этот механизм позволяет в реальном времени "прицепиться" к файлам журнала, например, определенного хоста и отслеживать там нужные вам параметры.

На примере ниже коллеги из VMware разбирают эту функциональность. Допустим, у вас возникла проблема с одним из веб-серверов, который дает необычные всплески трафика, и вы хотите понять, почему. С помощью Live Tail можно понять, какой IP-адрес соединяется с сервером и отследить, что происходит с трафиком данного приложения:

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

• Добавляем ключевое слово, например, имя вебсайта
• Добавляем log_type для сужения области отслеживания, в данном случае Apache
• Добавляем фильтр, чтобы убедиться, что мы отслеживаем только те логи, где есть поле remote_host
• Добавляем колонку remote_host, чтобы видеть в реальном потоке, с какими хостами происходят соединения

Перейти в представление Live Tail можно по кнопке в правом верхнем углу раздела Export Logs:

Любой запрос можно добавить в Избранное (создать Favorite Query), после чего его можно выбирать для отслеживания в режиме Live Tail:

Для фильтрации можно использовать составные фильтры по множеству условий:

Ключевое слово подсвечивается в самом логе:

Live stream можно останавливать и запускать снова, а элементы лога можно развернуть, чтобы посмотреть детали записи:

Отображаемые колонки можно добавлять и удалять:

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

Помимо функций Live Tail, в июньском релизе были также добавлены новые дэшборды и запросы для AWS и Azure.

Так теперь выглядят новые интеграции для AWS:

Например, вот дэшборд EventBridge Overview:

А вот все дэшборды для EventBridge:

Ну а вот так выглядят новые интеграции для Azure:

Если вы хотите попробовать поработать с VMware vRealize Log Insight в облаке AWS или Azure, то VMware предоставляет пробную версию на 30 дней.

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

Вильям Ламм рассказал о простом способе ограничения доступа к UI клиента vSphere Client. Делается это через настройки сервера Apache Tomcat, на базе которого построен виртуальный модуль vCenter Server Appliance. Называется это Access Control Valve - по ссылке можно подробно изучить опции, которые можно применять, а мы же рассмотрим простой пример ниже.

Идем по SSH на vCSA и открываем там следующий файл:

/usr/lib/vmware-vsphere-ui/server/conf/context.xml 

В него добавляем следующую запись:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

Значения x.x.x.x, y.y.y.y и далее за ними можно указать как разрешенные адреса для соединения с сервером. Блок "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" должен присутствовать всегда для обеспечения локального соединения сервисов самого vCenter.

Адреса, не занесенные в этот список, при соединении через веб-браузер получат 403 ошибку, при этом доступ через PowerCLI и API останется для этих адресов (поскольку это только настройка веб-сервера):

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

service-control --restart vsphere-ui

Компания VMware рассказала о том, что поменяется в содержательной части главного события года в сфере виртуализации в этом году - конференции VMworld 2021, которая пройдет 5-7 октября этого года. Перед этим мероприятием VMware получила около 1500 заявок на выступления и доклады от всех участников своей экосистемы (заказчики, партнеры, технические специалисты и блоггеры).

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

• Основной фокус будет сделан на заказчиках VMware, которые могут поделиться примерами использования продуктов и технологий из реальной жизни.
• Будет больше экспертных сессий с глубоко техническим контентом, для которых предусмотрен специальный билет Tech+. Он позволит больше общаться с экспертами и иметь доступ к документам уровня "deep dive".
• Бизнес и технические сессии будут разделяться по уровням сложности 100 и 200, также будут специальные технические сессии повышенной сложности с уровнем T300.
• Вернутся технические сессии, касающиеся VMware Design Studio и VMware {code} - об этом просили многие участники.
• Сессии можно будет также искать по метатемам, таким как управление несколькими облаками, защита современных приложений и облачных сервисов, использование перспективных технологий и т.п.

Не обойдется и без таких тем, как diversity, equity, inclusion и sustainability (хотя не очень понятно, как они относятся именно к виртуализации - но, видимо, у VMware уже есть и какая-то социальная миссия).

Регистрация на VMworld 2021 будет открыта с 15 июня по этой ссылке. Кстати, интересно, что прошлый VMworld Online посетили боле 100 тысяч участников.

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

Спешим поделиться важными новостями. Наряду с брендом «ИТ-ГРАД» на всех наших площадках в социальных сетях будет использоваться бренд #CloudMTS — с начала июня публикации на корпоративных ресурсах продолжатся от его имени.

Объединенная техническая команда облачных провайдеров готова еще активнее делиться накопленным опытом, экспертизой и ИТ-инсайтами. Это значит, что наши социальные сети, блоги и рассылки станут еще интереснее и полезнее. А экспертного контента, отраслевых активностей, акций и спецпредложений будет еще больше. Читайте нас, рекомендуйте коллегам и друзьям!

• Facebook
• Vkontakte
• Twitter
• Telegram
• Zen.yandex
• LinkedIn
• Habrahabr
• YouTube

Подробнее на сайте компании ИТ-ГРАД.

Многие Enterprise-администраторы настраивают автоматический регулярный бэкап решения для виртуализации и агрегации сетей VMware NSX-T из консоли, что описано, например, вот тут.

Между тем, как правильно заметил автор virten.net, при неудачном завершении задачи резервного копирования администратор не получает нотификации даже в дэшборде в разделе алармов.

В случае падения задачи бэкапа информация об этом доступна только в разделе Backup & Restore настроек:

Эту информацию можно получить и через API:

> GET /api/v1/cluster/backups/history HTTP/1.1
{
  "cluster_backup_statuses": [
    {
      "backup_id": "5cf21742-091a-b9b9-1f24-ad75ede2d23b-1615489436",
      "start_time": 1615489436085,
      "end_time": 1615489440865,
      "success": false,
      "error_code": "BACKUP_AUTHENTICATION_FAILURE",
      "error_message": "either backup server login failed or unauthorized access to backup directory"
    }
  ],
  "node_backup_statuses": [
    {
      "backup_id": "5cf21742-091a-b9b9-1f24-ad75ede2d23b-1615403036",
      "start_time": 1615403036017,
      "end_time": 1615403354709,
      "success": true
    }
  ],
  "inventory_backup_statuses": [
    {
      "backup_id": "inventory-1615490636",
      "start_time": 1615490636254,
      "end_time": 1615490641758,
      "success": true
    }
  ]
}

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

Коллега с virten.net написал сценарий на Python для Nagios, который позволит вам проверить статус последнего бэкапа кластера NSX-T, а также посмотреть возраст последней имеющейся резервной копии:

usage: check_nsxt_backup.py [-h] -n NSX_HOST [-t TCP_PORT] -u USER -p PASSWORD
                            [-i] [-a MAX_AGE]

# python check_nsxt_backup.py -n nsx.virten.lab -u audit -p password
NSX-T cluster backup failed
NSX-T node backup is to old (1461 minutes)

На сайте Вильяма Лама есть специальный раздел, посвященный вложенной виртуализации (Nested Virtualization) на базе гипервизора VMware ESXi. В частности, Вильям делает сборки ESXi, которые уже подготовлены к использованию в качестве виртуальных машин как виртуальные модули (Virtual Appliances) в формате OVA. Это может понадобиться для тестовых сред, когда вам нужно развернуть большую инфраструктуру и сделать полноценный кластер, а в распоряжении есть только 1-2 физических сервера.

Также обратите внимание на наш пост о библиотеке Content Library с шаблонами виртуальных модулей Nested ESXi от Вильяма. Адрес для подписки на эту библиотеку следующий:

https://download3.vmware.com/software/vmw-tools/lib.json

Кстати, все статьи о вложенной виртуализации можно найти и у нас по тегу Nested.

Если вы часто имеете дело с технической поддержкой VMware, то знаете, что довольно часто требуется собирать с хостов VMware ESXi дампы. Нередко администраторы настраивают удаленную отсылку дампов на сервер VMware vCenter Server Appliance (vCSA). По умолчанию размер раздел для дампов на нем равен 2 ГБ, что может оказаться мало, если инфраструктура у вас большая.

Вильям Лам задался этим вопросом и вспомнил, что есть такая настройка Repository max size в разделе ESXi Dump Collector для старого клиента vSphere Web Client:

Между тем, в новый vSphere Client на базе HTML 5 эту настройку не перенесли. Поэтому если вы используете VMware vCSA версий 6.7 или 7.0 с новым клиентом, то вам нужно открыть файл /etc/sysconfig/netdumper и изменить там следующий параметр:

NETDUMPER_DIR_MAX_GB 

Максимальный его размер может составлять 10GB.

После изменения размера раздела для дампов нужно перезапустить сервис дампера. На vCSA 7 делается одной командой:

service-control --restart vmware-netdumper

На vCSA 6.7 двумя:

service-control --stop vmware-netdumper
service-control --start vmware-netdumper

В 2014 году мы писали о продукте Horizon View Event Notifier, который предназначен для отправки администраторам писем по протоколу SMTP с различными алертами, произошедшими в VMware View.

Утилита соединяется с одной или несколькими базами данных Horizon View Event Database, вытаскивает оттуда выбранные администратором события (ошибки, предупреждения, инфо) и шлет письма на указанный email-адрес. При этом поддерживается возможность работы с несколькими БД, что позволяет собирать алерты с разных инсталляций VMware View (они же View Pods).

Спустя 7 лет, на сайте проекта VMware Labs неожиданно вышло обновление этой утилиты - появился Horizon Event Notifier 1.5. Что там нового:

• Изменено название с Horizon View Event Notifier на Horizon Event Notifier
• Изменена иконка и некоторые графические ресурсы
• Нотификации приходят в локальном формате времени, где запущена утилита
• Алерты теперь видны в интерфейсе
• Совместимо и протестировано с VMware Horizon 2103 (вышел в марте этого года)

Скачать VMware Horizon Event Notifier 1.5 можно по этой ссылке.

Некоторое время назад мы писали о новой версии решения VMware Cloud Foundation 4.2 (VCF), которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager. 

На днях VMware сделала небольшое обновление этого пакета - VMware Cloud Foundation 4.2.1, давайте посмотрим, что там нового:

• Обновления безопасности для Photon OS в SDDC Manager 4.2.1 (пакет PHSA-2021-3.0-185 обновлен до PHSA-2021-3.0-209 - подробнее тут).
• Критические обновления безопасности для VMware vCenter Server Appliance (мы писали об уязвимости тут).
• Обновление некоторых версий продуктов в составе пакета.

Новый Bill of Materials включает в себя следующие версии решений VMware:

Для пользователей пакета версии 3.10.2 также есть обновление - VCF 3.10.2.1, о нем прдробно рассказано вот тут. Вот его Bill of Materials:

Об обновлении подсистемы безопасности VMware vCenter Server Appliance 6.7 Update 3n рассказано тут.

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

Итак, для начала выводим список доступных USB-интерфейсов на сервере:

esxcli hardware usb passthrough device list

У Вильяма в списке 2 USB-хранилища (их пары VendorId:ProductId имеют значения 90c:2000 и 90c:1000):

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

esxcli hardware usb passthrough device disable -d 2:7:90c:1000

После этого будет вот такая картина:

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

Сначала добавляем расширенную настройку (Advanced Setting) на хосте ESXi, чтобы он принимал SSD-диски, подключенные к USB:

esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1

Теперь нужно создать SATP-правило, которое помечает наше USB-устройство как SSD-диск. Для этого нужно получить имя устройства с помощью команды:

vdq -q

Затем создаем переменную с именем устройства, например:

DEVICE_NAME="t10.JMicron_Generic_________0123456789ABCDEF"

Затем выполняем следующие команды для создания SATP-правила и перезагрузки устройства, которое подцепится как SSD-хранилище:

esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device=${DEVICE_NAME} --option=enable_ssd

esxcli storage core claiming unclaim --type device --device=${DEVICE_NAME}

esxcli storage core claimrule load

esxcli storage core claimrule run

Теперь устройство можно использовать как SSD-диск для vSAN или VMFS. Если хотите использовать его для vSAN, то нужно включить соответствующую расширенную настройку командой:

esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

После этого вы сможете увидеть данное устройство в выводе команды vdq -q как совместимое для vSAN, на котором можно создавать дисковые группы:

Если же вы хотите использовать этот SSD-диск как хранилище VMFS, то нужно сначала создать том, чтобы он был виден в интерфейсе vSphere Client.

Создаем переменную с полным путем к устройству:

DEVICE_PATH="/vmfs/devices/disks/t10.JMicron_Generic_________0123456789ABCDEF"

Далее выполняем команду, которая разметит наш том как VMFS:

partedUtil mklabel ${DEVICE_PATH} msdos

END_SECTOR=$(eval expr $(partedUtil getptbl ${DEVICE_PATH} | tail -1 | awk '{print $1 " \\* " $2 " \\* " $3}') - 1)

/sbin/partedUtil "setptbl" "${DEVICE_PATH}" "gpt" "1 2048 ${END_SECTOR} AA31E02A400F11DB9590000C2911D1B8 0"

/sbin/vmkfstools -C vmfs6 -b 1m -S $(hostname -s)-local-usb-ssd-datastore ${DEVICE_PATH}:1

Если все в порядке, вы увидите новый том в списке VMFS-томов в vSphere Client:

Дункан Эппинг написал интересный пост о том, что в кластере VMware HA есть возможность сделать хостам ESXi такую настройку, чтобы они выбирались как Primary при конфигурации/реконфигурации кластера. Это может оказаться полезным, например, в растянутом (Stretched) кластере, когда вам важно, чтобы Primary-хосты находились на основной площадке с целью ускорения процесса восстановления после сбоя (речь идет о 2-3 секундах в большинстве случаев, но для некоторых инфраструктур это может быть критично).

Пост этот актуален еще и потому, что настройки несколько изменились, начиная с VMware vSphere 7 Update 1, поэтому информация об этом может быть полезна для администраторов.

Прежде всего, в статье VMware KB 80594 рассказывается о том, какие настройки были изменены в механизме VMware FDM (он же HA). Самое главное, что до vCenter 7 Update 1 настройки хранились в файле /etc/opt/vmwware/fdm/fdm.cfg, теперь же они переехали в ConfigStore, работать с которым нужно путем импорта и экспорта json-файлов конфигурации.

Вот, кстати, интересующая нас табличка с изменениями параметров Advanced Settings в FDM:

Нас здесь интересует настройка node_goodness, большое численное значение которой и определяет, будет ли данный узел выбран как Primary (ранее в HA он также назывался Master).

Итак, Дункан показывает, как можно экспортировать расширенные настройки из ConfigStore:

configstorecli config current get -g cluster -c ha -k fdm
{
   "mem_reservation_MB": 200,
   "memory_checker_time_in_secs": 0
}

Все это можно также экспортировать в json-файл командой:

configstorecli config current get -g cluster -c ha -k fdm > test.json

Далее добавляем в этот json параметр node_goodness с большим значением, например, 10000000:

{
    "mem_reservation_MB": 200,
    "memory_checker_time_in_secs": 0,
    "node_goodness": 10000000
}

И импортируем его обратно в ConfigStore:

configstorecli config current set -g cluster -c ha -k fdm -infile test.json

В итоге хост ESXi 1507 был Primary:

А затем им стал узел 1505, для которого мы изменили данную расширенную настройку:

Ну и Дункан записал небольшое видео, раскрывающее весь процесс изменения данных настроек в VMware FDM / HA:

Компания VMware анонсировала новую возможность KB Insights, которая стала доступна в облачной версии решения для аналитики лог-файлов и мониторинга инфраструктуры VMware vRealize Log Insight Cloud.

С помощью KB Insights можно проанализировать проблемы облачной виртуальной инфраструктуры, которые выявляются вследствие анализа логов, и получить соответствующие ссылки на статьи VMware Knowledge Base и VMware Community, которые помогут в их решении.

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

Вот пример аналитики Log Insight Cloud, которая выявила проблемы по недоступности виртуальной машины в сети, случавшейся время от времени:

Оказалось, что эта проблема связана с дублированием IP-адреса в какой-то момент. Функция KB Insights предложила как ветку обсуждений этой проблемы на VMware Community, так и релевантную статью базы знаний "Duplicate IP address detected (1020647)".

Статья KB рассказывает о том, как изменить IP-адрес для найденного MAC-адреса устройства, а вот статья на комьюнити рассказывает о том, как найти второй сервис, где торчит тот же самый IP-адрес, чтобы решить, какой из адресов нужно поменять. Это решение, конечно же, дает администратору больше гибкости:

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

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

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

Источник.

Весной этого года мы писали о двух критических ошибках безопасности в сервисах VMware Carbon Black и VMware vCenter - тут и тут, соответственно. В свое время для них были выпущены патчи, закрывающие эти уязвимости. Но, надо сказать, что это далеко не единственные критические моменты в инфраструктуре безопасности vCenter - на днях VMware опубликовала патчи к VMSA-2021-0010 (сообщения CVE-2021-21985 и CVE-2021-21986).

Суть уязвимости заключается в том, что в плагине Virtual SAN Health Check есть дыра в процедуре валидации ввода данных, которая позволяет злоумышленнику получить доступ к удаленному исполнению кода через vSphere Client. CVSSv3 base score этой уязвимости максимальный - 9.8, поэтому нужно обновлять серверы vCenter прямо сейчас.

Если вы не используете VMware vSAN, у вас все равно эта дырка есть, так как плагин vSAN идет вместе с установкой vCenter по умолчанию. Затронуты, кстати, vCenter версий 6.5, 6.7 и 7.0 и их обновления, то есть все самые актуальные на текущий момент. Компания VMware создала по данной уязвимости специальный FAQ.

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

Также по данной уязвимости на VMware Communities есть специальный трэд.

Итак, теперь, собственно, какие патчи вам надо накатить (полное описание находится здесь):

• Для VMware vCenter 7.0 накатываем vCenter 7.0 Update 2b (вот тут)
• Для vCenrer 6.7 накатываем vCenter 6.7 Update 3n (вот тут)
• Для vCenrer 6.5 накатываем vCenter 6.5 Update 3p (вот тут)

VMware настойчиво рекомендует сделать обновление прямо сейчас, чтобы злоумышленники и всякое ransomware не добавили вам проблем, например, перед летним отпуском:)

На днях компания StarWind, ведущий производитель средств для создания программно-аппаратных хранилищ под виртуализацию, выпустила новую версию своего флагманского продукта - StarWind Virtual SAN v8 for Hyper-V (build 14120). Надо отметить, что в конце марта этого года StarWind уже выпускала обновление Virtual SAN (build 14033), поэтому ниже мы расскажем о новых возможностях обеих версий.

Итак, что нового появилось в StarWind Virtual SAN v8 for Hyper-V в этом году:

1. Компоненты VTL и Cloud Replication

• Поддержка Microsoft Azure - добавлена опция по загрузке файлов в Archive tier напрямую, без необходимости сначала добавлять их в Hot/Cool tier и дальнейшего перемещения в архив.
• Возможность Write Protect для виртуальных кассет.
• Минимальный размер кассеты установлен в 50 МБ.
• Режим VTL file operation mode изменен на принудительное закрытие неиспользуемых файлов. Если в работе слишком много частей виртуальных кассет, то много открытых файлов могло привести к исчерпанию ресурсов. Изменить это поведение теперь можно в параметре closedatafiles в конфиге StarWind.cfg.
• Исправлена ошибка при восстановлении кассет, разделенных на части, из облака (некоторые части могли не загружаться).
• Пофикшена ошибка в cloud replication, которая могла возникать, если установлена опция "Create new empty tapes automatically when existing tape removed from VTL for replication". Если она была включена, это могло привести к падению сервиса при создании новой виртуальной кассеты.

2. Улучшения синхронной репликации

• Исправлена ошибка с отклонением синхронизации HA-узла при перезапуске сервиса на одном из узлов (иногда процедура не стартовала автоматически).
• Исправлена ошибка, приводившая к падению сервиса в случае, если соединение с хранилищем или сетевое соединение испытывало падение производительности.
• Исправлена реализация алгоритма Node Majority failover strategy. Ранее она работала некорректно в случае, если соединение между узлами было нарушено, но только в одну сторону.
• Пофикшена процедура автоматического восстановления для трехсторонней репликации. Ранее она использовала информацию от двух из трех узлов, что некорректно для процедура auto-restore. Теперь учитывается статус от всех трех узлов.
• Поправлено некорректное поведение при операции расширения размера хранилища на узле. Это приводило к разрыву соединения для некоторых случаев, когда операции по работе с хранилищем занимали продолжительное время.
• Исправлена ошибка, которая вела к полной синхронизации вместо быстрой в некоторых случаях.
• Исправлена ошибка с обработкой IO-запросов на одном из хранилищ, приводившая к тому, что в случае зависания запроса на конфигурации с three-way репликацией происходила некорректная работа на всех трех узлах.

3. Основные улучшения

• Улучшения производительности для версии VSA (Virtual Storage Appliance).
• Исправлена проблема с закрытием сессии в случаях, когда обнаруживался критический недостаток ресурсов.
• Исправлена проблема с обработкой операции control connection close - в некоторых случаях это приводило к генерации большого числа нотификаций, а Management Console переставала отвечать.
• Исправлена процедура session close при остановке службы - теперь она не зависает в некоторых редких случаях.
• Исправлена проблема с зависанием Management Console при накатывании бесплатной лицензии на сервер без интернет-соединения.
• Было обновлено лицензионное соглашение.

4. StarWindX PowerShell Module

• Физические устройства теперь есть в общем списке устройств. Их можно использовать для экспорта с физических ленточных устройств.
• Добавлено свойство MaintenanceMode для объекта HA Device.

Загрузить пробную версию StarWind Virtual SAN v8 for Hyper-V можно по этой ссылке. Документация доступна здесь, а Release Notes - вот тут.

Отметим также, что обновился и продукт в формате виртуального модуля для платформы VMware - StarWind VSAN for vSphere (OVF Version 20210520, Version 8 build 14120). Release notes доступны тут (список улучшений там практически такой же, за исключением некоторых моментов в мартовской версии).

На сайте проекта VMware Labs появилась запись о том, что утилита App Volumes Packaging Utility 1.3 теперь официально включена в состав VMware App Volumes 4, version 2103. Такое иногда происходит с утилитами проекта Labs, некоторые из которых становятся либо самостоятельными продуктами, либо включаются в состав уже существующих решений.

Напомним, что Packaging Utility позволяет упаковывать приложения для использования с App Volumes. С помощью нее можно добавить необходимые метаданные в приложение MSIX на базе дисков VHD таким образом, чтобы их можно было использовать вместе с пакетами формата AV. Получившиеся VHD формата MSIX будут требовать App Volumes 4 версии 2006 или более поздней, а также Windows 10 версии 2004 или более поздней.

Соответственно сам продукт App Volumes был обновлен, давайте посмотрим на его новые возможности:

• Теперь при установке App Volumes Manager можно выбрать пункт "App Volumes Tools" при установке на машину с Windows 10, который и устанавливает Packaging Utility. Далее с помощью команды appcapture.exe можно упаковывать приложения без необходимости использования консоли App Volumes Manager. С помощью appcapture можно автоматизировать процессы упаковки приложений для установщиков в silent-режиме, которые можно получать как в VMDK, так и в VDH форматах (причем одновременно). С помощью appcapture можно конвертировать пакеты между форматами VHD and VMDK, а также работать с пакетами формата MSIX.
• Теперь есть возможность использовать глобальную настройку, позволяющую использовать пакет на любой ОС Windows 10. В Advanced Settings можно поставить галочку, которая отключает проверку, что та же самая версия ОС использовалась для создания пакета и его доставки в рабочее окружение пользователя.
• Интервал Import Storage Groups по умолчанию был увеличен с 15 минут до 4 часов, чтобы позволить задаче закончить обработку большого числа пакетов на медленных хранилищах. Этот параметр можно изменить в настройках.
• На странице Managed Storage Locations хранилище может быть помечено как read-only. В этом случае App Volumes Manager пропускает это хранилище, когда обновляет пакет или AppStack. Так как App Volumes регулярно записывает дополнительные метаданные в пакеты, чтобы отслеживать их обновления, эта опция оказывается очень полезной для некоторых хранилищ.
• Также была обновлена подсистема безопасности и исправлены ошибки.

Загрузить VMware App Volumes 4, version 2103 со встроенной утилитой App Volumes Packaging Utility 1.3 можно по этой ссылке.

Недавно мы писали о VM Service - службе, которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин. Она была анонсирована в vSphere 7 Update 2a.

Многие пользователи жалуются, что консоль виртуальных машин, развернутых через VM Service в кластере vSphere with Tanzu, оказывается недоступна для логина, даже для администраторов. Над этой проблемой работают, но пока в интерфейсе это выглядит так:

Между тем, попасть в консоль иногда нужно (например, для отладки или траблшутинга) - и для этого есть воркэраунд.

Итак, заходим по SSH на VMware vCenter Server Appliance (vCSA) и выполняем следующие команды, которые получают root-пароль от Supervisor Cluster, выводят его в консоли и инициируют сессию к одному из узлов супервизор-кластера:

SV_DECRYPT_OUTPUT=$(/usr/lib/vmware-wcp/decryptK8Pwd.py)

SV_CLUSTER_IP=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'IP: ' '{print $2}' | awk '{print $1}')

SV_CLUSTER_ROOT_PASSWORD=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'PWD: ' '{print $2}' | awk '{print $1}')

echo -e "\n${SV_CLUSTER_ROOT_PASSWORD}\n"

ssh root@${SV_CLUSTER_IP}

Далее, после того, как мы залогинились в Supervisor Cluster, нужно получить креды от нужного нам узла. Делается это следующим набором команд:

VM_SERVICE_ACCOUNT_USERNAME=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.password}' | base64 -d)
VM_SERVICE_ACCOUNT_PASSWORD=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.username}' |base64 -d)
echo -e "\n${VM_SERVICE_ACCOUNT_PASSWORD}\n${VM_SERVICE_ACCOUNT_USERNAME}\n"

После этого заходим в vSphere Client под этими кредами и функция запуска консоли для данной ВМ вам будет доступна:

Источник.

На сайте проекта VMware Labs обновился Community Networking Driver for ESXi до версии 1.2. Этот пакет представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe.

С момента того, как мы впервые писали об этом пакете драйверов, вышли их версии 1.1 и 1.2 - давайте посмотрим, что в них появилось нового:

• Поддержка больших пакетов Jumbo Frames (размер MTU до 9000)
• Поддержка механизма Wake-on-LAN (WOL) для устройств Intel i225 NIC
• Исправлена проблема для карточек Intel vPro, которая могла приводить к "розовому экрану смерти" (PSOD) на ESXi

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

Установить драйвер можно с помощью команды:

esxcli software vib install -d /path/to/the offline bundle zip

После этого нужно обязательно перезагрузить ваш ESXi, до перезагрузки сетевой адаптер работать не будет.

Скачать Community Networking Driver for ESXi 1.2 можно по этой ссылке.

На сайте проекта VMware Labs появилась еще одна утилита в сфере Machine Learning, которая может оказаться полезной некоторым Enterprise-администраторам, работающим с высокопроизводительными системами. Средство Resource-Efficient Supervised Anomaly Detection Classifier представляет собой ресурсно-эффективный классификатор для обнаружения аномалий запросов, который дополняет алгоритмы Random-Forest и XGBoost. По сравнению с упомянутыми средствами, VMware заявляет меньший объем используемой памяти и более эффективное использование CPU.

Цель данной утилиты - быстро натренировать небольшую модель таким образом, чтобы она корректно классифицировала большинство запросов. Далее, используя полученную универсальную модель, можно создавать более сложные экспертные ML-модели, натренированные на исключительные случаи.

Для работы алгоритма на Python вам потребуется наличие следующих компонентов:

• CMake 3.13 или выше
• numpy
• pandas
• sklearn
• xgboost

Скачать Resource-Efficient Supervised Anomaly Detection Classifier можно по этой ссылке.

Когда вышло обновление VMware vSphere 7 Update 2, мы рассказывали о новых оптимизациях для процессоров AMD EPYC, которые были сделаны в платформе виртуализации на базе гипервизора ESXi. Реализация поддержки новых функций CPU идет в соответствии с развитием технологий аппаратной виртуализации AMD, которую VMware поддерживает наравне с таковой от Intel.

Недавно VMware выпустила отдельный документ "Performance Optimizations in VMware vSphere 7.0 U2 CPU Scheduler for AMD EPYC Processors", где рассказано, какие были сделаны оптимизации, и как именно они влияют на увеличение производительности:

В документе есть много интересных тестов (большинство из них сделано с помощью утилиты VMmark3), приведем ниже результаты некоторых из них:

• Увеличение производительности одной ВМ для БД Microsoft SQL Server под нагрузкой HammerDB (тут и далее нормировано к показателям vSphere 7 Update 1):

• Несколько виртуальных машин с 8 vCPU на борту и нагрузкой HammerDB - производительность при увеличении числа виртуальных машин на хосте:

Использование базы данных CockroachDB на 6-узловом кластере, прирост производительности до 50%:

Тестирование кластера Kubernetes c узлами по 64 воркера с помощью бенчмарка Weathervane (на 16 инстансах приложений прирост производительности - более 40%):

В общем, документ очень интересный - посмотрите.

Оказывается у VMware есть утилита TENS, что расшифровывается как Traffic Emulator for Network Service. Это еще один эмулятор сетевой нагрузки от VMware, который, в отличие от аналогов, сфокусирован на паттернах нагрузки, а не только на генерации объема и интенсивности сетевого потока. В основном, подобные средства предназначены для того, чтобы выяснить максимальные параметры сетевой нагрузки, которые могут выдержать те или иные компоненты. Кроме того, при генерации нагрузки эти средства, как правило, работают с одним приложением, когда речь идет о задании паттернов.

VMware же решила сделать утилиту для симуляции паттернов нагрузки для нескольких приложений, чтобы изучать их поведение в условиях, приближенных к реальным. Проект TENS распространяется как Open Source и доступен в репозитории на GitHub.

Продукт состоит из двух компонентов:

• Traffic Engine Controller (TEC) - это мозг всей системы, который управляет распределенными воркерами (их может быть сколько угодно) и предоставляет доступ сторонним системам через API.
• Traffic Engines Datapath (TE-DP) - компоненты непосредственно эмулирующие трафик нагрузки в соответствии с реальными паттернами.

TENS может эмулировать несколько браузерных сессий, клиентов, соединений и запросов на уровнях L4 и L7. Это позволяет заполнить разрыв между тестовым окружением, предпроизводственной средой, которую надо хорошо оттестировать, и производственным окружением, где приложения должны выдерживать требования к нагрузке по TCP/HTTP/UDP. Также TENS выводит отчет о метриках и ошибках для компонентов тестируемой системы.

Основные возможности VMware Traffic Emulator for Network Service:

• Функции для валидации и отчетности серверов балансировки нагрузки и серверов приложений.
• Генерация трафика от нескольких пользователей, нескольких сессий одного пользователя и нескольких соединений/запросов в рамках одной сессии - все это для нескольких вычислительных узлов.
• Комплексные метрики, выявление аномалий и мониторинг в реальном времени с одного узла с возможностью сообщения об ошибках как на уровне L4 (TCP/UDP), так и на L7 (HTTP/HTTPS).
• Возможность генерации L7-траффика с разных исходных IP и пространств имен, с внедренными куками, хэдерами и параметрами запросов в измерениях RPS, TPS, TPUT и CPS.
• Возможность запуска в нескольких процессинговых узлах, которые контролируются единой точкой доступа через API.
• Поддержка трафика http/1, http/1.1 и http/2 на уровне L7.
• Поддержка SSL версий SSLv2, SSLv3, TLSv1, TLSv1.0, TLSv1.1, TLSv1.2 и TLSv1.3 на уровне L7.
• Поддержка взаимной аутентификации сервер-клиент за счет проверки сертификатов на уровне L7.
• Возможность эмуляции аплоадов и загрузок больших UDP-датаграмм с несколькими одновременными подключениями на уровне L4.
• Утилита TENS упакована для использования в контейнеризованных системах - как в облачных, так и онпремизных.
• Возможность управлять утилитой через REST API для автоматизации операций и интеграции в общую инфраструктуру рабочих процессов тестирования.
• Поддержка SSL session reuse и persistence validation, что позволяет более безопасно организовывать процесс тестирования.

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

Весной этого года Edisoft и ИТ-ГРАД провели совместный вебинар в формате воркшопа, где рассказали о трендах автоматизации и роботизации бизнес-процессов, а также наглядно показали: как можно заменить человеческий труд при обработке данных и документов программными роботами и облачными решениями.

Недавно на сайте проекта VMware Labs обновилась утилита App Volumes Entitlement Sync до версии 4.4. Напомним, что она позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать. В прошлый раз мы писали об этом средстве вот тут.

Давайте посмотрим, что нового в Entitlement Sync 4.4 и других версиях, вышедших после 4.1:

• Возможность обработки очень больших JSON-файлов (когда у вас много приложений и пакетов, он получается большой).
• Полностью переработанный механизм сравнения приложений и пакетов с возможностью исправления связей на реплицируемых сайтах
• Предыдущий пункт работает хорошо для формата репликации App Volumes 4.3+, но в целом подходит для любой версии 4.x.
• Поддержка сравнения GUID на основной и резервной площадках в целях индентификации GUID приложений.
• Полностью обновленный механизм логирования - данные записываются в %temp%. Теперь их много, что позволяет лучше проводить траблшутинг процесса.
• Нереплицируемые приложения больше не помечаются как ошибки в консоли.
• Улучшенный механизм постпроцессинга репликации.

Загрузить последнюю версию App Volumes Entitlement Sync можно по этой ссылке.

Несколько недель назад компания VMware выпустила обновление своего основного средства кросс-облачного восстановления виртуальных сред VMware Cloud Disaster Recovery. В новой версии появилось несколько полезных важных возможностей, о которых мы расскажем ниже. Напомним, что ранее у VMware было средство Cloud-to-Cloud Disaster Recovery, функции которого вошли в это обновление.

Давайте посмотрим, что появилось в VMware Cloud DR:

1. Cloud-to-Cloud DR - поддержка VMware Cloud on AWS SDDC в качестве исходного сайта

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

2. Двухузловая конфигурация Pilot Light

Pilot Light - это схема, которую пользователи большой инфраструктуры VMware используют для уменьшения RTO (Recovery Time Objective) в случае сбоев. Для этого развертывается небольшое горячее окружение, которое всегда готово принять на себя нагрузку производственной среды. Теперь минимальный размер этого окружения сократился с 3 до 2 хостов, что дает меньшую цену входа в эту схему.

3. Управление несколькими инстансами из одной консоли

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

4. Новые географии

Теперь для решения Cloud DR доступны Сан-Паулу, Сеул и Стокгольм. Общая карта регионов теперь выглядит так (всего их 16):

5. Комплаенс HIPAA BAA

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

Более подробно о решении VMware Cloud Disaster Recovery можно узнать на этой странице.

Не так давно мы писали о механизме VMware vSAN Enhanced Durability, который позволяет еще больше защитить кластер хранилищ от аварий и сбоев, которые могут происходить не в один момент, а друг за другом на протяжении некоторого времени.

Дункан Эппинг рассказал о том, что происходит, если в нем всего три хоста. Например, если у вас есть 2 площадки, по три хоста ESXi на каждой, но в случае сконфигурированной политикии SFTT=1 (это Stretched FTT) у вас получается RAID-1 для дисковых объектов виртуальной машины на каждой из площадок:

При этом два хоста хранят в себе Data Component виртуальной машины, а третий хост работает для нее как Witness на случай изоляции одного из хостов кластера. Теперь возникает вопрос - а что произойдет с механизмом Enhanced Durability, если один из хостов перевести в Maintenance Mode? Где будет создаваться Durability Component (он хранит все поступающие операции записи Write IO), который защищает машину от сбоя на уровне площадки при переведенном в режим обслуживания хосте?

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

Ну и небольшое демо процесса тестирования механизма Enhanced Durability в этих условиях от Дункана:

На сайте проекта VMware Labs обновилась интересная и полезная многим Enterprise-админстраторам утилита Forklift for Workspace ONE UEM (она же Workspace ONE UEM Workload Migration Tool) - ее третья версия вышла в начале мая. О первой версии этого средства мы писали еще два года назад вот тут.

Forklift for Workspace ONE UEM позволяет провести бесшовную миграцию конфигураций приложений и устройств между различными окружениями Workspace One UEM (например, тестовой средой и производственной). Ее возможности включают в себя:

• Миграцию приложений, профилей, сенсоров (Sensors), скриптов объектов Windows 10 Baselines Continuous Delivery pipelines как часть решения для создания/обновления и апгрейда ресурсов из сред разработчиков в производственные среды.
• Шаблоны экспортируемых/импортируемых ресурсов в виде контейнеров для быстрого их развертывания в среде UEM.

Forklift for Workspace ONE UEM представляет собой набор из двух связанных контейнеров, вспомогательные скрипты для их запуска, а также Docker Compose file, чтобы обеспечивать связь этих контейнеров.

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

• Поддержка более чем одного окружения (исходного и целевого)
• Поддержка MST и иконок для миграции приложений Windows 10
• Поддержка приложений размером более 2 ГБ
• Поддержка сенсоров и сценариев при миграции
• Поддержка объектов Continuous Delivery Pipelines

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

Еще в 2019 году компания VMware анонсировала утилиту VMware Usage Meter 3.6.1 для vCloud Availability 3.x, которая позволяла автоматически измерять потребление облачных ресурсов и создавать отчеты на помесячной основе. Предназначено это для облачных провайдеров, предоставляющих услуги аренды виртуальных машин по модели IaaS. На днях была анонсирована новая версия Usage Meter 4.4, которая расширяет функциональность версии 3.6.1.

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

1. Ежемесячные отчеты

Новая возможность Usage Meter позволяет привязать метку (label) к каждому клиенту и на базе нее отслеживать потребление ресурсов, формируя ежемесячные отчеты. Это делается за счет применения механизма правил к объектам vCenter или VMware Cloud Director.

2. Поддержка LDAP

Теперь облачные администраторы могут залогиниться в виртуальный модуль Usage Meter с использованием аутентификации LDAP. Более подробно об этом можно почитать вот тут.

3. Офлайн отчеты

Ранее отчеты UM были доступны только после утверждения со стороны поддержки VMware, теперь же они доступны всем. Настроить их можно при развертывании виртуального модуля vCenter Server в формате OVA, где можно настроить обход валидации Usage Insight registration.

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

4. Улучшения механизма апгрейда

В прошлом апгрейд Usage Meter 4.X использовал файл SHAR, который загружался в Usage Meter, после чего выполнялся скрипт апгрейда. Теперь в версии 4.4 для этого используется ISO-образ, который можно привязать к любому виртуальному модулю Usage Meter 4.1+ и выполнить сценарий из ISO-образа как Root.

Ну и напоследок небольшое обзорное видео о развертывании Usage Meter:

Для использования возможностей Usage Meter вам нужно переключиться на Flex Pricing Model, что является обязательным требованием:

Скачать VMware Usage Meter 4.4 можно по этой ссылке.