Новости Статьи VMware Veeam StarWind Microsoft ИТ-ГРАД Citrix Symantec 5nine События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 4880 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru | Ссылка дня: VMware vSphere 6.7 Update 3 доступен для загрузки

Как быстро и просто провести тест хранилищ с использованием утилиты IOBlazer.


Недавно на сайте проекта VMware Labs обновилась одна из самых полезных утилит для администраторов хранилищ VMware vSphere – IOBlazer. Она позволяет сгенерировать нагрузку на хранилища с любых платформ - Linux, Windows и Mac OS, при этом администратор может задавать паттерн нагрузки с высокой степенью кастомизации, что очень важно для реального тестирования подсистемы хранения для виртуальных машин.


Таги: VMware, IOBlazer, Storage, Performance, vSphere, VMachines

Новый документ - "Learning Guide – GPUs for Machine Learning on vSphere".


Недавно мы писали про интересную штуку - утилиту Machine Learning on VMware Cloud Foundation, которая предоставляет инженерам по работе с данными инструменты в области Data Science в рамках виртуальной инфраструктуры. К сожалению, она пока не поддерживает использование GPU хостов, а работает только с CPU. Но заслуживает внимание сам факт такого решения - VMware начинает плотно прорабатывать тему машинного обучения.

Также о задачах машинного обучения на платформе vSphere мы рассказывали в статье "Некоторые аспекты использования VMware vSphere для задач машинного обучения и технология FlexDirect от компании BitFusion".

Еще один элемент этой концепции - выпущенный на днях документ "Learning Guide – GPUs for Machine Learning on vSphere". В нем VMware рассказывает о том, как правильно строить системы, заточенные под алгоритмы машинного обучения, на платформе VMware vSphere.

Документ позволит архитекторам ИТ-инфраструктур и командам DevOps ответить на следующие вопросы:

  • Зачем нужны серверы с GPU для задач machine learning (ML) на платформах high performance computing (HPC).
  • Как именно используется модуль GPU.
  • Как на платформе vSphere строить ML-системы.
  • Как транслировать модуль GPU в рабочую нагрузку ML в виртуальной машине.
  • Как наладить взаимодействие между командой data scientists и администраторов виртуальной инфраструктуры.

Задачи машинного обучения с использованием GPU можно решать тремя способами:

Эти способы реализуют соответствующие технологии:

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


Таги: VMware, vSphere, GPU, vGPU, HPC, Whitepaper

Новое на VMware Labs: vSAN Performance Monitor.


На сайте проекта VMware Labs появилась очередная интересная утилита - виртуальный модуль vSAN Performance Monitor, предназначенный для мониторинга метрик в среде отказоустойчивых кластеров VMware vSAN и их визуализации.

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

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

Напомним, что 5 лет назад была выпущена похожая утилита - vSAN Observer, ну а создатели vSAN Performance Monitor открыто пишут, что при разработке вдохновлялись именно ей.

Само средство поставляется в виде виртуального модуля (Virtual Appliance), который реализует 3 основных компонента:

  • Коллектор Telegraf - это агент, который собирает метрики в кластере и сохраняет их в базе данных InfluxDB.
  • InfluxDB - собственно, сама база данных, хранящая метрики.
  • Grafana - это фреймворк, который используется для визуализации метрик из базы.

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

В качестве платформы и целевой машины для vSAN Performance Monitor поддерживаются vSphere 6.0 и VM hardware 11  (или более поздние). Для работы утилиты вам потребуется включить службу Virtual SAN Performance Service (о том, как это сделать, написано вот тут).

Скачать vSAN Performance Monitor можно по этой ссылке.


Таги: VMware, vSAN, Performance, Labs, vSphere, Storage

Анонсирована новая версия платформы виртуализации VMware vSphere 6.7 Update 3.


Вчера мы писали о том, что в перед предстоящим VMworld 2019 компания VMware рассказала о новых возможностях решения для организации отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. Одновременно с этим была анонсирована и новая версия главной платформы виртуализации VMware vSphere 6.7 Update 3.

Напомним, что прошлая версия - vSphere 6.7 Update 2 - вышла весной этого года. Давайте посмотрим, что нового будет в vSphere 6.7 U3:

1. Поддержка нескольких vGPU (от NVIDIA) для одной виртуальной машины.

Теперь vSphere поддерживает несколько устройств NVIDIA GRID virtual GPU (vGPU), привязанных к одной виртуальной машине. Это, прежде всего, даст возможность увеличения вычислительных мощностей для тяжелых нагрузок, предъявляющих высокие требования к расчетам графического процессора (например, задачи машинного обучения).

2. Поддержка AMD EPYC Generation 2.

Новый релиз vSphere будет полностью совместим с поколением процессоров AMD EPYC. VMware и AMD работают в тесном сотрудничестве в целях поддержки самых последних нововведений в плане безопасности и производительности, заявленных в последних моделях данной линейки CPU.

3. Возможность изменить PNID для vCenter.

Идентификатор PNID (Primary Network IDentifier) сервера vCenter Server - это его сетевое имя (оно же FQDN), которое задается на этапе установки. Теперь есть возможность изменить его прямо в интерфейсе:

4. Поддержка Dynamic DNS (DDNS).

Dynamic DNS - это механизм обновления записей DNS-серверов новыми данными при изменении IP-адресов хостов. Ранее при использовании динамических IP для vCenter Server appliance (VCSA), в случае, если адрес менялся, приходилось вручную обновлять DNS-записи (собственно, поэтому никто и не использовал динамические IP). Теперь же с поддержкой DDNS этот процесс автоматизирован.

5. Улучшения поддержки драйверов.

Для сетевого драйвера VMXNET3 версии 4 были добавлены следующие возможности:

  • Guest encapsulation offload and UDP (расчет контрольных сумм)
  • Поддержка ESP RSS для стека Enhanced Networking Stack (ENS)

Также было обновлено множество драйверов, например, в драйвере ixgben появились функции queue pairing для оптимизации производительности CPU, а в драйвере bnxtnet добавилась поддержка адаптеров Broadcom 100 GbE и потоков multi-RSS.

Вот полный список обновленных драйверов:

  • VMware nvme
  • Microchip smarpqi
  • Marvell qlnativefc
  • Broadcom lpfc/brcmfcoe
  • Broadcom lsi_msgpt2
  • Broadcom lsi_msgpt35
  • Broadcom lsi_msgpt3
  • Broadcom lsi_mr3
  • Intel i40en
  • Intel ixgben
  • Cisco nenic
  • Broadcom bnxtnet

Скорее всего, новая версия VMware vSphere 6.7 Update 3 будет доступна для скачивания либо во время VMworld 2019, либо через несколько дней после его завершения. Следите за нашими обновлениями.


Таги: VMware, vSphere, Update, vCenter, ESXi

Как делать схемы и диаграммы для виртуальной инфраструктуры VMware vSphere без Microsoft Visio и бесплатно?


В прошлом мы много писали о стенсилах Visio для различных продуктов VMware (а также от других вендоров, например, Veeam Stencils). Между тем, пользоваться Visio не всем удобно - кто-то привык работать на Mac OS, где нет Microsoft Visio, кому-то не хочется покупать этот инструмент ради простеньких диаграмм и т.п.

Потому я думаю, что многим будет полезно узнать о проекте draw.io, который бесплатно позволяет рисовать схемы и диаграммы средствами онлайн-утилиты с использованием стенсилов VMware, Veeam и других. Для начала работы загрузите, например, стенсилы VMware с помощью меню Import:

После импорта можно сразу начать рисовать диаграммы:

После составления диаграммы или схемы, ее можно экспортировать в формат картинки или PDF, а также в файл VSDX (это пока в состоянии beta).

Напомним, что сами стенсилы можно скачать по этим ссылкам:

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


Таги: VMware, Stencils, Visio, Бесплатно, vSphere, Graphics, Reportng

Компоненты обновленной архитектуры VMware Cloud Foundation 3.8 уже доступны для скачивания.


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

В конце июля компания VMware выпустила обновление этой архитектуры - Cloud Foundation 3.8. Теперь в состав комплекса решений входят следующие компоненты:

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

1. Первый релиз публичного API.

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

2. Упрощение управления жизненным циклом.

Теперь вся архитектура поддерживает автоматическое обновление продуктов семейства Realize с помощью продукта vRealize Suite Lifecycle Manager (vRSLCM). Можно обновлять vRealize Log Insight, vRealize Operations Manager и vRealize Automation. Также автоматическое обновление доступно и для решения VMware NSX-T.

3. Поддержка Cloud Foundation на платформе VxRail.

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

Также консоль SDDC Manager теперь поддерживает управление сертификатами для VxRail Manager. Помимо этого, VxRail Manager теперь интегрирован с решением Log Insight таким образом, что он предоставляет автоматизацию управления логами и мониторинг для всей инфраструктуры.

4. Улучшения масштабируемости.

Теперь vCF поддерживает расширение кластера vRealize Operations Manager в консоли SDDC Manager для случаев, когда пользователям нужно промасштабировать кластер и добавить новые узлы.

5. Улучшения SSO.

Для обеспечения лучшего взаимодействия между доменами управления (Management Domains) и доменами рабочей нагрузки (Workload Domains), архитектура Cloud Foundation теперь может объединять домены SSO (а точнее их контроллеры PSC) для двух или более экземпляров Cloud Foundation.

Более подробно узнать об архитектуре VMware Cloud Foundation 3.8 можно по этой ссылке. Release Notes доступны тутвот тут - для платформы VxRail).


Таги: VMware, Cloud Foundation, Update, vSphere, VxRail, Cloud

Где найти все сессии предстоящего VMware VMworld 2019 и топ-25 докладов от Дункана Эппинга.


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

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

Кстати, не забывайте и об онлайн-библиотеке материалов VMworld 2018.

Ну а для тех, кому лень искать по всем этим сотням докладов, блоггер Дункан Эппинг выпустил свой список топ-25 сессий, который мы приведем ниже:

Конечно же, как и всегда, мы будем освещать VMworld 2019. Смотрите также наши обзоры с прошлых конференций:


Таги: VMware, vSphere, VMworld, Events

Использование общих ресурсов Content Library в гибридной среде VMware vCloud on AWS.


На прошлой неделе мы писали об организации среды управления на базе vCenter Hybrid Linked Mode для гибридной виртуальной инфраструктуры, объединяющей ресурсы частного и публичного облаков. Сегодня мы поговорим еще об одной полезной вещи - библиотеке контента Content Library, в которой можно хранить шаблоны виртуальных машин (VM Templates), готовые виртуальные устройства (Virtual Appliances) в формате OVF/OVA, а также другие объекты (например, ISO-образы).

VMware vSphere Content Library позволяет подписать датацентры на обновления главного датацентра (который представляется как издатель/publisher), где можно создать шаблон виртуальной машины, а на уровне подчиненного датацентра (подписчик/subscriber) администраторы видят содержимое библиотеки и развертывают машины из него.

Такая же ситуация и с облачной и гибридной средой -  Content Library очень просто и быстро позволяет распространять контент по сети датацентров.

Так же, как и в онпремизной инфраструктуре, в облаке VMware vCloud on AWS вы можете подписаться на обновления существующей Content Library. Для этого в vSphere Client перейдите в Menu > Content Libraries:

Нажмите плюсик для создания новой библиотеки:

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

Далее указываем Subscription URL вашей библиотеки:

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

Дальше выбираем хранилище, где будет находиться контент:

Ну и после создания библиотека появится в списке:

Когда вы кликните на библиотеку, вы увидите разделение на шаблоны виртуальных машин, готовые виртуальные модули OVF/OVA и другой контент, такой как ISO-образы:

Далее можно выбрать, например, шаблон ВМ, нажать на него правой кнопкой и выбрать пункт создания новой ВМ из этого шаблона (New VM from This Template...):

Также весь этот путь в рамках рабочего процесса по операциям в vCenter можно пройти в лабораторной работе VMware Cloud on AWS - Getting Started Hands-on Lab.


Таги: VMware, vSphere, vCloud, AWS, Content Library, Amazon

Настройка гибридного режима Hybrid Linked Mode для онпремизного и облачного датацентров на платформе VMware vCloud on AWS (VCM).


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

Сегодня мы поговорим об основном инструменте VMC, который позволяет управлять гибридной облачной средой. Сначала отметим, что управление такой структурой основывается на механизме Linked Mode, который объединяет серверы vCenter и позволяет использовать единое пространство объектов в географически распределенных датацентрах. Сейчас он называется Enhanced Linked Mode или Embedded Linked Mode (когда Platform Services Controller и vCenter Server Appliance находятся вместе на одном сервере).

Если вы разворачиваете Linked Mode на собственной инфраструктуре, то все серверы vCenter должны быть в одном домене SSO и иметь одну и ту же версию (включая номер билда). Когда же вы используете общий режим vCenter в гибридной среде (Hybrid Linked Mode), то ситуация, когда в облаке развернута более новая версия vCenter, считается нормальной.

Есть 2 способа использовать гибридный режим управления vCenter. Первый - это развернуть виртуальный модуль (virtual appliance) Cloud Gateway в своей инфраструктуре и соединить его с облачной инфраструктурой SDDC. Второй - это зайти с помощью vSphere Client на облачный SDDC и управлять объединенными ресурсами частного и публичного облака оттуда.

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

Чтобы начать работу по созданию единой управляющей среды гибридного облака, нужно скачать установщик Cloud Gateway installer. Для этого надо зайти в консоль VMware Cloud on AWS и перейти на вкладку Tools. Там можно скачать этот виртуальный модуль:

Скачиваем ISO-образ Cloud Gateway и монтируем его к вашей рабочей станции. Запускаем его из папки /ui-installer и проходим по шагам мастера. На одном из них задаем параметры сервера онпремизного vCenter, где будет установлен шлюз:

В процессе установки вас попросят указать пароль root, целевой датастор, конфигурацию сети, NTP и SSO, также будет возможность присоединить шлюз к домену Active Directory.

Далее нужно переходить ко второму этапу - настройке гибридного режима Hybrid Linked Mode. Не забудьте свериться с требованиями к этому режиму в документации.

Далее нужно будет указать IP-адрес облачного сервера vCenter и параметры учетной записи cloudadmin@vmc.local.

Эту информацию можно получить в консоли VMware Cloud on AWS, выбрав ваш SDDC, затем Settings и развернуть поле Default vCenter User Account:

В качестве Identity Source нужно указать ваш онпремизный домен AD, для которого вы хотите настроить доступ.

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


Таги: VMware, vCenter, Hybrid Linked Mode, Cloud, Hybrid, vSphere, VCM, AWS, Amazon

На VMware Labs спустя неделю обновился vSphere Mobile Client до версии 1.2.


На прошлой неделе мы писали о выпуске мобильного клиента для управления виртуальной инфраструктурой VMware vSphere - Mobile Client версии 1.1.

А на днях компания VMware на сайте проекта Labs уже выложила его обновление - vSphere Mobile Client 1.2. Давайте посмотрим, что там нового:

  • Улучшения inventory - возможность добавить ВМ в закладки, после чего можно быстро перейти к ней из верхней панели в заголовке.
  • Дэшборд vCenter теперь агрегирует хосты и виртуальные машины.
  • Свайп карточки ВМ теперь показывает скриншот, по клику на который отображается большая картинка.
  • Множество исправлений ошибок.

Скачать обновленный vSphere Mobile Client 1.2 можно по этим ссылкам:

Чтобы получать пуш-уведомления на ваши устройства, нужно будет поднять vSphere Mobile Client Notification Service в виде контейнера Docker. О том, как это сделать написано тут, а скачать сам контейнер можно на странице vSphere Mobile Client.


Таги: VMware, Labs, vSphere, Mobile, Client, Update

Как обновлять и апгрейдить инфраструктуру VMware vCenter HA?


Многи администраторы VMware vSphere, особенно в крупных инфраструктурах, развертывают механизм VMware vCenter HA, обеспечивающий отказоустойчивость сервера VMware vCenter (а точнее виртуальной машины vCenter или vCenter Server Appliance, vCSA). Все понимают, что vCenter / vCSA - это важнейшая часть виртуальной инфраструктуры, ведь без нее не работают такие критичные сервисы, как Site Recovery Manager, NSX и Horizon View.

Функции vCenter HA появились еще в VMware vSphere 6.5, но в vSphere 6.7 Update 1 они были существенно доработаны, а сам процесс обновления и апгрейдов vCenter упрощен. При этом управление механизмом vCenter HA полностью перешло в vSphere Client в рамках единого рабочего процесса (раньше были 2 воркфлоу - Basic и Advanced).

Давайте посмотрим, какие пути апгрейда и обновления существуют для конфигурации vCenter HA. Для начала напомним, как это выглядит:

Две машины с vCenter (активный узел и его клон - пассивный узел), а также компонент Witness образуют собой кластер, где Witness защищает от сценария Split Brain в среде vCenter HA (не путайте это с обычным vSphere HA). В случае отказа основного узла, его функции берет на себя резервный, что существенно быстрее по сравнению с восстановлением vCenter средствами стандартного HA (перезапуск на другом сервере). Это в итоге отражается на меньшем времени RTO для таких критичных сервисов, как SRM и NSX, в случае сбоев.

Перед обновлением помните, что для vCenter HA не поддерживается создание снапшотов, а значит нужно обязательно сделать File-Based Backup основного сервера vCenter перед обновлением.

Если у вас VMware vSphere 6.5, то при обновлении вы можете не разбивать кластер vCenter HA, а просто скачать ISO-образ с обновлениями (через VMware Patch Portal), либо ничего не скачивать и сразу инициировать процесс обновления из командной строки, если у вас есть доступ в интернет из компонентов кластера.

Делается все это так:

  • Сначала кластер vCenter HA надо перевести в режим обслуживания (maintenance mode), что не прервет репликацию, но предотвратит автоматический запуск процесса восстановления (failover).

  • Затем заходим на компонент Witness по SSH и запускаем его обновление из командной строки. Если у вас есть доступ в интернет на этом экземпляре vCenter, то делается это простой командой:

software-packages install --url --acceptEulas

Если же вы скачали ISO-образ с обновлениями, то делается это следующей командой:

software-packages install --iso --acceptEulas

  • Далее заходим на пассивный узел vCenter и там делаем то же самое.
  • Инициируем вручную процесс восстановления vCenter на пассивный узел (failover).
  • Обновляем активный узел vCenter.
  • Возвращаем конфигурацию в исходное состояние (failback).
  • Отключаем режим обслуживания (maintenance mode).

Если же у вас vCenter 6.7, то опция обновления у вас одна - отключение и удаление конфигурации HA, после чего происходит накат обновления на активном узле и повторное развертывание HA-конфигурации (такая же опция доступна и для vCenter 6.5). Этот рабочий процесс обусловлен изменениями в схеме базы данных, которые происходят в vCenter 6.7.

Начиная с vSphere 6.7 Update 1, установщик vCenter Server Upgrade installer может автоматически обнаружить присутствие кластера vCenter HA:

Далее в процессе обновления он сохранит его конфигурацию, обновит активный узел vCenter, а потом развернет его реплики для пассивного узла и узла Witness.

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


Таги: VMware, vCenter, HA, vSphere, Update, Upgrade

После обновления VMware vCenter Server Appliance (vCSA), при попытке зайти в интерфейс VAMI - страница не найдена или содержимое окна просто пропадает.


Некоторые пользователи сталкиваются с проблемой при обновлении сервера VMware vCenter Server Appliance (vCSA). После накатывания апдейта на vCSA (в частности, здесь пишут про билд 6.5.0.30100) администратор идет по адресу:

https://<vCenter_FQDN>:5480

И видит, что страница не открывается, браузер не находит веб-сервер.

Это происходит потому, что иногда после обновления vCSA не поднимается служба vami-lighttp, которая отвечает за веб-интерфейс VAMI (Virtual Appliance Management Infrastructure). Нужно пойти в консоль vCSA и там выполнить следующую команду для вывода статуса этой службы:

ps -ef | grep vami-lighttp

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

/etc/init.d/vami-lighttp start

После этого VAMI должен начать работать. Также у vCSA есть загадочная зависимость от протокола IPv6, которая описана здесь.

Ну и посмотрите нашу статью, в которой описывается ситуация, когда страница VAMI на vCSA открывается, но при вводе учетных данных выводится сообщение "Unable to login".


Таги: VMware vCSA, Bug, Update, Troubleshooting, vCenter, vSphere

Еще одна новинка VMware Labs в сфере Data Science - Machine Learning on VMware Cloud Foundation.


На этой неделе мы писали про обновления на сайте проекта VMware Labs - Virtual Machine Compute Optimizer и vSphere Mobile Client, а сегодня расскажем еще про одну новую штуку - Machine Learning on VMware Cloud Foundation (vMLP).

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

  • Виртуальное окружение на основе облака VMware Cloud Foundation (VCF) и платформы Kubernetes.
  • На данный момент для вычислений поддерживается только CPU (но модули GPU будут поддерживаться в будущем).
  • Платформа построена на базе фреймворков Open Source Kubeflow и Horovod.

 

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

  • Data collection and cleaning (получение данных из различных источников и описание семантики данных с использованием метаданных).
  • Data cleansing and transformation (приведение собранных данных в порядок и их трансформация из сырого формата в структурированный, который больше подходит для процессинга).
  • Model training (разработка предиктивных и оптимизационных моделей машинного обучения).
  • Model serving (развертывание модели для запуска в реальном окружении, где могут обслуживаться онлайн-запросы).

Для использования движка vMLP вам потребуется развернутая инфраструктура VMware Cloud Foundation 3.8.

В комплекте с платформой идет документация. Скачать весь пакет можно по этой ссылке.


Таги: VMware, Labs, ML, vSphere, Cloud, VCF

Еще одна новая штука на VMware Labs - Virtual Machine Compute Optimizer.


Вчера мы писали об очередной новинке на VMware Labs, мобильном клиенте vSphere Mobile Client для iOS и Android, а сегодня расскажем еще об одной утилите - Virtual Machine Compute Optimizer. Это средство представляет собой PowerShell-сценарий для модуля PowerCLI VMware.VimAutomation.Core, который собирает информацию о хостах ESXi и виртуальных машинах в вашем виртуальном окружении и выдает отчет о том, правильно ли они сконфигурированы с точки зрения процессоров и памяти.

Для этого в отчете есть колонка VMCPUsOptimized, которая принимает значения Yes или No.

Далее также идут колонки, где показаны оптимальные количества сокетов и ядер для виртуальных машин, которые было бы неплохо сделать для текущей конфигурации (OptimalSockets и OptimalCores). Текущая конфигурация также представлена в колонках VMNumSockets и VMCoresPerSocket.

Назначения колонок представлены на картинке ниже:

Надо понимать, что VMCO анализирует вашу инфраструктуру только на базе рекомендаций для оптимальной конфигурации виртуальных машин без учета реальной нагрузки, которая исполняется внутри. Для такой задачи нужно средство для сайзинга посерьезнее - например, VMware vRealize Operations Manager.

Скрипт Virtual Machine Compute Optimizer можно запускать как минимум под аккаунтом с правами на чтение инфраструктуры vCenter. Скачать его по этой ссылке.


Таги: VMware, Labs, Compute, vSphere, ESXi, PowerCLI, PowerShell

Новое на VMware Labs - мобильный клиент vSphere Mobile Client 1.1 для iOS и Android.


Еще очень давно, 8 лет назад, компания VMware развивала мобильный клиент (см. также тут) для управления инфраструктурой VMware vSphere, но забросила это дело на некоторое время.

И вот совсем недавно на сайте проекта VMware Labs появилось средство vSphere Mobile Client 1.1. Это очередной подход VMware к управлению виртуальной средой через мобильные приложения для iOS и Android.

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

  • Просмотр информации и виртуальных машинах - просмотр статуса ВМ (включено/выключено), использования ресурсов и конфигурации машин.
  • Управление ВМ - операции с питанием (в том числе, перезагрузка). Возможность найти виртуальную машину с помощью поиска. Если вы свайпните влево карточку с виртуальной машиной, то получите скриншот ее консоли, который можно сохранить.
  • Мониторинг задач - можно "подписаться" на любую запущенную задачу и получать нотификации на телефон о том, когда она завершится. При этом неважно, что ваш девайс находится в неактивном режиме или в данный момент вы работаете с другим приложением.
  • Графики производительности - можно отслеживать использование ресурсов виртуальными машинами в реальном времени, либо в разрезе дня, недели, месяца или года назад. Счетчики включают в себя метрики CPU, памяти, хранилищ и сети. Также на дэшборде можно посмотреть общее использование ресурсов vCenter.

Ссылки на загрузку vSphere Mobile Client:

Чтобы получать пуш-уведомления на ваши устройства, нужно будет поднять vSphere Mobile Client Notification Service в виде контейнера Docker. О том, как это сделать написано тут, а скачать сам контейнер можно на странице vSphere Mobile Client.


Таги: VMware, Labs, Mobile, vSphere, VMachines, Monitoring

Storage I/O Control (SIOC) версии 2 в VMware vSphere - что там интересного?


Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.

Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.

SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):

На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:

Надо отметить, что SIOC v1 начинает работать только тогда, когда у датастора есть затык по производительности, и он не справляется с обработкой всех операций ввода-вывода.

Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.

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

Поэтому важно понимать, что SIOC v1 и SIOC v2 можно использовать одновременно, так как они касаются разных аспектов обработки потока ввода-вывода от виртуальных машин к хранилищам и обратно.

SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:

На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:

Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:

Так для Normal:

А так для High:

Если выберите вариант Custom, то дефолтно там будут такие значения:

Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.

Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:

После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:


Таги: VMware, vSphere, SIOC, Update, SPBM, Storage, Performance, VMachines

Монтирование датасторов VVols в VMware vSphere через PowerShell на примере Pure Storage.


Мы часто пишем о томах VVols (Virtual Volumes), которые позволяют вынести часть нагрузки по обработке операций с хранилищами на сторону аппаратных устройств (они, конечно же, должны поддерживать эту технологию), что дает пользователям преимущества по сравнению с VMFS. В инфраструктуре VVols массив сам определяет, каким образом решать задачи доступа и организации работы с данными для виртуальных машин, выделяя для их объектов (виртуальные диски и прочее) отдельные логические тома (VVols).

Один из известных производителей, поддерживающих технологию VVols - это компания Pure Storage. Недавно Cody Hosterman написал статью о том, как подключить тома VVols в VMware vSphere через PowerCLI для хранилищ Pure Storage. Коди развивает свой модуль PowerShell, который называется PureStorage.FlashArray.VMware.

Давайте посмотрим, как он работает. Сначала можно почитать о доступных опциях командлета Mount-PfaVvolDatastore, с помощью которого можно сделать монтирование датастора VVol:

Командлет может делать следующее:

  • Проверяет, презентован ли protocol endpoint (PE) указанного массива кластеру. Если нет, то с его помощью можно сделать это.
  • Ресканирует кластер, чтобы убедиться, что PE виден хостам.
  • Монтирует VVol в кластере.
  • Возвращает датастор хранилищу.

Пример 1 - имеется прямой доступ к массиву

Соединяемся с vCenter и создаем соединение с FlashArray:

connect-viserver -Server <vCenter FQDN>
$flasharray = new-pfaConnection -endpoint <FlashArray FQDN> -credentials (get-credential) -ignoreCertificateError -nonDefaultArray

В интерфейсе vSphere Client датастор VVol еще не будет смонтирован:

Со стороны Pure Storage protocol endpoint также не подключен:

Запускаем Mount-PfaVvolDatastore:

Mount-PfaVvolDatastore -flasharray $flasharray -cluster (get-cluster <cluster name>) -datastoreName <datastore name>

После этого PE будет подключен к Pure Storage:

А датастор VVol будет смонтирован к кластеру:

Пример 2 - нет доступа к массиву

Значит тут мы полагаем, что администратор хранилищ уже настроил PE, и вам нужно только смонтировать том VVol:

Так как датастор VVol ранее не монтировался, нельзя просто создать array connection (нет доступа к массиву). В этом случае подойдет командлет Get-VasaStorageArray:

Передав в командлет монтирования массив FA-m50, имя кластера и имя датастора, можно смонтировать том VVol:

$vasaArrays = Get-VasaStorageArray
Mount-PfaVvolDatastore -vasaArray $vasaArrays[<desired index>] -cluster (get-cluster <cluster name>) -datastoreName <datastore name>

Если обобщить, то процесс монтирования датастора VVol с самого начала выглядит так:

  • Установка модуля PowerShell
  • Соединение с массивом
  • Соединение с vCenter
  • Создание хостовой группы (в случае с iSCSI нужно еще настроить iSCSI-таргеты)
  • Зарегистрировать VASA-провайдер
  • Смонтировать датастор VVol

Полный сценарий PowerShell приведен ниже:

install-module PureStorage.FlashArray.VMware

$flasharray = new-pfaConnection -endpoint flasharray-m50-1 -credentials (get-credential) -ignoreCertificateError -nonDefaultArray
connect-viserver -Server vcenter-02

$cluster = get-cluster Embarcadaro

New-PfaHostGroupfromVcCluster -cluster $cluster -iscsi -flasharray $flasharray

New-PfaVasaProvider -flasharray $flasharray -credentials (get-credential)

Mount-PfaVvolDatastore -flasharray $flasharray -cluster $cluster -datastoreName m50-VVolDS

Так это выглядит в командной строке:

А так в консоли vSphere Client:


Таги: VMware, vSphere, PowerShell, VVols, Storage, Hardware, Pure Storage

Улучшенный интерфейс управления плагинами в VMware vSphere 6.7 Update 2.


Не так давно мы писали о новых возможностях последней версии платформы виртуализации VMware vSphere 6.7 Update 2. Одним из нововведений стал улучшенный интерфейс управления плагинами (Plugin Management UI), который дает пользователю полный контроль над процессами обновления и развертывания плагинов к vSphere.

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

В подразделе Client Plug-ins раздела Administrator теперь приведены все клиентские зарегистрированные плагины на любом из серверов vCenter в вашем окружении. Также у этих плагинов есть статусы: In Progress, Deployed, Failed или Incompatible.

Статусы Failed и Incompatible являются кликабельными - при нажатии на них всплывет подсказка с возможной причиной возникновения подобных ошибок или причины несовместимости (при возможности будет также приведен участок лога):

В процессе инсталляции плагин проходит через несколько фаз, которые отслеживаются сервером vCenter, также их можно получать через TaskManager API (его могут использовать и сторонние разработчики). Выполняемые задачи отображаются на сервере vCenter в 3 разделах:

  • Панель Recent Tasks в нижней части клиента
  • Консоль в разделе задач (Task Console)
  • Просмотр представления Tasks для выбранного объекта vCenter Server

Задачи создаются и отслеживаются на сервере vCenter, к которому в данный момент подключен vSphere Client. Если же виртуальная среда работает в режиме федерации Enhanced Linked Mode, то задачи по развертыванию плагина создаются на всех подключенных серверах vCenter. Поэтому любой экземпляр vSphere Client будет видеть эти задачи.

Как происходит работа с плагинами

При логине пользователя в vSphere Client, все плагины vCenter загружаются в кэшированную папку самого клиента на сервере vCenter. Для отслеживания этого процесса создается задача "Download plug-in". Если загрузка плагина прошла успешно, то он становится доступным для развертывания, что видно в консоли задач. И это значит, что он был загружен в кэшированную папку.

Следующая фаза - это задача "Deploy plug-in", которая стартует следующей. Если она завершается успешно, это значит, что плагин установлен и доступен для использования со стороны vSphere Client. Кстати, если задача Download plug-in прошла с ошибкой, то и задача Deploy plug-in будет пропущена.

Ошибки плагинов при развертывании теперь детально описаны в консоли:

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

В случае апгрейда плагина этот процесс представляется набором из трех задач: "Download plug-in", "Undeploy plug-in" и "Deploy plug-in". После этого в vSphere Client появляется глобальная нотификация о новой версии развернутого плагина и с просьбой сделать рефреш в браузере, чтобы плагин начал работать.

Один сервер vCenter может работать только с одной версией плагина, но в архитектурах Enhanced Linked Mode и Hybrid Linked Mode может быть несколько серверов vCenter, каждый из которых может содержать свою версию плагина.

В этом случае vSphere Client обрабатывает плагины двумя способами:

  • Local plug-in architecture - в этом случае оперирование происходит с самой новой версией плагина, обнаруженной на всех доступных серверах vCenter. При этом все остальные версии плагина игнорируются. Если обнаруживается более новая версия плагина на одном из серверов vCenter - происходит ее апгрейд.
  • Remote plug-in architecture - она появилась в vSphere 6.7 Update 1. В этом случае происходит поддержка своей версии плагина на уровне того сервера vCenter, с которым происходит оперирование со стороны vSphere Client. Такое поведение используется, например, в среде Hybrid Linked Mode, где версии плагинов и серверов vCenter могут отличаться очень значительно. В этом случае все версии плагина скачиваются с соответствующих экземпляров vCenter и работа со стороны vSphere Client происходит с каждой версией как с независимым плагином.

Ну и напоследок приведем статусы, которые могут возникать при развертывании и апгрейде плагинов:

In progress

Плагин находится в стадии развертывания.

Deployed

Плагин установлен и доступен для использования через интерфейс vSphere Client.

Failed

Показывается при невозможности скачать или установить плагин:

  • Download error
    • Установка из незащищенного места - используется http вместо https.
    • Невозможно получить URL плагина.
    • vSphere Client не авторизован для скачивания плагина.
  • Packaging error
    • Поврежден zip-пакет плагина.
    • Отсутствует файл манифеста.
    • Отсутствует папка plugins.
    • Отсутствуют необходимые бандлы в плагине.
  • Deployment error
    • Ошибка связей (Dependency error) при развертывании плагина на vSphere Client.
    • Собственная ошибка плагина (Runtime plug-in error).
Incompatible

Показывается когда плагин не поддерживается для данной версии vSphere Client. Возможные причины:

  • Плагин добавлен в черный список администратором.
  • В плагине прописано, что он поддерживает только конкретные версии vSphere Client (и вашей в списке нет).
  • Это плагин на базе флэш-интерфейса под старый клиент vSphere Web Client.

Таги: VMware, vSphere, Plugin, Update, Troubleshooting, Client, Upgrade, vCenter

Вышел VMware vSphere 6.5 Update 3 и обновления других продуктов.


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

Давайте посмотрим, что нового в vSphere 6.5 U3.

Новые функции vCenter 6.5 Update 3:

  • События о добавлении, удалении и модификации пользовательских ролей содержат информацию о пользователе, который производит изменения.
  • Улучшения возможностей аудита в компоненте VMware vCenter Single Sign-On - теперь появились события для следующих операций: управление пользователями, логин, создание групп, изменение источника идентификации, управление политиками. Доступна эта фича только для виртуального модуля vCSA с интегрированным Platform Services Controller. Поддерживаемые источники идентификации: vsphere.local, Integrated Windows Authentication (IWA) и Active Directory over LDAP.
  • Поддержка новых внешних баз данных - добавлена поддержка Microsoft SQL Server 2014 SP3.
  • Обновления ОС Photon для vCSA.

Release Notes для vCenter 6.5 U3 находятся здесь.

Новые функции ESXi 6.5 Update 3:

  • Драйвер ixgben добавляет функцию queue pairing для оптимизации эффективности CPU.
  • С помощью ESXi 6.5 Update 3 вы можете отслеживать использование лицензий и обновлять топологию коммутаторов. Также улучшения можно увидеть в Developer Center клиента vSphere Client.
  • Поддержка устаревших серверов AMD Zen 2.
  • Множество обновлений драйверов устройств: lsi-msgpt2, lsi-msgpt35, lsi-mr3, lpfc/brcmfcoe, qlnativefc, smartpqi, nvme, nenic, ixgben, i40en и bnxtnet.
  • Поддержка Windows Server Failover Clustering и Windows Server 2019.
  • Добавлено свойство com.vmware.etherswitch.ipfixbehavior в распределенные виртуальные коммутаторы, чтобы позволить пользователям выбирать способ трекинга входящего и исходящего трафика. Значение 1 включает сэмплирование для входящего и исходящего трафика, значение 0 включает его только для исходящего (значение по умолчанию).

Release Notes для ESXi 6.5 U3 находятся здесь.

Если вы ожидали среди возможностей чего-то действительно нового - увы, этого не бывает. VMware надо развивать ветку vSphere 6.7 и следующие версии платформы. Скачать VMware vSphere 6.5 Update 3 можно по этой ссылке.

Какие еще продукты VMware были обновлены параллельно с этим релизом:

  • vSphere Replication 6.5.1.4 - просто обновление с исправлением ошибок.
  • App Volumes 2.17 - поддержка Windows 10 1903, коммуникация с SQL Server по протоколу TLS 1.2. Остальное - здесь.
  • User Environment Manager 9.8.0 - это большое обновление, подробнее о нем вот тут.

Таги: VMware, vSphere, Update, ESXi, vCenter, vCSA, AppVolumes, Replication, UEM

10 полезных вещей, которые надо знать об SSL-сертификатах VMware vSphere.


Многие администраторы платформы VMware vSphere очень часто интересуются вопросом замены сертификатов для серверов ESXi в целях обеспечения безопасности. Как правило, это просто инструкции, которые не дают понимания - а зачем именно нужно менять эти сертификаты.

Недавно VMware выпустила интересную статью на тему сертификатов в vSphere и других продуктах, приведем ниже основные выдержки из нее.

1. Сертификаты - это вопрос доверия и шифрования.

При соединении с различными веб-консолями компонентов инфраструктуры VMware vSphere используется протокол HTTPS, где S означает "Secure". Инфраструктура SSL, а точнее ее последователь Transport Layer Security (TLS), использует известный в криптографии принцип открытого и закрытого ключей, который позволяет узлам, доверяющим друг другу безопасно обмениться информацией по шифрованному каналу.

TLS развивается по следующему пути:

  • Версия 1.0 имеет уязвимости, он небезопасен и больше не должен использоваться.
  • Версия 1.1 не имеет таких уязвимостей, как 1.0, но использует такие алгоритмы шифрования, как MD5 и SHA-1, которые больше не считаются безопасными.
  • Версия 1.2 добавляет шифрование AES, которое работает быстро и не использует небезопасные методы, сам же алгоритм использует SHA-256. На текущий момент это стандарт TLS.
  • Версия 1.3 не содержит слабых точек и добавляет возможности увеличения скорости соединения, этот стандарт скоро будет использоваться.

Если вы используете сертификаты vSphere, то независимо от того, какие они (самоподписанные или выданные центром сертификации) - общение между компонентами виртуальной инфраструктуры будет вестись посредством TLS с надежным шифрованием. Вопрос сертификатов тут - это всего лишь вопрос доверия: какому объекту, выпустившему сертификат, вы доверяете - это и есть Центр сертификации (он же Certificate Authority, CA).

Многие крупные компании, имеющие определенный вес (например, Microsoft) сами являются Центрами сертификации, а некоторые компании используют службы Microsoft Active Directory Certificate Services, чтобы встроить собственные CA в операционную систему и браузеры (импортируют корневые сертификаты), чтобы "научить" их доверять этим CA.

2. В VMware vSphere сертификаты используются повсеместно.

Как правило, они используются для трех целей:

  • Сертификаты серверов ESXi, которые выпускаются для управляющих интерфейсов на всех хост-серверах.
  • "Машинные" сертификаты SSL для защиты консолей, с которыми работает человек - веб-консоль vSphere Client, страница логина SSO или Platform Service Controllers (PSCs).
  • "Solution"-сертификаты, используемые для защиты коммуникаций со сторонними к платформе vSphere продуктам, таким как vRealize Operations Manager, vSphere Replication и другим.

Полный список компонентов, где vSphere использует сертификаты, приведен вот тут.

3. vSphere имеет собственный Центр сертификации.

Платформа vSphere из коробки поставляется с собственным CA, который используется для коммуникации между компонентами. Называется он VMware Certificate Authority (VMCA) и полностью поддерживается для vSphere как с внешним PSC, так и для vCenter Server Appliance (vCSA) со встроенным PSC.

Как только вы добавляете хост ESXi в окружение vCenter, то VMCA, работающий на уровне vCenter, выпускает новый сертификат на этот ESXi и добавляет его в хранилище сертификатов. Такая же штука происходит, когда вы настраиваете интеграцию, например, с решениями vRealize Operations Manager или VMware AppDefense.

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

4. Есть 4 способа внедрить инфраструктуру сертификатов на платформе vSphere.

Вот они:

  • Использовать самоподписанные сертификаты VMCA. Вы можете просто скачать корневые сертификаты с веб-консоли vCenter, импортировать их в операционную систему клиентских машин. В этом случае при доступе к веб-консоли, например, vSphere Client у вас будет отображаться зеленый замочек.
  • VMCA можно сделать подчиненным или промежуточным (subordinate/ intermediate) центром сертификации, поставив его посередине между CA и конечными хостами, что даст дополнительный уровень сложности и повысит вероятность ошибки в настройке. VMware не рекомендует так делать.
  • Отключить VMCA и использовать собственные сертификаты для любых коммуникаций. Ваш ответственный за сертификаты должен нагенерировать запросы Certificate Signing Requests (CSR) для всех компонентов. Эти CSR-запросы вы отсылаете с CA, которому вы доверяете, получаете их подписанными, после чего устанавливаете их в ручном режиме. Это отнимает время и чревато ошибками. 
  • Использовать гибридный подход - для хостов ESXi в их коммуникации с vCenter использовать самоподписанные VMCA сертификаты, а для веб-консолей vSphere Client и прочих использовать перевыпущенные сертификаты, которые надо установить на сервере vCenter и хостах, с которых будет управляться инфраструктура через браузер (тогда в нем появится зеленый замочек). Это самый рекомендуемый VMware вариант использования сертификатов.

5. Enterprise-сертификаты - тоже самоподписанные.

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

6. Не создавайте промежуточный Центр сертификации.

Если вы создаете intermediate CA (он же subordinate CA) для VMCA, превращая его в посредника, вы создаете потенциальную опасность для виртуальной инфраструктуры - если кто-то получает доступ к корпоративному центру сертификации и его парам ключей, то он может навыпускать любых сертификатов от имени VMCA и перехватывать потом любые коммуникации.

7. Можно изменять информацию для самоподписанных сертификатов CA.

С помощью утилиты  Certificate Manager utility вы можете сгенерировать новый VMCA с необходимой информацией о вашей организации внутри него. Эта утилита перевыпустит все сертификаты и заменит их на всех хостах виртуальной инфраструктуры. Это хорошая опция для гибридной модели. Кстати, вы можете менять даты устаревания сертификатов, если дефолтные вас не устраивают.

8. Тестируйте инфраструктуру сертификатов перед внедрением.

Вы можете развернуть виртуальную инфраструктуру и провести все эксперименты с сертификатами в виртуальной среде, где вы можете использовать виртуальные (nested) серверы ESXi. Приятная штука в том, что вы можете создавать снапшоты виртуальных машин, а значит в случае чего - быстро откатитесь на рабочий вариант. Еще одна среда для экспериментов - это облачная инфраструктура VMware Hands-on Labs, где можно безопасно ставить любые эксперименты.

Попробуйте также новую vSphere 6.7 Lightning Lab.

9. Делайте бэкапы своей инфраструктуры.

Делайте резервную копию вашего vCenter и PSC на уровне файлов через веб-консоль VAMI. Также утилитой Certificate Manager можно скопировать старый набор сертификатов перед развертыванием новых (но только один набор сертификатов, учитывайте это). Также эта процедура полностью поддерживается со стороны VMware Global Support Services.

10. Понимайте, зачем вы заморачиваетесь с заменой сертификатов.

Ответьте для себя на несколько вопросов:

  • Стоит ли иконка зеленого замочка в браузере всех этих заморочек?
  • Нужно ли всем видеть этот замочек или только команде администрирования vSphere?
  • Почему вы доверяете vCenter для управления всем в виртуальной инфраструктуре, но не доверяете VMCA?
  • В чем отличие самоподисанного сертификата вашего предприятия от самоподписанного сертификата VMCA?
  • Действительно ли комплаенс требует от вас кастомных CA-сертификатов?
  • Какова будет цена процедур по замене сертификатов в инфраструктуре vSphere во времени и деньгах?
  • Увеличивает или уменьшает риск итоговое решение и почему конкретно?

Дополнительные ресурсы


Таги: VMware, vSphere, Security, Certificates, SSL, ESXi

Как работает и как используется Enhanced vMotion Compatibility (EVC) в кластерах VMware vSphere.


Как знают почти все администраторы платформы VMware vSphere, для кластеров VMware HA/DRS есть такой режим работы, как Enhanced vMotion Compatibility (EVC). Нужен он для того, чтобы настроить презентацию инструкций процессора (CPU) хостами ESXi так, чтобы они в рамках кластера соответствовали одному базовому уровню (то есть все функции процессоров приводятся к минимальному уровню с набором инструкций, которые гарантированно есть на всех хостах).

Ввели режим EVC еще очень давно, чтобы поддерживать кластеры VMware vSphere, где стоят хосты с процессорами разных поколений. Эта ситуация случается довольно часто, так как клиенты VMware строят, например, кластер из 8 хостов, а потом докупают еще 4 через год-два. Понятно, что процессоры уже получаются другие, что дает mixed-окружение, где по-прежнему надо перемещать машины между хостами средствами vMotion. И если набор презентуемых инструкций CPU будет разный - двигать машины между хостами будет проблематично.

EVC маскирует инструкции CPU, которые есть не на всех хостах, от гостевых ОС виртуальных машин средствами интерфейса CPUID, который можно назвать "API для CPU". В статье VMware KB 1005764 можно почитать о том, как в кластере EVC происходит работа с базовыми уровнями CPU, а также о том, какие режимы для каких процессоров используются.

Надо отметить, что согласно опросам VMware, режим кластера EVC используют более 80% пользователей:

В VMware vSphere 6.7 появились механизмы Cross-Cloud Cold и Hot Migration, которые позволяют переносить нагрузки в онлайн и офлайн режиме между облаками и онпремизной инфраструктурой.

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

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

Обратите внимание, что Per-VM EVC доступна только, начиная с vSphere 6.7 и версии виртуального железа Hardware Version 14. Эта конфигурация сохраняется в vmx-файле (потому и переезжает вместе с машиной) и выглядит следующим образом:

featMask.vm.cpuid.Intel = “Val:1”
featMask.vm.cpuid.FAMILY = “Val:6”
featMask.vm.cpuid.MODEL = “Val:0x4f”
featMask.vm.cpuid.STEPPING = “Val:0”
featMask.vm.cpuid.NUMLEVELS = “Val:0xd”

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

Основная причина, по которой не включают EVC - это боязнь того, что поскольку машины не будут использовать весь набор инструкций CPU (особенно самых последних), то это даст снижение производительности. Поэтому VMware написала целый документ "Impact of Enhanced vMotion Compatibility on Application Performance", где пытается доказать, что это не сильно влияет на производительность. Вот, например, производительность Oracle на выставленных базовых уровнях для разных поколений процессоров (в документе есть еще много интересных графиков):

Чтобы включить EVC на базе виртуальной машины, нужно ее выключить, после чего настроить нужный базовый уровень. Для автоматизации этого процесса лучше использовать PowerCLI, а сама процедура отлично описана в статье "Configuring Per-VM EVC with PowerCLI".

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

Get-VM | Select Name,HardwareVersion,
@{Name='VM_EVC_Mode';Expression={$_.ExtensionData.Runtime.MinRequiredEVCModeKey}},
@{Name='Cluster_Name';Expression={$_.VMHost.Parent}},
@{Name='Cluster_EVC_Mode';Expression={$_.VMHost.Parent.EVCMode}} | ft

Это даст примерно следующий результат (надо помнить, что отчет будет сгенерирован только для VM hardware version 14 и позднее):

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

Понять максимально поддерживаемый режим EVC на хосте можно с помощью команды:

Get-VMHost | Select-Object Name,ProcessorType,MaxEVCMode

В итоге вы получите примерно такой отчет:

В целом тут совет такой - включайте режим Enhanced vMotion Compatibility (EVC) в кластерах и для виртуальных машин VMware vSphere сейчас, чтобы не столкнуться с неожиданными проблемами в будущем.


Таги: VMware, vSphere, vMotion, EVC, CPU, Cloud Computing, Cloud

На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.


На сайте VMware Labs обновилась утилита HCIBench до версии 2.1.

Напомним, что о версии HCIBench 2.0 мы писали вот тут, а здесь мы рассматривали использование этой утилиты для замеров производительности кластеров VMware vSAN. Напомним, что это средство позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ Virtual SAN, а также других конфигураций виртуальной инфраструктуры.

Проект HCIbecnh ("Hyper-converged Infrastructure Benchmark") является оберткой для известного open source теста VDbench, он позволяет организовать автоматизированное тестирование гиперконвергентного кластера (HCI-кластера). Гиперконвергентный кластер - это когда все его вычислительные ресурсы, системы хранения и сети виртуализованы и собраны в единую интегрированную сущность и управляются из одной точки.

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

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

  • Интерфейс переключили на темную тему.
  • Переработанная технология подготовки VMDK, которая теперь работает гораздо быстрее за счет использования рандомизации на дедуплицированных хранилищах.
  • Добавлена возможность обновления процесса подготовки VMDK.
  • Добавлена проверка портов базы данных Graphite в процесс превалидации.
  • Пароли vCenter и хостов ESXi затемняются при сохранении
  • Добавлена кнопка удаления гостевой ВМ ("Delete Guest VM").
  • Пофикшены проблемы с дисплеями для Grafana.
  • Пофикшена проблема с пустыми результатами при отработки модели нагрузки FIO (Flexible I/O).
  • Множество мелких исправлений ошибок.

Скачать HCIBench 2.1 можно по этой ссылке. Документация пока доступна только для версии 2.0.


Таги: VMware, HCIBench, Update, Performance, ESXi, vSphere, vSAN, VMDK, Storage

Обновления, патчи, апгрейды и нумерация версий VMware vCenter на платформе vSphere - как это устроено?


Очень часто администраторы платформы VMware vSphere задаются следующими вопросами о версиях продукта vCenter: какая разница между обновлением vCenter (он же update) и патчем (patch)? в чем отличие апгрейда (upgrade) и миграции (migration)? почему некоторые версии vCenter нумеруются как-то отдельно? Попробуем дать ответы на эти вопросы ниже, используя материал вот этой статьи в блоге VMware.

Первое, что нужно понять - это нумерация версий vCenter. Она подразумевает 2 компонента - номер версии (например, vCenter 6.7 Update 2a) и номер билда (например, 13643870):

Номер версии имеет также и цифровое обозначение. Если вы зайдете в интерфейс VMware Appliance Management Interface (VAMI), то увидите там номер билда (13643870), а также полный номер версии (6.7.0.31000):

Если же вы зайдете в vSphere Client и перейдете там на вкладку Summary для вашего сервера vCenter (в данном случае vCenter Server Appliance, vCSA), то увидите там версию 6.7.0:

В данном случае в поле Build указан номер билда клиента vSphere Client (13639324), и не стоит его путать с номером билда самого vCenter. Все это как-то более-менее соотносится между собой (VAMI дает более полную информацию о цифровом номере версии).

Теперь, чтобы сложить все это в единую картину и соотнести с датой релиза конкретной версии vCenter, существует статья базы знаний KB 2143838, где есть полезная табличка:

Обратите внимание на последнюю колонку - Client/MOB/vpxd.log. Это версия клиента vSphere Client, и именно она появится в лог-файле vpxd.log, поэтому не стоит удивляться, что она отличается от номера билда vCenter.

Теперь перейдем к апдейтам и патчам. vCenter Server Update - это полноценное обновление платформы, которое может включать в себя новый функционал, исправления ошибок или доработки существующей функциональности. Выходит апдейт довольно редко и имеет свое строковое наименование (например, vCenter 6.7 Update 2a). Для апдейта всегда выпускается документ Release Notes, и его можно скачать через my.vmware.com.

Патч - это постоянно выпускаемое небольшое обновление для vCenter, которое поддерживает уровень безопасности, закрывает критические уязвимости, исправляет фатальные ошибки и т.п. Он может относиться к вспомогательным компонентам vCSA, например, Photon OS, базе данных Postgres DB или фреймворку Java.

Для патча нет выделенного документа Reelase Notes, но информация о нововведениях доступна в VMware vCenter Server Appliance Photon OS Security Patches. Патчи нельзя скачать через my.vmware.com, но они загружаются через VMware Patch Portal. Само собой, патчи включаются в апдейты, выпускаемые на какой-то момент времени. Патчи накатываются в рамках одного цифрового обновления. То есть 6.7 Update 1 не патчится напрямую на 6.7 Update 2b, сначала надо накатить апдейт 6.7 Update 2a, а затем уже пропатчиться на 6.7 Update 2b.

Также на VMware Patch Portal вы можете найти ISO-образы vCenter Server, но их не надо использовать для новых развертываний, они нужны только для восстановления вашего vCenter Server Appliance, если вы используете резервное копирование на уровне файлов.

Теперь перейдем к разнице между апгрейдом и миграцией. Апгрейд - это обновление мажорной версии сервера vCenter одного типа развертывания (например, вы делаете апгрейд vCenter Server Appliance 6.5 на vCenter Server Appliance 6.7). Миграция - это когда вы меняете тип развертывания vCenter, переходя, например, с Windows-платформы на Linux (к примеру, vCenter Server 6.5 for Windows мигрируете на vCenter Server Appliance 6.7).

Если вы обновляете vCSA 6.5 на 6.7, то апгрейд идет как бы ненастоящий - развертывается новый виртуальный модуль vCSA 6.7, и на него переезжают все настройки (FQDN, IP, сертификаты и UUID), а также содержимое базы данных vCSA 6.5.

Также надо упомянуть и back-in-time upgrade - это когда вы хотите обновить, например, vSphere 6.5 Update 2d на vSphere 6.7 Update 1. Прямое обновление тут не поддерживается, так как  Update 2d для версии 6.5 вышел позднее, чем Update 1 для версии 6.7. То есть Update 2d содержит код, которого нет в Update 1, а значит это может вызвать потенциальные конфликты.

Поэтому для каждой новой версии vCenter выпускается раздел Upgrade Notes for this Release, где можно найти информацию о возможности апгрейда:


Таги: VMware, vCenter, Update, Upgrade, vSphere

Проверки кластера VMware vSphere Update Manager перед обновлениями хостов (Remediation).


У средства обновления хостов VMware vSphere Update Manager (VUM) есть полезный механизм проверок Pre-Check Remediation Report, который выполняет предварительную проверку условий для обновления хостов ESXi, чтобы этот процесс не прервался уже после его начала. Эти условия очень просты, но иногда позволяют сэкономить массу времени, особенно в большой инфраструктуре VMware vSphere.

Чтобы запустить эти проверки, надо выбрать нужный вам кластер и нажать кнопку Pre-Check Remediation:

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

Отчет Pre-Check Remediation Report для кластера может содержать следующие пункты:

Номер Текущий статус Рекомендуемое действие Описание
1 Отключен ли DPM? Отключите DPM в кластере

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

2 Включен ли DRS? Включите DRS в кластере

Именно DRS позволяет серверу vCenter смигрировать ВМ на другие хосты ESXi, чтобы обновить целевой хост-сервер.

3 Отключен ли HA admission control? Отключите HA admission control

HA admission control предотвращает миграцию ВМ средствами vMotion, в результате которой не выполняются правила доступности слотов. Перед обновлением этот механизм лучше отключить.

4 Включен ли EVC в кластере? Включите EVC в кластере

EVC позволяет убедиться, что все хосты в кластере презентуют одинаковый набор инструкций CPU виртуальным машинам. Это позволяет гарантировать, что все они могут перемещаться на любой хост кластера средствами vMotion во время эвакуации машин с обновляемого хоста ESXi.

5 Успешны ли проверки vSAN health check? Проверьте страницу vSAN Health Check на наличие проблем

Проверки vSAN Health Check представляют собой набор тестов для хостов ESXi, составляющих кластер vSAN (например, тесты доступности хранилищ во время обновления). Они должны завершиться успешно перед началом процедуры обновления хостов.

Отчет Pre-Check Remediation Report для виртуальных машин может содержать следующее:

Номер Текущий статус Рекомендуемое действие Описание
1 К ВМ привязан привод CD/DVD Отключите привод CD/DVD

 

Это редкая, но случающаяся проблема, когда такие приводы используются, например, для монтирования ISO-образов.
2 К ВМ привязан floppy-драйв Отключите привод floppy

 

Очень редко, но бывает.
3 Для ВМ включена технология FT Отключите Fault Tolerance для ВМ

 

Технология Fault Tolerance не позволяет VUM обновлять ВМ.
4 На ВМ установлен VMware vCenter Server, при этом DRS в кластере отключена Включите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion

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

 

5 На ВМ установлен VMware vSphere Update Manager, при этом DRS в кластере отключенаВключите DRS в кластере и убедитесь, что машина может мигрировать средствами vMotion vCenter управляет процессом обновления, поэтому нужно, чтобы он мог переехать на другой хост в процессе обновления ESXi.


Таги: VMware, vSphere, Update Manager, VUM, Update, Обучение, ESXi, VMachines

Обновление безопасности VMSA-2019-0009 для VMware Tools. Как вам можно обновиться.


Компания VMware опубликовала уведомление VMSA-2019-0009 для пакета VMware Tools, который содержит уязвимость, позволяющую непривилегированному пользователю читать данные из гостевой ВМ, а также негативно влиять на ее гостевую ОС. Уязвимости подвержены версии VMware Tools ниже 10.3.10.

В качестве примера использования такой уязвимости можно привести Windows-машины, где включены службы Microsoft Remote Desktop Services. Также риску подвержены службы Microsoft SQL Server или IIS, использующие сервисные аккаунты.

Сначала надо вывести все ВМ, имеющие VMware Tools версии ниже 10.3.10 с помощью следующей команды PowerCLI:

Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’} | Sort-Object Name | Format-Table

Вот такая команда выдаст все Windows-машины с VMware Tools ниже, чем 10.3.10:

Get-VM | Where-Object {$_.Guest.ToolsVersion -lt ‘10.3.10’ -and $_.Guest.GuestFamily -eq ‘windowsGuest’} | Sort-Object Name | Format-Table

Проверить версию VMware Tools можно и самостоятельно в VMware vSphere Client:

Помните, что VMware 6.7 Update 2a идет с версией VMware Tools 10.3.5. Надо отметить, что гостевые ОС Linux не подвержены уязвимости, поэтому не пугайтесь, что open-vm-tools имеют только версию 10.3.5.

Последнюю же версию пакета тулзов можно скачать по этой ссылке: https://www.vmware.com/go/tools.

Если вы хотите обновить VMware Tools через офлайн-бандл, то скачайте "VMware Tools Offline VIB Bundle", после чего можно использовать vSphere Update Manager (VUM) для развертывания установщиков пакета на хостах ESXi без простоя. После этого машины должны в течение 5 минут схватить новую версию тулзов (таков период обновления информации об актуальной версии пакета). Установленная версия VMware Tools также проверяется и при vMotion, а, кроме того, и при операциях с питанием ВМ (включение/выключение).

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

Обновление VMware Tools можно инициировать через PowerCLI с помощью следующего командлета:

Get-VM | Where-Object {$_.ExtensionData.Guest.ToolsVersionStatus -eq "guestToolsNeedUpgrade" -and $_.PowerState -eq "PoweredOn"} | Get-VMGuest | Where-Object {$_.GuestFamily -eq "windowsGuest" } | Update-Tools -NoReboot -RunAsync

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

Get-VM “TEST-VM-02” | Where-Object…
Get-Folder “Test VMs - Snapshotted" | Get-VM | Where-Object…

Через vSphere Client тулзы также прекрасно обновляются:

Если вы используете опцию "Automatic Upgrade", то машина будет обновлена автоматически (без взаимодействия с гостевой ОС) и, при необходимости, перезагрузится. Также вы можете использовать обновление тулзов без немедленной перезагрузки, применив инструкции, описанные в KB1018377. Надо помнить, что в этом случае до перезагрузки будет работать старая версия VMware Tools, а значит, что до перезагрузки машины уязвимость будет актуальна.

Еще одна опция - настроить обновления тулзов в настройках виртуальной машины:

 

 

Иногда администраторы гостевой системы имеют эксклюзивный доступ к ней (например, админы бизнес-критичных баз данных) и контролируют все происходящие в ней события. Для этого надо настроить их взаимодействие с машиной как указано в KB 2007298.

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

  • VMwareToolboxCmd.exe –v - проверка установленной версии.
  • VMwareToolboxCmd.exe upgrade status - возможность обновления для доступных апгрейдов.
  • VMwareToolboxCmd.exe upgrade start - запуск процедуры апгрейда.

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


Таги: VMware, Tools, Update, vSphere, ESXi, VMachines

Как предоставить доступ виртуальной машине в облаке VMware vCloud on AWS из сети Compute Network в сеть SDDC Management Network?


Для многих пользователей публичного облака VMware vCloud on AWS одним из первых возникает вопрос - как предоставить доступ из виртуальной машины в сети Compute Network в сеть SDDC Management Network, например, для целей управления сервисами vCenter или другими службами виртуального датацентра?

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

Естественно, что для целей обеспечения безопасности в облаке, эти две сети по умолчанию разделены. Первое, что вам нужно сделать - это понять, с каким типом решения NSX для управления сетью вы работаете (NSX-T или NSX-V). Сделать это можно с помощью вот этой статьи.

Процедура для NSX-V

В среде NSX-V вам нужно настроить IPsec VPN между компонентами Management Gateway (MGW) и Compute Gateway (CGW) перед тем, как заработает коммуникация между сетями.

Для настройки VPN для компонента Management Gateway нажимаем Add VPN в консоли VMC и вводим требующуюся информацию сетевой идентификации (публичный IP удаленного шлюза, параметры удаленной сети и ключи), что должно отражать конфигурацию Compute Gateway (остальные настройки можно оставить по умолчанию).

Далее надо настроить VPN для Compute Gateway путем выполнения тех же шагов, что и в предыдущем абзаце, только указав конфигурацию шлюза Management Gateway. После того, как настройки обеих VPN будут сохранены, начнет отображаться статус "Partially Connected". Потом нажимаем ссылку Actions в правом верхнем углу, выбираем Edit и сохраняем настройки еще раз, чтобы на обоих шлюзах показался статус "Connected":

Теперь надо настроить сетевой экран Compute Gateway Firewall, чтобы разрешить исходящие соединения в SDDC Management Network по порту 443 для требуемых ВМ (этот порт используется для vSphere Client, а также для доступа через средства OVFTool и PowerCLI).

В приведенном ниже примере машина имеет адрес 192.168.1.4, и мы хотим позволить ей общаться с сетью 10.2.0.0/16 через порт 443:

Теперь нужно добавить в фаервол Management Gateway Firewall правила для разрешения входящих соединений для vCenter Server и хостов ESXi по порту 443 от наших определенных ВМ. Здесь все точно так же - указываем IP машины 192.168.1.4, и нам нужно добавить 2 правила для входящего трафика для разрешения коммуникации со средствами управления виртуальной инфраструктурой:

После этого вы можете залогиниться в виртуальную машину и использовать средства управления платформой vSphere, например, применять утилиту импорта виртуальных модулей OVFTool, как рассказано тут.

Процедура для NSX-T

В среде NSX-T вам не нужно создавать VPN для получения функциональности маршрутизации, которая изначально заложена в маршрутизаторе T0, ведь обе сети Management и Compute Network присоединены к T0. Между тем, правила сетевого экрана добавлять, конечно же, нужно.

В решении NSX-T используются сущности Inventory Groups, чтобы сгруппировать набор виртуальных машин и/или IP-адреса/сети, которые можно использовать при создании правил сетевого экрана.

Создаем две Inventory Groups для нашей Compute Group - одну для нашей виртуальной машины и одну для того, чтобы представлять сеть Management Network. Идем в Groups и в левой части выбираем пункт "Workload Groups", где создаем 2 группы:

  • Windows10 с Member Type вида Virtual Machine и указываем ВМ из инвентаря.
  • VMC Management Network с Member Type вида IP Address и указываем сетевой диапазон 10.2.0.0/16.

Теперь нужно создать еще одну Inventory Group для нашей Management Group, которая будет отражать ВМ, для которой мы хотим сделать доступ. Чтобы это сделать, идем в Groups, выбираем "Management Groups" и создаем следующую группу:

  • Windows10 Private IP с Member Type вида IP Address и указываем частный IP-адрес ВМ (в данном случае это 192.168.1.2).

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

Теперь нужно создать правило сетевого экрана, чтобы разрешить Compute Gateway исходящие соединения к SDDC Management Network по порту 443 для нужных ВМ. Идем в Gateway Firewall и выбираем "Compute Gateway", где создаем новое правило, которое отражает группу Windows 10 как источник и группу VMC Management Network как назначение, а в качестве сервиса выбираем HTTPS (помним также про кнопку Publish).

Теперь надо создать правила на уровне Management Gateway, чтобы разрешить входящие соединения к хостам vCenter Server и ESXi по порту 443 из нужных нам ВМ. Идем в Gateway Firewall, слева выбираем "Management Gateway", затем создаем правило, которое отражает группу Windows 10 как источник, а в качестве группы назначения указываем vCenter и ESXi (сервис ставим также HTTPS):

После выполнения этой процедуры вы сможете залогиниться в ВМ Windows и использовать утилиту OVFTool для импорта/экспорта ВМ в ваш виртуальный датацентр (см. также данную процедуру здесь).

Если все было сделано правильно, вы должны иметь возможность доступа к интерфейсу vSphere Client из нужной вам ВМ, а также возможность выполнять сценарии PowerCLI и использовать утилиту OVFTool, как показано на скриншоте ниже:


Таги: VMware, vCloud, VMConAWS, Cloud, Amazon, vNetwork, Networking, vSphere, ESXi, VMachines, Blogs

Ошибка в консоли клиента vSphere Client "The ramdisk 'tmp' is full" на серверах HPE ProLiant с кастомным образом ESXi и пакетом HPE Agentless Management (AMS).


Те, кто используют серверы HPE ProLiant с гипервизором VMware ESXi и пакетом управления HPE Agentless Management (AMS) для кастомизированных образов ESXi от HP, могут столкнуться со следующим сообщением об ошибке в клиенте vSphere Client:

The ramdisk 'tmp' is full

Выглядит это чаще всего вот так:

Проблема актуальна для всех версий VMware ESXi 6.0, VMware ESXi 6.5 и VMware ESXi 6.7 с пакетом Agentless Management Service (AMS) версии 11.4.0.

Если зайти в консоль ESXi и выполнить там команду vdf, то можно увидеть, что раздел /tmp заполнен на 99%:

В самом же разделе tmp есть файлик ams-bbUsg.txt, который и является источником проблем:

Для временного решения этой проблемы нужно просто удалить этот файлик, и сообщения об ошибке прекратятся. Но чтобы этого не происходило, надо обновить ваш пакет HPE Agentless Management (AMS) версии 11.4.0, где проявляется данная проблема, на версию 11.4.2. О том, как это сделать написано в статье базы знаний HP:

Advisory: VMware - VMware AMS Data File Filling Up Tmp May Cause VUM Updates to Fail On HPE Servers Running VMware ESXi 6.0/6.5/6.7 with AMS Version 11.4.0.

Сам репозиторий с обновленным AMS находится по следующей ссылке:

http://vibsdepot.hpe.com/hpe/may2019


Таги: VMware, HP, ESXi, Bug, Bugs, Storage, vSphere, Client

Ограничения Persistent Memory для виртуальных машин на платформе VMware vSphere.


В августе прошлого года мы сделали статью о новом виде памяти Persistent memory (PMEM) в VMware vSphere, которая находится на уровне между DRAM и Flash SSD с точки зрения производительности:

Надо сказать, что устройства с Persistent Memory (они же, например, девайсы с Intel Optane Memory) уже начинают рассматривать некоторые пользователи для внедрения в своей виртуальной инфраструктуре, поэтому надо помнить об их ограничениях, которые раскрыл Дункан Эппинг.

С точки зрения предоставления памяти PMEM виртуальной машине, на платформе vSphere есть 3 способа:

  • vPMEMDisk - vSphere представляет PMEM как обычный диск, подключенный к виртуальной машине через контроллер SCSI. В этом случае ничего не нужно менять для гостевой ОС или приложений. В таком режиме работают любые системы, включая старые ОС и приложения.
  • vPMEM - vSphere представляет PMEM как устройство NVDIMM для виртуальной машины. Большинство последних версий операционных систем (например, Windows Server 2016 и CentOS 7.4) поддерживают устройства NVDIMM и могут предоставлять их приложениям как блочные или байт-адресуемые устройства. Приложения могут использовать vPMEM как устройство хранения через тонкий слой файловой системы direct-access (DAX), либо замапить регион с устройства и получать к нему прямой доступ через байтовую адресацию. Такой режим может быть использован старыми или новыми приложениями, но работающими в новых версиях ОС, при этом версия Virtual Hardware должна быть не ниже 14.
  • vPMEM-aware - это то же самое, что и vPMEM, но только с дополнительными возможностями приложения понимать, что машина использует такое устройство, и пользоваться его преимуществами.

Если виртуальная машина использует такие устройства, то она имеет очень существенные ограничения, которые на данный момент препятствуют их использованию в производственной среде. Они приведены в документе "vSphere Resource Management Guide" на странице 47 внизу. А именно:

  • vSphere HA - полностью не поддерживается для машин с включенными vPMEM устройствами, вне зависимости от режима использования.
  • vSphere DRS - полностью не поддерживается для машин с включенными vPMEM устройствами (машины не включаются в рекомендации и не мигрируют через vMotion), вне зависимости от режима использования.
  • Миграция vMotion для машин с устройствами vPMEM / vPMEM-aware доступна только на хосты с устройствами PMEM.
  • Миграция vMotion машин с устройством vPMEMDISK возможна на хост без устройства PMEM.

Будем надеяться, что эта ситуация в будущем изменится.


Таги: VMware, vSphere, Memory, PMEM, Intel, VMachines, HA, DRS

Серьезная проблема с виртуальными машинами с включенной Virtualization-Based Security (VBS) на платформе VMware vSphere.


Начиная с VMware vSphere 6.7, компания VMware поддерживает технологию защищенной виртуализации Virtualization-Based Security (VBS). Это один из механизмов, который позволяет предоставлять пользователям более защищенные рабочие Windows-среды средствами технологий Device Guard и Credential Guard (последняя предназначена для изоляции пространства хранения учетных записей от потенциальной кражи вредоносным ПО). Эти функции очень важны для защиты, например, таких компонентов инфраструктуры, как серверы Active Directory.

Между тем, с виртуальными машинами, работающими с поддержкой данной технологии, была найдена серьезная проблема - они зависают или выпадают в синий экран смерти (BSOD) при загрузке. Баг проявляется при включенной технологии VBS (на скриншоте vSphere Client на базе HTML5 с Hardware Version 14):

Также этот баг актуален и для включенной поддержки технологии I/O MMU:

Возможность VBS доступна в Microsoft Windows 10/2016/2019, сам же баг стал проявляться, начиная с версии Windows Insider Build 18362. VMware говорит, что проблема находится на стороне Microsoft, но оба вендора совместно работают над выпуском патча для ОС.

Статья базы знаний VMware KB 68043 содержит вопросы, которые позволят вам определить, затрагивает ли вас проблема.

Помимо проверки настроек в интерфейсе vSphere Client, которые вы видите на скриншотах выше, можно использовать вот такой PowerCLI-скрипт для определения машин, которые затрагивает проблема:

Get-View -ViewType VirtualMachine | Where {(($_.Config.Flags.VbsEnabled -eq "True") -or ($_.Config.Flags.VvtdEnabled -eq "True")) -and ($_.Summary.Config.GuestID -like "windows9*")} | Select Name,@{Name=”VBS”; Expression={$_.Config.Flags.VbsEnabled}},@{Name=”IOMMU”; Expression={$_.Config.Flags.VvtdEnabled}}

После того, как вы найдете у себя такие ВМ, то выхода у вас два:

  • Не использовать VBS и I/O MMU для виртуальных машин.
  • Использовать workaround, который приведен в статье KB 68043.

Workaround заключается в следующем:

  • Выключаем машину и отключаем VBS и I/O MMU для нее.
  • Устанавливаем ОС на ВМ или обновляем ее до самых последних апдейтов.
  • Выключаем ВМ, выбираем в настройках "Expose hardware assisted virtualization to guest".
  • Включаем ВМ, в настройках включаем функцию (feature) "Hyper-V" в гостевой ОС, после чего перезагружаем машину.
  • Опять выключаем ВМ и включаем VBS и/или I/O MMU, после чего она уже будет нормально работать.

Помните, что такой Workaround не вечен для свежих установок, например, из образов 1903 & 19H1 DVD/ISO, так как следующее обновление потенциально может вернуть баг, который еще не пофикшен со стороны Microsoft. Имейте это в виду, когда создаете шаблоны виртуальных машин для массового развертывания. Поэтому сначала все обновляем до самой последней версии, потом уже используем Workaround выше.

Кстати, все могло бы быть и хуже) Например, уязвимость Remote Desktop Services vulnerability (CVE-2019-0708), требующая немедленного обновления не затрагивает системы с описанной проблемой выпадения в BSOD. Уязвимость с удаленным рабочим столом актуальна только для систем Windows XP, 7, Windows Server 2003, 2008 (+ R2), а баг с зависанием актуален только для более поздних Windows.

Ждем пока сделают нормальный фикс, и не надо будет плясать с Workaround'ом. А пока можете на всякий случай отключить VBS, если позволяют корпоративные политики.


Таги: VMware, vSphere, Security, VBS, Microsoft, Windows, Bug, Bugs

Новое на VMware Labs - Distributed Trust Incident Reporting.


На сайте проекта VMware Labs появилась новая интересная Open Source утилита - Distributed Trust Incident Reporting. Она предназначена для документирования инцидентов в сфере информационной безопасности, которое часто осуществляется на бумаге или в Excel даже в крупных компаниях. Некоторые системы имеют централизованную базу данных инцидентов с возможностью отслеживания ответных мер, принятых в качестве реакции на инцидент, но только на уровне собственного предприятия.

Текущие подходы по мнению VMware обладают рядом недостатков:

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

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

Утилита Distributed Trust Incident Reporting позволяет:

  • Увидеть всем сторонам процесса зафиксированный инцидент.
  • Позволяет всем сторонам отреагировать, как того требует ситуация и зафиксировать это.
  • Принимает на вход отчеты информационных систем об инцидентах.
  • Добавляет прозрачности между разными сущностями/организациями.

Работает это все на базе контейнеров Docker, а технологическую платформу фиксирования инцидентов предоставляют решения VMware blockchain или Ethereum blockchain.

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

Проект Distributed Trust Incident Reporting доступен для скачивания из репозитория GitHub.


Таги: VMware, Labs, Security, vSphere, Blockchain

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48    >   >>
Реклама





Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

Быстрый переход:
IT-Grad VMware StarWind Veeam PowerCLI Offtopic Gartner Citrix VSAN GDPR 5nine Hardware VeeamON Nutanix vSphere RVTools Enterprise Security Code Cisco vGate Microsoft Cloud SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Teradici Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter VMachines Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V vSAN vROPs Stencils Labs Bug UEM vRNI VTL Networking Horizon vCSA Tools vCloud Forum iSCSI SRM HCI App Volumes Video Workspace ONE Backup VMUG NSX HA Update Manager VCP VVols Workstation Update DR Cache Storage DRS VMworld Workspace DRS Fusion Lifecycle Visio Log Insight Operations Manager SDDC Virtual Appliance OpenStack PowerShell LSFS Client Datacenter Intel Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Performance Nested AWS XenDesktop VSA vNetwork SSO Host Client VMDK Whitepaper Appliance VUM V2V Support Обучение Web Client Mobile Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers Converter XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP SC VMM Certification VDP Partners PCoIP RHEV vMA Award Network USB Licensing Logs Server Demo vCHS Calculator Бесплатно vExpert Beta SAN Exchange MAP ONE DaaS Monitoring VPLEX UCS SDK Poster VSPP Receiver vMotion VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V VirtualCenter NFS ThinPrint SIOC Plugin Memory CLI Helpdesk Troubleshooting VIC Upgrade VDS Migration Director API Android Graphics Diagram Air DPM Flex Mac Open Source SSH VAAI Chargeback Heartbeat MSCS Ports SVMotion Bugs Composer
Интересные плакаты:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Сравнение Oracle VirtualBox и VMware Workstation.

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Как использовать возможности VMware vSphere Management Assistant (vMA).

Проектирование инфраструктуры виртуализации VMware vSphere 4.

Как поднять программный iSCSI Target на Windows 2003 Server для ESX

Работа с дисками виртуальных машин VMware.

Бесплатные программы для VMware ESX / ESXi в среде Virtual Infrastructure / vSphere (часть 2).

Новые возможности VMware vSphere 5.0 - официально.

Все ресурсы о виртуализации:
Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Купить:

VMware vSphere 6.5


Veeam Backup 9.5


Полезные ресурсы:


Видео компании VMware

Видео про Citrix Xen

Видео о виртуализации Microsoft

Утилиты для виртуальных машин Microsoft.

Книги на английском языке

Блоги на английском языке

Блоги на русском языке

Агрегация статей в твиттере VMC:


Copyright VM Guru 2006 - 2019, Александр Самойленко. Правила перепечатки материалов.