вторник, 16 февраля 2016 г.

Миграция с VMware Embedded PSC на External PSC на Windows Server

Начиная с версии vSphere 6.0 U1, стала поддерживаться миграция vCenter Server со встроенного Platform Services Controller на внешний PSC.

Разнесение PSC и vCenter между серверами может потребоваться в больших виртуальных средах, если вы планируете настроить балансировку служб PSC, использовать несколько серверов vCenter, объединенных в Enhanced Linked Mode, или создать отказоустойчивый кластер vCenter Server.

Краткие шаги по миграции:
  1. Если включен брандмауэр Windows, откройте порты 88, 389, 636, 2012,2014, 2020, 7080, 7081, 11711, 11712 на сервере vCenter с установленным PSC. Иногда при перезагрузке сервера может возникать ситуация, когда службы PSC не прослушивают порт 2020, в этом случае помогает перезапуск службы VMware afd Service.
  2. Установите External PSC на отдельный сервер, подключив к тому же домену (по умолчанию, vsphere.local), и указав тот же сайт, что был задан при установке Embedded PSC. Узнать имя сайта можно, выполнив следующую команду на сервере vCenter:
    "C:\Program Files\VMware\vCenter Server\python\python.exe" "C:\Program Files\VMware\vCenter Server\VMware Identity Services\lstool\scripts\lstool.py" get-site-id --url https://psc_node_fqdn/lookupservice/sdk
    Если в процессе установки возникает ошибка "failed to run vdcpromo", то, скорее всего, вы не открыли какой-то из портов. В этом случае проверьте их при помощи Telnet с какого-нибудь компьютера из локальной сети.
  3. Перенастройте vCenter Server на использование нового PSC: http://pubs.vmware.com/vsphere-60/index.jsp?topic=%2Fcom.vmware.vsphere.install.doc%2FGUID-E7DFB362-1875-4BCF-AB84-4F21408F87A6.html
  4. Удалите записи о старом PSC, чтобы исправить ошибку в Perfcharts: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2131327
  5. Удалите старые корневые сертификаты на сервере vCenter: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2133028
  6. Замените Machine и User сертификаты на vCenter Server: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2112279
  7. и http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2112281
  8. Поправьте сертификаты: http://kb.vmware.com/selfservice/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=2121701
  9. Перезагрузите сервер vCenter Server.


пятница, 12 февраля 2016 г.

Использование силосов для хранения индивидуальных настроек VMware User Environment Manager

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

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

С одной стороны, пользователь хочет использовать один профиль и иметь идентичные настройки ОС и приложений на каждом компьютере.

С другой стороны, должны использоваться разные профили, например, для терминальной фермы Citrix - один профиль, для виртуальной рабочей станции VDI - второй, для локального компьютера или ноутбука - третий. Необходимость использования нескольких профилей может быть вызвана разными причинами - различиями в версии или разрядности ОС, отличия в конфигурации приложений (разные места установки и расположения конфигурационных файлов на разных компьютерах), отличиями в аппаратной конфигурации компьютеров (разное разрешение мониторов, многомониторные конфигурации). Ну и, пожалуй, главная причина - одновременное изменение настроек одного профиля с нескольких компьютеров приводит, порой, к весьма неожиданным результатам.

Настройка нескольких хранилищ для профилей, например, при использовании стандартных перемещаемых профилей Windows или профилей VMware Persona Management, хоть и решает данную проблему, но, во-первых, приводит к необходимости выделять на файловом сервере дисковое пространство под каждый новый профиль, во-вторых, поскольку профили никак не синхронизируются между собой, потребует от пользователя выполнять одни и те же настройки несколько раз.

Для решения этой проблемы в VMware UEM существует механизм силосов (silo). Вы можете создать несколько силосов, по одному на каждый тип профиля, задать в каждом из силосов нужные настройки приложений и ОС, и для каждой группы серверов или рабочих станций указать путь к своему силосу.

Для начала требуется включить поддержку силосов (Silo support) в окне Settings в консоли UEM Management Console.

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

Каждый силос представляет собой каталог на файловом сервере, где располагается конфигурация UEM, например, \\fileserver\UEMConfig\silos\termfarm1 и т.д.

Настройки силоса выполняются через групповую политику Silo-specific Flex config files. В политике есть две настройки:
Central location of silo-specific Flex config files - указывает путь к каталогу, где хранятся конфигурационные файлы (Flex configuration file) силоса.
Silo-specific suffix - (опциональная настройка) имя дочернего каталога, где будет храниться архив профиля пользователя (UEM profile archive) для данного силоса. Если суффикс не указан, то в качестве имени дочернего каталога будет использоваться имя силоса.

Поскольку эта политика относится к пользовательской части GPO, то для ее применения на компьютеры потребуется использовать group policy loopback processing mode (о том, что это такое, можно почитать по ссылке: https://technet.microsoft.com/en-us/library/cc978513.aspx).

Настройка силоса выглядят следующим образом:
  1. Создайте в консоли UEM Management Console новый силос.
  2. Создайте в Active Directory новое организационное подразделение, например, termfarm1.
  3. Поместите в OU компьютеры, для которых потребуется указать настройки силоса.
  4. Создайте новый объект групповой политике и включите настройку Configure user Group Policy loopback processing mode в режиме Merge.
  5. В этой же политике укажите путь к силосу Central location of silo-specific Flex config files.
  6. Примените групповую политику к созданному OU.
  7. Повторите шаги для другой группы компьютеров.
Теперь вы можете создавать конфигурации для приложений и ОС по аналогии с каталогом General.

При работе с силосами важно помнить следующие нюансы.

В плане настройки силосы ничем не отличаются от каталога General, где, по умолчанию, создаются конфигурационные файлы приложений и ОС.

В силосах хранятся только настройки UEM в части Personalization (настройки приложений и ОС), в силосах нельзя задавать настройки User Environment (подключения сетевых дисков, принтеров, задания переменных окружения и т.д.) и Application Migration (перенос настроек между приложениями).

Если вы создаете конфигурационный файл для одного и того же приложения (настройки ОС) и в каталоге General, и в силосе, то FlexEngine агент будет обрабатывать оба файла. Если в конфигурационных файлах задаются предопределенные настройки для одних и тех же файлов, папок или веток реестра, то после импорта на рабочую станцию настройки из силоса будут иметь приоритет ("перезапишут" настройки из конф.файла General каталога).

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

Для того чтобы рассмотреть, как настройки силоса сочетаются с архивами профиля пользователя, рассмотрим небольшой пример. Пусть ключ реестра HKCU\software\application\key определяется в predefined параметрах на уровне каталога general, в конфигурации силоса, а также сохранен в основном архиве профиля пользователя, а также архиве профиля пользователя на уровне силоса.
  1. Каталог general: key = A
  2. Архив профиля: key = B
  3. Конфигурация силоса: key = C
  4. Архив профиля в силосе: key = D
При входе пользователя в систему (или запуске приложения, если включен Flex Direct) значение параметра key в реестре будет равно D. Если разрешен экспорт настроек в архив профиля пользователя и на уровне каталога General, и на уровне силоса, то после выхода пользователя из системы (или закрытия приложения) значение key станет равным:
  1. Каталог general: key = A
  2. Архив профиля: key = D
  3. Конфигурация силоса: key = C
  4. Архив профиля в силосе: key = D
Из этого следует один важный момент, если вам требуется, чтобы для двух разных компьютеров (например, VDI и терминальном сервере) в профиле пользователя сохранялись разные настройки и не перезаписывали друг друга, то вам потребуется создать два силоса, в каждом из которых создать свой конфигурационный файл приложения.

понедельник, 8 февраля 2016 г.

Настройки профиля пользователя через VMware User Environment Manager

Разбираясь в VMware UEM, я решил записать небольшое видео, которое показывает настройку профиля пользователя на примере задания обоев рабочего стола.

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

понедельник, 1 февраля 2016 г.

Ошибка Personal vDisk при обновлении MCS образа Citrix XenDesktop

При обновлении базового образа в Machine Catalog, использующего персональные диски (Persinal vDisk), в консоли Citrix Desktop Studio виртуальная машина отображается со статусом Unregistered, а при подключении к ВМ через консоль появляется ошибка "Citrix personal vDisk failed to Start" с кодом: 0xC03A001A.

При этом в файле журнала PvDActivation.Errors.txt на виртуальной машине могут появляться следующие сообщения:
[ERROR][12-11-2015 14:21:04]VDeskNativeV   [0169] Creating of the child VHD P:\UserData.V2.VHD.UpdateInProgress failed with error -> = -1069940710
[ERROR][12-11-2015 14:21:04]VDeskNativeV [0577] Failed to create differencing disk P:\UserData.V2.VHD.UpdateInProgress, against P:\UserData.V2.vhd, Error:-1069940710
[ERROR][12-11-2015 14:21:04]VDeskNativeA [2476] Failed to create diffrencing disk for applying updates,Error:-1069940710

Ошибка возникает из-за того, что на персональном диске (P:\) включено сжатие на уровне файловой системы NTFS, что не поддерживается виртуальными дисками .vhd. Отключите сжатие в свойствах диска (снижите флажок с Compress this drive to save disk space / Сжать этот диск для экономии места) и перезагрузите ВМ.

понедельник, 25 января 2016 г.

Немного истории: продукты VMware, которых больше нет с нами

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

VMware ESX Server

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

VMware ESX Server - первый гипервизор типа 1 для процессоров Intel x86. ESX не был первым серверным гипервизором, и даже не был первым продуктом VMware. Однако в нем впервые были реализованы такие функции, как живая миграция ВМ (vMotion), высокая доступность ВМ (High Availability), автоматическая балансировка (Distributed Resource Scheduler), управление питанием (Distributed Power Management) и многое другое.

Кстати, вы никогда не задавались вопросом, что значить аббревиатура ESX? Так вот, ESX - это Elastic Sky X. Что лишний раз доказывает, что еще в далеком 2002 VMware разрабатывала свои продукты с оглядкой на облачные вычисления...

ESX строился на базе монолитной архитектуры, все драйверы, сеть и подсистема ввода-вывода работали на уровне гипервизора. Однако для управления гиперзовиром на каждом хосте устанавливалась небольшая служебная ВМ - Service Console на базе модифицированного дистрибутива Red Hat Linux. С одной стороны, это накладывало ряд ограничений - служебная ВМ отъедала часть вычислительных ресурсов хоста, ее диски, как и любой другой ВМ требовалось размещать на VMFS хранилище, а каждый хост нуждался, по меньшей мере, в двух IP адресах, один - для VMKernel интерфейса, второй - для Service Console. С другой стороны, Service Console предоставляла возможность установки стороннего ПО (агентов, плагинов), которые расширяли возможности по мониторингу и управлению гипервизором. Наличие Service Console породило распространенное заблуждение, что гипервизор ESX является модифицированным Linux'ом.

Стоит упомянуть, что первые версии ESX устанавливались и управлялись по отдельности, однако, начиная ESX 2.0, для централизованного управления несколькими хостами появился VMware VirtualCenter (ныне хорошо известный под именем vCenter Server). Тогда, собственно, и появился Virtual Infrastructure, который представлял собой набор продуктов для виртуализации, состоящий из гипервизора ESX и ПО управления VirtualCenter. К версии 4.0 Virtual Infrastructure был переименован в vSphere.

В 2008 году появился альтернативный гипервизор - ESXi, который не нуждался в Service Console, был гораздо меньше в размере, но не поддерживал многое из того, что умел ESX (у ESXi отсутствовал WEB интерфейс, встроенный брандмауэр, возможность загрузки по SAN, интеграция с Active Directory и пр.). С каждой новой версией VMware постепенно наращивала функционал ESXi. VMware vSphere 4.1 стал последним релизом, включающим гипервизор ESX. Начиная с 5.0 VMware оставила только ESXi.

VMware GSX Server / Server

Долгие годы VMware GSX Server выпускался параллельно с VMware ESX. Ground Storm X (так расшифровывается аббревиатура GSX) представлял собой гипервизор второго типа и устанавливался поверх серверных ОС Microsoft Windows, RedHat или SUSE Linux. Использование гипервизора тип 2 имело свои плюсы. Во-первых, GSX поддерживал гораздо более широкий перечень оборудования и мог работать даже на десктопном железе в отличие от "капризного" ESX. Во-вторых, VMware GSX был крайне прост в установке и настройке, любой, кто работал с VMware Workstation, был способен управиться и с GSX. В-третьих, GSX имел встроенный NAT и DHCP сервер, что позволяло легко настраивать сеть для ВМ.

Как и старший собрат GSX поддерживал централизованное управление через VirtualCenter.

Позже GSX был переименован в VMware Server, получил при этом возможность запускать 64-битные ВМ, а также выделять ВМ несколько виртуальных процессоров. Вышедший в конце 2008 года VMware Server 2.0 стал бесплатным, обзавелся полноценным веб-интерфейсом и возможностью проброса USB устройств внутрь ВМ, однако потерял поддержку VMware VirtualCenter.

К этому времени гипервизоры ESX и ESXi заняли большую часть рынка серверной виртуализации. Выход бесплатных версий VMware ESXi Free и Microsoft Hyper-V Server стали последним гвоздем в крышку гроба VMware Server. VMware и Microsoft забросили свои гипервизоры для серверных ОС.

VMware vCenter Server Heartbeat

Продукт, предназначенный для обеспечения высокой доступности служб vCenter и смежных сервисов (СУБД, SSO, Update Manager), разрабатывался не самой VMware, а сторонней компанией - Neverfail Group.

В основе механизма защиты лежала идея организации двухузлового кластера, работающего в режиме active-passive. Пассивный узел следил за состоянием основного узла, и в случае его недоступности, запускал кластеризованные сервисы. Для работы кластера не требовалось общее хранилище, т.к. изменения, выполненые на активном узле периодически реплицировались на пассивный узел. vCenter Heartbeat обеспечивал защиту как физических, так и виртуальных, и даже смешанных конфигураций vCenter, когда один узел был физическим, а второй - виртуальным.

Хотя какое-то время vCenter Heartbeat и был единственным способом обеспечить защиту vCenter не только от аппаратных, но и от программных сбоев, реализация откровенно хромала. Сложная процедура установки и обслуживания кластера, а также масса багов сделали свое черное дело. В итоге, начиная с vSphere 5.5 U3 / vSphere 6.0 компания VMware отказалась от vCenter Heartbeat и вернулась к более привычному способу кластеризации средствами Microsoft Failover Cluster.

VMware vCenter Protect

Для тех из вас, кто работал с vSphere хотя бы с 4-й версии, должно быть известно, что в то время vCenter Update Manager поддерживал установку обновлений не только для гипервизоров ESX/ESXi, но также гостевых операционных систем и различного ПО. Однако начиная с 5.0 данный функционал был исключен из Update Manager, вместо этого VMware стала предлагать отдельный продукт - VMware vCenter Protect, который был приобретен вместе с компанией Shavlik.

Помимо обновления гостевых ОС, vCenter Protect позволял выполнять инвентаризацию программного и аппаратного обеспечения, запускать различные сценарии по расписанию, выполнять проверку на наличие уязвимостей.

Но, по всей вимости, продажи шли не очень хорошо, кроме того в портфеле VMware был vRealize Configuration Manager, приобретенный в 2010 у EMC, и выполнявший функции патч-менеджмента, инвентаризации и многого другого. Поэтому в 2013 vCenter Protect был продан компании LANDesk.

VMware Virtual Storage Appliance

Virtual Storage Appliance - первая попытка VMware играть на рынке программно-определяемых СХД. VSA предназначался для SMB и позволял создавать общую отказоустойчивую СХД на базе локальных дисков, устанавленных в сервер.

На каждом хосте ESXi развертывался специальный апплайнс VSA. Виртуальные диски VSA размещались на VMFS хранилище, созданном на томах локального RAID контроллера. Половина дискового пространства предназначалась для зеркалирования данных с другого VSA (этакий сетевой аналог RAID 1), расположенного на соседнем хосте, половина оставалась под полезные данные. Затем каждый апплайнс презентовал свое зеркалируемое хранилище по протоколу NFS обратно всем хостам виртуализации. Одна инсталляция поддерживала 2 или 3 хоста виртуализации, при использовании 2 хостов vCenter Server выполнял роль арбитра и должен был разворачиваться на отдельном физическом сервере или хосте ESXi, не входящем в VSA.

Функционал VSA был весьма ограниченным. Так, например, первая версия VSA поддерживала размещение только на VMFS томах с RAID 1 или 10, что приводило к высоким накладным расходам на хранение данных (фактически, полезное пространство составляло менее 1/4 от объема локальных дисков), отсутствовала поддержка VAAI, не было поддержки кэширования или тиринга.

Все это в совокупности с не слишком низкой ценой и невысокой производительностью не позволили VSA вытеснить привычные СХД из SMB сегмента. Поэтому вскоре после выхода первой версии Virtual SAN в 2014, продукт был снят с продаж.

VMware Virsto

Еще одна жертва Virtual SAN, продукт одноименной компании, которую VMware приобрела в 2013 году. Насколько мне известно, после покупки Virsto так и не появился в прайс-листах, а был практически сразу же помножен на ноль.

Перпективная разработка в области программно-определяемых хранилищ данных, Virsto представлял собой виртуальный апплайнс, выполняющий роль виртуализатора СХД, т.е. ресурсы СХД презентовались аплайнсу, а аплайнс, в свою очередь, отдавал дисковое пространство хостам по протоколу NFS. Сердцем Virsto была VirstoFS - специализированная файловая система, позволяющая оптимизировать операции записи и чтения за счет использования механизмов, схожих с теми, что можно видеть в СХД NetApp FAS. Virsto мог аккумулировать случайные операции записи в специальном журнале и затем последовательно записывать данные на СХД, что положительно сказывалось на IOPS и задержках. Кроме того, Virsto поддерживал многоуровневое хранение данных (тиринг) и оптимизировал работу со снапшотами за счет хранения в оперативной памяти метаданных о том, какой блок с данными в каком из снимков находится.

Несмотря на то, что продукт так и не вышел, старания разработчиков не прошли даром - в Virtual SAN 6.0 вместо VMFS-L появился новый формат разметки дисков на базе VirstoFS и поддержка "продвинутых" снапшотов.

VMware Lab Manager

Продукт для автоматизации развертывания и управления жизненным циклом ВМ в тестовых окружениях.

По сути Lab Manager являлся менеджером менеджеров, разворачивался поверх существующей инсталляции VMware ESX/ESXi и vCenter и позволял организовывать многопользовательский (многоарендный) доступ к общей виртуальной инфраструктуре, выделять пользователям необходимый набор вычислительных ресурсов, автоматически выдавать IP адреса ВМ из пулов, создавать изолированные сети для ВМ, указывать срок аренды для ВМ.

С ростом популярности темы облачных вычислений VMware переключилась на другой продукт - vCloud Director, постепенно перенеся из Lab Manager все наработанные фишки и закрыв его.

VMware ACE

Закончить обзор я хочу на достаточно редком звере - VMware ACE. Еще до появления VDI в своем классическом виде и широкого распространения BYOD компания VMware предлагала клиентам ПО для централизованного управления виртуальными рабочими станциями, которые могли запускаться на персональных компьютерах пользователей - VMware ACE.

ACE работал в связке с клиентскими гипервизорами VMware Workstation и Player и позволял управлять ВМ на основании заданных политик. С помощью политик администраторы могли ограничить функционал ВМ (например, отключить проброс USB устройств или контролировать доступ в сеть), принудительно шифровать виртуальные диски, разрешать доступ к ВМ только для авторизованных пользователей, настраивать срок жизни ВМ, по истечении которого ВМ переставала запускаться и т.д. ВМ вместе с политиками и гипервизором VMware Player могли быть экспортированы в виде готово пакета Pocket ACE и переданы пользователю любым удобным способом (на CD-диске, flash-накопителе или по сети). При необходимости, администратор мог развернуть в сети сервер ACE Management Server, к которому подключались клиентские гипервизоры и запрашивали актуальные настройки политик для ВМ.

Не смотря на интересный функционал, продукт не получил широкого распространения, и по словам VMware не отвечал всем требованиям тех немногих заказчиков, что его использовали, поэтому в 2011 он был снят с продажи. Спустя несколько лет на смену ACE пришел VMware Horizon FLEX, имеющий собственный механизм доставки ВМ на компьютеры пользователей, а также поддерживающий гипервизор VMware Fusion Pro для ОС Apple MAC OS X.

среда, 20 января 2016 г.

Презентация с выступления VMUG 2015 Winter

В декабре прошлого года на очередном VMUG я делал доклад на тему: "Docker в виртуальной среде VMware".


Видео с демонстрацией.

Запуск нескольких экземпляров Apache Tomcat в Docker контейнерах.

Пример установки Photon OS для запуска Docker контейнеров.

Демонстрация работы с Docker контейнерами через плагин к vRealize Orchestrator.

Пример создания ВМ VMware ESXi через Docker Machine.



понедельник, 11 января 2016 г.

Установка и настройка VMware Horizon Client for Linux для Ubuntu 14.04

За последний год VMware активно дорабатывала VMware Horizon Client for Linux, добавляя в него все больше функций. Последняя актуальная версия клиента поддерживает проброс USB устройств и принтеров, RTAV (Real-Time Audio-Video) аутентификацию по смарт-картам, двухфакторную аутентификацию с помощью RSA SecurID или RADIUS, многомониторную конфигурацию, подключение локальных папок (в тестовом режиме).

Из функций, которые на текущий момент не поддерживаются в клиенте для Linux: MMR (Multimedia Redirection), проброс сканеров и serial портов, подключенных к клиентским устройствам.

В качестве примера рассмотрим установку клиента под 32-битной версией ОС Ubuntu 14.04.3 (64-битная версия Ubuntu 14.04 на текущий момент официально не поддерживается).


Установка клиента

Перед установкой клиента загрузите последние актуальные обновления для ОС:
sudo apt-get update
sudo apt-get upgrade

Создайте символическую ссылку на библиотеку libudev (требуется для работы USB Redirection и RTAV):
sudo ln -s /lib/i386-linux-gnu/libudev.so.1.3.5 /usr/lib/libudev.so.0

В Ubuntu Software Center доступна устаревшая версия клиента VMware View Client 2.2, поэтому загрузите с сайта VMware последнюю версию VMware Horizon Client 3.5 и запустите процедуру установки:
chmod +x VMware-Horizon-Client-3.5.0-2999900.x86.bundle
sudo ./VMware-Horizon-Client-3.5.0-2999900.x86.bundle

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

После завершения установки выберите автоматическую регистрацию сервисов (Register and start installed service(s) after the installation).

Клиент готов к работе и может быть запущен из консоли с помощью команды vmware-view, что довольно неудобно. В качестве альтернативного варианта можно создать ярлык и добавить его на панель Unity Launcher. Для этого создайте файл-описание:
cd ~/.local/share/applications/
nano vmware-view.desktop

Добавьте в него следующее содержимое:
[Desktop Entry]
Version=1.0
Type=Application
Name=VMware Horizon Client
Icon=/usr/share/pixmap/vmware-view.png
Path=/home/user
Exec=/usr/bin/vmware-view
StartupNotify=false
StartupWMClass=Vmware-view
#OnlyShowIn=Unity;
#X-UnityGenerated=true

Зарегистритуйте приложение, используя файл-описание:
sudo desktop-file-install vmware-view.desktop

Теперь приложение появится в списке доступных для запуска, и его можно будет вынести на панель launcher'а.

Настройка аутентификации по смарт-картам

Для аутентификации через клиент Horizon Client по смарт-картам требуется дополнительная настройка. В качестве примера приведено описание настройки для CCID карт-ридера и смарт-карт Aladdin eToken.

Для начала установите необходимые записимости:
sudo apt-get install pcsc-tools pcscd libccid libqt4-core libqt4-gui hal-info

Если вы используете CCID карт-ридер с драйвером libccid, то он автоматически определится ОС, для других моделей может потребоваться установка дополнительных драйверов (например, Athena ASEDrive IIIe). Список карт-ридеров и драйверов можно посмотреть на сайте wiki.debian.org/Smartcards.

Проверьте, что карт-ридер корректно работает, используя команду:
pcsc_scan

Смарт-карты Aladdin eToken

Для аутентификации с использованием eToken смарт-карт потребуется установить ПО SafeNet Authentication Client.

Перед установкой SAC загрузите и установите две библиотеки (libhal1 и libha1-storage1):
wget http://mirrors.kernel.org/ubuntu/pool/universe/h/hal/libhal1_0.5.14-8_i386.deb
sudo dpkg -i libhal1_0.5.14-8_i386.deb

wget http://mirrors.kernel.org/ubuntu/pool/universe/h/hal/libhal-storage1_0.5.14-8_i386.deb
sudo dpkg -i libhal-storage1_0.5.14-8_i386.deb

Загрузите дистрибутив SAC с сайта (для примера используется версия SAC 8.3). Установите ПО:
sudo dpkg -i SafenetAuthenticationClient-8.3.34-0_i386.deb

Запустите SafeNet Authentication Client Tools и проверьте, что ОС видит сертификаты на смарт-карте.

Создайте каталог и символическую ссылку на библиотеку eToken:
sudo mkdir /usr/lib/vmware/view/pkcs11/
sudo ln -s /usr/lib/libeTPkcs11.so /usr/lib/vmware/view/pkcs11/

Теперь аутентификация по смарт-картам должна заработать.

Смарт-карты Aladdin JaCarta

Для работы со смарт-картами Aladdin JaCarta вам потребуется загрузить ПО JaCarta PKI for Linux (http://www.aladdin-rd.ru/support/downloads/39875/).

После загрузки распакуйте архив и установите клиент JaCarta PKI:
sudo dpkg -i idprotectclient_637.03-0_i386.deb

При помощи утилиты IDProtect Manager проверьте, что смарт-карта видна в ОС.

Создайте каталог и символическую ссылку на библиотеку JaCarta:
sudo mkdir /usr/lib/vmware/view/pkcs11/
sudo ln -s /usr/lib/x86-athena/libASEP11.so /usr/lib/vmware/view/pkcs11/

Теперь аутентификация по смарт-картам должна заработать.

P.S. Для работы Single Sign-On при использовании смарт-карт на виртуальной машине вместе с VMware Horizon View Agent должен быть установлен компонент PCoIP Smartcard и SafeNet Authentication Client.