История о подключении FC Tape Library к VMware ESXi

Внимание: перед тем, как выполнять рекомендации, приведенные в статье, прочтите данное сообщение. Проброс ленточной библиотеки внутрь виртуальных машин НЕ поддерживается VMware и НЕ является приемлемым решением для организации резервного копирования виртуальной среды. Я настоятельно рекомендую рассмотреть альтернативные варианты решения задачи, например, установить FC HBA адаптер в любой доступный физический сервер и подключить к нему ленточную библиотеку. Это избавит вас от множества проблем, связанных с настройкой проброса библиотеки внутрь ВМ и дальнейшей эксплуатацией данного решения. В особенности, когда вам потребуется что-то восстановить из резервной копии.

Обновление: начиная с vSphere 5.0, VMware перестала поддерживать подключение ленточных приводов (библиотек) к хостам ESXi в том числе по SAS/SCSI интерфейсу (https://www.vmware.com/support/vsphere5/doc/vsphere-esx-vcenter-server-50-release-notes.html): 
Tape drives. VMware does not support tape drives that are connected to ESX/ESXi hosts. For additional information, see Knowledge Base article 1016407.

Недавно у одного из заказчиков появилась необходимость подключить ленточную библиотеку HP StorageWorks MSL2024 G3 к серверу резервного копирования, расположенному внутри виртуальной машины, работающей под управлением VMware ESXi 4.1.

До этого момента я несколько раз встречал сообщения о возможных проблемах при использовании ленточных библиотек в виртуальной среде, но руководство Fibre Channel SAN Configuration Guide окончательно развеяло мои сомнения:

"ESX/ESXi does not support FC connected tape devices"

Памятуя о том, что "unsupported" далеко не всегда равняется "not working", и учитывая, что библиотека уже была приобретена заказчиком, было принято решение попробовать ее подключить.

Небольшое отступление - не то, чтобы я был ярым противником использования не поддерживаемых решений, но уже не раз убеждался, что соблюдение требований вендоров позволяет избежать большого числа проблем при настройке и дальнейшей эксплуатации системы. Вдобавок, для резервного копирования виртуальной среды гораздо более эффективно использование специализированных решений, вроде VMware Data Recovery или Veeam Backup & Replication, которые не работают с ленточными библиотеками.

Библиотека была смонтирована, подключена к FC свитчу и настроена, в консоли vSphere Client сделан Rescan устройств хранения, после чего было обнаружено одно устройство - стример, автозагрузчик куда-то пропал.

Вкладка Paths немного прояснила ситуацию.

Оба пути, по которым ESXi должен был получить доступ к автозагрузчику, показывались как мертвые (Dead). Проверка коммутации библиотеки b серверов, настроек зон на FC свитче результатов не принесла.

В Интернете удалось найти несколько похожих проблем и определить причину такого поведения. Все дело в некорректной работе ESXi с некоторыми FC устройствами в режиме ALUA (Asymmetric Logical Unit Access). Убедиться в этом можно, открыв журнал событий ESXi (/var/log/messages):

Запуск команды esxcli nmp satp listrules -s VMW_SATP_ALUA позволил получить список всех правил, настроенных на сервере по умолчанию:

В качестве решения проблемы предлагалось удалить лишнее правило, что и было сделано с помощью команды:
esxcli nmp satp deleterule --satp VMW_SATP_ALUA --claim-option tpgs_on

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

Затем оба устройства (стриммер и автозагрузчик) были добавлены в выбранную виртуальную машину. Для этого в свойствах ВМ нужно нажать кнопку Add... и в открывшемся окне в качестве типа устройства выбрать SCSI Device и нужное устройство.

Happy End.

Работаем с XenDesktop 5

Недавно очередная, на этот раз уже пятая, версия Citrix XenDesktop показала всем свое новое "лицо".

Программисты Citrix'а сжалились над простыми смертными вроде нас с вами и полностью переработали интерфейс продукта, сделав его более удобным и дружелюбным. Эту работу трудно переоценить, вспоминая то множество оснасток, которыми приходилось ранее управлять в XenDesktop 4 и до сих пор приходится - в XenApp.

Одно из основных нововведений - централизованная консоль управления Citrix Desktop Studio с помощью которой можно назначать виртуальные рабочие станции пользователям, настраивать пользовательские и компьютерные политики, управлять веб-сайтами Citrix.


Для рядовых администраторов и сотрудников технической поддержки пригодится Desktop Director, позволяющий наблюдать за инфраструктурой XenDesktop и выполнять базовые операции с рабочими станциями через веб-браузер.


Каким образом эти нововведения затронули процедуру установки и настройки?

В качестве примера рассмотрим самый простой вариант развертывания VDI инфраструктуры, включающий в себя сервер XenDesktop, рабочую станцию и клиентский компьютер, с которого будет осуществляться подключение. В качестве рабочей станции можно использовать выделенный физический компьютер или виртуальную машину, работающую под управлением любого доступного гипервизора (Citrix XenServer, Microsoft Hyper-V или VMware ESX). В данном примере не предполагается выполнять интеграцию XenDesktop с подсистемой виртуализации для автоматизации развертывания и управления виртуальными машинами, поэтому каждую рабочую станцию, добавляемую в XenDesktop придется устанавливать и настраивать отдельно. Пример схемы развертывания приведен на рисунке.

В качестве ОС, устанавливаемой на серверы, рекомендуется использовать Windows Server 2008 R2, а в качестве клиентской ОС - Windows 7.

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

Для установки XenDesktop вам понадобится дистрибутив, который можно загрузить с сайта Citrix после прохождения регистрации. В моем случае использовалась Evaluation версия, включающая в себя все необходимые компоненты.

Установка и настройка сервера XenDesktop
Распакуйте XD5_Plat_Single.zip и подмонтируйте образ XenDesktop5.iso к серверу. Запустите установщик и выберите Install XenDesktop.


Примите лицензионное соглашения, выбрав I accept terms and conditions и нажмите Next.


На странице выбора компонентов (Select Components to Install) убедитесь, что выбраны все компоненты и нажмите Next.


На странице Firewall Configuration нажмите Next.

На странице Summary нажмите Install.

Дождитесь окончания установки. На странице Installation Successful убедитесь, что Configure XenDesktop after closing выбрано и нажмите Close.


В открывшейся консоли Citrix Desktop Studio выберите выберите вариант Advanced Configuration.


Укажите имя сайта (Site), путь к файлу лицензий (License file location) и редакцию (Edition). Проверьте, что выбран вариант использования сервер баз данных по умолчанию (Use default database). Нажмите Next.


При добавлении первого сервера система сама предложит создать и настроить подключение к базе. Нажмите OK.


На вкладке Host укажите тип хоста (Host type) - None, нажмите Next.


На вкладке Summary нажмите Finish.


Дождитесь, пока система завершит настройку.

Настройка рабочих станций
Установите Citrix XenDesktop Agent на виртуальной машине или рабочей станции, к которой удаленно будет подключаться пользователь. Запустите установщик, нажмите Install Virtual Desktop Agent.


Выберите вариант Advanced Install.


Если для видеокарты используется WDDM драйвер, то при установке на физический компьютер или виртуальную машину VMware ESX, вы получите сообщение с предложением отключить данный драйвер. Согласитесь, нажав Yes, так как если этого не сделать, то драйвер Citrix System Inc. Display Driver не сможет работать (подробнее об проблеме можно прочитать тут).


На странице Select Components to Install снимите Support for XenApp Application Delivery и нажмите Next.

На странице Controller Location в поле Manually enter controller location(s) введите имя сервера, на котором установлены службы XenDesktop. Нажмите Next.


На странице Virtual Desktop Configuration нажмите Next.


На странице Summary нажмите Install.


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

Откройте консоль Citrix Desktop Studio на сервере, щелкните правой кнопкой мыши по Machines и выберите Create Catalog.


В мастере Create Catalog на странице Machine Type выберите Physical и нажмите Next.


На странице Machines & users с помощью кнопки Add Computers... добавьте из Active Directory учетную запись рабочей станции, которую вы настроили ранее.


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


На странице Administrators нажмите Next.


На странице Summary задайте имя создаваемого каталога (Catalog name) и нажмите Finish для завершения настройки.


Теперь требуется назначить пользователям рабочие станции.

Щелкните правой кнопкой мыши по Assigments и выберите Create Desktop Group.

В мастере Create Desktop Group на странице Catalog выберите ранее созданный каталог, в поле Add machines введите количество машин, которое требуется назначить. Нажмите Next.


На странице Users с помощью кнопки Add... добавьте из Active Directory группы или пользователей, которым следует разрешить подключаться к удаленным рабочим станциям, и нажмите Next.


На странице Delegation нажмите Next.

На странице Summary введите имя, которое будут видеть пользователи при подключении (Display name) и имя группы (Desktop Group name) и нажмите Finish.


Проверка работы XenDesktop
На клиентской машине откройте браузер. В адресной строке впишите имя сервера XenDesktop. При первом входе на сайт вам предложат установить плагин Citrix Online Plugin Web.


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


Если вы все сделали правильно, то вам будет доступен удаленный рабочий стол.


Поздравляю с успешной настройкой.

Решение проблемы The View Connection Server connection failed. Network error

В определенных ситуациях при подключении к серверу VMware View Connection Server, например версии 4.5, с помощью клиента VMware View Client, установленного в Windows Vista/7, вы можете получать ошибку следующего содержания:


The View Connection Server connection failed. Network error. Contact your network administrator.

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

Просмотр журнала "debug-<date>.txt", который располагается в "%userprofile%\AppData\Local\VMware\VDM\logs", позволяет получить более детальное сообщение об ошибке:

DEBUG [wswc_http] WININET ErrorCode = 12057

Поиск по номеру ошибки в Интернете приводит к статьям, описывающим проблемы со списками отзывов сертификатов (CRL). Проверить это предположение можно, отключив проверку CRL в свойствах настроек Интернет: Start -> Control Panel -> Internet Options -> Advanced -> Check for server certificate revocation.

Так и есть! Теперь клиент нормально подключается.

Но что могло послужить причиной? Посмотрим на сертификат, который используется в VMware View Connection Server.

Так и есть. Список отзыва сертификатов содержит лишь LDAP путь (т.к. Центр Выдачи Сертификатов был установлен с настройками по умолчанию), который не может использоваться для проверки компьютерами, не входящими в домен.

Публикация дополнительных путей, доступных клиентам (например, http:// или file://), и повторная выдача сертификата серверу View позволит решить проблему.

P.S. а проверку CRL на клиенте лучше включить обратно. :-)

Различия VMware vShield Zones и vShield App 4.1 update 1

Если попытаться коротко описать vShield App, то это ни что иное, как более продвинутая (и более дорогая) версия vShield Zones.

Основное назначение vShield Zones и vShield App заключается в возможности создавать правила, которые фильтруют IPv4 пакеты (IPv6 не фильтруется) от виртуальных машин и к виртуальным машинам, подпадающие под определенные правила (совпадение адреса отправителя, адреса получателя, порта и используемого протокола). Какие функции становятся доступными при переходе на vShield App? Давайте посмотрим.

Лицензия на право использования vShield Zones входит в редакции vSphere Advanced, Enterprise или Enterprise Plus; vShield App лицензируется отдельно по количеству защищаемых виртуальных машин.

Обновление с vShield Zones до vShield App производится путем добавления соответствующей лицензии в vCenter Server и не требует установки дополнительных компонентов.

По сравнению с предыдущими версиями vShield Zones, процедура установки в 4.1 существенно упростилась. Больше не требуется загружать и добавлять в vCenter отдельную виртуальную оснастку (appliance) vShield Zones. Вся процедура установки и настройки выполняется из консоли виртуальной машины vShield Manager, которая содержит в себе необходимые компоненты.

Кроме того, больше нет разделения групп портов и виртуальных коммутаторов на незащищенные (Unprotected), подключенные к физическим сетевым адаптерам, и защищенные (Protected), подключенные к виртуальным машинам. После установки агента vShield Zones на сервер ESX правила фильтрации начинают действовать на все виртуальные машины независимо от их расположения.

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

Пакеты анализируются vShield Zones/App в соответствии с существующей таблицей и при нахождении первого подходящего правила отбрасываются или доходят до получателя. Порядок просмотра правил следующий:

• правила для датацентра с высоким приоритетом;
• правила для кластера;
• правила для группы портов;
• правила для датацентра с низким приоритетом;
• правила по умолчанию.

Для vShield Zones при редактировании правила администратор может задавать в качестве адреса отправителя и получателя только определенный IP адрес или подсеть.

В vShield App возможности по созданию правил расширены - в качестве источника или назначения трафика можно указывать виртуальные машины, расположенные в определенном датацентре, кластере, группе портов, VLAN'е; либо, наоборот, все виртуальные машины, которые НЕ находятся внутри датацентра, кластера, группы портов.

Администратор также может создавать свои собственные группы безопасности (Security Groups) и включать в них выбранные виртуальные сетевые адаптеры.

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

Средство просмотра графиков и отчетов по типу трафика (VM Flow) было переименовано в Flow Monitoring и перекочевало из vShield Zones в vShield App, что крайне огорчает, т.к. никаких других нововведений замечено не было.

Администратор все также может добавить описание для протоколов (Port Mapping), неизвестных vShield App, для более наглядного их отображения в отчетах и при создании правил.

Наконец, начиная с версии 4.1 Update 1, в vShield App появилась функция SpoofGuard, которая позволяет избежать подмены IP адресов в виртуальных машинах. При включении SpoofGuard
для каждой виртуальной сетевой карты ставится в соответствие один определенный IP адрес (администратор может подтвердить корректность IP адреса вручную или автоматически при первом назначении), в случае изменения IP адреса система заблокирует отправку и прием пакетов на данную сетевую карту до тех пор, пока администратор не подтвердит корректность новых настроек в vShield App.