вторник, 24 июля 2018 г.

Парсер для правил NSX Distributed Firewall

Update 05.08.2018: в новой версии появилась возможность подключения к NSX Manager для экспорта текущих правил.

VMware NSX позволяет экспортировать правила распределенного фаерволла в файл в XML формате. Данный формат не очень удобен для анализа и включения в документацию, поэтому я написал небольшой парсер, конвертирующий правила из XML формата в HTML или CSV.

Скрипт имеет следующий формат:
Parse-NSXRules.ps1 -FilePath <string> -ResultPath <string> [-Property <string>] [-Format <string>]

и использует следующие параметры:
  • -ResultPath <string> - (обязательный) Указывает путь к файлу, в котором будут сохранены результаты.
  • -FilePath <string> - (опциональный) Указывает путь к XML файлу с правилами.
  • -Property <string> - (опциональный) Указывает перечень столбцов для отображения, разделенных запятыми. По умолчанию отображает все столбцы.
  • -Format <string> - (опциональный) Указывает формат итогового файла. Поддерживает CSV, HTML или XML. По умолчанию используется HTML формат.
  • -NSXManager <string> - (опциональный) Указывает IP адрес или DNS имя сервера NSX Manager для подключения.
  • -Username <string> - (опциональный) Указывает имя пользователя для подключения к NSX Manager.
  • -Password <string> - (опциональный) Указывает пароль пользователя для подключения к NSX Manager.
Примеры использования скрипта:

#Сохранить результат в HTML файле
.\Parse-NSXRules.ps1 -FilePath C:\Temp\NSX_rules.xml -Format HTML -ResultPath C:\Temp\parsed_rules.html

#Сохранить результат в CSV, отобразить только столбцы id,name,source и action
.\Parse-NSXRules.ps1 -FilePath C:\Temp\NSX_rules.xml -Format CSV -ResultPath C:\Temp\parsed_rules.csv -Property "id,name,source,action"

#Подключиться к NSX Manager и сохранить результат в формате XML
\parse-nsxrules.ps1 -Format XML -ResultPath C:\Temp\parsed_rules.csv -NSXManager 192.168.1.10 -Username admin -Password VMware1!

Пример получаемого HTML файла:

Загрузить скрипт можно по ссылке: https://github.com/omnimod/NSX-Firewall-Rules-Parser

вторник, 19 июня 2018 г.

Немного о дизайне VDI. Часть 7. Виртуальные машины

Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам.
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI

7.1 Служебные виртуальные машины

К служебным ВМ относятся серверы, обеспечивающие работу VDI инфраструктуры: vCenter Server, View Connection Server, Unified Access Gateway, View Composer и пр.

В официальной документации VMware приводится информация к требуемым аппаратным ресурсам и перечень совместимых ОС и СУБД для каждого компонента VDI инфраструктуры. Зачастую служебные ВМ поставляются производителем в виде готовых виртуальных апплайнсов с заранее определенной аппаратной конфигурацией.

суббота, 16 июня 2018 г.

Ошибка 1603 при установке Horizon View Composer 7.x

При установке VMware View Composer 7.x на Windows Server 2012 или 2016 может возникать ошибка с кодом 1603.

В журнале vmmsi.log в папке %ProgramData%\VMware\logs\ отображаются сообщения вида:

CustomAction InstallVstor2Driver.5ACA97E0_7C64_4970_A763_840E81DAAF0B returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)
Action ended 20:34:47: InstallFinalize. Return value 3.

Данная ошибка возникает, если ВМ использует EFI, и настроена загрузка с использованием Secure Boot. Отключить Secure Boot можно в свойствах ВМ: VM Options -> Boot Options -> Secure Boot.

После этого установка Composer должна пройти нормально.

понедельник, 11 июня 2018 г.

Проблемы с подготовкой Linked Clone ВМ Windows 10 при использовании SysPrep

Недавно наткнулся на старый/новый баг Horizon 7.x в работе механизма кастомизации Linked Clone ВМ с гостевой ОС Windows 10 при использовании SysPrep.

В интерфейсе Horizon Administrator ВМ застревает в статусе Customizing. Сама ВМ в ходе кастомизации меняет имя, однако не вводится в целевой домен, оставаясь в рабочей группе. При этом создание Linked Clone ВМ через QuickPrep или Full Clone ВМ, а также Customization Specification из vCenter Server работают корректно.

Это происходит если в мастер образе, из которого создается ВМ, присутствует виртуальный CD-привод, которому назначена буква D. При первой загрузке новой ВМ Disposable диску назначается буква, которая изменяется при следующей загрузке. На данном диске располагается исполняемый файл для запуска кастомизации и вводу ОС в домен, однако из-за смены буквы диска путь к файлу изменяется.

Для решения данной проблемы можно воспользоваться одним из следующих методов.

Заранее изменить букву CD-привода в мастер образе, например, на F.

В настройках пула явно указать букву для Disposable диска (Disposable disk drive letter) и пересоздать Linked Clone ВМ.

Аналогичная проблема встречалась для Windows 7 еще в View 4.x, однако, я не припомню, чтобы сталкивался с ней в Horizon 6.x: https://kb.vmware.com/s/article/2006967

вторник, 22 мая 2018 г.

Немного о дизайне VDI. Часть 8. Подсистема хранения

Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам.
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI

8.1 Масштабирование СХД

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