Летом этого года компания VMware выпустила технологические превью настольных платформ виртуализации Workstation 2018 и Fusion 2018, а на днях состоялся их финальный релиз. VMware выпустила новые версии VMware Workstation 15 и VMware Fusion 11. Давайте посмотрим, что нового появилось в платформе VMware Workstation 15, которая уже доступна для загрузки...
На прошлой неделе компания Veeam в Праге собирала участников сообщества Veeam Vanguards 2018, где мы пили чешское и катались по Влтаве. Но самым интересным было не это, а рассказы о перспективах компании, ее новых продуктах и технологиях, о которых мы расскажем в ближайшем будущем.
Один из самых ожидаемых релизов - это Veeam Backup and Replication 9.5 Update 4, который, скорее всего, будет официально поддерживать резервное копирование виртуальных машин на недавно вышедшей новой версии платформы VMware vSphere 6.7 Update 1 (хотя и на данный момент фактически он на ней прекрасно работает, но нужно кое-что сделать).
В новой версии VBR будет много всего полезного, но давайте остановимся на двух возможностях. Первая - это функция Staged Restore, которая позволяет проводить манипуляции с данными внутри бэкапов с помощью скриптов перед их реальным восстановлением в производственную среду.
Главное назначение этой возможности - соблюдения комплаенса GDPR (если вы работаете с данными европейцев), который закрепляет, в частности, за бывшим работником организации право на удаление персональной информации о нем, которая хранится, как минимум, в Active Directory. Поэтому с помощью сценариев можно удалить аккаунт бывшего пользователя из AD и, например, его почтовый ящик из Exchange, чтобы не нарваться на нарушение и штраф.
Схема выглядит так - администратор восстанавливает резервную копию в полностью изолированное окружение, с помощью сценария PowerShell удаляет из машины требуемые данные, после чего она переходит в производственную среду:
В принципе, вы можете создать список действующих сотрудников в текстовом документе и удалять из бэкапа тех, кто ему не соответствует. Но для этого надо быть знакомым с PowerShell. Ну а примеры подобных сценариев вы скоро найдете в репозитории Veeam на GitHub (VeeamHub).
Вторая интересная фича Update 4 - это возможность проверки антивирусом резервной копии перед восстановлением (как раз на стадии Staged Restore), чтобы она не заразила производственную среду:
Причем поддерживаются не только самые распространенные антивирусы, но и с помощью сценариев вы сможете интегрировать любой антивирус, который поддерживает запуск из командной строки. В этом случае виртуальная машина и ее данные как бы помещаются на карантин (Antivirus Quarantine) и далее, пролечившись, они могут быть восстановлены в продакшен.
Зачем это нужно, если у вас уже есть антивирус внутри ВМ? Очень просто - есть атаки, называемые Zero-day, то есть, например, ваши данные были заражены вирусом, о котором еще не знает ваш антивирус. В этом случае в бэкап этот вирус попадет, ну а при восстановлении он заразит вашу виртуальную машину, вызвав, например, полное блокирование ее работы.
Процесс Secure Restore позволяет защититься от этого вида уязвимостей:
Более подробно о новых возможностях Veeam Backup and Replication 9.5 Update 4 мы расскажем в ближайшем будущем - когда он выйдет.
В Евросоюзе обработку персональных данных регулирует небезызвестная директива GDPR. В России за это отвечает ФЗ-152 «О персональных данных». Мы расскажем о требованиях, которые предъявляют эти положения к работе с ПД на рынках РФ и Европы.
Европейский подход
GDPR в Европе работает с 25 мая 2018 года. Под его действие попадают все компании (интернациональные в том числе), которые хранят или обрабатывают персональные данные граждан Евросоюза.
Что считать ПД по GDPR?
Персональными считаются данные, по которым можно установить личность владельца – пользователя сервиса (хотя бы косвенно): ФИО, домашний адрес, IP-адрес, логин на каком-либо сайте и другие идентификаторы. Сюда же относится информация, касающаяся социальной или культурной принадлежности.
Еще в GDPR выделена особая категория конфиденциальных данных. Она включает религиозные убеждения гражданина, его биометрические показатели, а также медицинские сведения.
Требования к операторам данных
Получать согласие на обработку данных. Обрабатывать персональные данные без согласия их владельца запрещено. При этом нельзя считать согласием молчание или бездействие пользователя. Также оператор должен сообщить, с какой целью используется собираемая информация.
Защищать персональные данные. Компания-обработчик обязана защитить ПД от кражи, повреждения или подмены. Поэтому сведения должны шифроваться, а их распространение – контролироваться.
Назначать сотрудников по защите данных. Они управляют бизнес-процессами, касающимися работы с ПД, и следят за соблюдением требований GDPR. Это особенно важно, если организация проводит масштабные исследования или обрабатывает большие объемы конфиденциальных сведений (например, медицинских записей).
Обеспечивать право на забвение. Обработчик обязан удалить ПД пользователя по запросу, если это требование не идет вразрез с интересами сообщества или другими правами жителей ЕС.
Уведомлять представителей регулятора об утечках данных. Об уязвимости нужно сообщить в течение трех дней с момента обнаружения «бреши».
В РФ работу компаний с ПД клиентов и пользователей регулирует ФЗ-152 «О защите персональных данных». Он обязателен для исполнения всеми компаниями, зарегистрированными в России, а также филиалами иностранных организаций.
Что считать ПД по ФЗ-152?
Определение ПД в ФЗ-152 похоже на то, что дает GDPR: персональными данными считается любая информация, с помощью которой можно установить личность человека (номер телефона, номер банковской карты и так далее).
Требования к операторам данных
Получать согласие на обработку ПД. Дополнительно оператор ПД должен сообщить пользователю, какая информация о нем собирается и в каких целях применяется. Например, на нашем сайте все это прописано в политиках конфиденциальности.
Без согласия человека можно обрабатывать только ПД из открытых источников.Однако здесь нужно соблюдать осторожность, так как были прецеденты (по решению верховного и арбитражного судов нашей страны), когда данные в открытом доступе по разным причинам оказывались запрещены для обработки.
Собирать только ту информацию, которая необходима для работы предоставляемого сервиса. Собирать и хранить данные «на всякий случай» запрещено. По этой причине владелец интернет-магазина не имеет права просить у пользователей сканы паспортов.
Удалять или обезличивать более ненужные ПД. Оператор должен уничтожить неактуальные данные или обновить и уточнить данные, в которых есть ошибки.
Штрафы за нарушение требований закона разные для физических и юридических лиц и варьируются от 1000 до 75 тыс. рублей. Например, физическое лицо получит штраф в 3–5 тыс. рублей за обработку ПД без согласия владельца. Юрлицу то же нарушение обойдется в 30–75 тыс. рублей.
Чем поможет облачный провайдер
В обоих законах – российском ФЗ-152 и европейском GDPR – сказано, что оператор может делегировать обработку ПД третьей стороне (если владелец персональных данных на это согласен).
Часто в роли третьей стороны выступает IaaS-провайдер. Он предоставляет инфраструктуру с полным набором технических и административных систем защиты персональных данных. Например, эту услугу предоставляем мы в «ИТ-ГРАД». Она называется «Облако ФЗ-152».
У нас защищенный хостинг, в основе которого оборудование таких компаний, как Dell, NetApp, Juniper, Cisco и др. Система снабжена программно-аппаратным комплексом шифрования. Такая инфраструктура снижает юридические риски компаний.
Сервис «Облако ФЗ-152» подходит как для отечественных, так и для иностранных организаций. Все они получают возможность работать с клиентами из РФ в полном соответствии с законом и обеспечивать высокий уровень защищенности персональных данных пользователей.
Недавно компания VMware объявила о выпуске обновленной версии решения vCloud Availability Cloud-to-Cloud Disaster Recovery 1.5, которое предназначено для репликации и восстановления виртуальной инфраструктуры в одном из облаков сервис-провайдеров (между датацентрами, в каждом из которых работает vCloud Director).
Напомним, что это решение дополняет семейство продуктов VMware vCloud Availability for vCloud Director, которое предназначено для сервис-провайдеров и выполняет функции обеспечения доступности виртуальных машин в их публичных облаках.
vCloud Availability Cloud-to-Cloud DR - это часть сервисов VMware Cloud Provider Platform, обеспечивающих функционирование публичных облаков. При этом данное решение подключается как плагин для vCloud Director и работает между облаками различной природы (онпремизными и публичными), предоставляя репликацию и восстановление виртуальных машин и сервисов vApp между различными экземплярами vCloud Director в разных датацентрах.
Кстати, первая версия этого решения по отзывам сократила время ручных операций по обслуживанию и диагностике служб репликации на 72%. Давайте посмотрим, что нового появилось в Cloud-to-Cloud DR версии 1.5.
Улучшения произошли в 5 ключевых областях:
1. Интегрированный пользовательский интерфейс в vCloud Director.
Сервис-провайдеры, использующие vCloud Director 9.1 и более поздние версии продукта, получили обновленный интерфейс (для предыдущих версий останется старый). Кроме того, клиенты сервис-провайдеров получили возможность включить функции Disaster Recovery и зайти в vCloud Director прямо из тулбара.
Также обновился и API до версии 1.5 (он позволяет интегрировать функции vCloud Availability Cloud-to-Cloud DR в пользовательские порталы). API теперь позволяет управлять такими продуктами и процессами, как: Replication manager, рабочие процессы репликации vApp, мониторинг состояния системы, первоначальная конфигурация репликации (создание туннеля, DNS, конфигурации точек репликации и т.п.), а также управление системой на уровне всей площадки.
Помимо этого, теперь для Cloud-to-Cloud DR обеспечена сквозная аутентификация из vCloud Director, что очень удобно для пользователей.
2. Улучшения юзабилити и рабочих процессов.
В новой версии Cloud-to-Cloud DR появилась возможность управления политиками, которые позволяют задать RPO ну уровне клиента, что дает возможность обеспечить различным клиентам разный уровень соответствия политикам RPO (а для последней версии vSphere можно обеспечить RPO=5 минут). Также можно установить максимальное число снапшотов и максимальное число репликаций на клиента.
Одна из новых удобных возможностей - это комплексные фильтры, которыми можно вывести виртуальные машины и объекты vApp, к которым далее можно применить некоторые действия (например, создать снапшоты или запустить восстановление).
3. Улучшения масштабируемости инфраструктуры.
Теперь можно использовать до 300 активных репликаций для одного большого узла vCloud Availability Replicator, около 100 клиентов с активными репликациями, до 7 экземпляров vCloud Availability Replicator на один экземпляр vCloud Availability Cloud-to-Cloud и до 2 ТБ объема защищаемых VMDK-дисков. С точки зрения операций, их может быть где-то до 120 штук одновременно, а всего тестировалось до 3000 активных операций для более чем 100 клиентов (программного ограничения нет).
4. Плагин Orchestration plugin для создания собственных рабочих процессов.
Через некоторое время станет доступен отдельный плагин, который будет работать под vRealize Orchestrator и будет позволять конструировать такие рабочие процессы, как, например, построение инвентори или сбор и обработка данных от экземпляров vCloud Availability vApp Replication Manager. Рабочий процесс можно сделать в vRealize Orchestrator Client, после чего импортировать его в vCloud Director и далее исполнять их там.
5. Функции улучшения ежедневной эксплуатации для администраторов.
vCloud Availability Cloud-to-Cloud 1.5 будет иметь плагин для vRealize Operations 6.6.1 и более поздних версий (будет доступен несколько позже), который будет предоставлять информацию о компонентах и их активностях, инвентори, общему состоянию, сработавших алармах, доступной емкости, статусу репликации и прочему. Сервис-провайдеры теперь смогут показывать клиентам расширенные отчеты, в которых будет информация о соблюдении оговоренных KPI и SLA.
Спустя несколько недель ожидания после анонса обновленной версии платформы виртуализации VMware vSphere 6.7 Update 1, компания VMware сделала ее доступной для загрузки. Скачать продукт, включая ESXi 6.7 Update 1 и vCenter 6.7 Update 1, можно по этой ссылке:
Напомним, что обо всех новых возможностях этого решения мы писали вот тут. Кроме того, в составе vSpher 6.1 Update 1 стал доступен и VMware vSAN 6.7 Update 1, про который мы писали вот тут.
Ну и главная новость этого релиза - это, бесспорно, полнофункциональный vSphere Client на базе HTML5! Мы ждали этого годами, и это сбылось. Вот пост об этом от VMware, там много подробностей, о которых мы скоро тоже расскажем.
Для него, кстати, доступна темная тема (см. последние наши новости о vSphere Client 3.42):
Клиент на HTML5 включает в себя не только все старые рабочие процессы, но и новые возможности, такие как упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).
Вкратце суммаризуем все новые возможности VMware vSphere 6.7 Update 1:
Полнофункциональный VMware vSphere Client на базе HTML5
Утилита vCenter Server Converge Tool для миграции на внедренный (embedded) PSC
Новая версия vSAN и улучшения HCI (обновления микрокода через Update Manager)
Улучшения Content Library
vMotion для карточек NVIDIA Quadro vDWS и поддержка Intel FPGA
Отдельно давайте посмотрим, а что нового появилось в VMware vSAN 6.7 Update 1:
Новый мастер Cluster quickstart
Обновление драйверов и firmware через Update Manager
Механизмы защиты при выводе хостов из эксплуатации и переводе в режим обслуживания
Разные представления vROPs для обычных и растянутых кластеров vSAN
Поддержка режима Mixed MTU для растянутых кластеров
Обновленные средства для сайзинга инфраструктуры
Улучшенные функции Health Check
Улучшенная диагностика для персонала поддержки VMware GSS
Обновить VMware vCenter Server Appliance 6.7 на Update 1 можно через интерфейс VAMI (vCenter Appliance Management Interface, он же Appliance Management User Interface или MUI):
Ну и, конечно же, скоро будет много интересных статей про отдельные фичи. Не забывайте наведываться.
Когда мы писали о новых возможностях платформы VMware vSphere 6.5 два года назад, мы упомянули о новой возможности резервного копирования и восстановления сервисов vCenter на уровне файлов. Сегодня мы расскажем о функциональности VMware vCenter File-Based Backup and Restore несколько подробнее.
Этот механизм доступен через интерфейс VMware Appliance Management Interface (VAMI), работа с которым происходит по порту 5480. Бэкапить можно как сам сервер vCSA, так и службы Platform Services Controller (PSC). При этом во время бэкапа не потребуется никаких дополнительных процедур - ни установки агентов, ни "подмораживания" служб vCenter на время работы резервного копирования.
В качестве канала для бэкапа может быть использован один из протоколов: FTP(s), HTTP(s) или SCP. По ним передаются все файлы, составляющие сервисы vCenter, включая файлы базы данных. Во время восстановления vCSA или PSC вам потребуется только монтирование ISO-образа vCSA.
Процесс восстановления подразумевает развертывание нового ISO-образа vCSA с сохранением прошлых параметров идентификации (UUID и прочее). После развертывания образа происходит накат забэкапленных файлов.
В VMware vSphere 6.7 сервисы резервного копирования и восстановления vCenter были существенно улучшены. Во-первых, для этой задачи появился отдельный раздел Backup. Во-вторых, появилась опция запланированного бэкапа, которая очень удобна:
В качестве места назначения резервных копий используется адрес:
При этом вам не нужно создавать папки Backup Folder (по умолчанию это "vCenter") и Subfolder (по умолчанию это VCSA FQDN) - они будут созданы автоматически.
В третьих, обратите также внимание на новую опцию Number of backups to retain - она позволит хранить несколько бэкапов. После создания расписания резервного копирования его можно изменять в любой момент:
Обратите внимание, что внизу приведен список выполненных задач и их статусы.
Также в версии vCSA 6.7 появился браузер файлов резервного копирования, поэтому теперь нет необходимости знать все пути к бэкапам. Кстати, обратите внимание на первую букву в названии бэкапа (S - значит scheduled, то есть запланированный, а M - manual, сделанный вручную).
При восстановлении сервера vCSA вам понадобятся данные учетной записи vSphere SSO. Если у вас несколько внешних серверов PSC, то в этом случае не поддерживается восстановление узла PSC при доступности остальных партнеров. Надо вывести этот узел из эксплуатации с помощью команды cmsso-util unregister и развернуть новый узел PSC, синхронизировав его с партнерами. В этом и будет суть восстановления узла PSC.
Также для целей обучения у VMware есть свои Walkthrough, которые очень полезно пройти, чтобы увидеть процесс резервного копирования и восстановления vCenter в деталях:
Напомним, что VMFS-6 впервые появилась в VMware vSphere 6.5 и с тех пор сильно не изменялась, но если посмотреть на отличия шестой версии от пятой, то они весьма существенные:
Как мы видим, основных отличий четыре:
Доступ к хостам ESXi 6.0 и более ранних к VMFS-6 уже невозможен.
Последний пункт как раз и стал причиной того, что произошло изменение в структуре метаданных томов, а значит VMFS-5 нельзя проапгрейдить до VMFS-6. Альтернативой является создание нового датастора VMFS-6, перемещение туда всех виртуальных машин и удаление старого.
Создаем новый VMFS-6:
Перемещаем туда все виртуальные машины тома VMFS-5 через Storage vMotion или Cold migration и удаляем его:
Как стало понятно, для такого "апгрейда" датастора VMFS-5 вам потребуется еще столько же места на другом датасторе или готовом к форматированию под VMFS-6 хранилище, чтобы переместить туда виртуальные машины.
Чтобы посмотреть текущие версии VMFS с помощью PowerCLI, нужно выполнить команду:
Get-Datastore | Select Name, FileSystemVersion | Sort Name
Перед началом процесса апгрейда нужно ознакомиться со статьей KB "Migrating VMFS 5 datastore to VMFS 6 datastore". Для миграции надо использовать командлет Update-VmfsDatastore, который также делает некоторые проверки перед миграцией.
При этом надо учитывать несколько моментов:
На время миграции нужен датастор VMFS-5 такой же или большей свободной емкости.
Машины перемещаются средствами Storage vMotion на временное хранилище.
Командлет убеждается, что на датасторе не осталось ВМ, миграция которых не поддерживается (это машины с поддержкой SRM, VADP, VRM и Clustering).
Командлет временно отключает механизм Storage DRS при своей работе (и включает по окончании). Если сценарий во время исполнения упадет, то вам придется включать Storage DRS вручную.
Нужно внимательно изучить использование параметров Resume и Rollback в случае появления ошибок.
Посмотрим, какие последовательные действия делает сценарий:
Проверяет наличие ВМ с поддержкой VADP, SMPFT, MSCS/RAC на исходном датасторе.
Убеждается, что датастор доступен со всех хостов.
Валидирует, что временный датастор имеет достаточно емкости для размещения виртуальных машин.
Устанавливает функцию Storage DRS Automation в режим manual.
Размонтирует исходный датастор.
Удаляет старый датастор и создает на его месте новый датастор VMFS-6.
Перемещает ВМ и другие данные со временного датастора на новый.
Восстанавливает настройку Storage DRS Automation.
Теперь, собственно, как использовать командлет Update-VmfsDatastore:
Если у вас что-то пошло не так, вы сможете использовать параметр rollback для отката, а также если возникают ошибки, то после их исправления можно использовать параметр resume.
Больше об использовании командлета Update-VmfsDatastore написано вот тут.
Информация этой заметки не покажется многим из вас новой, но для некоторых может оказаться полезной. Как вы знаете, управляющий компонент VMware vCenter Server сейчас поставляется в двух изданиях vCenter Server, устанавливаемый на платформе Windows, и vCenter Server Appliance (vCSA), представляющий собой готовую к использованию виртуальную машину с сервисами vCenter.
Напомним, что развертывание vCSA уже является опцией по умолчанию, а vCenter для Windows уже не будет присутствовать в следующих версиях VMware vSphere после 6.7.
На данный момент есть 3 издания VMware vCenter:
1. VMware vCenter Essentials
Это издание vCenter недоступно к отдельному заказу. Оно входит в состав изданий vSphere Essentials и vSphere Essentials Plus, которые допускают управление не более чем тремя хостами ESXi (в каждом не более двух физических CPU). Помимо данного ограничения, vCenter Essentials не имеет поддержки таких функций как (детальнее о них - далее):
Enhanced Linked Mode (ELM)
vCenter Server High Availability (VCHA)
vCenter Server File-Based Backup and Restore
vCenter Server Migration Tool
vRealize Orchestrator
vCenter Essentials в составе издания Essentials Plus можно проапгрейдить на vCenter Standard в составе пакета vSphere with Operations Management Acceleration Kit для одного из более высших изданий:
2. VMware vCenter Foundation
Это издание vCenter также не содержит в себе пять перечисленных выше фичей, но позволяет управлять не тремя, а уже четырьмя хостами ESXi с любым числом физических процессоров на борту (ранее число хостов было равно трем, но, начиная с vSphere 6.5 Update 1, его увеличили до четырех). Его можно купить отдельно от лицензий на хосты VMware vSphere / ESXi.
Одна лицензия vCenter Foundation также позволяет создать растянутый кластер из двух площадок, на каждой из которых есть по два хоста ESXi (суммарно под управлением vCenter там находится 4 хоста и Witness VM).
3. VMware vCenter Standard
Это, несмотря на название, самое максимальное издание vCenter. Оно не ограничивает никакую функциональность, то есть в нем доступно управление аж до 2000 хостами ESXi. Здесь вам будут доступны возможности объединения нескольких управляющих серверов Enhanced Linked Mode (ELM), но для каждого из серверов vCenter нужна, само собой, отдельная лицензия Standard.
Также вы сможете производить резервное копирование на уровне файлов (File-Based Backup and Restore) и обеспечивать высокую доступность сервисов vCenter (VCHA) - при этом для нее не нужна дополнительная лицензия на резервный vCenter, хватит одной:
Помимо этого, пользователи vCenter Standard могут применять vCenter Server Migration Tool для миграции с сервисов vCenter для Windows на платформу vCSA. Ну и можно использовать vRealize Orchestrator, который очень пригодится для автоматизации операций в больших инфраструктурах.
Многие из вас пользуются лабораторными работами VMware Hands-on Labs, которые позволяют освоить работу с различными продуктами и технологиями, проходя по шагам интерфейса. Но это подходит только для целей обучения работе в интерфейсе этих решений, а если хочется полноценно запустить какой-нибудь продукт (например, vSAN, NSX или PKS) в реальных условиях и посмотреть на его производительность - то для этого есть портал VMware TestDrive, о котором недавно написал Дункан Эппинг.
Преимущество данного сервиса в том, что инфраструктура в нем построена на базе референсной архитектуры VMware, на сертифицированном оборудовании, а среда настроена таким образом, что позволяет оценить реальную нагрузку на аппаратные компоненты (сеть, хранилища, процессор/память).
TestDrive работает в облаке Softlayer от IBM и доступен во всех глобальных регионах по миру (US, EMEA, APJ). При этом, работая с инфраструктурой, вы можете делать множество интересных вещей под аккаунтом SuperUser, свободу сильно не ограничивают, за исключением удаления объектов. VMware говорит, что TestDrive в этом году использовали уже 344 тысячи раз.
По окончании тестирования партнер VMware может посмотреть его результаты и обсудить их с клиентом:
Чтобы партнерам VMware использовать данный сервис, им нужна компетенция VTSP HCI, после чего TestDrive будет доступен через Partner Central. Для начала получения компетенции зайдите в Partner University и подпишитесь на аккредитацию Hyper-Converged Infrastructure accreditation:
Одно из самых интересных на портале - возможность тестирования кластеров хранилищ vSAN (на данный момент это vSAN 6.7, но скоро окружение будет обновлено до vSAN 6.7 Update 1). Там доступно управление виртуальной инфраструктурой десктопов Horizon и машинами, а также есть доступ к средству тестирования нагрузки HCIBench. С помощью решений vSAN Health and Performance Service и vROPs можно замерять задержки (latency) и число операций ввода-вывода в секунду (IOPS) в различных условиях эксплуатации виртуальных машин:
Надо понимать, что в качестве аппаратной среды используется All-Flash конфигурация хостов, поэтому все работает довольно шустро.
Для доступа к сервису нужно попросить его у своего поставщика, являющегося партнером VMware, который должен зарегистрироваться на портале vmtestdrive.com.
Бонус для дочитавших до этого места! Дункан выбил возможность всем желающим использовать VMware TestDrive в течение 30 дней, для этого надо зарегистрироваться с промо-кодом DUNCANYB или использовать вот эту ссылку.
Сотрудники компании VMware написали интересную серию статей об обновлении VMware vSphere, где одной из самых интересных оказалась статья про обновление VMware Tools через PowerCLI. Одновременно там рассматриваются и вопросы обновления виртуального железа ВМ.
Давайте посмотрим, как правильно выполнять эту процедуру. Прежде всего, помните: сначала надо обновить VMware Tools во всех ВМ и только после этого обновлять VM Hardware, а не наоборот!
Итак, давайте пройдем процедуру апгрейда VMware Tools с помощью фреймворка PowerCLI.
1. Если вы посмотрите в интерфейс vSphere Client, то увидите, что на вкладке Summary написана текущая версия VMware Tools а также приведена информация о том, нужен ли их апгрейд.
2. Чтобы увидеть, какие машины нуждаются в апгрейде, а какие имеют последние версии VMware Tools, нужно выполнить команду:
Неудобство здесь в том, что обновление VMware Tools на всех машинах происходит в одно время. Поэтому нужно загнать процесс в цикл, где в один момент будет обрабатываться одна машина:
ForEach ($VM in $OutOfDateVMs){Update-Tools -NoReboot -VM $VM.Name -Verbose}
Более подробную информацию об обновлении VMware Tools через PowerCLI можно получить здесь.
4. Также в настройках виртуальной машины можно поставить галку "Check and upgrade VMware Tools before each power on", которая позволит проверять обновления тулзов и накатывать их при каждой загрузке ВМ:
Запустим команду из п.5, чтобы убедиться, что настройка автоматического обновления выставлена:
7. Теперь настало время обновить VM Compatibility, то есть виртуальное аппаратное обеспечение виртуальной машины (Virtual Hardware). Для этого сначала проверим текущие его версии на всех виртуальных машинах командой:
Get-folder Testing | Get-VM | Select Name, Version | Sort Name
Помните, что апгрейд Virtual Hardware процедура очень ответственная, например, 14-я версия железа совместима только с vSphere 6.7. И перед каждым обновлением VM Hardware делайте снапшот виртуальной машины (он сохраняет конфигурацию виртуального железа), чтобы откатиться к тему в случае проблем гостевой ОС с новым виртуальным железом.
8. Для обновления Virtual Hardware, например, на машине VM08 используйте вот такой скрипт:
Это можно проделать только для выключенной виртуальной машины, и тут не бывает настройки автоматического обновления, так как это процедура ответственная и довольно редкая. Больше о функциях VM Compatibility вы можете прочитать здесь.
RSS
