Vmware horizon client for windows xp

VMware Horizon Client for Windows Release Notes

Horizon Client for Windows 3.4 | 4 June 2015

Last Updated: 9 June 2015

These release notes cover the following topics:

Key Features

VMware Horizon Client for Windows makes it easy to access your Windows virtual desktop with the best possible user experience on the Local Area Network (LAN) or across a Wide Area Network (WAN).

• Support for Windows 8 and 8.1 (with Updates) and Windows 7 systems — Windows XP and Windows Vista are supported only with Horizon Client 3.2.1 and earlier. See Resolved in Horizon Client 3.2.1.
• Unmatched performance — The adaptive capabilities of the PCoIP display protocol are optimized to deliver the best user experience, even over low-bandwidth and high-latency connections. Your desktop is fast and responsive regardless of where you are.
• Simple connectivity — Horizon Client for Windows is tightly integrated with VMware Horizon 6 for simple setup and connectivity.
• Secure from any location — At your desk or away from the office, your data is delivered securely to you wherever you are. SSL/TLS encryption is always used to protect user credentials, and enhanced certificate checking is performed on the client. Horizon Client for Windows also supports optional RADIUS and RSA SecurID authentication.

What’s New in This Release

The 3.4 release of Horizon Client for Windows includes the following new features:

• Client drive redirection
  Users can now share folders and drives on their Windows client systems with remote desktops and applications. This feature is called client drive redirection. Requires View Agent 6.1.1 or later.
• Serial port redirection
  With serial port redirection, users can redirect locally connected serial (COM) ports such as built-in RS232 ports or USB-to-serial adapters. Devices such as printers, bar code readers, and other serial devices can be connected to these ports and used in the remote desktops.
• Support for Windows Media Multimedia Redirection (MMR) for RDS desktops
  Windows Media MMR is now supported for videos playing on RDS desktops. In past releases, this feature was supported only on VDI desktops that run on single-user machines. For details about supported desktops, see see System Requirements for Windows Media MMR in the Setting Up Desktop and Application Pools in View guide.
• Linux remote desktops
  Administrators can set up a Linux virtual machine as a remote desktop. End users can log in to a Linux remote desktop from Horizon Client for Windows. Requires View Agent 6.1.1 or later and Horizon Client for Windows 3.4. Not all features are supported in this release. For more information, see Setting Up Horizon 6 for Linux Desktops.
• Usability enhancements when using multiple monitors
  You can now change the display mode, such as from All Monitors mode to Fullscreen mode, without having to disconnect from the desktop. Also, if you have Horizon Client use only one monitor, the client remembers which monitor was used the last time you launched the desktop. This preference is remembered on a per-desktop basis.
• Shade menu bar can be repositioned
  When you use All Monitors mode or Fullscreen mode, a shade menu bar appears at the top of the window, in the center. You can now drag the shade menu bar horizontally if you need to slide it out of the way.
• Temporary removal of FIPS mode support
  For security reasons, this release does not support FIPS (Federal Information Processing Standard) mode. If your company requires that clients be FIPS-enabled, do not upgrade to Horizon Client 3.4. Wait for a future release.

Internationalization

The user interface and documentation for Horizon Client are available in English, Japanese, French, German, Simplified Chinese, Traditional Chinese, and Korean.

Before You Begin

• The OpenSSL library has been updated to version openssl-1.0.1m.
• VMware Horizon Client for Windows requires one of the following operating systems:
  • 32-bit or 64-bit Windows 8, 8.1, or 8.1 Update, Enterprise or Pro edition
  • 32-bit or 64-bit Windows 7 SP1, Home, Enterprise, Ultimate, or Professional edition
• VMware Horizon Client for Windows is supported with the latest maintenance release of Horizon View 5.3.x, VMware Horizon 6.0.x, or VMware Horizon 6 version 6.1.x.
• To install, download the installer from the VMware Horizon Client download page.
• For more system requirements and installation instructions, see Using VMware Horizon Client for Windows.

Resolved Issues

Resolved in Horizon Client 3.4

Which bugs got fixed that we want to mention. —>
• (Base bugs 1413106, 1314672, 1263835, 1276879, and 1337535)
  —> Previously, the mouse pointer would sometimes jump to the middle of a remote desktop window. For example, this issue could occur if you minimized or closed a window for an application other than Horizon Client, or if you restored a remote desktop window that had been minimized, or if you move your mouse pointer from another window to a remote desktop window, or while inside a remote desktop window, you pressed the Caps Lock key or Scroll Lock key so that the lock status on the client system is different from the lock status in the remote desktop. This issue has been resolved.
• (Base bug 1372405)
  —> Previously, the scanner redirection feature did not work with the Microsoft Fax and Scan application. This issue has been resolved.

Resolved in Horizon Client 3.3

• (DocPR 1358419, from base bug 1314484, says it was fixed in Cart15Q1, but you still have to do all this rebooting, so leave it here)
  —> Previously, certain WIA scanning devices did not appear in the Scanner Redirection for VMware Horizon menu on the desktop after the devices’ drivers were installed and the devices were plugged into the client computer. This issue has been resolved.

Resolved in Horizon Client 3.2.1 (Released on 9 June 2015)

• Horizon Client for Windows 3.2.1 is the last version of Horizon Client that is supported for installing on Windows XP and Vista client operating systems. For more details, see Retiring Old OSes: XP, Vista, Mac OS X 10.6 & 10.7.
• (DocPR 1459295, from base bug 1430822)
  —> Previously, if you wanted to change the display mode, such as from All Monitors mode to Fullscreen mode, you had to first disconnect from the desktop. This issue has been resoved only in Horizon Client 3.2.1 and 3.4. You can now right-click the system tray (notification area) icon on the client system to open the Settings window and change the display mode. For more information, see the online help topic called «Change the Display Mode While a Desktop Window Is Open.» Although this topic states that you must have Horizon Client 3.4, the feature is also available in Horizon Client 3.2.1.
• (Base bugs 1413106, 1314672, 1263835, 1276879, and 1337535)
  —> Previously, the mouse pointer would sometimes jump to the middle of a remote desktop window. For example, this issue could occur if you minimized or closed a window for an application other than Horizon Client, or if you restored a remote desktop window that had been minimized, or if you move your mouse pointer from another window to a remote desktop window, or while inside a remote desktop window, you pressed the Caps Lock key or Scroll Lock key so that the lock status on the client system is different from the lock status in the remote desktop. This issue has been resolved only in Horizon Client 3.2.1 and Horizon Client 3.4.
• (DocPR 1310123, from base bug 1306612, moved up from known issues section)
  —> Previously, if you connected to a Windows Server 2008 R2 remote desktop, the virtual printing feature sometimes did not work correctly, so that instead of having a redirected virtual printer as the default, the Printers and Devices list in the remote desktop showed the location-based printer as the default. This issue has been resolved in Horizon Client 3.2.0 and later releases.

Resolved in Horizon Client 3.1

• (Doc PR 1205717—No corresponding engineering bug)
  —> Previously, remote applications that depended on user interaction with the System Tray could not be shut down. This issue has been resolved. System tray items from the remote desktop now appear in the system tray of the client system.

Resolved in Horizon Client 3.0

• (Bug 1196138)
  —> Previously, the client did not support connections via proxy server if the proxy details were configured using group policy preferences. This issue has been resolved.
• (Bug 1167536)
  —> Previously, if you used the Log In as Current User feature, the connection might fail unless you logged in to the local operating system as an admin user. This issue occurred if the primary DNS name was different from the primary domain name. This issue has been resolved.
• (Doc PR 1162602, from bug 1163364, which has no fix-by)
  —> Previously, if you enabled the group policy setting called «Disable sending CAD when users press Ctrl+Alt+Del» in the remote desktop, then on the Windows client, selecting «Send Ctrl-Alt-Delete» from the menu bar had no effect. Also, using the Ctrl+Alt+Insert key combination had no effect. These issues have been resolved.
• (2.2 known issue—Doc bug 1095168, from bug 1093311, scheduled for 2.4)
  —> Previously, if you used a Windows 8.1 client device and attempted to configure a Philips SpeechMike USB device to be split and redirected to the View desktop, the USB redirection would fail.
  This issue has been resolved.
• (Bug 1233355)
  —> Previously, the client could not connect to a server if the server short name was used. This issue has been resolved.
• (Bug 1169842)
  —> Previously, under certain connection failure conditions, the following error message appeared, even if the server did not provide a self-signed certificate: «Cannot verify your connection. The server provided a self-signed certificate instead of a verifiable certificate.» This issue has been resolved so that the client no longer presents an incorrect failure message.
• (Bug 1114413)
  —> Previously, if you used a tablet client device, if you moved the mouse pointer within 10 mm of the top of the screen, the tab for the shade dropped down. This issue has been resolved so that the shade does not drop down unless you move the pointer to the very top of the screen.

Источник

VMware Horizon client

Для подключения к VDI необходимо скачать и установить на свое устройство программу VMware Horizon client. С ее помощью можно подключиться к своей виртуальной рабочей станции и получить максимально возможный на сегодняшний день функционал и производительность в среде Horizon.

VMware Horizon client 4.8.0 (Win x64) — скачать

VMware Horizon client 4.8.0 (MacOS) — скачать

VMware Horizon client 4.8.0 (Linux x64) — скачать

VMware Horizon client 4.8.0 (iOS) — iTunes

VMware Horizon client 4.8.0 (Android) — Google Play

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

VMware Horizon архитектура

За время существование продукта он успел аккумулировать в себе большое количество функций, которые чаще всего появлялись после интеграции в VMware Horizon сторонних программных продуктов, купленных компанией VMware. Но любое внедрение сопровождается усложнением архитектуры, отладке взаимодействий компонентов, обучению специалистов и другие смежные процессы. Поэтому сейчас рассматривать VMware Horizon нужно уже, как часть целого. Продукт, объединяющий в себе все наработки называется VMware Workspace One. По идее VMware инфраструктура большой компании давно уже не ограничивается рамками ЦОДов, а успешно использует сторонние сервисы SaaS, облачные ресурсы и сторонние приложения.

Опустимся на уровень ниже и сфокусируемся на эталонной архитектура VMware Horizon для одной площадки. Здесь мы видим набор компонентов, соответствующий максимальной редакции VMware Horizon Enterprise.

Уровень серверной виртуализации реализован на продуктах: VMware vSphere Enterprise Plus, гиперконвергентном VMware vSAN, сетевую безопасность обеспечивает VMware NSX.
Программный уровень VDI представляет собой классическую схему с добавлением новых компонентов в виде AppVolumes для доставки слоев приложений и Identity Manager для сквозной аутентификации в локальных и сторонних SaaS и мобильных приложениях. Еще один новый программный продукт — это User Environment Manager, который дополняет управление профилем пользователя.

Жизненный цикл виртуальной машины VDI от создания до обнуления протекает в тесном контакте со всеми окружающими сервисами. ВМ для пользователя сначала собирается для пользователя из разных слоев, а после выхода из сессии, разбирается. На картинке ниже наглядно показаны основные компоненты.

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

2. Формулы расчета плотности VDI

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

Чтобы вне зависимости от вендора ПО посчитать сколько виртуальных машин VDI можно запустить на одном сервере, необходимо запомнить следующие правила для CPU-RAM-Disk:

1. CPU. На одно физическое ядро процессора закладывается 6 виртуальных машин, типа «офисная». Если в сервере 2 процессора по 8 ядер в каждом, то 2*8*6=96 ВМ. Причем общая нагрузка на процессоры в середине рабочего дня будет в пределах 50-75%.

2. RAM. На одну виртуальную машину типа «офисная» Windows 7 закладывается 2Гб оперативной памяти, среднее потребление будет 1.3Гб — 1.8Гб в зависимости от запущенных в данный момент пользователем приложений. Причем, производители советуют использовать Windows 7 32 bit, судя по всему, чтобы срабатывали собственные ограничители операционной системы.

3. Disk. Во время запуска операционной системы и входа пользователя в сессию (загрузка профиля) виртуальная машина делает 50 IOPS, а во время работы 10-15 IOPS (операций ввода вывода в секунду), чем значительно нагружает дисковую подсистему. Момент загрузки всех виртуальных машин разом и входа пользователей в сессии называется «Boot Storm», нагрузка на подсистему хранения в этот момент максимальная. Чтобы рассчитать необходимую пиковую производительность дисковой подсистемы нужно кол-во виртуальных машин умножить на 50 IOPS. Например, для 96 ВМ понадобится система хранения, пиковая производительность которой 4800 IOPS. Если предположить, что чтение и запись будут соотноститься 70/30, то для достижения этой производительности потребуется 50 SAS дисков 10к (RAID 10). Согласитесь, что неразумно использовать такое количество SAS дисков в системе хранения данных для 96 виртуальных машин. Поэтому VDI сейчас немыслим без SSD или других технологий, которые могут обеспечить высокую производительность системы хранения данных. После загрузки виртуальных машин и окончания Boot Storm, когда пользователи работают в штатном режиме виртуальная машина делает 10-15 IOPS. Для 96 ВМ понадобится производительность 10 SAS дисков в RAID 10, что тоже немало. Также не стоит переоценивать возможности SSD дисков, у них высокие показатели по IOPS-ам только в идеальных усоловиях и непродолжительное время, после чего происходит снижение производительности в 2-10 раз. Принято считать, что при продолжительной нагрузке у SAS диска 10к показатель IOPS равен 150 IOPS, а у SSD диска 1200 IOPS.
Для дисковой подсистемы получается не самая радужная калькуляция. Поэтому необходимой производительности добиваются не наращиванием дисков SAS, а используя SSD диски, применяя дополнительные технологии, меняя архитектуру. Обо всем этом ниже.

3. Варианты архитектуры VDI

Для лучшего понимания материала будет рассмотрим проект на 500 пользователей офисного типа.

Используя известные нам формулы, необходимо рассчитать ресурсы, для работы 500 пользователей VDI.

Количество серверов VDI = 500 пользователе/6 пользователей на ядро/16 ядер в сервере = 5 серверов (2 x CPU 8 core) + 1 сервер резервной замены
Объем оперативной памяти в каждом сервере = 500 пользователей * 2Гб/ 5 серверов = 200 Gb
Производительность дисковой подсистемы. Во время Boot Storm = 500*50 IOPS= 25 000 IOPS. Во время работы = 500*10 IOPS= 5 000 IOPS

Стандартный вариант архитектуры (на 500 пользователей)

Первая архитектура, самая привычная, пришедшая из серверной виртуализации. У нас будут серверы для запуска виртуальных машин VDI, у нас будут серверы для запуска виртуальных машин с инфраструктурными ролями, у нас будет система хранения для фалов виртуальных машин. Соединены серверы и система хранения зелеными линиями, которые могут представлять из себя любую совместимую технологией FC, iSCSI, SAS, NFS.
Важный момент относящийся к VDI. Нет необходимости защищать виртуальные машины VDI на случай выхода из строя физического сервера, за исключением варианта использования полных клонов. Если виртуальная машина пользователя по каким-то причинам прекращает работать, то сотрудник подключается к другой виртуальной машине VDI на другом сервере, куда уже загружается его профиль, слои приложений, подключаются перенаправленные папки, сетевые диски, принтеры.

А вот виртуальные машины с инфраструктурными ролями наоборот необходимо защитить с помощь технологий серверной виртуализации, поэтому потребуется, как минимум, 2 физических сервера, для объединения их в отказоустойчивый кластер.

VDI на локальных SSD дисках (на 500 пользователей)

Один из вариантов решения — это VDI на локальных дисках. Принцип очень простой. Когда мы собираемся из «золотого образа» создать N-ое количество виртуальных машин VDI, то в качестве хранилища нужно указать локальные диски. Тогда «золотой образ» копируется на локальные диски каждого хоста виртуализации, после чего локально на каждом сервере создаются виртуальные машины с дифференциальными дисками. ВСЯ дисковая нагрузка ложится на локальные SSD диски, мощная система хранения данных просто не нужна.

По данной технологии могут работать Citrix XenDesktop и VMware Horizon View. На СХД имеет смысл хранить виртуальную машину «золотой образ» , файлы инфраструктурных виртуальных машин, профили пользователей. Общая стоимость решения снижается на разницу в цене на быструю систему хранения и СХД начального уровня.

Другие варианты архитектуры VDI

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

VMware в последней версии Horizon View предлагает использовать технологию vSAN. Ее использование позволяет вообще не покупать систему хранения данных, вместо нее на основе локальных дисков будет создано распределенное файловое хранилище, которое может обеспечить необходимый уровень производительности и отказоустойчивости для виртуальных машин VDI и для виртуальных машин инфраструктуры. Более подробно я напишу про vSAN в отдельной статье, посвященной VDI от VMware. Официальный документ можно найти по этой ссылке (link)

Citrix, как альтернативный вариант архитектуры для VDI проектов, предлагает рассматривать свой Provisioning server (PVS), естественно, в отказоустойчивом исполнении. К сожалению, нет официального документа по референсной архитектуре, который бы смог прояснить спорные моменты, которых достаточно много. Подробнее можно почитать на сайте Citrix (link). Изюминкой технологии является создание бездисковых виртуальных машин VDI. «Золотой образ» специальным образом публикуется на PVS и транслируется (только на чтение) в виртуальную машину по сети. Все временные файлы ОС сохраняются в отдельный файл, который может хранится в оперативной памяти виртуальной машины или на PVS сервере или на диске виртуальной машины (но тогда она не совсем бездисковая). Опять же, все эти ухищрения главным образом направлены на снижение нагрузки на основную систему хранения данных. Более подробно я напишу про PVS в отдельной статье, посвященной VDI от Citrix.

Технологии

Варианты оптимизации производительности от VMware:

• View Accelerator — технология которая позволяет сохранять в оперативной памяти ESXi сервера часто используемые на чтение блоки данных. Позволяет снизить количество операций чтения с системы хранения во время BootStorm и входа пользователей в сессии. На хосте виртуализации используется всего 1Гб оперативной памяти для хранения блоков данных.
• vSphere Storage APIs Array Integration — некоторые системы хранения берут на себя выполнение операций, команды на которые посылает vCenter Server. Позволяет снизить нагрузку на СХД во время операций развертывания и обновления виртуальных машин VDI.
• Transparent page sharing — технология встроенная в ESXi. Позволяет снизить объем используемой оперативной памяти за счет выявления одинаковых блоков, которые виртуальные машины могут использовать совместно. А так как у нас на хостах VDI будут запущены одинаковые операционные системы, которые будут использоваться для одинаковых офисных задач, то экономия может достигать 10-40%. Все будет зависеть от однотипности виртуальных машин и выполняемых задач.
• Карта разгрузки PCoIP — если подключение происходит по PCoIP, то установка в сервер карты с аппаратным чипом от Terradici может привести к снижению нагрузки на CPU до 30%. По протоколу PCoIP передаются измененные пиксели, соответственно, агент, установленный на VDI машине должен определить, какие именно пиксели изменились, завернуть информацию в протокол и отправить клиенты. И дл всего этого используются ресурсы центрального процессора. Если на экране происходит постоянная смена изображения — это очень сильно нагружает CPU. Карта разгрузки берет на себя функции упаковки трафика изображения в PCoIP, чем, обычно, занимается CPU и тем самым снижает нагрузку. Контролировать работу карты нельзя, полностю передать ей функцию передачи PCoIP трафика нельзя, она сама рещает когда включаться в работу и чем заниматься. Надо понимать, что этой картой VMware лечит свои собственные болячки, т.к. у других производителей эта проблема тоже есть, но не стоит настолько остро.

Варианты оптимизации производительности от Citrix:

• IntelliCache — решение подкупающее своей простотой, чтобы разгрузить систему хранения данных нужно использовать локальные диски серверов. Клон золотого образа кэшируется на локальном хранилище сервера и становится доступен на чтение запущенным виртуальными машинам VDI. Если у вас настроено очищение ВМ после выхода пользователя из сессии, то дифференциальные диски также создаются локально и удаляются после logoff-а. Есть вариант и сохранением изменений пользователя на дифференциальных дисках, в этом случае можно сохранять эти данные на общем хранилище и на локальном (будет использоваться только для чтения). Условия, которые необходимо выполнить для работы IntelliCache следующие: общее хранилище должно быть NFS, гипервизор должен быть XenServer, во время установки XenServer необходимо включить технологию Thin provisioning для локального хранилища хоста.

Варианты оптимизации производительности на стороне СХД

• Tiering — функционал системы хранения данных, который позволяет выделить SSD диски для хранения блоков данных, к которым часто происходит обращение. Вся информация также хранится и на SAS дисках в «медленном» разделе. В случае операции чтения система хранения считывает блок с tier раздела (если он там есть) и не обращается к «медленному» разделу. Функционал тиеринга в разных системах хранения работает по-разному, например, в каких-то проходит 24 часа для сбора информации, какие блоки считать «горячими» и поместить на SSD, в каких-то начинает работать сразу. Чтобы избежать ошибок, обобщать не стану, основной принцип должен быть понятен.

Как создаются виртуальные машины

В инфраструктуре VDI обязательно понадобится платформа виртуализации, которой можно управлять из центральной консоли, в эту консоль будут поступать команды от управляющего VDI софта на создание, обновление, включение, выключение, удаление и другие операции с пользовательскими виртуальными машинами. В рассматриваемых решениях такая платформа виртуализации включена в стоимость лицензий VDI. Для VMware Horizon — это VMware vSphere Enterprise Plus, для Citrix XenDesktop — это Citrix XenServer, Microsoft RDS использует встроенную в Windows server 2016 виртуализацию Hyper-V. Рассмотрим самый простой пример, чтобы понять механизм работы службы, которая разворачивает виртуальные машины.

Пример

Сейчас специально опускаются моменты, связанные с инфраструктурным ПО, чтобы сосредоточиться на механизме создания множества виртуальных машин. Возьмем обычный сервер с локальными дисками, на котором нужно развернуть VDI. Сначала администратором в ручном режиме создается эталонная виртуальная машина, которая на схеме называется «W7gold», в нее устанавливаются необходимые программы, специальным образом оптимизируются внутренние службы Windows для максимальной производительности, инсталлируется агентское ПО VDI. После чего запускается автоматический процесс создания N-го числа виртуальных машин. Средствами гипервизора с текущего состояния «W7gold» делается полный клон (диск виртуальной машины копируется полностью), затем клон готовится к размножению с помощью QuickPrep (более быстрый в работе аналог Sysprep). После чего уже с виртуальной машины клона «W7clone» делаются связные клоны. В данном случае диск виртуальной машины «W7clone» не копируется, а становится доступен на чтение N-ому числу виртуальных машин. Все изменения в этих виртуальных машинах пишутся в отдельный дифференциальный файл-диск. Важно то, что работа всех созданных виртуальных машин зависит теперь от одного диска «W7clone», который нельзя перемещать, повреждать и тем более удалять. Вот так в упрощенном виде выглядит механизм создания виртуальных машин VDI.

Источник