На днях компания VMware обновила свой HTML5-клиент для управления виртуальной инфраструктурой, выпустив vSphere Client 3.41 накануне предстоящего VMworld 2018. Кстати, многие надеются, что на VMworld будет анонсирована финальная версия vSphere Client с полным списком возможностей, которые сейчас предоставляет только Web Client.

Давайте пока посмотрим на улучшения новой версии vSphere Client 3.41 (напомним, что о версии клиента 3.40 мы писали в начале августа):

• Появилась функция Code capture - запись пользовательских действий, которые были сделаны в рамках текущей сессии через vCenter API, и генерация соответствующего скрипта.
• Для начала записи нужно нажать "Start recording" на странице "Code Capture" или кнопку записи в заголовке окна.
• Для остановки записи сценария надо нажать кнопку Stop, после чего будет сгенерирован скрипт PowerCLI.
• Чтобы отключить функцию code capture для всех пользователей, нужно добавить строчку "codecapture.disabled=true" в файл конфигурации клиента (надо будет его перезапустить):
  /etc/vmware/vsphere-client/vsphere-client/webclient.properties
• Несколько исправлений ошибок.

Напомним, что о функции Code capture мы уже писали. Она стала доступной как Project Onyx для vSphere Web Client 6.0 Update 1 (в комментариях также пишут, что Onyx работает, по крайней мере, в версии 6.5). А сам Onyx как макрорекордер появился еще в далеком 2009 году.

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

Недавно мы писали о том, что нет нормального решения проблемы по отключению пользователей от десктопа VMware Horizon View по времени неактивности. Наш читатель Андрей прислал нам инструкцию для тонких клиентов Wyse:

1. В конфигурацию клиента добавляется параметр:

Inactive=<время в минутах>

чтобы клиент самостоятельно отключался по бездействию (со стороны Horizon происходит Disconnect).

Также хорошо бы добавить параметр:

ShutdownCounter=<время в секундах>

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

2. В настройках пула виртуальных десктопов задается время для завершения работы пользователя после отсоединения сессии (Automatically logoff after disconnect):

3. Если вы используете одноразовые десктопы для пользователей, которые выполняют только свою задачу в имеющихся приложениях и не сохраняют данные, их можно уничтожить после процедуры logoff. Для этого нужно выставить параметр Delete Immediately для настройки Delete or refresh machine on logoff:

На днях компания VMware обновила свой PowerShell-фреймворк для управления виртуальной инфраструктурой, выпустив PowerCLI 10.2.0. Напомним, что о версии VMware PowerCLI 10.1.1 мы писали вот тут. Это уже четвертый релиз в этом году, самое значимое обновление - PowerCLI 10 - вышло в марте.

На самом деле, нового в PowerCLI 10.2 появилось не так уж и много:

• Поддержка обновленной версии решения NSX-T 2.2 в модуле VMware.VimAutomation.Nsxt.
• Вывод из эксплуатации модуля VMware.VimAutomation.PCloud (он еще доступен, но будет убран в будущем), ранее он управлял функциями vCloud Air.
• Обновление функции Get-VIEvent, которое решает проблему с неожиданной ошибкой "Error in deserializing body of reply message for operation ‘RetrieveProperties’".

Также была обновлена и документация:

• VMware PowerCLI 10.2.0 User’s Guide
• VMware PowerCLI 10.2.0 Cmdlet Reference

Напомним, что обновить PowerCLI теперь очень просто - надо выполнить команду:

Update-Module -Name VMware.PowerCLI

Кстати, если будете на VMworld 2018, посмотрите интересную техническую сессию DEV3504BU про PowerCLI.

Если вам нечем заняться, и нужно как-то разнообразить вялые админские будни, то можно, например, кастомизировать страницу логина в VMware vSphere Client, поставив вместо нее страничку vYetti:

Работает эта штука как в VMware vSphere 6.5, так и в vSphere 6.7. Инструкции по установке здесь.

Как многие уже знают, не так давно VMware выпустила обновленную версию решения для виртуализации и доставки рабочих окружений пользователей VMware Horizon 7.5. Среди новых возможностей клиентов Horizon View была такая фича: "VMware Blast выбирает оптимальный транспорт автоматически (UDP или TCP) для предоставления лучшего качества обслуживания пользователю (ранее нужно было делать это вручную)".

Оказывается, это очень важная штука, и называется она Blast Extreme Network Intelligent Transport (BENIT). Ранее компания VMware анонсировала механизм Blast Extreme Adaptive Transport (BEAT), который позволял переходить на UDP-протокол в сетях с плохим качеством связи, предоставляя пользователю выбор типа соединения:

Blast Extreme автоматически подстраивается под параметры Bandwidth, Latency и Packet Loss в различных сетях и выбирает наиболее эффективный транспорт: TCP или UDP. Работало это так:

• Excellent - предназначен для LAN-сетей с хорошим качеством (высокая скорость и низкие потери пакетов). В этом случае используется только TCP протокол - и для управления передачей, и для отправки самих данных.
• В случае выбора Poor протокол Blast Extreme использует только UDP для управления передачей и отсылки данных. Это оптимально для WAN-сетей с большими задержками и коэффициентом потерь пакетов 20% и более.
• Дефолтный пункт - Typical - это оптимальный выбор для 99% пользователей. В этом случае будет использоваться TCP для управления передачей, а UDP для основной отправки данных, с учетом адаптивного алгоритма. Если по каким-то причинам UDP будет недоступен (например, заблокирован политикой на сетевом экране), то произойдет незаметное для пользователя переключение на TCP.

Далее в версии VMware Horizon 7.3.1 появились отдельные каналы для для USB и CDR внутри протокола Blast. Это позволило инкапсулировать весь трафик в рамках одного протокола, что удобно с точки зрения управления каналом.

Между тем, некоторые недостатки такого механизма еще оставались, особенно при использовании UDP:

• UDP часто заблокирован в корпоративной инфраструктуре или сильно зажат по ширине канала.
• Маршрутизация на основе политик может вести TCP и UDP трафик через совершенно разные пути.
• Некоторым приложениям (например, копированию файлов) гораздо важнее сырая пропускная способность, чем уровень отклика для пользователя, с чем отлично справляется TCP.
• При использовании TCP в протоколе Blast нагрузка на CPU является несколько повышенной, если сравнивать с собственными механизмами оптимизации TCP в операционных системах.

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

Еще одной проблемой является использование мобильных клиентов - протоколы TCP или Adaptive Transport предоставляют надежное соединение только когда постоянно доступно. Но мобильное устройство может переключиться с Wi-Fi на 3G/LTE, при этом, например, копирование файлов в гостевой ОС не должно прерываться.

Как следствие, VMware разработала протокол сеансового уровня для Blast, который появился в VMware Horizon View 7.5.0 и Horizon Clients 4.8.0 - Blast Extreme Network Intelligent Transport (BENIT).

Этот протокол предоставляет следующие характеристики:

• Надежность - гарантия последовательной доставки данных в условиях прерывания сетевого соединения / переключения сетевых адаптеров.
• Переключение транспорта для отдельного приложения на основе отклика приложения в сети.
• Балансировка нагрузки за счет одновременного использования обоих транспортов для различных приложений, а также за счет выбора конкретного транспорта для определенного класса трафика (например, File Copy).

Так это выглядит наглядно:

Привязка нужного типа протокола происходит динамически на уровне сессии для каждого приложения или типа трафика через компонент мультиплексор.

Давайте посмотрим на некоторые аспекты такого решения:

Надежность

Тут возникает 2 основных проблемы:

• Потеря соединения для транспортного протокола, когда данные были отосланы и, возможно, получены получателем, но источник не получил подтверждение этого. Для протокола BENIT это решается повторной отправкой данных только в случае переключения транспорта для приложения.
• Эффект Race condition - когда приложение отправило пакет под одному каналу, а потом произошло переключение транспорта, и оно отправило другой пакет по другому каналу, а ответ для них может прийти в обратном порядке. Эта проблема решается механизмом обнаружения и коррекции ошибок.

Переключение транспорта

Для того, чтобы механизм BENIT работал эффективно, нужна возможность смотреть на производительность транспорта для определенных приложений, которая и реализована в протоколе. Решение по переключению может приниматься на основе заранее заданной политики (дефолтно это потери пакетов > 1%, задержка > 50 мс и пропускная способность < 200 Мб/с), либо с помощью интеллектуального алгоритма, который сам понимает необходимость переключения. Статические политики вы можете задать самостоятельно, на основе эмпирических результатов производительности для отдельных приложений или инфраструктуры в целом.

При работе с соединениями BENIT будет периодически тестировать их характеристики и производить необходимые переключения транспорта для приложений. Это снимает с администраторов и пользователей обязанность самостоятельно производить выбор типа соединения.

Кстати, надо понимать, что переключение транспорта происходит независимо на клиенте и на удаленном десктопе, то есть если на клиенте что-то меняется (например, параметры адаптера), то именно там происходит переключение транспорта, а на десктопе все остается как и было.

Аналитика при переключении транспорта

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

Поэтому здесь есть механизм обучения - если, например, произошла серия "плохих" переключений с BEAT на TCP и обратно, то BENIT запомнит эту связь и будет поддерживать TCP-соединение, даже если все требования по переключению будут выполнены.

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

• Lazy switching - если одна порция трафика пока еще целиком не послалась через транспорт, то следующая посылается уже через новый канал, при этом на старом еще некоторое время ожидается квитанция о приеме, и если ее не приходит - то сообщение перепосылается уже через новый канал. Это вызывает некоторую задержку времени переключения, но зато эффективно с точки зрения использования канала.
• Rollback and switch - в этом случае недопосланное сообщение аннулируется, происходит мгновенное переключение и перепосылка этого сообщения по новому каналу. Это приводит к максимально быстрому переключению, но часть трафика в канале дублируется.

Некоторые результаты тестирования

Вот так выглядят результаты по FPS при просмотре видео на виртуальном десктопе при использовании протоколов TCP и BENIT в условиях различных сетевых соединений:

А вот результаты по копированию файлов через механизм Drive Redirection:

Ну и главное - BENIT позволяет сохранить поток копирования файлов при переключении между соединениями Wi-Fi и 3G/LTE на мобильном интернете или при потере сетевого соединения (по умолчанию настроено время ожидания 120 секунд, его можно изменять):

Cormac Hogan, специалист по отказоустойчивым серверным хранилищам на базе хостов VMware vSAN, написал интересный пост о "растянутых кластерах" (vSAN Stretched Clusters). Это кластеры, которые образуют единое пространство хранения между двумя географически разделенными площадками, в котором продолжают работать различные механизмы обеспечения доступности виртуальной инфраструктуры, например, VMware HA (он восстанавливает отдельные ВМ в рамках площадок, а также всю площадку целиком в случае ее сбоя).

Если вы используете виртуальные ПК на базе полных клонов с инфраструктуре VMware Horizon View, то вы можете исполнять их на растянутом кластере в конфигурации Active/Passive в рамках одного View Pod (набора серверов Connection Server):

Это именно Active/Passive конфигурация, которая поддерживает пользовательские соединения только на одной площадке, вторая находится в резерве, а вся инфраструктура десктопов управляется одним набором серверов View Pod, размещенном на основном сайте:

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

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

Надо отметить, что архитектура Active/Active (когда десктопы активно работают на обеих площадках) в решении Horizon View не поддерживается для растянутых кластеров. Причина в том, что группа серверов Connection Servers в рамках одного сайта (Pod) должна иметь отличное соединение по сети LAN, чему нет гарантий в среде растянутого кластера, когда они разместятся на обеих площадках.

При этом ничего не мешает вам использовать Active/Active-конфигурацию не для растянутого кластера, а для двух Pods с разными кластерами vSAN на каждой из площадок в рамках архитектуры Cloud Pod Architecture (CPA).

Ну а если вы используете non-persistent виртуальные десктопы и связанные клоны (Linked Clones) или мгновенные клоны (Instant Clones), то рекомендация VMware тут та же самая - не использовать растянутый кластер vSAN. Потому что, в отличие от полных клонов, данные дисковых объектов могут создаваться и уничтожаться на лету в больших объемах, что пока еще не поддерживается для единого пространства хранения vSAN.

Вместо этого нужно создавать View Pod на каждой из площадок и поддерживать свой кластер vSAN на уровне каждого сайта, как показано на картинке выше.

Ну и еще момент - решение VMware AppVolumes также не поддерживается в растянутых кластерах VMware vSAN.

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

Помимо самого обновления на YouTube появилось обзорное видео этого продукта:

Так как утилиту перезалили на VMware Labs, у нее отсутствует секция Changelog, поэтому нам не получится узнать, что же там появилось нового:) Доверимся авторам. Кстати, надо отметить, что для работы с этим средством вам понадобится версия VMware Horizon не ниже 7.2 и Enterprise-лицензия.

Если вам не нравятся пороговые значения, на которые ориентируется Horizon Helpdesk Utility при отслеживании метрик, вы всегда можете поправить их в файле:

AppData\Roaming\HorizonHelpDeskAgent\threshold.json

Начать работать с утилитой очень просто:

• Скачиваете и устанавливаете setup.exe
• Запускаете Horizon HelpDesk Logon
• Вводите полный адрес своего VMware Horizon Connection Server (например, https://connectionserver.dom.local) и учетные данные и жмете "logon".

Скачать Horizon Helpdesk Utility 1.21 можно по этой ссылке.

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

Оказывается это обычный баг, описанный в KB 57245. Просто-напросто SNMP в VMware vSphere 6.7 не работает (причина в механизме реализации потоков - основной thread не завершается, в то время, как дочерний уже вызывается). На данный момент нет способа обхода проблемы.

Инженеры VMware обещают, что эта ошибка будет исправлена до конца года (we are currently investigating what is causing this issue and hope to have a solution out for this issue later this year), но пока пользоваться SNMP невозможно.

Компания SL Tech, основанная в 2006 году, специализируется на создании современных IT-решений для бизнеса и жизни. Являясь частью группы SEALINE, в которую также входит страховой и перестраховочный брокер с одноименным названием, компания занимает лидирующие позиции среди страховых брокеров России. Ставя в приоритет задачи по разработке и управлению портфелем проектов, предназначенных как для потребителей, так и для поставщиков услуг в высокотехнологичных областях, SL Tech уделяет особое внимание современным технологиям. Вот почему сегодня вся инфраструктура компании вынесена в облако надежного провайдера. Как не допустить ошибок при выборе поставщика услуг, на что обратить внимание при тестировании облачной площадки, какие в целом задачи решает облако – ответами на эти и другие вопросы поделились сотрудники SL Tech.

Специфика бизнеса и особенности деятельности компании

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

Команда SL Tech состоит из амбициозных людей, профессионалов в своем деле, увлеченных масштабными и неординарными задачами. Одним из ключевых направлений деятельности компании является создание маркетплейсов. Первые проекты были запущены в сфере финтех- и тревел-индустрии, семейства INSTORE. И это не просто разработка очередного онлайн-сервиса, SL Tech строит высокотехнологичный мост – коммуникацию между клиентами и поставщиками. Благодаря верной стратегии управления и четко заданным векторам развития компания осваивает неохваченные сферы и открывает для себя новые горизонты.

Зачем потребовалось облако?..Читать статью далее->>

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

В качестве исходной информации Workspace ONE Intelligence использует данные из Workspace ONE UEM и продукта Apteligent (технология отслеживания производительности приложений). Специальный компонент Workspace ONE Intelligence Connector позволяет собрать данные из UEM и отправить их в движок отчетности Intelligence (пользователи SaaS-решения Workspace получают функциональность отчетов сразу из облака). С помощью интегрированных дэшбордов и отчетов администратор может принимать важные решения по конфигурации большой инфраструктуры Workspace ONE.

Давайте посмотрим, что интересного есть в отчетах Workspace ONE Intelligence. Каждый пользователь Workspace ONE может получить Intelligence Reports бесплатно на 30 дней и попробовать полную функциональность решения. Для этого нажать кнопку Get started в разделе Intelligence и пройти по шагам мастера:

После того, как вы заполните все необходимые поля для старта нового триала Intelligence, вам станет доступна функциональность отчетов.

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

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

А вот так выглядит результат отчета по устройствам:

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

• My Dashboard
• Security Risk
• Apps Dashboard
• OS Updates
• Patches
• Automation
• Apteligent

В общем, тем, кто использует решение Workspace ONE, однозначно имеет смысл попробовать возможности Intelligence (особенно в большой инфраструктуре), тем более, что это средство развивается весьма динамично, и практически ежемесячно появляются все новые отчеты и дэшборды.

Не случайно заголовок поста со знаком вопроса. Пользователи инфраструктуры виртуальных ПК VMware Horizon View не раз задумывались о том, как можно отключить сессию пользователя в случае его неактивности на десктопе и затем потушить гостевую ОС и виртуальную машину (или сделать log off). Это нужно делать, прежде всего, в целях безопасности, чтобы брошенные и неактивные виртуальные ПК не висели доступными для взлома, а, во-вторых, по соображениям экономии аппаратных ресурсов, которые обслуживают неактивные сессии.

Как ни странно, у VMware (в отличие от Citrix) такой настройки из коробки нет (по крайней мере, об этом пишут тут). Если обратиться к статье официальной документации "Configuring Settings for Client Sessions", то мы увидим, что из похожего есть только настройка "Forcibly disconnect users". Она определяет время, через которое происходит отключение сессии пользователя после его логина в систему, но нам хотелось бы задать таймаут неактивности, после которого бы происходило отключение.

Похожей настройки нет и в User Environment Manager. Поэтому пользователи самостоятельно ищут выход из положения. Например, вот тут коллега использует встроенную в Windows утилиту для отключения сейссий tsdiscon.exe. Он пытался найти триггер в UEM, который бы запустил tsdiscon.exe и прервал сессию.

Триггеры в UEM можно добавлять в разделе Conditions:

Он попытался использовать триггер Workstation Locked и выполнить команду tsdiscon:

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

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

Эту утилиту можно прошить в золотой образ VMware View и запускать с флагом -h (hidden mode).

Но может есть какой-нибудь способ попроще? Никто не в курсе?

Как некоторые из вас знают, компания VMware еще в 2013 году сделала возможным обновление пакета VMware Tools без перезагрузки. Доступной эта функция стала в vSphere 5.1 и с тех пор постоянно дорабатывалась.

Например, если говорить о Windows Server 2016, то здесь было сделано вот какое улучшение. Теперь паравиртуализованный драйвер хранилищ Paravirtual SCSI (pvscsi) можно официально обновлять через службу Windows Update от Microsoft. Это значит, что если у гостевой ОС есть доступ в интернет, он будет автоматически обновляться.

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

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

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

В демо ниже можно увидеть, как VMware Tools версии 10.2.0 обновляются на 10.3.0 без перезагрузки (пинг к системе не пропадает), при этом в виртуальной машине используются драйверы pvscsi и vmxnet3 (сетевой адаптер). Их обновления будут применены после следующего обновления Windows, требующего перезагрузки:

В заключение рекомендуем сессию предстоящего VMworld о жизненном цикле VMware Tools в виртуальном датацентре: VIN1972BU – Mastering the VMware Tools Lifecycle in Your VMware vSphere Data Center.

В конце мая этого года компания VMware выпустила обновленную линейку решений своих продуктов для виртуализации настольных ПК предприятия VMware Horizon 7.5. Одной из составляющих данной линейки был продукт User Environment Manager версии 9.4, о новых возможностях которого мы писали вот тут. Напомним, что этот продукт предназначен для управления пользовательскими окружениями и настройками в рамках инфраструктуры виртуальных ПК.

На днях VMware выпустила финальную версию VMware Workspace ONE User Environment Manager 9.6 для конфигурации мобильных устройств, давайте посмотрим, что в этом продукте появилось нового (а нового немало!):

А именно:

1. Возможность регистрации устройств по QR-кодам.

Теперь пользователь может зарегистрировать устройство как рабочее с помощью сканирования QR-кода. Пока это работает только для Android-устройств.

Чтобы настроить этот механизм, нужно пойти в Devices > Staging & Provisioning > Staging и выбрать Configure Enrollment.

2. Поддержка Biometeric Passcode для Android-устройств.

Теперь в качестве аутентификации можно использовать механизмы распознавания лица или отпечатка пальца. Настроить это можно в разделе Devices > Profiles & Resources > Profiles > Add > Add Profile > Android > Passocde.

3. Упрощенная конфигурация профилей для устройств Samsung.

Теперь стандартные политики Samsung Knox интегрированы в профиль Android Work Managed profile. А именно:

• Passcode
• Restrictions
• Date/Time
• APN

Чтобы настроить это, надо пойти в Devices > Profiles & Resources > Profiles > Add > Add Profile > Android и включить настройки OEM.

4. Функция Factory Reset Protection для Android-устройств.

Теперь процедура переназначения устройств новым пользователям существенно упростилась и не требует данных предыдущего аккаунта. Настраивается это здесь: Devices > Profiles & Resources > Profiles > Add > Add Profile > Android > Enterprise Factory Reset Protection.

5. Поддержка одного общего устройства для нескольких пользователей.

Эта важная фича для Android позволяет пользователям делать check-in и check-out на устройстве, что дает возможность сэкономить на самих устройствах и при этом обеспечивает безопасность.

6. Контроль менеджера задач в Chrome OS.

Теперь есть профиль Chrome OS Application Control Profile, который контролирует возможность пользователей завершать задачи в Task Manager. Отключается эта возможность в Devices > Profiles & Resources > Profiles > Add > Add Profile > Chrome OS > Application Control.

7. Режим Verified Device Mode для Chrome OS.

Это новая фича Chrome OS в разделе Chrome OS Security & Privacy profiles, которая убеждается в том, что требования к безопасности соблюдены перед загрузкой устройства. Настраивается это тут: Devices > Profiles & Resources > Profiles > Add > Add Profile > Chrome OS > Security & Privacy (настройка Device Verified Mode Required).

8. Настройки Skip Screen для iOS.

Теперь эта функция предотвращает нотификации для следующих компонентов при работе Apple Setup Assistant:

• iMessage и FaceTime
• Software Update
• Screen Time

Настраивается это тут: Groups & Settings > All Settings > Devices & Users > Apple > Device Enrollment Program.

9. USB Restricted Mode для iOS.

Позволяет превратить Lightning-порт только в порт зарядки, без возможности использования USB, если девайс не разлочили в течение недели. Настраивается это здесь: Devices > Profiles & Resources > Profiles > Add > Apple iOS > Restrictions, функция USB Restricted Mode.

10. Функция Remote View for iOS.

Она позволяет удаленно просматривать экран устройства. Включается так: Devices > List View > [Select Device] > More Actions > Support > Start Remote View.

11. Функции самостоятельного управления приложениями Mac OS.

Это позволяет более гибко и быстро развертывать приложения и давать пользователям возможность локально их удалять. Настраивается в Apps & Books > Applications > Native > Internal > Desired State Management.

12. Улучшенные нотификации об установке приложений.

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

13. Удаленная перезагрузка Windows 10.

Через консоль или API можно отправить команду перезагрузки на устройства Windows 10, которая будет исполнена через 5 минут (это позволит сохранить данные пользователям).

14. Консолидированный просмотр OEM-обновлений Windows 10.

Теперь все обновления видно в едином представлении с возможностью фильтрации по типу: audio driver, chipset driver, BIOS updates и другое. Посмотреть это можно в Devices > Lifecycle > Updates > OEM Updates.

15. Ротация сертификатов SSL для VMware Tunnel.

Теперь можно на лету добавить до двух сертификатов для SSL-тоннеля и менять их без остановки работы пользователей.

16. Тип установки Unified Access Gateway (UAG).

Теперь администраторы могу использовать Unified Access Gateway (UAG) как тип установки и настроить Content Gateway на UAG или смигрировать существующий Windows или Linux Content Gateway на UAG. Это настраивается в Groups & Settings > All Settings > Enterprise Integration > Content Gateway.

17. Возможность SAML-аутентификации для отдельных сервисов.

Настроить ее можно в Groups & Settings > All Settings > Enterprise Integration > Directory Services, затем включить Use SAML For Authentication.

18. Отзыв токенов Azure при удалении устройства.

Теперь очистка устройства автоматически удаляет и его Azure-токен. Настраивается это в Accounts > Administrators > Administrator Settings > Directory Services (включить Automatically revoke user tokens when wiping device).

Более подробно о решении VMware Workspace ONE User Environment Manager 9.6 можно узнать по этой ссылке.

На сайте проекта VMware Labs появилась новая утилита vRealize Operations REST Notifications Helper, которая предназначена для администраторов решения vRealize Operations, использующих интерфейс REST для отсылки алертов третьей стороне.

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

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

Скачать утилиту vRealize Operations REST Notifications Helper можно по этой ссылке. Для загрузки документации выберите из комбо-бокса загрузки файл instructions.pdf. Для работы с утилитой вам понадобится какой-нибудь Linux и Java Runtime Environment (JRE) 1.8+.

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

Эта та область, в которой мы с вами привыкли в лидерах видеть только Dropbox (ну может еще немного Microsoft и Google):

А, оказывается, ShareFile от них не так уж и далеко.

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

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

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

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

Отчет Gartner можно скачать по этой ссылке.

Компании M1Cloud (облачный сервис-провайдер Stack Group) и Veeam Software пришлашают на совместный вебинар "Как обеспечить максимальную надежность и высокую доступность критичных данных и приложений в облаке? Практические подходы и важные нюансы".

Вебинар пройдет в эту среду, 8 августа в 12-00 по московскому времени. Регистрация тут.

На вебинаре представители M1Cloud и Veeam Software расскажут о практических подходах к обеспечению высокой доступности критичных данных и максимальной надежности работы приложений в облаке для реализации проектов средних и крупных предприятий.

• Вводное слово: Чем мы обеспечиваем повышенную надежность облачной инфраструктуры M1Cloud для бесперебойной работы бизнес-критичных приложений. (Владимир Денеко, Архитектор отдела архитектуры клиентских решений Stack Group / M1Cloud)
• Послеаварийное восстановление как услуга (Disaster Recovery as a service) на базе Veeam Cloud Connect в инфраструктуре облачного сервис-провайдера. Практика применения. (Владимир Денеко, Архитектор отдела архитектуры клиентских решений Stack Group / M1Cloud; Ирина Ленцнер, Инженер направления «Cloud», Veeam Software)
• Сверхвысокая доступность данных при резервном копировании, в том числе для удаленных пользователей, с помощью сервиса Veeam Agent под управлением сервис-провайдера. (Ирина Ленцнер, Инженер направления «Cloud», Veeam Software)
• Резервное копирование как сервис под управлением облачного сервис-провайдера на инфраструктуре Заказчика и в облаке на базе Veeam Backup & Replication. Особенности применения для быстрого и надежного резервного копирования и восстановления. (Владимир Денеко, Архитектор отдела архитектуры клиентских решений Stack Group / M1Cloud)
• Object Storage: сценарии практического применения. S3, как способ сокращения издержек для архивного хранения данных в облаке. (Владимир Денеко, Архитектор отдела архитектуры клиентских решений Stack Group / M1Cloud)
• Перспективы развития и ожидаемый функционал технологий резервного копирования Veeam. (Ирина Ленцнер, Инженер направления «Cloud», Veeam Software)
• Заключительная часть и ответы на вопросы (специалисты Stack Group и Veeam Software).

Для кого

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

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

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

Регистрируйтесь бесплатно!

Компания VMware наконец-то обновила свой главный документ о производительности основной платформы виртуализации - "Performance Best Practices for VMware vSphere 6.7". Несколько ранее мы писали о документе "What’s New in Performance - VMware vSphere 6.7", в котором были рассмотрены основные нововведения последней версии продукта в плане производительности, но там было всего 13 страниц, а в этой книге о производительности - аж 88!

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

• Hardware-assisted virtualization
• Storage hardware considerations
• Network hardware considerations
• Memory page sharing
• Getting the best performance with iSCSI and NFS storage
• Getting the best performance from NVMe drives
• vSphere virtual machine encryption recommendations
• Running storage latency-sensitive workloads
• Network I/O Control (NetIOC)
• DirectPath I/O
• Running network latency-sensitive workloads
• Microsoft Virtualization-Based Security (VBS)
• CPU Hot Add
• 4KB native drives
• Selecting virtual network adapters
• The vSphere HTML5 Client
• vSphere web client configuration
• Pair-wise balancing in DRS-enabled clusters
• VMware vSphere update manager
• VMware vSAN performance

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

Несколько интересных моментов из документа:

• Начиная с версии vSphere 6.7, платформа больше не поддерживает программную виртуализацию CPU (только аппаратную).
• vSphere Flash Read Cache (vFRC) может негативно влиять на производительность vMotion.
• Для VVols массив сам обнуляет блоки перед созданием тома, поэтому нет возможности указать тип диска "eager" или "lazy".
• Если вы используете виртуальный сетевой адаптер старой модели с пониженной пропускной способностью, например, Vlance, который показывает в гостевой ОС 10 Мбит/с - это не значит, что он будет работать на этой скорости. Он будет работать на скорости, максимально поддерживаемой физическим оборудованием и хостом ESXi.

Остальные полезные фишки - в документе.

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

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

• Функция проверки соответствия (Check compliance) для Host Profiles в кластере.
• Возможности Pre-check и remediate host (сделано не до конца) при накате профилей хостов.
• Функции Extract для профилей хостов и возможность для их изменения.
• Возможность управления избранным в Host profiles (на серверах vCenter 6.5).
• Функции копирования настроек между профилями хостов (для vCenter 6.5).
• Исправления ошибок.

Довольно-таки не густо для релиза, который готовили с середины июня. Загрузить VMware vSphere Client 3.40 можно по этой ссылке.

На сайте проекта VMware Labs появилась очередная интересная штуковина - проект Horizon Helpdesk Utility, который перенял всю основную функциональность Helpdesk в HTML5 интерфейсе управления VMware Horizon, но поставляется теперь как отдельное решение с расширенными возможностями.

Кроме привычных администраторам возможностей, в Horizon Helpdesk Utility были добавлены следующие функции:

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

Скачать утилиту Horizon Helpdesk Utility можно по этой ссылке.

Недавно мы рассматривали некоторые аспекты резервного копирования на томах VVols в среде VMware vSphere. Одна из важных составляющих этого процесса - снапшоты (snapshots). Мы упоминали, что ввиду архитектуры VVols в плане снапшотов, снимки на уровне дисковых массивов на томах VVols работают быстрее при откате к снапшоту и консолидации (удалении всех снапшотов диска VMDK).

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

Снапшоты на томах VMFS

Сначала посмотрим на традиционную архитектуру снапшотов виртуальных машин на томах VMFS. Когда для машины делается снапшот, создается VMDK-файл, представляющий собой redo log (назовем его лог наката). В этот момент основной диск ВМ переводится в режим только для чтения (read only), а все новые операции записи (writes) идут в новый VMDK (дельта диск), который становится активным диском в плане новых операций чтения-записи для новых блоков, а старые блоки читаются из старого базового VMDK.

Если же мы хотим удалить один из снапшотов, мы должны склеить (накатить - redo) все сделанные операции записи новых блоков из логов наката к предыдущим точкам во времени. Например, если у вас есть базовая точка PIT1 (основной VMDK-диск), а также снапшоты PIT2 и PIT3, то чтобы удалить, например, снапшот PIT2 вам надо повторить (накатить) все операции его redo log на основном VMKD (PIT1), чтобы получить стабильную итоговую цепочку PIT1-PIT3 (без PIT2). Это довольно трудозатратная операция.

Если вы хотите откатиться к одному из снапшотов (revert), например, к исходному состоянию PIT1, то работает это очень просто - следующие снапшоты в цепочке просто отбрасываются (удаляются их VMDK):

Если же вы хотите удалить все снапшоты (консолидировать диск ВМ - операция consolidate), то процедура будет очень накладной. Об этой процедуре мы детально писали вот тут. Сначала PIT2 склеивается с PIT3, а потом уже получившийся диск склеивается с PIT1.

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

Снапшоты для томов VVols

Давайте теперь посмотрим, как снапшоты работают в среде VVols. Здесь базовый диск находится в режиме чтения-записи всегда и всегда хранит в себе самое актуальное состояние. При создании снапшота диска VMDK происходит создание файла VMDK, который хранит в себе отличия (трекаются изменившиеся блоки), происходившие с какого-то момента времени (можно сказать, что это undo log). При этом основной контекст чтения-записи остается на основном VMDK.

В такой схеме операция revert будет происходит довольно долго по сравнению с таковой на VMFS - надо будет откатить изменения PIT3 в базовом диске, а потом изменения PIT2 (если мы идем к состоянию PIT1), но надо помнить, что откатываться к снапшоту приходиться не так уж и часто.

А вот операция консолидации (удаление всех снапшотов) - очень частая при резервном копировании. И вот тут для такой архитектуры работает это все моментально - мы просто откидываем ненужные объекты undo log, оставляя только базовый диск, который содержит в себе самое актуальное состояние на данный момент:

При необходимости вернуться к какому-то из снапшотов в среде VVols надо будет в базовом диске откатить все те изменения блоков (undo), которые зафиксированы в VMDK-диске снапшота, отслеживаемые с нужного момента времени (например, PIT1):

Интересная штука - аналитическая компания Gartner, известная своими "магическими квадрантами", выпустила отчет Gartner Magic Quadrant for Unified Endpoint Management 2018, в котором решение Workspace ONE по управлению конечными устройствами пользователей (в том числе мобильными) на основе технологии AirWatch признано лидером и вообще находится на первом месте:

Не секрет, что VMware и Gartner очень "дружат", но и выставлять на первое место полную лажу Gartner не стала бы. Интересно, что технология AirWatch, купленная VMware и не имевшая прямого отношения к основному бизнесу компании, вывела VMware на первое место в этом сегменте. Она обошла даже Microsoft с ее решением Enterprise Mobility + Security (EMS).

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

• полнота видения (completeness of vision)
• способность реализации (ability to execute)

Каждый поставщик, попавший в рамки рассмотрения для исследуемого сегмента рынка, оценивается по этим двум критериям. При этом, полнота видения откладывается на оси абсцисс, способность реализации — на оси ординат. Каждый поставщик, таким образом, оказывается в одном из четырёх квадрантов плоскости, называемых:

• Лидеры (leaders) — поставщики с положительными оценками как по полноте видения, так и по способности реализации.
• Претенденты (сhallengers) — поставщики с положительными оценками только по способности реализации.
• Провидцы (visionaries) — поставщики с положительными оценками только по полноте видения.
• Нишевые игроки (niche players) — поставщики с отрицательными оценками по обоим критериям.

Кстати, Magic Quadrant по серверной виртуализации больше не публикуется (вы, возможно, заметили, что его не было в этом и в прошлом году) - так как Gartner считает этот рынок зрелым, там все и так всем понятно, поэтому никакой аналитической работы проводить не нужно.

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

1. Обновление VMware Horizon 7.5.1

В этом обновлении не появилось ничего нового, за исключением исправления безопасности CVE-2018-6971. Эта уязвимость заключается в том, что в процессе установки Horizon в файл vmmsi.log записывалась информация об учетных записях, которую могли считать привилегированные пользователи. Более подробно об этом рассказано тут.

Более подробно о самом обновлении можно прочитать в Release notes. Скачать VMware Horizon 7.5.1 можно по этой ссылке.

Здесь было сделано несколько улучшений служб управления:

• Pivotal tc Server заменен на сервер Tomcat версий 8.5.24 и 8.5.23.
• Кастомизация гостевых ОС Windows и Linux на vCenter Server поддерживает самые актуальные временные зоны.
• Поддержка TLS версии 1.2 для защищенного соединения с Microsoft SQL Server.
• Поддержка баз данных Microsoft SQL Server 2014 Service Pack 2, SQL Server 2016, SQL 2016 Service Pack 1 и SQL Server 2012 Service Pack 4.

Более подробно об обновлении можно прочитать в Release notes. Скачать VMware vCenter Server 6.0 Update 3g можно по этой ссылке.

3. Обновление VMware vSphere Integrated Containers 1.4.2

В этом обновлении только пофикшена проблема интеграции vSphere Integrated Containers Registry с компонентом сканирования на уязвимости Clair. Более подробно это улучшение описано вот тут.

Более подробно об обновлении можно прочитать в Release notes. Скачать vSphere Integrated Containers 1.4.2 можно по этой ссылке.

4. Обновление VMware vCenter Server 6.7.0c

Это обновление содержит в себе только исправления ошибок, которые описаны в разделе Resolved Issues документа Release notes. Скачать vCenter Server 6.7.0c можно по этой ссылке.

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

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

Для ПО резервного копирования тома виртуальные машины на томах VVols выглядят аналогично таковым на томах VMFS, поэтому ни схема, ни средства резервного копирования в инфраструктуре VVols не изменяются:

Резервное копирование делается через механизм vSphere APIs for Data Protection (VADP), который создает снапшот на хранилище, чтобы после его создания ПО для бэкапа могло забрать диски с данными ВМ. Отличие тут в том, что в этой схеме снапшот ВМ делает программное обеспечение дискового массива, на сторону которого передаются операции по работе со снапшотами и другие функции.

Кстати, интересная штука - стандартно для виртуальной машины в VMware vSphere можно сделать до 32 снапшотов, хотя VMware рекомендует делать их не более 2-3 в одной цепочке, так как большее количество может привести к различного рода проблемам. А вот с аппаратными снапшотами на томах VVols можно сделать 32 снапшота, и это никаких проблем не повлечет.

На массивах с поддержкой VVols есть поддержка операций "consolidate" и "revert" для снапшотов. В среде VVols они работают по-другому: там есть базовый VMDK, который всегда остается таковым, и куда идет запись, а также вместо записи изменений в redo log там есть read-only файлы снапшотов, которые не подцепляются в зависимую цепочку. При откате снапшота с базовым VMDK никаких длительных последовательных операций не производится (в отличие от VMFS), соответственно все это делать можно безопасно (подробнее - тут).

Также важно помнить, что использование Change Block Tracking (CBT) и vMotion для виртуальных машин на томах VVols может привести к порче данных (подробнее об этом тут). Эта проблема уже решена, но ее исправления будут доступны в следующих релизах vSphere 6.0, 6.5 и 6.7, а пока отключайте DRS для кластеров с виртуальными машинами на томах VVols.

На момент написания статьи VVols поддерживается для работы в трех режимах резервного копирования:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Защищенное резервное копирование по Ethernet (NBDSSL) - то же самое, что и NBD backup, только с использованием SSL-шифрования при соединении через TCP/IP.

А вот метод без использования сети Ethernet (SAN-to-SAN backup) по-прежнему не поддерживается. Это происходит потому, что для в традиционной инфраструктуре VMFS есть виртуальный хост backup proxy, который говорит виртуальному модулю резервного копирования, какие блоки нужно читать по сети SAN. В среде VVols через VASA API компонент VASA provider на стороне физического сервера или дискового массива пока не может построить физический SAN-путь от хоста ESXi с томом VVols.

VASA provider нуждается в защите (если он реализован в виде виртуальной машины), так как он содержит в себе структуру томов VVols (и маппинги машин к устройствам), и если этот компонент будет потерян, то вы полностью потеряете управление над хранилищами (запущенные машины при этом еще будут работать).

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

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

Компания VMware выпустила обновленную версию своего клиента для управления отдельными хост-серверами - VMware ESXi Embedded Host Client 1.31. Напомним, что о прошлом релизе клиента, который вышел в марте этого года, мы писали вот тут (это версия 29, тридцатую пропустили).

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

• Исправлены проблемы, которые проявлялись в некорректном выборе значений комбо-боксов.
• Обновился пользовательский интерфейс настроек клиента синхронизации времени NTP.
• Фреймворк AngularJS был обновлен до версии 1.6.10.
• Исправлены некоторые ошибки.

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

После того, как вы загрузите VIB-пакет с Host Client, используйте следующую команду для его установки на ESXi:

ssh root@<esx ip or hostname> esxcli software vib install -v <path_to_vib>

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

https://<esx ip or hostname>/ui

Скачать VMware ESXi Embedded Host Client 1.31 можно по этой ссылке.

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

Для vMotion и SVMotion есть вот такой скрипт от Luc Dekens, который экспортирует миграции за указанное число часов или дней в файл XLS. Запустить его можно такой командой (скрипт точно работает для vSphere 6.5, как пишут здесь):

get-motionhistory -Entity (get-cluster "Cluster 1" | get-vm) -Days 2 | Export-csv -NoTypeInformation -UseCulture E:\VMware\Prod_vMotions.csv

На выходе будет вот такая табличка (обратите внимание, что миграции поделены на пользовательские и системные от DRS/SDRS, а также в поле Type указано, что это - vMotion или SVMotion):

Также ребята из компании Opvisor несколько адаптировали этот скрипт в разрезе миграций хранилищ Storage vMotion для подсчета общего объема миграций и выложили его тут. Работа этого скрипта дает вот такой результат:

Если вы хотите импортировать виртуальный модуль (Virtual Appliance), который идет в формате OVA, на платформу VMware Workstation или Fusion, то иногда при импорте можете получить вот такую ошибку:

Invalid target disk adapter type: pvscsi.

Это все оттого, что платформы Fusion/Workstation пока не поддерживают паравиртуализованный адаптер хранилищ (PVSCSI storage adapter) для формата виртуальных машин OVA (например, в этом формате идет PhotonOS).

Решением этой проблемы является конвертация OVA в формат OVF в помощью ovftool:

ovftool --allowExtraConfig photon-custom-hw13-2.0-304b817.ova photon-custom-hw13-2.0-304b817.ovf

Далее нужно открыть файл формата OVF в обычном текстовом редакторе и найти там строчку:

<rasd:ResourceSubType>VirtualSCSI</rasd:ResourceSubType>

и заменить ее на строчку:

<rasd:ResourceSubType>lsilogic</rasd:ResourceSubType>

После этого нужно удалить созданный файл манифеста (он будет с расширением .mf, наподобие photon-custom-hw13-2.0-304b817.mf), поскольку контрольная сумма OVF-файла изменилась с изменением вами строчки. Ну а затем импортируйте ваш OVF-модуль в среду Workstation/Fusion. Если же вы непременно хотите иметь его в формате OVA, то выполните обратную команду:

ovftool --allowExtraConfig photon-custom-hw13-2.0-304b817.ovf photon-custom-hw13-2.0-304b817.ova

На сайте проекта VMware Labs обновилась полезная утилита Cross vCenter Workload Migration, которая предназначена для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). Напомним, что о первой ее версии мы писали в конце прошлого года вот тут.

По отзывам пользователей, утилита Cross vCenter Workload Migration часто пригождается, когда требуется массовая миграция сотен и тысяч виртуальных машин между распределенными датацентрами.

Во-первых, в новой версии добавилась возможность указывать целевой пул ресурсов и папку (VM Folder), куда требуется переместить выбранные виртуальные машины:

Это позволяет реализовывать массовые миграции с точки зрения организационной структуры (папки) и с точки зрения использования ресурсов (пулы).

Во-вторых, появилась поддержка VMware Cloud on AWS (VMC). Раньше Cross vCenter vMotion Utility не поддерживала специфическую иерархию ресурсов и прав доступа AWS, но теперь все работает отлично. Вот пример миграции ВМ в облачный датацентр из онпремизного:

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

• Увеличилось число одновременных миграций с 10 до 100.
• Появилась возможность выбрать целевой хост ESXi для миграции.
• Поддерживается миграция ВМ с общими хранилищами, а также еще и функции клонирования в дополнение к миграции.
• Улучшилось отображение свойств и ресурсов ВМ, а также интерфейс REST API.

Скачать Cross vCenter Workload Migration Utility можно по этой ссылке. А вот, кстати, обзорное видео об этом средстве:

Некоторые из вас (особенно администраторы VMware Horizon 7.5) знают, что в последней версии VMware vSphere 6.7 появилась возможность приостанавливать виртуальные машины, использующие vGPU, с высвобождением ресурсов графического адаптера под другие задачи. Ранее ресурсы графической карты возвращались платформе только при выключении виртуальной машины.

На эту тему VMware записала небольшое видео с демонстрацией данной возможности:

Для демо используются два 2 пула ресурсов: первый - под два виртуальных десктопа VMware Horizon, а второй - под две машины, использующие ресурсы vGPU для расчета моделей с помощью библиотеки машинного обучения TensorFlow.

Все 4 машины настраивают на использование политики, которая привязана к адаптеру NVIDIA Tesla P40 и позволяет использовать до половины ресурсов видеокарты. Сначала включают 2 виртуальных ПК Horizon, которые съедают всю карту, поэтому остальные две машины включить не удается. Но затем десктопы приостанавливают (Suspend), после чего машины с TensorFlow становится возможно запустить. Ну и в заключение тушат одну из машин TensorFlow, после чего успешно запускают один из виртуальных ПК Horizon (Resume).

Производитель графических адаптеров NVIDIA также записала небольшое демо своей технологии GRID для vSphere 6.7:

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

В общем, это нововведение весьма удобная и полезная штука.

Многие пользователи кластера отказоустойчивости хранилищ VMware vSAN замечали, что в настройках служб кластера есть такая опция "Erase disks before use", которая доступна при шифровании хранилища (vSAN Encryption).

Эта настройка позволяет очистить диск перед использованием шифрования на нем, чтобы соблюсти требования к безопасности хранения и обслуживания данных, например, NIST 800-88 Revision 1, определение "Clear":

Clear applies logical techniques to sanitize data in all user-addressable storage locations for protection against simple non-invasive data recovery techniques; typically applied through the standard Read and Write commands to the storage device, such as by rewriting with a new value or using a menu option to reset the device to the factory state (where rewriting is not supported).

В приложении A приведенного выше документа есть такая таблица (приведены только 2 строки из нее):

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

Ставя галку "Erase disks before use" надо понимать, что процесс заполнения блоков случайными значениями занимает значительное время, которое зависит от типа используемого хранилища и инфраструктуры хранения в целом.

Также важно помнить, что включение vSAN Encryption влечет за собой шифрование только новых создаваемых дисковых объектов и не применяется к существующим на хранилище блокам (то есть их потенциально можно считать с диска, расшифровка их не потребуется). Таким образом, использование vSAN Encryption с настройкой "Erase disks before use" имеет смысл только при добавлении устройств, где ранее существовали данные.

Поэтому:

• Включайте опцию "Erase disks before use", когда:
  • Включаете vSAN Encryption для существующуего vSAN кластера, в котором требуется вычистить свободные блоки.
  • Добавляете хост, который имел ранее данные на локальных дисках, в кластер vSAN.
  • Выполняете операцию rekey для инициации процедуры deep rekey (запрос нового KEK и новых уникальных DEKs для каждого устройства vSAN).
• Не обязательно включать "Erase disks before use", когда:
  • Включаете vSAN Encryption для полностью нового кластера vSAN, в котором ранее не было данных на добавляемых дисках.
  • Добавляете в кластер vSAN хост, у которого на локальных дисках не было чувствительных данных.
  • Выполняете операцию rekey для инициации процедуры shallow rekey (только запрос нового KEK).

Еще в настольной платформе виртуализации VMware Fusion 10 для Mac OS, вышедшей осенью прошлого года, появился программный интерфейс REST API, который позволяет управлять как самой платформой, так и виртуальными машинами, исполняемыми на ней. Совсем недавно, когда вышла версия VMware Workstation 2018 Tech Preview, в которой также появился новый REST API полностью идентичный таковому в VMware Fusion. Однако для Workstation он пока работает только для хостовой ОС Windows.

REST API позволяет управлять различными функциями виртуальных машин, например их inventory, питанием, клонированием, сетевым взаимодействием, получением IP и MAC-адресов, а также другими аспектами их функционирования. Все это позволяет проводить автоматизированные тесты в виртуальных машинах, когда их требуется клонировать и настраивать, а затем уничтожать по окончании теста. Эти функции пока доступны только для Windows.

Давайте посмотрим, как это работает. Сначала сконфигурируем доступ к REST API, задав логин и пароль для авторизации:

• Чтобы настроить Credentials к REST API на машине с Workstation, нужно перейти в папку C:\Program Files (x86)\VMware\VMware Workstation и запустить там:
  vmrest.exe --config
• На VMware Fusion нужно пойти в /Applications/VMware Fusion.app/Contents/Public и запустить там:
  ./vmrest -C

На Workstation вас попросят задать пользователя и пароль:

C:\Program Files (x86)\VMware\VMware Workstation>vmrest --config

 VMware Workstation REST API

 Copyright (C) 2018 VMware Inc.

All Rights Reserved

vmrest 1.1.0 build-8888902

 Username:alex

 New password:

 Retype new password:

 Processing...

 Credential updated successfully

На Fusion это будет выглядеть вот так:

MacBook-Pro-alex:Public alex$ ./vmrest -C

 VMware Fusion REST API

 Copyright (C) 2015-2017 VMware Inc.

All Rights Reserved

vmrest 1.0.0 build 6754183

 Username:alex

 New password:

 Retype new password:

 Processing...

 Credential updated successfully

После этого можно запускать REST API:

• На Fusion это делается командой ./vmrest
• На Workstation надо просто запустить vmrest.exe

После этого у вас на рабочей станции запустится веб-сервер, через который вы сможете получить доступ к REST API как через браузер, так и через сторонние REST-клиенты или системы, которые вы хотите интегрировать с Workstation или Fusion. На Workstation для доступа к веб-серверу на дефолтном порту используйте адрес:

http:\\127.0.0.1:8697

На Fusion ссылка аналогичная (можно писать 127.0.0.1 вместо localhost):

http:\\localhost:8697

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

Первое что вы увидите - это REST API Explorer, запущенный в интерфейсе Swagger, в котором показаны доступные для использования функции по работе с хостом и виртуальными машинами:

Тут вам не понадобится использовать Curl, PowerShell, Postman или другие инструменты, чтобы протестировать основные функции API.

Здесь все просто:

• Host Networks Management - здесь можно посмотреть все виртуальные сети на хосте, а добавить, изменить или удалить форвардинг портов.
• Maintenance - можно задать режим работы демона (можно его выключить для перехода в режим обслуживания).
• VM Management - управление виртуальными машинами (получение их списка и информации о ВМ, задание их настроек, клонирование ВМ и удаление).
• VM Network Adapters Management - управление сетевыми адаптерами ВМ (получение списка сетевых адаптеров и IP-адресов ВМ, а также создание, обновление или удаление сетевых адаптеров ВМ).
• VM Power Management - получение состояния ВМ и управление ее питанием.
• VM Shared Folders Management - монтирование, размонтирование или изменение конфигурации общих папок на хосте.

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

Далее можно нажать на Show/Hide для некоторых пунктов и посмотреть доступные операции:

Обратите внимание на цветовое кодирование, оно поможет вам понимать, чем вы занимаетесь при тестировании API:

• Методы GET будут подсвечены синим цветом - это абсолютно безопасно, так как они только читают данные.
• Желтым цветом будут подсвечены методы PUT - это изменение каких-либо настроек.
• Зеленые методы POST - это создание новых сущностей (например, сетевых адаптеров) или выполнение операций (например, клонирование ВМ).
• Красные методы DELETE - удаление сущностей.

Каждую операцию можно раскрыть подробнее, нажав на соответствующую строчку. Например, раскроем GET /vms для VM Management:

Здесь объясняется модель данных JSON-массива, в которой ожидается прием параметров.

Если посмотреть ниже, то мы найдем кнопку TRY IT OUT!, по нажатию на которую мы получим ответ в блоке Responce Body, где будет ID виртуальных машин и путь к ним в хостовой системе:

В данном случае код ответа (Responce Code) был 200, но бывают и другие коды ответа, обратите на них внимание:

Давайте попробуем уже метод не чтения, а метод PUT (обновление настроек). Например, для PUT /vms/{id}. Здесь мы видим, что можно поменять число процессоров ВМ и объем выделенной памяти:

Если вы кликните справа на Example Value, то значение примера подставится в окошко parameters и вам останется лишь поменять числовые значения. После того, как вы измените параметры и нажмете try it out, в поле Responce body должна отобразиться новая конфигурация ВМ.

Также можно, например, создать сетевой адаптер для виртуальной машины с помощью метода POST:

Ну и затем удалить его с помощью метода DELETE (обратите внимание, что Responce code в этом случае будет 204, а не 200):

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

Ну а дальше вы можете получить доступ к REST API Workstation или Fusion через любой REST-клиент, например, через PowerShell или Postman, но самый простой метод - это использовать curl. Как это сделать, вы можете прочитать вот в этой статье Вильяма Лама.