Интересная штука появилась на GitHub - проект VMware Community Homelabs от Вильяма Лама, в котором описаны конфигурации и стоимость аппаратных тестовых лабораторий участников комьюнити VMware, которые они строят у себя дома или где-либо еще за свои деньги.
Самая бюджетная (кстати, у Вильяма Лама) лаба стоит 800 долларов, самая дорогая - 150 000 долларов, средняя - 1152 доллара. Вот так выглядит схема домашней лаборатории почти за 10 миллионов рублей:
А вот за 50 тысяч рублей:
Свою домашнюю лабораторию вы можете добавить в список с помощью вот этой странички.
На Reddit коллеги заметили, что при включении технологии Turbo Boost в процессорах Intel, из виртуальной машины увеличения производительности не наблюдается. Напомним, что Turbo Boost — это технология компании Intel для автоматического увеличения тактовой частоты процессора свыше номинальной, если при этом не превышаются ограничения мощности, температуры и тока в составе расчётной мощности (TDP).
При этом емкость CPU показывается прежней, даже при создании существенной нагрузки на процессор:
В комментариях люди правильно отвечают, что поскольку Turbo Boost - это аппаратная возможность, гостевая система виртуальной машины не ловит отображение увеличения аппаратной мощности в виртуальную машину. При этом если вы посмотрите на виртуальную машину с 4 процессорами 2.4 ГГц с уровня хоста ESXi с включенным Turbo Boost до 3 ГГц, вы увидите утилизацию процессора 4*3=12 ГГц.
То есть гостевая система вполне будет использовать преимущества этой технологии, но отображать утилизацию процессора она будет в соответствии с его номинальной мощностью.
Интересные вещи делает наш коллега Jorge de la Cruz. Он скрупулезно и дотошно делает полезные дэшборды в Grafana для платформы виртуализации VMware vSphere и решения Veeam Availability Suite, которые могут помочь администраторам в решении повседневных задач мониторинга и траблшутинга.
Чтобы сделать доступными функции визуализации этих метрик, вам потребуется развернуть следующие компоненты:
Коллектор и нативный плагин Telegraf к VMware vSphere - агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
InfluxDB - собственно, сама база данных, хранящая метрики.
Grafana - фреймворк, который используется для визуализации метрик из базы.
О том, как это все заставить работать, чтобы получать красивые дашборды, подробно написано вот тут и тут. Ниже мы лишь приведем примеры того, как это выглядит:
1. vSphere Overview Dashboard.
Здесь визуализуются все высокоуровневые параметры виртуальной инфраструктуры, такие как загрузка ресурсов кластера, заполненность хранилищ, состояние гипервизора и использование ресурсов виртуальными машинами.
Лайв-демо такого дэшборда доступно по этой ссылке.
2. vSphere Datastore Dashboard.
Тут можно найти все метрики, касающиеся хранилищ, включая параметры чтения и записи, и многое другое:
Лайв-демо такого дэшборда доступно по этой ссылке.
3. vSphere Hosts Dashboard.
Тут видны основные метрики с уровня хоста для каждого из серверов ESXi: конечно же, загрузка аппаратных ресурсов и сети, а также дисковые задержки (latency):
Лайв-демо такого дэшборда доступно по этой ссылке.
4. vSphere VMs Dashboard.
Здесь можно увидеть самые полезные метрики для всех виртуальных машин вашего датацентра. Здесь можно увидеть аптайм, загрузку системных ресурсов и сети, latency, счетчик CPU Ready и другое:
Лайв-демо такого дэшборда доступно по этой ссылке.
5. vSphere Hosts IPMI dashboard.
Этот дэшборд отображает информацию IPMI для серверов Supermicro и HPE, доступную через iLO. Пригодится, когда вам нужно взглянуть на статус ваших систем в распределенной инфраструктуре удаленных офисов и филиалов.
Кроме приведенных выше дэшбордов для VMware vSphere, у Jorge de la Cruz также есть несколько дэшбордов для решений Veeam Software:
Бывает так, что в вашей виртуальной инфраструктуре есть несколько серверов VMware vCenter, объединенных с помощью режима Linked Mode. Потом, например, вы теряете один из серверов vCenter. При этом после запуска консоли vSphere Client или vSphere Web Client на мастер-сервере vCenter вы видите предупреждение об отсутствующем сервере vCenter в объединенной конфигурации:
Could not connect to one or more vCenter Server Systems
Чтобы убрать это оповещение и привести конфигурацию в порядок, надо залогиниться на главный сервер vCenter и выполнить там следующую команду:
Если вывод будет таким, значит у вас нет внешнего Platform Services Controller (PSC), можно продолжать исполнять команды локально. Выводим список всех узлов vCenter:
root@vcenter-1 [ ~ ]# /usr/lib/vmware-vmafd/bin/dir-cli nodes list
Enter password for administrator@sso-1.local:
Node: vcenter-1.home.lab
Type: PSC
Site: First-local
Partner #1: ldap://vc_old.home.lab
root@vcenter-1 [ ~ ]# cmsso-util unregister --node-pnid vc_old.home.lab --username administrator@sso-1.local
Password:
Solution users, computer account and service endpoints will be unregistered
2020-02-10T13:02:41.359Z Running command: ['/usr/lib/vmware-vmafd/bin/dir-cli', 'service', 'list', '--login', 'administrator@sso-1.local']
2020-02-10T13:02:41.399Z Done running command
Stopping all the services ...
All services stopped.
Starting all the services ...
Started all the services.
Success
Проверяем, что старый vCenter удален из списка:
root@vcenter-1 [ ~ ]# /usr/lib/vmware-vmafd/bin/dir-cli nodes list
Enter password for administrator@sso-1.local:
Node: vcenter-1.home.lab
Type: PSC
Site: First-local
После этого предупреждение о невозможности подключиться к серверу vCenter исчезнет из vSphere Client.
На сайте проекта VMware Labs обновился пакет USB Network Native Driver for ESXi до версии 1.4, который содержит в себе драйверы для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам необходимо подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.
Давайте посмотрим, что там появилось нового:
Добавлена поддержка USB-устройств SuperMicro/Insyde Software Corp.
Исправлена проблема больших кадров 9K Jumbo frames для устройств с чипсетом RTL8153.
Устранена ошибка с неправильным отображением пропускной способности для некоторых устройств на дефолтной скорости.
Не так давно мы писали о политиках хранилищ SPBM на базе тэгов в кластере VMware vSAN. Это один из механизмов категоризации объектов, который может применяться не только к хранилищам, но и хостам, виртуальным машинам и другим объектам. Появился он еще в версии VMware vSphere 5.1.
На днях компания VMware выпустила интересный документ VMware vSphere 6.7 Tagging Best Practices, в котором описаны лучшие практики по использованию тэгов в виртуальной инфраструктуре.
В документе рассматривается использование API для тэгов, работа с которым происходит через интерфейсы Java или PowerShell.
Например, вот команда по выводу всех виртуальных машин, которым назначен определенный тэг:
// List tags associated with tagId from above
// Assumes tagAssociation object from above
List retDynamicIds = tagAssociation.listAttachedObjects(tagId);
А вот так можно вывести список всех тэгов для конкретной виртуальной машины:
$allCategoryMethodSVC = Get-CisService com.vmware.cis.tagging.category
$alltagMethodSVC = Get-CisService com.vmware.cis.tagging.tag
$allTagAssociationMethodSVC = Get-CisService com.vmware.cis.tagging.tag_association
# Use first VM from above list
$useThisVMID = $useTheseVMIDs[0]
$tagList = $allTagAssociationMethodSVC.list_attached_tags($useThisVMID)
У VMware обнаружилась полезная интерактивная инфографика, которая наглядно показывает, что происходит с дисковыми объектами виртуальных машин хоста кластера хранилищ VMware vSAN, когда его переводят в режим обслуживания (Maintenance Mode). Напомним, что о том, как это работает, мы подробно писали вот тут.
Чтобы посмотреть различные сценарии работы данного режима, нужно открыть страничку по этой ссылке и нажать на кнопку Explore maintenance mode:
Далее можно будет выбрать основные параметры перевода в этот режим.
Сначала указываем способ миграции данных:
Full data migration - данные копируются на другие хосты таким образом, чтобы обеспечить исполнения политики FTT/RAID на оставшемся наборе хостов ESXi при введении в режим обслуживания одного или двух хостов.
Ensure Accessibility – это миграция только тех компонентов, которые есть в кластере в единственном экземпляре. При этом, для некоторых объектов на период обслуживания не будет соблюдена политика Failures to tolerate (FTT).
No Data Migration – в этом случае никакие компоненты не будут перемещены с хоста, поэтому некоторые ВМ могут оказаться недоступными (если на этом хосте их дисковые компоненты находятся в единственном экземпляре, а уровень RAID недостаточен для предоставления доступа к объекту).
Потом надо задать значение политики FTT и тип организации избыточности RAID0 для FTT=0, RAID1 или RAID5 для FTT=1, RAID6 для FTT=2. А далее нужно указать, один или два хоста мы переводим в режим обслуживания.
Например, если мы укажем, что нам нужен тип миграции Full data migration, при этом надо соблюсти политику FTT=2/RAID-6, то система попросит добавить еще один хост ESXi в кластер, так как оставшихся 5 хостов в этом случае будет не хватать, чтобы обеспечить требуемые политики.
Ну а при выборе выполнимого сценария будет показана анимация происходящего при переводе одного или двух хостов в режим обслуживания процесса, который вовлекает перемещение дисковых объектов виртуальных машин на другие хосты.
Надо сказать, что не рекомендуется переводить сразу 2 хоста в режим обслуживания, так как это может привести к тому, что невозможно будет обеспечить требуемые политики FTT/RAID в имеющейся аппаратной конфигурации (хотя перевод двух хостов в maintenance mode вполне поддерживается со стороны vSAN).
В общем, интересная штука - попробуйте посмотреть, как визуализируются различные сценарии.
Некоторые пользователи виртуальной инфраструктуры VMware vSphere после недавнего обновления браузера Google Chrome (а недавно вышел Chrome 80) заметили, что через vSphere Client 6.7 больше не получается подключиться:
В консоли браузера Chrome можно увидеть вот такую ошибку:
Error in connection establishment: net:: ERR_CERT_AUTHORITY_INVALID
Проблему эту подсветили наши коллеги с Reddit. Связана она с тем, что новый Chrome 80 имеет повышенные требования к безопасности и требует повторной генерации и установки сертификата с хоста ESXi. Решается проблема, как отметили в комментариях, следующим образом:
1. Идем на хост ESXi, открываем Networking -> TCP/IP stacks -> Default TCP/IP stack по ссылке:
Устанавливаем Host-name (например: esx1) и Domain-name (например: my.local) и сохраняем файл.
3. Идем по ssh на хост ESXi и выполняем там следующие команды:
cd /etc/vmware/ssl
/sbin/generate-certificates
Копируем файл castore.pem на клиентский комьютер и устанавливаем его в раздел "Trusted Root Certification Authorities". Для Windows переименовываем файл castore.pem в castore.pem.cer и просто устанавливаем его двойным кликом. Выбираем Local Machine->Manual->Browse->выбираем Trusted Root Certification Authorities.
4. Перезапускаем службу хоста ESXi:
/etc/init.d/hostd restart
После этого vSphere Client через Chrome 80 должен работать без проблем.
В декабре мы писали о новой версии решения VMware OS Optimization Tool, которое предназначено для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.
В январе вышла новая версия (билд b1140) этого решения. Давайте посмотрим, что в ней появилось нового:
Новая кнопка на экране результатов задач, которая позволяет сохранить страницу как HTML-файл.
Новая опция, которая упрощает задачу запуска Sysprep с использованием стандартного файла ответов. Теперь можно отредактировать файл ответов до запуска Sysprep для него.
Новая опция по автоматизации задач в рамках этапа финализации (они переехали из common options), которые запускаются как последний шаг перед тем, как Windows будет выключена, чтобы ВМ была использована в решении VMware Horizon. Она включает в себя задачи по system clean up (очистка диска, NGEN, DISM и задача Compact). Ранее эти задачи были доступны в диалоге опций командной строки. Также можно чистить лог событий, информацию о серверах KMS и отпускании IP-адреса.
Новая вкладка опций Security - она позволяет быстро выбрать наиболее частые настройки безопасности. Они относятся к Bitlocker, Firewall, Windows Defender, SmartScreen и HVCI.
Добавлен параметр командной строки -o для запуска утилиты без применения оптимизаций (например, clean up).
Изменена дефолтная настройка на "не отключать Webcache", потому что это приводило к невозможности для браузеров Edge и IE сохранять файлы.
На сайте проекта VMware Labs появилась очередная интересная штука - утилита Pallas. Нужна она тем, у кого серверы ESXi находятся в изолированной относительно средств vCenter управления среде (за сетевыми экранами и далеко).
Понадобиться, например, это может в следующих случаях:
У вас несколько хостов ESXi, которые работают в полностью изолированной сети, но у вас есть требование по управлению ими из публичной сети.
Ваш хост ESXi не имеет кабельного соединения с сетью и должен быть подключен через WiFi или мобильное подключение. Например, ESXi работает на нефтяной вышке или в вагоне поезда, а вам нужно безопасно управлять этим хостом с сервера vCenter.
Ваш ESXi работает на IoT-компьютере (edge-девайс), а вам нужно удаленное управление таким хостом (патчинг, создание ВМ и т.п.).
Для этих целей создается специальная агентская виртуальная машина (Dominate agent VM), в которую напрямую (через pass-through) пробрасывается устройство, которое дает интернет (например, LTE-модем). Такая ВМ уже, в свою очередь, взаимодействует с хостом через ESXi SDK для выполнения функций управления (например, передача команд по развертыванию новой ВМ).
Эта машина взаимодействует уже с Pallas Manager через протокол MQTT, который не разрешает любые входящие соединения, то есть инфраструктура оказывается защищенной от доступа извне. Больше деталей об этом продукте можно узнать из видео ниже:
Документация по проекту Pallas находится здесь (просто выберите PDF из комбо-бокса загрузки), а скачать сам виртуальный модуль в формате OVA можно по этой же ссылке.
Как знают многие администраторы решения для виртуализации и доставки настольных ПК предприятия VMware Horizon 7, при использовании графических карт NVIDIA есть возможность применять режим vSGA, обеспечивающий использование общего графического адаптера несколькими виртуальными машинами. Режим vSGA - это самый простой и эффективный способ использовать аппаратное ускорение для графики в виртуальных машинах.
Недавно в компании VMware провели тестирование производительности режима vSGA на платформе VMware Horizon 7, сравнив его с программным CPU-only, с одной стороны, и режимом GRID vGPU, с другой. Забегая вперед скажем, что конечно же vSGA показал лучшие результаты, чем CPU-only, при этом общий уровень оказался не сильно хуже, чем оптимизированный режим GRID vGPU.
Итак, давайте посмотрим на тестовую конфигурацию (тесты проводились как внутри десктопной ВМ на хосте, так и из клиента Horizon Client, расположенного на этом же хосте, чтобы убрать воздействие сетевого взаимодействия на тест):
Параметр
Значение или конфигурация
VCPUS
2
Memory
8 GB
Disk
64 GB
OS
Windows 10 Enterprise
Applications Installed
Office 2013, Chrome Browser, Adobe Reader
VDI Protocol
Blast
VRAM
96 MB
vSGA (3D Memory)
512 MB
vGPU Profile
M60-1b
VMware Horizon
Version 7.6
VDI desktop resolution
1600x1200
С точки зрения программного обеспечения, использовались следующие рабочие нагрузки:
Приложения Microsoft Office
Adobe Acrobat для открытия документов
Воспроизведение видео с YouTube
Просмотрщики CAD-файлов
Движок WebGL
Эксперимент 1
В первом эксперименте записывалось содержимое экрана пользователей (напрямую в VDI-десктопе, без использования удаленного протокола доступа) в трех конфигурациях и сравнивалось в разрезе двух основных показателей:
Отображаемое число кадров в секунду (frames per second, FPS)
Плавность картинки в десктопе vSGA в сравнении с CPU-only десктопом
Результатом первого теста для vSGA (анимация в PowerPoint) является более плавная картинка с большим числом FPS (поэтому запись с vSGA длится дольше):
Эти параметры численно нормализовали к уровню для vGPU и представили на графике (чем выше столбики, тем лучше):
Также в рамках этого эксперимента в PowerPoint запустили еще небольшое видео, чтобы наглядно продемонстрировать преимущество vSGA:
Эксперимент 2
Во время второго эксперимента в VMware запускали воспроизведение видео в PowerPoint из клиента Horizon Client. Там были проанализированы скриншоты видео, чтобы подсчитать FPS во всех трех режимах (CPU-only, vSGA и vGPU). Результаты также нормализовали к уровню vGPU:
На правом графике также показано нормализованное число артефактов, возникающих при отображении видео - в режиме CPU-only их достаточно много, и это видно невооруженным глазом.
Также в рамках эксперимента сравнили скриншоты, сделанные из видео на YouTube, напрямую в десктопе без удаленного доступа по протоколу PCoIP:
Очевидно, что в vSGA картинка более четкая. А вот при сравнении vGPU и vSGA уже нет столь явного различия:
Эксперимент 3
В этом эксперименте в десктопе просто запустили бенчмарк WebGL для трех режимов - CPU-only, vSGA и vGPU.
Тест / Режим
vSGA
CPU-only
vGPU (M60-1b)
WebGL Aquarium
40 fps
4 fps
60 fps
WebGL Unity3D
42 371
23 020
56 307
WebGL Bmark
1174
720
2079
Обратите внимание, как плохо справляется режим CPU-only с тестом Aquarium. Ну и в целом видно, что vSGA работает вполне сносно, хотя и не дотягивает до vGPU.
Выводы тестирования очевидны - используйте vSGA и vGPU, если в ваших десктопах пользователи работают с графикой. Это существенно увеличивает производительность и плавность картинки. Кстати, если вы используете vSGA, то сможете делать vMotion виртуальных машин между хостами, даже если на них стоят разные графические адаптеры, а вот для vMotion с vGPU нужно унифицировать хост-серверы в этом плане (включая одинаковые версии драйверов).
На днях компания VMware сделала анонс о грядущих изменениях в лицензировании платформы виртуализации VMware vSphere. Теперь понятие "лицензия на CPU" будет включать в себя процессоры, которые содержат до 32 физических ядер.
Если в процессоре больше ядер, то квантоваться они будут по 32 штуки - то есть, если в физическом CPU 64 ядра, то вам потребуется 2 лицензии VMware vSphere (2x32). Надо понимать, что речь идет о физических ядрах процессоров, а не о логических, доступных через Hyper-threading.
Процессоры с таким количеством ядер уже не за горами - например, AMD анонсировала процессор Ryzen 9 3990X с 64 ядрами, который будет стоить $4 000 (его обещают выпустить уже 7 февраля). Intel уже продает процессор Xeon Platinum 8280 с 28 ядрами на борту, но скоро в соревновании с AMD неизбежно надо будет делать больше ядер - так что изменения в лицензировании vSphere уже скоро станут вполне актуальны.
Наглядно новую схему лицензирования процессоров можно представить так:
Данные изменения вступят в силу 2 апреля 2020 года, но до 30 апреля действует grace period - то есть до этой даты вы сможете купить и лицензировать хосты VMware ESXi по старым правилам (очевидно, что VMware потребует доказательства приобретения и самих серверов до этой даты). Поэтому если до этого времени вдруг у ваших процессоров окажется очень много ядер - самое время будет приобрести лицензии VMware vSphere впрок.
В августе прошлого года мы писали о решении VMware Project Octant, которое предназначено для визуализации кластера Kubernetes на дэшборде с точки зрения пространств имен и объектов, которые они содержат. Также там отображаются связи объектов и ресурсов. В отличие от дэшборда Kubernetes, Octant запускается локально на вашей рабочей станции, что позволяет избежать проблем, связанных с требованиями к безопасности.
Так вот, это средство постоянно обновляется со стороны VMware, и недавно были выпущены обновления Octant 0.10 и 0.10.1. Давайте посмотрим, что там появилось интересного:
Теперь прямо из веб-браузера можно выполнять команды для исполняемых сейчас контейнеров. Для этого нужно выбрать Pod, после чего контейнер в нем, где есть ссылка Execute Command:
При выполнении команд вы будете видеть терминал в интерактивном режиме:
Вторая интересная возможность - это Workload Viewer, позволяющий посмотреть информацию об использовании ресурсов оборудования рабочими нагрузками (и входящими в них Pods). Для этого надо выбрать раздел Workloads и кликнуть на нужный workload для просмотра информации о нем:
Прочие улучшения. Среди них можно отметить:
Клавиши быстрого доступа для часто выполняемых команд
Добавлена поддержка API для v1 и v1beta1 CRD
Метаданные объектов вынесены на отдельную вкладку
Множество небольших улучшений и исправлений ошибок
Все изменения Project Octant 0.10.0 и 0.10.1 приведены здесь и здесь, соответственно. Загрузить Octant можно по этой ссылке в разделе Assets. Основной репозиторий проекта находится тут.
На днях компания Intel опубликовала руководство по безопасности Security Advisory INTEL-SA-00329, в котором описаны новые обнаруженные уязвимости в CPU, названные L1D Eviction Sampling (она же "CacheOut") и Vector Register Sampling. Прежде всего, надо отметить, что обе этих уязвимости свежие, а значит исправления для них пока не выпущено.
Соответственно, VMware также не может выпустить апдейт, пока нет обновления микрокода CPU от Intel. Когда Intel сделает это, VMware сразу выпустит патч, накатив который на VMware vSphere вы избавитесь от этих потенциальных уязвимостей.
Vector Register Sampling (CVE-2020-0548). Эта уязвимость является пережитком бага, найденного в подсистеме безопасности в ноябре прошлого года. Она связана с атаками типа side-channel, о которых мы писали вот тут. В рамках данной атаки можно использовать механизм Transactional Synchronization Extensions (TSX), представленный в процессорах Cascade Lake. О прошлой подобной уязвимости можно почитать вот тут. А список подверженных уязвимости процессоров Intel можно найти тут.
L1D Eviction Sampling (CVE-2020-0549). Эта уязвимость (ее также называют CacheOut) позволяет злоумышленнику, имеющему доступ к гостевой ОС, получить доступ к данным из памяти других виртуальных машин. Более подробно об уязвимостях данного типа можно почитать на специальном веб-сайте. Также вот тут находится список уязвимых процессоров.
Следите за обновлениями VMware, патчи будут доступны сразу, как только Intel обновит микрокод процессоров. Достаточно будет просто накатить обновления vSphere - и они пофиксят уязвимости CPU.
В каких условиях сегодня находится бизнес? С каждым годом растет конкуренция, и, чтобы оставаться в выигрышном положении, нужно соответствовать требованиям рынка. Внедрение современных ИТ-технологий, в том числе облачных, позволяет организациям перестраивать бизнес-процессы, существенно ускоряя производство. Очевидно, что трансформация, которую переживают многие компании, дает возможность конкурировать и достигать значимых результатов.
Но так было не всегда. 10 лет назад российский рынок жил другими стандартами: преобладал подход, когда предприятия строили и сопровождали ИТ-инфраструктуру силами штатных специалистов, сами закупали оборудование и не задумывались о переносе даже части сервисов вовне. Перенос ИТ-инфраструктуры целиком даже не обсуждался.
Со временем ситуация изменилась. Компании стали чаще уходить от on-premise-инсталляций и выносить на площадки провайдера критичные сервисы, от которых напрямую зависит деятельность предприятия. Теперь облачные технологии стали привычным инструментом. Выросло доверие к локальным провайдерам, поскольку они успели накопить экспертизу и перенять опыт у западных коллег.
Цифровая трансформация производства на примере компании Jotun
На портале VMware Labs появилась очередная новинка - PowerShell-модуль Power vRA Cloud, с помощью которого можно отобразить сложное множество программных интерфейсов VMware vRealize Automation Cloud API в простой набор функций PowerShell. Поэтому с помощью данного средства можно разрабатывать сценарии по управлению облачной инфраструктурой VMware vRealize Automation Cloud с помощью PowerShell вместо прямой работы с API.
Сразу надо сказать, что этот модуль не поддерживается со стороны VMware (как и все утилиты на VMware Labs, находящиеся в статусе Tech Preview), поэтому используйте его осторожно.
После скачивания zip-файла с VMware Labs, распакуйте его и импортируйте модуль командой:
Import-Module .\PowervRACloud.psd1
Далее можно вывести список всех доступных функций:
Get-vRACloudCommands
Для соединения с инфраструктурой vRealize Automation используйте следующую команду (формируем токен как безопасную строку):
$APIToken = Read-Host -AsSecureString
Потом передаем этот API-токен при соединении:
Connect-vRA-Cloud -APIToken $APIToken
Ну а дальше можно использовать API, например, можно вывести аккаунты vRA командой:
На сайте проекта VMware Labs появилась новая версия мобильного клиента для управления платформой VMware vSphereс мобильного телефона - vSphere Mobile Client 1.9.1 (а немногим ранее вышла версия 1.9). Напомним, что прошлая версия клиента vSphere Mobile Client 1.6 была выпущена в октябре прошлого года.
Давайте посмотрим, что нового появилось в мобильном клиенте за последнее время:
Возможность сохранить информацию о доступе к vCenter Server (адрес сервера и имя пользователя).
Возможность использовать распознавание FaceId или доступ по отпечатку пальца для логина на сервер vCenter.
Добавлено быстрое действие выключения хоста ESXi.
Улучшена совместимость с движком автозаполнения в полях ввода логина.
Исправлены мелкие баги прошлых версий.
Скачать обновленный vSphere Mobile Client 1.9.1 можно по этим ссылкам:
Также не забудьте посмотреть инструкцию о развертывании Notification Service (он доступен как Docker-контейнер), чтобы включить Push-уведомления на своих устройствах.
Недавно компания Microsoft объявила о том, что мартовские обновления Windows в этом году затронут поведение серверов Microsoft LDAP (доменных контроллеров), которые являются частью сервисов Active Directory. Эти изменения заключаются в том, что теперь механизмы LDAP channel binding и LDAP signing будут включаться по умолчанию, а для уже существующих инсталляций дефолтные настройки изменятся. На это обратил внимание один из наших читателей, который дал ссылку на соответствующую статью коллег из компании VMware.
В целом, инициатива эта позитивная - она согласуется с оповещением безопасности CVE-2017-8563, которое говорит о том, что незащищенная коммуникация LDAP может быть скомпрометирована. Поэтому, начиная с марта, любая LDAP-коммуникация, которая не использует TLS, потенциально может быть отвергнута Windows-системой. Почитайте, кстати, об этой суете на Reddit.
Это, конечно же, затрагивает и платформу VMware vSphere, компоненты которой могут использовать как обычный протокол LDAP (ldap://), так и защищенный LDAPS (ldaps://) для соединения со службами Active Directory. Также VMware vSphere поддерживает и механизм аутентификации Integrated Windows Authentication (IWA), который не затрагивают грядущие изменения.
Если вы уже настроили ваш vCenter Server для доступа к Active Directory через LDAP с TLS (LDAPS) или через механизм IWA, то вам не стоит бояться обновлений (если эти соединения идут не через балансировщики или прокси-серверы).
Проверить текущую интеграцию с LDAP в vCenter можно в разделе Configuration -> Identity Sources:
Как мы видим из трех источников идентификации по ldap только один использует TLS и будет работать после апдейтов, а вот первые два источника требуют перенастройки.
После мартовских обновлений при логине в vSphere Client через аккаунты Active Directory вы можете получить вот такую ошибку:
Invalid Credentials
При попытке добавить или изменить Identity Source в vCenter вы получите вот такую ошибку:
Check the network settings to make sure you have network access to the identity source
Поэтому попытаться сделать нужные настройки (хотя бы в изолированной от производственного окружения среде) нужно уже сейчас. Тем более, что vCenter позволяет одновременно использовать несколько Identity Sources.
Для того, чтобы настроить и протестировать LDAP Channel Binding & Signing можно использовать следующие материалы:
Документ о настройке LDAP Signing в Windows Server 2008 говорит, что вам надо изменить групповую политику "Default Domain Policy" (для домена), а также "Default Domain Controllers Policy" (для контроллеров домена), после чего дождаться ее обновления или обновить ее командой gpupdate /force.
Надо понимать, что обновление этих политик затронет не только инфраструктуру VMware vSphere, но и все остальные сервисы, использующие LDAP, поэтому процесс этот нужно тщательно спланировать. Кстати, если вы это будете делать для виртуальных машин с контроллерами домена в тестовой конфигурации, то можно сделать снапшот всего тестового окружения перед изменением конфигурации, чтобы откатиться к ним в случае, если вы что-то не предусмотрели (для производственной среды снапшоты контроллеров домена делать не стоит).
Чтобы проверить, что политики применились, можно использовать встроенную утилиту Windows ldp.exe. Запустите ее на контроллере домена и укажите адрес localhost и порт 389:
Дальше идите в меню Connection утилиты и выберите там пункт Bind, где нужно ввести креды доменного администратора и выбрать вариант Simple bind:
После этого вы должны увидеть ошибку "Error 0x2028 A more secure authentication method is required for this server", которая говорит о том, что вы корректно отключили все небезопасные байндинги LDAP:
Если вы не получили такой ошибки, то значит настройки у вас еще не применились, и их надо проверить.
О настройке сервера vCenter для LDAPS рассказано вот тут. Единственное, что вам потребуется - это добавить рутовый сертификат для сервера vCenter, который можно вывести следующей командой (если под Windows надо будет поставить Open SSL, под Linux утилита уже встроена):
Далее скопируйте все данные между "—–BEGIN CERTIFICATE—" и "—–END CERTIFICATE—–", после чего сохраните это в текстовый файл.
Никакой срочности до марта нет, поэтому не нужно суетиться и обновлять все Identity Sources, но разрабатывать план по переходу на LDAPS и тестировать его нужно уже сейчас. Будет неприятно, если пользователи неожиданно столкнутся с проблемой аутентификации. И да, откладывать обновления Windows не вариант - это единственный способ своевременно закрывать дырки в сфере информационной безопасности для вашей компании.
Хотя бы раз у каждого администратора VMware vSphere была такая проблема, когда один или несколько хостов VMware ESXi в консоли vSphere Client на сервере vCenter отображались в статусе Not Responding. Причин для этого может быть масса, сегодня мы постараемся разобрать наиболее частые из них.
1. Прежде всего, надо убедиться, что хост ESXi находится во включенном состоянии.
Желательно убедиться в этом как физически (сервер включен в стойке), так и взглянуть на его консоль (например, через iLO/iDRAC). Ситуация может быть такой, что хост выпал в PSOD (Purple Screen of Death, он же Purple Diagnostic Screen).
В этом случае с хостом надо разбираться в соответствии со статьей KB 1004250 и повторно добавлять его к серверу vCenter, когда он успешно загрузится.
2. Если хост ESXi включен, но все еще находится в статусе Not Responding, надо попробовать перезапустить там Management agents (операция Restart Management Network).
Они включают в себя сервисы по коммуникации между сервером vCenter и хостом ESXi. Делается это в соответствии со статьей KB 1003490.
Также будет не лишним выполнить тест сети управления - опция Test Management Network. Ошибки, возникающие при этом, помогут понять, что случилось:
3. Проверьте, что со стороны vCenter Server у вас есть соединение с хостом ESXi - как по IP, так и по FQDN.
Казалось бы очевидный шаг, который не все выполняют первым при первичной диагностике. Просто сделайте пинг хоста ESXi со стороны сервера vCenter:
4. Убедитесь, что со стороны сервера ESXi также виден сервер vCenter.
Дело в том, что vCenter ожидает регулярных хартбитов со стороны хостов ESXi, чтобы считать их подключенными. Если в течение 60 секунд он не получает таких хартбитов, то он объявляет хост ESXi Not Responding, а в конечном итоге и Disconnected.
Иногда такое состояние возникает, когда сервер vCenter спрятан за NAT относительно хостов ESXi:
В этом случае серверы ESXi не смогут достучаться до сервера vCenter. Более того, такая конфигурация вообще не поддерживается со стороны VMware (см. статью KB 1010652), несмотря на то, что для нее существует workaround.
Ваша задача - обеспечить коммуникацию хоста ESXi с сервером vCenter по порту 902 (TCP/UDP):
Кстати, таймаут в 60 секунд для хартбитов можно увеличить, например, до 120 секунд, если у вас большие задержки в сети. Для этого нужно изменить значение параметра config.vpxd.heartbeat.notrespondingtimeout в расширенных настройках сервера vCenter, как описано в статье KB 1005757.
5. Попробуйте убрать хост ESXi из инвентори vCenter и добавить его снова.
Делается это в соответствии со статьей KB 1003480. Просто выберите для хост ESXi в контекстном меню vSphere Client опцию Disconnect:
Потом просто добавьте хост ESXi в окружение vCenter снова.
6. Если ничего из этого не помогло - время заглянуть в логи.
В первую очередь надо посмотреть в лог агента vpxa (/var/log/vpxa.log), как описано в статье KB 1006128. Например, причиной того, что агент vpxa не стартует может оказаться нехватка памяти, выделенной для сервисов ESXi. Тогда в логе vpxa будет что-то вроде этого:
[2007-07-28 17:57:25.416 'Memory checker' 5458864 error] Current value 143700 exceeds hard limit 128000. Shutting down process.
[2007-07-28 17:57:25.420 'Memory checker' 3076453280 info] Resource checker stopped.
Также нужно убедиться, что процесс hostd работает и отвечает на команды. Для этого можно заглянуть в лог hostd (/var/log/vmware/hostd.log), как описано в KB 1002849. Например, там может быть вот такая ошибка:
2014-06-27T19:57:41.000Z [282DFB70 info 'Vimsvc.ha-eventmgr'] Event 8002 : Issue detected on sg-pgh-srv2-esx10.sg-pgh.idealcloud.local in ha-datacenter: hostd detected to be non-responsive
Ошибки могут вызывать разные причины, но наиболее частая из них - нехватка ресурсов для сервиса hostd.
7. Последнее, но не менее важное - проверить, нет ли проблем с хранилищем.
Если все остальное уже посмотрели, то нужно обязательно отработать вариант с неполадками хранилища на хосте ESXi. Основные рекомендации по этому случаю даны в KB 1003659. Диаграмма траблшутинга в этом случае выглядит следующим образом (кликабельно):
Вывод
Если ваш хост ESXi перешел в статус Not Responding или Disconnected, попробуйте сначала такие простые действия, как проверка включенности самого ESXi, пинг хостов vCenter и ESXi в обе стороны (не забыв также порт 902), рестарт Management agents, передобавление хоста ESXi в инвентори. Потом посмотрите более сложные варианты, такие как работоспособность агента vpxa и сервиса hostd. Ну а потом уже проверяйте работу хранилищ на ESXi, где может быть много всякого рода проблем.
Недавно мы писали о том, что компания VMware выпустила новую превью-версию настольной платформы виртуализации VMware Workstation Tech Preview 20H1. Одновременно с этим было выпущено превью платформы и для Mac OS VMware Fusion Tech Preview 20H1, которое получило новую функциональность работы с контейнерами с кодовым названием Project Nautilus.
Подход к бета-версиям со стороны команд разработки Fusion и Workstation теперь несколько изменится - они будут выпускать обновления к Tech Preview в течение года, пока в итоге не получится финальный релиз. Обычно на это уходит несколько месяцев. Для Fusion сейчас это релиз TP20H1.
Также бинарники, документация и ассеты переезжают на GitHub, где теперь есть удобный портал для скачивания продукта и получения дополнительной информации.
Давайте взглянем на основные новые возможности Fusion 2020 года:
Наконец-то была реализована функциональность Project Nautilus, которая позволяет запускать любые OCI-compliant контейнеры на маке. Сейчас работа с контейнерами Docker в Mac OS часто идет через боль, поэтому такое решение очень пригодится пользователям. Эта функциональность будет доступна бесплатно для пользователей VMware Fusion. Для управления контейнерами будет использоваться новая утилита vctl, которая использует наработки проектов runC, containerD, Cri-O и Kubernetes (более подробно описано здесь).
Для реализации среды управления контейнерами используется подход, аналогичный тому, что применен в Project Pacific - для запуска контейнеров в качестве гостевой ОС используется ультралегковесная Linux-система (PodVM, он же Native Pod), которая почти не дает накладных расходов на виртуализацию. Каждая PodVM с одним контейнером внутри получает свой IP-адрес от кастомной сети VMnet. При это для такой машины можно использовать bridged networking, абсолютно прозрачно работая с контейнером. Можно отдельно настроить и port forwarding, если это вам необходимо.
Вторая возможность Fusion - это человеческая реализация работы с USB-устройствами хоста. Раньше была проблема с тем, что при установке продукта запрос разрешений для USB-устройств происходил позже завершения установки, что приводило к их неработоспособности (надо было переустанавливать продукт). Также подключение и отключение USB-девайсов часто глючило. Теперь же Fusion интегрирован в нативный USB-стек Apple на уровне ядра, что должно привести к тому, что работа Fusion с хостовыми устройствами USB будет стабильнее и быстрее. Скоро в специальном репозитории должны появиться материалы на эту тему.
Скачать VMware Fusion Tech Preview 20H1 по прямой ссылке можно отсюда. Портал со всеми материалами находится тут.
На днях компания VMware выпустила очередное обновление своей утилиты для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные) - Cross vCenter Workload Migration Utility 3.1. Напомним, что версия 3.0 этого средства выходила на VMware Labs в ноябре прошлого года.
Давайте посмотрим на новые возможности утилиты:
Поддержка конвертации форматов диска между Thick (Lazy Zeroed), Thick (Eager Zeroed) и Thin provisioning.
Поддержка шаблона переименования виртуальной машины при операциях клонирования.
Также появилась парочка багофиксов:
Устранена ошибка дубликата выбранной сети при пакетной миграции ВМ.
Исправлена ошибка запуска, когда указан новый домашний vCenter в качестве аргумента командной строки.
Напомним, что утилитой можно пользоваться через плагин в составе vSphere Client с интерфейсом на базе технологии HTML5, так и в отдельном графическом интерфейсе.
Скачать Cross vCenter Workload Migration Utility 3.1 можно по этой ссылке.
Компания VMware выпустила обновленное технологическое превью настольной платформы виртуализации VMware Workstation Tech Preview 20H1 (первая половина 2020 года). Это первый релиз в этом году, который, как правило, выходит в GA через 2-3 месяца после выхода превью.
Главное нововведение VMware Workstation 2020 - это возможность запускать продукт на хосте Windows 10, где включены возможности Hyper-V или Virtualization Based Security за счет использования Windows Hypervisor Platform API. Это позволит также запустить и использовать сервисы Device Guard и Credential Guard одновременно с VMware Workstation. Данная возможность была представлена еще на VMworld 2019, и вот теперь ее можно уже полноценно тестировать.
Для того, чтобы Workstation работала на Windows 10 с этими фичами, потребуется следующее:
Windows 10 20H1 из Windows insider program (минимальный билд 19041)
Intel Haswell CPU или более новый
AMD Bulldozer CPU или более новый
VMware предлагает на таких хостах потестировать пользователям включение/выключение виртуальной машины и базовые операции с ней, а также проверить запуск машин с предыдущих версий Workstation.
Скачать VMware Workstation Tech Preview 20H1 можно по этой ссылке. Также можно обсудить свой опыт работы с новой версией в специальном комьюнити. Кроме того, есть еще вот такой обзорный документ по новой версии (там есть информация об известных проблемах).
В конце ноября прошлого года мы писали о постерах, посвященных решению vRealize Network Insight и его очень широким возможностям поиска. Эти возможности позволяют находить нужные сущности и объекты в инфраструктуре VMware vSphere, NSX и прочих компонентах.
Вышедший в начале января постер vRealize Network Insight Search Poster for SD-WAN & VeloCloud показывает, какие поисковые шаблоны можно использовать для платформы SD-WAN (это технология купленной компании VeloCloud, которая реализует концепцию Software-Defined Networking в рамках WAN-сетей). Как некоторые из вас помнят, интеграция с решениями VeloCloud появилась в vRNI пятой версии.
На сайте проекта VMware Labs появилась действительно интересная новинка - утилита vSphere Software Asset Management (vSAM). С помощью vSAM можно собрать подробную информацию об инсталляции VMware vSphere на вашей площадке, касающуюся лицензий - весь инвентарь и доступные лицензии, проще говоря, ассеты.
Утилита забирает все данные по API и генерирует отчет об использовании лицензий виртуальной инфраструктуре в формате PDF, который могут использовать администраторы, менеджеры и консультанты для целей отчетности, планирования и любых других.
Сама утилита vSAM представляет собой легковесное Java-приложение, которое может работать под Windows, Linux или Mac OS. Давайте посмотрим на его возможности:
Поддержка кластера хостов ESXi под управлением vCenter Server, а также отдельных серверов ESXi с версиями vSphere 5.5, 6.x или более новыми.
Генерация комплексных отчетов в следующих категориях:
Высокоуровневая информация об инсталляции
Отчет о компонентах (отдельные ESXi или кластер серверов с vCenter)
Высокоуровневый отчет об использовании лицензионных ключей
Генерация рекомендаций в следующих сферах:
Оповещение об использовании триальной лицензии
Срок лицензии:
Оповещение об истечении лицензии через 90 дней
Алерты об истекших лицензиях
Емкость доступных лицензий
Оповещение об использовании лицензий выше заданного порога
Оповещение о нехватке лицензий
Алерт о превышении лицензионных лимитов
Жизненный цикл продуктов
Информация по вступлении в фазу End of General Support info
Оповещение за 90 дней для EoGS
Нотификация о неподдерживаемых больше продуктах
Защита чувствительной информации за счет:
Сбор данных только для задачи Software Asset Management
Маскирование чувствительной информации в отчете
Поддержка шифрования файла с сырыми данными
Поддержка объединения нескольких отчетов в один
Поддержка английского и китайского языков
Поддержка кастомизации отчетов
Вот примеры сгенерированных отчетов:
Скачать утилиту VMware vSphere Software Asset Management Tool можно по этой ссылке.
Вчера мы писали про выпуск новой версии решения VMware App Volumes 4, предназначенного для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам.
Одновременно с релизом этой платформы, на сайте проекта VMware Labs появилась новая утилита App Volumes Migration Utility, которая дополняет средства App Volumes по облегчению жизни администраторов, занимающихся обслуживанием решения.
Эта утилита позволяет смигрировать старые объекты AppStacks, в которых распространялись приложения в VMware App Volumes 2.18, на новый формат VMware App Volumes 4.0, который реализует концепцию приложений и пакетов. С помощью App Volumes Migration Utility можно сделать так, чтобы не потребовалось повторное развертывание приложений в среде App Volumes после миграции основного продукта.
Работать с утилитой просто. Вводим данные для входа:
Выбираем выходную файловую шару для пакетов:
Отмечаем доступные для миграции AppStacks и нажимаем кнопку Migrate:
Скачать App Volumes Migration Utility можно по этой ссылке.
Компания VMware выпустила новую версию решения App Volumes 4. Напомним, что решение App Volumes предназначено для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам. О бета-версии четвертого поколения технологии App Volumes мы писали вот тут, а на днях вышел ее финальный релиз.
Давайте посмотрим, что там появилось интересного:
1. Новые возможности упрощенного управления приложениями
Теперь вместо объектов AppStacks, как это было в App Volumes 2.x, пользователи работают со следующими объектами:
Applications – вы сначала создаете приложение. Оно содержит в себе одну или несколько версий упакованного программного продукта. Назначения прав пользователям, группам, компьютерам или организационным единицам производится на уровне приложения. Назначения могут быть также сделаны внутри определенных пакетов.
Packages – после создания приложения вы используете packaging VM для сбора изменений, которые приложение вносит на диск, для того, чтобы подготовить его к распространению для пользователей и компьютеров. Это тот же процесс, что и был при создании AppStacks. Пакеты назначаются на стадии создания, после чего они могут идти по стадиям жизненного цикла.
Programs – после создания пакета происходит автогенерация программы. Название программы назначается автоматически. Одна программа может содержать или несколько установщиков приложений.
Такая архитектура дает большую гибкость и гранулярность при управлении приложениями:
Например, при выходе новой версии приложения, вы можете добавить нужный Package в уже существующий объект Application и доставлять его нужным пользователям.
С другой стороны, такая модель позволяет управлять приложениями на уровне иерархии организации. Например, можно создать Application для отделов маркетинга, где будут отдельные пакеты для каждого отдела. А уже на уровне отдела сделать сборки (Program) для каждого из случаев (например, роль пользователя на уровне отдела):
2. Новая функция сосуществования приложений старых версий
Приложения версии 2.x, сделанные как App Stacks, могут сосуществовать с новыми приложениями версии 4.x (Applications/Packages) в рамках административной консоли App Volumes 4. Для этого в консоли сделана специальная вкладка для 2.x приложений, которые вы можете постепенно перетаскивать на новую версию платформы.
3. Дополнительные функции
В этой категории появились следующие улучшения:
Application Owners – вы можете назначить сущности Active Directory для обозначения владельца конкретного приложения.
Application History – вы можете посмотреть список административных действий, выполненных с приложением, и кто их выполнил.
Intent-based Assignments with a Current Marker – вы можете обозначить один из пакетов приложения как текущий, чтобы обозначить, что именно данная версия будет доставляться пользователям.
Single-app Package Format – приложения теперь можно распространять в рамках одного пакета, которые можно комбинировать как угодно и в рамках конфигурации с несколькими VMDK-дисками в процессе доставки пользователям.
Package Lifecycle Stages – теперь для пакета можно видеть стадии его жизненного цикла (New, Tested, Published или Retired).
Package Notes – можно отслеживать детали пакета, путем добавления заметок о требуемой специфике или конфигурации приложения, после того, как вы закончили упаковку приложения в пакет.
Improved Template Management – файлы Template policy (cfg) теперь переместились из шаблона диска в базовый образ, поэтому их можно просто апдейтить путем обновления агента. App Volumes Manager предоставляет интерфейс для загрузки и обслуживания шаблонов.
Upgrading – можно обновить App Volumes Manager с версии 2.18 или более поздних, но продолжать управлять агентами 2.x (более подробно об этом рассказано в документации).
Prevent Modifications to Installed Applications (в стадии Tech Preview) – некоторые из пользователей могут иметь возможность изменять или деинсталлировать приложения из базового образа. Это может иметь последствия в виде влияния на writable volume, который привязан к другой ВМ с таким же приложением (и вызвать непредсказуемые последствия). Поэтому администратор может запретить модификации приложений пользователями (по умолчанию такая функция отключена).
AppStack Migration Tool – это специальная утилита, которая позволяет мигрировать объекты AppStacks 2.x на пакеты приложений (Packages) версии 4.x. Более подробно о App Volumes Migration Utility мы расскажем в ближайшее время.
Жизненный цикл распространяемого через App Volumes 4.0 приложения теперь выглядит следующим образом:
Администратор создает приложение нужной версии и сохраняет метаданные, которые отражают параметры окружения, в котором пакет создавался.
С помощью App Volumes и ThinApp администратор убеждается, что данная версия приложения работает в разных ОС и не конфликтует с другими приложениями.
В пилотной среде происходит тестирование данной версии приложения на некотором наборе релевантных пользователей.
Если тестирование прошло успешно, происходит публикация приложений в производственной среде. Назначение прав происходит тем же образом, что и в старом App Volumes версий 2.x.
После выхода новых обновлений происходит списание старой версии приложений App Volumes.
Также по всем функциям App Volumes 4 можно пройтись в рамках интерактивного walk-through:
Более подробно об App Volumes 4 можно узнать на этой странице. Release Notes доступны тут.
Осенью прошлого года компания VMware выпустила VMware Cloud Foundation 3.9. Напомним, что это комплексное программное решение, которое включает в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.
На днях было выпущено небольшое обновление архитектуры VCF 3.9.1, где появилось несколько небольших новых возможностей.
Главное обновление - это новый Bill of Materials (BoM) для последних версий продуктов (включая апдейты 2020 года):
Компонент VCF
Версия
Дата релиза
Номер билда
Cloud Builder VM
2.2.1.0
14 JAN 2020
15345960
SDDC Manager
3.9.1
14 JAN 2020
15345960
VMware vCenter Server Appliance
6.7 Update3b
05 DEC 2019
15132721
VMware ESXi
6.7 Update 3b
05 DEC 2019
15160138
VMware vSAN
6.7 Update 3b
05 DEC 2019
14840357
VMware NSX Data Center for vSphere
6.4.6
10 OCT 2019
14819921
VMware NSX-T Data Center
2.5
19 SEP 2019
14663974
VMware Enterprise PKS
1.5
20 AUG 2019
14878150
VMware vRealize Suite Lifecycle Manager
2.1 Patch 2
02 JUL 2019
14062628
VMware vRealize Log Insight
4.8
11 APR 2019
13036238
vRealize Log Insight Content Pack for NSX for vSphere
3.9
n/a
n/a
vRealize Log Insight Content Pack for Linux
2.0.1
n/a
n/a
vRealize Log Insight Content Pack for vRealize Automation 7.5+
1.0
n/a
n/a
vRealize Log Insight Content Pack for vRealize Orchestrator 7.0.1+
2.1
n/a
n/a
vRealize Log insight Content Pack for NSX-T
3.8.2
n/a
n/a
vSAN Content Pack for Log Insight
2.2
n/a
n/a
vRealize Operations Manager
7.5
11 APR 2019
13165949
vRealize Automation
7.6
11 APR 2019
13027280
VMware Horizon 7
7.10.0
17 SEP 2019
14584133
Остальные новые возможности включают в себя:
Функция Application Virtual Networks (AVN) - она позволяет решению vRealize Suite быть развернутым в сетях NSX overlay networks. AVN, которые являются стандартом по умолчанию, начиная с этой версии архитектуры VCF, предоставляют преимущества портируемости и быстрого восстановления после запланированного простоя или в случае аварии. Чтобы узнать больше об этих сетях и перевести компоненты vRealize Suite на эту технологию почитайте вот эту статью.
Поддержка API для нескольких физических сетевых адаптеров и распределенных коммутаторов (vSphere Distributed switches). Теперь API поддерживает до трех vDS и до 6 физических NIC, что дает возможность применения API в высокопроизводительных средах с большим числом адаптеров и виртуальных коммутаторов (например, физическое разделение типов трафика).
Улучшения Cloud Builder - обновленный графический интерфейс включает в себя несколько улучшений рабочих процессов, а также показывает в отчетах детали задач, которые были выполнены во время развертывания.
Улучшения Developer Center - теперь можно получить доступ к Cloud Foundation API и примерам кода из дэшборда SDDC Manager.
Более подробная информация об улучшениях VMware Cloud Foundation 3.9.1 приведена в Release Notes.
Некоторые администраторы сталкиваются с такой конфигурацией виртуальной инфраструктуры, когда управляющий сервер VMware vCenter оказывается за NAT или сетевым экраном относительно части хостов VMware ESXi:
В этом случае получается добавить хосты ESXi в vCenter, но через примерно одну минуту они уходят в офлайн, при этом успешно пингуются. Также в течение этой минуты, пока они видны в vCenter, хосты не могут синхронизировать свою конфигурацию. Причина такого поведения проста - в агент vCenter на хостах ESXi (он же vpxa) прописывается внутренний адрес vCenter для связи со стороны ESXi.
Эти хартбиты идут на целевой порт 902 TCP/UDP (источник варьируется):
Если погуглить, то можно найти статью KB 1010652, где сказано, что такая конфигурация не поддерживается со стороны VMware.
Но есть обходной путь, который вполне работает у многих пользователей. Нужно открыть 902 порт на вашем фаерволе/NAT, а также поменять в файле конфигурации агента vCenter
/etc/vmware/vpxa/vpxa.cfg
строчку:
<serverIp>10.0.0.1</serverIp> на внешний IP-адрес вашего NAT-маршрутизатора. Также нужно добавить следующий параметр в этот файл, чтобы указанный IP не поменялся назад:
<preserveServerIp>true</preserveServerIp>
Перед редактированием файла vpxa.cfg нужно поменять права доступа командой:
chmod 744 /etc/vmware/vpxa/vpxa.cfg
а после редактирования вернуть их назад:
chmod 444 /etc/vmware/vpxa/vpxa.cfg
По окончании процедуры надо перезапустить management agents на хостах ESXi командой:
services.sh restart
И надо понимать, что данная конфигурация хоть и работает, но не поддерживается со стороны VMware. Официально для размещения vCenter за NAT workaround не существует.
Больше двух лет назад мы писали о средстве DRS Dump Insight, появившемся на сайте проекта VMware Labs. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS.
Также мы писали о специальном плагине на базе HTML5 к vSphere Client для данного сервиса. Он добавляет функции утилиты DRS Dump Insight в интерфейс vSphere Client, работающего с сервером vCenter Server Appliance (vCSA).
На днях вышло обновление DRS Dump Insight 1.1, в котором появились следующие новые возможности:
Пользователи теперь могут загружать несколько дампов, указав папку, в которой все они лежат.
На базе загруженных дампов создается таймлайн миграций vMotion, по которому можно перемещаться в целях анализа нескольких дампов.
Пользователи могут экспортировать результат анализа нескольких дампов в виде одного PDF-документа.
Добавлена поддержка дампов VMware vSphere 6.5 Update 2, vSphere 6.5 Update 3 и vSphere 6.7 Update 3.
Множество исправлений ошибок и улучшений движка анализа.
Воспользоваться утилитой DRS Dump Insight 1.1 можно по этой ссылке.
Интересное наблюдение от коллеги с блога ivobeerens.nl - оказывается драйверы pvscsi и vmxnet3, входящие в состав пакета VMware Tools, накатываются в гостевую ОС машин VMware vSphere через службу обновлений Windows Update:
В версии VMware Tools 10.3.10 (или выше) это работает для ОС Windows Server 2016 и Windows Server 2019.
Таким образом, указанные драйверы обновляются как часть процесса обновления Windows, что, в свою очередь, сокращает число требуемых перезагрузок во время обновлений.
RSS
