Архив

Архив раздела ‘View’

Бэкап конфигурации View Connection Server

В этой статье мне хочется напомнить способы бэкапа данных серверов View, тем более что недавно ко мне обращались с подобными запросами. И если у компонента Composer есть база данных, которую можно бэкапить, то у View Connection Server своей базы нет, а бэкапить все целиком довольно неудобно. Да и что делать, например, если решено перенести конфигурацию на другой сервер без потери данных. Это может понадобиться в случае миграции сервера на другую ОС.

У VMware существует документ, подробно описывающий способы резервного копирования компонентов View, я же распишу бэкап сервера View более подробно. Чтобы не бэкапить все целиком, но вынести конфигурационные данные одним файлом, размером около полмегабайта, достаточно воспользоваться инструментами vdmexport/vmdimport, хранящимися по адресу: C:\Program Files\VMware\VMware View\Server\tools\bin

Для того чтобы сохранить текущую конфигурацию VMware View Connection Server, достаточно прописать vdmexport > xxx.ldf

Восстановить конфигурацию можно командой vdmimport –f xxx.ldf

Подробнее все это описывается в этом документе.

Categories: Backup, View, VMware Tags: , ,

Отключение верхнего бара в VMware View Client

VMware View – очень популярное решение для построения VDI инфраструктуры. Многие уже приобрели тонкие и нулевые клиенты для использования данного решения и очень довольны этим. Но также многие в Production решении используют ПК и ноутбуки с установленным на них клиентом VMware View. При заходе на рабочий виртуальный стол у этого клиента сверху остается бар, с помощью которого аналогично терминальному доступу Windows мы можем свернуть окно с виртуальным десктопом, а также ряд дополнительных функций, например проброс USB, выбор другого пула и т.д. Это довольно удобно, но если пользоваться рабочим столом постоянно, довольно утомляет постоянное появления данного бара, как только мышку поднимешь чуть выше. Многим было бы гораздо удобнее убрать этот бар, так как либо физической ОС не пользуются вообще, либо крайне редко и можно просто выйти туда с помощью Ctrl+Alt+Delete. В интернете уже довольно много тем по этому поводу, мне бы хотелось посвятить данную статью именно этой проблеме.

Для начала скопируем файл vdm_client.adm, который находится по адресу C:\Program Files\VMware\VMware View\Server\extras\GroupPolicyFiles\ на сервер Active Directory. Далее заходим в Group Policy Management->Group Policy Objects->Default Domain Policy. Выбираем Administrative Templates в User Configuration, жмем правой кнопкой мыши и выбираем пункт Add/Remove Templates. Добавляем туда наш скопированный файл vdm_client:

Далее в меню Classic Administrative Templates появится директория VMware View. Там можно настроить массу параметров, дополнительные параметры также доступны, если добавить этот же файл в шаблоны не User Configuration, а Computer Configuration, например то же отключение синхронизации времени, которое я описывал в прошлой статье, но уже массово, для всех клиентов в домене. В нашем случае важен лишь пункт Enable the shade. Выбираем его конфигурацию и выставляем Disabled.

Все настроено, важно помнить лишь то, что отмена верхнего бара в клиенте VMware View будет работать лишь для тех операционных систем, которые введены в домен. То есть если мы хотим, чтобы с физики выход через клиента был без бара, то эта физическая машина должна быть в домене. В верхнем баре была важная фича, коннект USB устройств, так вот через vdm_client.adm шаблон можно настроить автоматический проброс USB, что делает работу с виртуальным десктопом полностью схожим с физическим ПК.

Categories: View, VMware Tags: ,

Совместимость VSphere и XenDesktop

Сегодня получил запрос, касающийся совмещения двух продуктов компаний VMware и Citrix. Задумка следующая: развернуть на гипервизоре ESXi платформу для VDI от Citrix – XenDesktop. Вопросы были примерно следующие: можно ли сие сделать, будет ли работать, нужно ли докупать что-то дополнительно, к кому обращаться в случае краха всего этого и т.д.
Так как ESXi – это гипервизор и ему не важно, что на нем крутится, главное чтобы это были ВМ, то и запустить на нем можно любые приложения и сервисы (поправьте меня списком неработающих :) ). Поэтому XenDesktop работать будет, более того, у VMware есть специальный продукт, VSphere Desktop, который выключает ограничение по лицензированию оперативной памяти при использовании сторонних продуктов VDI. Но сомнительный выигрыш в стоимости лицензий никак не окупит возможного возникновения проблем с таким гибридным построением VDI. Дело в том, что VMware поддерживает лишь инфраструктуру в этом случае, за неработающую платформу на базе XenDesktop VMware не отвечает. С другой стороны Citrix поддерживает свой продукт лишь на базе гипервизора XenServer. Так что лучшим вариантом будет выбрать одну линейку продуктов, либо ESXi и View, либо XenServer и XenDesktop, так мы избавимся от головной боли и лишних проблем в совместимости.

Отмена синхронизации времени агента View с клиентом

У VMware View есть одна особенность, иногда очень неудобная, а теперь, когда время по мск сменилось на +4:00 с +3:00, эта особенность стала для некоторых головной болью. Дело в том, что по умолчанию агент «подсасывает» время с клиента, который на него заходит, то есть, если Вы заходите с клиента, который установлен на Windows без заплатки времени, или с тонкого клиента, на котором время также сбито, то агент будет прописывать Вашей ВМ правильный часовой пояс НО неправильное время. Это очень мешает, а может привести и к потере данных, если доменные политики чувствительны к синхронизации времени.

На большинстве сайтов и форумах разводят руками, мол таких настроек нету, копайтесь внутри конфигурационных файлов. На самом деле все немного проще. Для того, чтобы агент держал свои настройки часового пояса и времени, достаточно лишь зайти в реестр, прописав в Run строке параметр regedit и перейдя в следующую папку: [HKLM\Software\VMware, Inc.\VMware VDM\Agent\Configuration], после чего добавив Строковый параметр DisableTimeZoneSynchronization со значением true:

После этого у Вас все будет работать, никакие сервисы перезагружать не нужно :)

Также это можно сделать массово, как групповую политику. Для этого на нашем сервере View заходим в папку: C:\Program Files\VMware\VMware View\Server\Extras\GroupPolicyFiles\ Копируем оттуда файл vdm_agent.admpolicy на компьютер с AD, и в групповых политиках (GPO), находим параметр Time Zone Synchronization и отключаем его (disable). После этого все рабочие столы в домене будут оставлять свое время, не беря его с клиентов.

Categories: View, VMware Tags: , ,

Диски рабочих столов View

Если мы используем в своей VDI инфраструктуре View Composer и linked clones, то могут возникнуть недопонимания, как диск самой ВМ называется на датасторе (файл .vmdk) и где он находится. Дело в том, что при создании ВМ создание дисков подразделяется на несколько этапов, при это и находиться диски будут в разных местах. Этапы следующие:

  1. При создании самой ВМ с десктопной ОС Windows мы определяем, сколько у нас места будет занимать системный диск;
  2. При создании пула уже в VMware View мы выбираем, сколько у нас будут занимать еще два диска.
1 диск (Persistent Data Disk) — диск с пользовательскими данными, на нем будут находиться все данные пользователя, а также бывшая C:\Documents and Settings\. Программы также теперь нужно будет устанавливать на этот диск, по умолчанию нам предлагается назвать его D:\. В зависимости от того, сколько мы его сделаем, столько места будет у пользователя для его личных данных.
2 диск (System Disposable Disk) — диск с временными файлами и логами, своеобразный своп-файл на уровне ОС. Его объем прямо пропорционален производительности на уровне СХД, но больше 10 Гб его делать просто бессмысленно.

После создания пула при заходе на рабочий стол мы увидим следующие диски:

Для нашего случая я взял диск системы 60 Гб, 0.2 Гб отъелись при форматировании Windows’ом NTFS, пользовательский диск 60000 Мб, а также Temp-диск — 4 Гб. Это то, что мы видим со стороны ОС, но все эти диски являются виртуальными и лежат на датасторе в качестве .vmdk файлов. Раз мы создавали их не вместе, то и лежат они в разных папках ВМ. При созданиие linked clones у нас есть 3 типа ВМ:

  • Родительская ВМ (Master Replica), ее еще называют Золотой Образ — та ВМ, из которой мы создаем пул на основе ее снимка, снэпшота.
  • Реплика (replica) — ВМ системного характера, являющаяся базой для всех ВМ в пуле и держащая системный диск с ОС Windows.
  • Клон (linked clone) — сам виртуальный рабочий стол, на котором будут работать пользователи.
Давайте подробнее остановимся на каждом из этих типов и посмотрим его файлы.

Файла в разных типах ВМ

Начнем с Золотого Образа:

1. Это дельты изменений после совершения снэпшотов, то есть диски, которые создавались при создании снимков;

2. Сам системный диск нашего Золотого Образа.

 Эти диски не играют особой роли при расчете занимаемого места рабочими столами, единственное, максимальный объем системного диска начинает рассчитываться уже отсюда, поэтому при создании системного диска нужно быть предельно аккуратным, пользователи его видят и смогут его забить, если не были ограничены права (точнее не его, а дельту, но от этого меньше места не станет :) )

Теперь перейдем к реплике:

3. Это диск с адресом дельты, то есть некая ссылка на него, обращать особо внимания на него нет смысла, так как он всегда весит 1 Мб;

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

Теперь перейдем к рабочему столу:

5. Overhead диск, особо нагрузки не несет, растет по мере увеличения объема дисков;

6. Диск системы, так как VSphere не может понять, что система находится в другом месте, то создает подобный диск, сам по себе не очень интересен, в нем всегда будет какое-то количество информации;

7. Обычный своп-файл на уровне гипервизора, равен выданному объему оперативной памяти;

8. Первый нужный нам диск. Это Temp-диск который виден в самой ВМ, максимальный объем столько, сколько выдали при создании пула во View. Это второе число, которое будет нам важно;

9. Это и есть дельта, то есть накопившиеся изменения, которые пользователь внес в системный диск. Обычно ее объем равен 10-50 % от максимального. Ее процент означает, сколько процентов использует пользователь данных у ее, остальное берет с системного диска. Запомним это число;

10. Ну и последний, пользовательский диск, это то, сколько мы выдали пользователю при создании пула, и на сколько он его уже забил. Этим диском можно оперировать как в самой VSphere, отсоединяя, присоединяя к другим ВМ, так и в интерфейсе View, что правильнее, там есть своя вкладка для этого — Persistent Disks.

Теперь остается понять, как рассчитывается объем занимаемого места самой ВМ. Рассчитывается он из суммы следующих дисков: 4+8+9+10.

Все же место, занимаемое рабочими столами считается следующим образом:  суммируем все 8+9+10 диски всех десктопов и прибавляем к ним один раз реплику. Сам смысл объединенных клонов в том, чтобы системный диск был посчитан один раз, что дает несомненную экономию для СХД.

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

Categories: View, VMware Tags: , , ,

Зачем нужны тэги в VMware View

Сразу после вводной статьи решил пробежаться по технических аспектам :)
Многие из нас пользовались, тестировали или работают с VMware View, продуктом для VDI. Как известно, у него есть сервер, брокер-соединения, с помощью которого и происходит соединение конечного пользователя с его виртуальным рабочим столом.
Для этого при установке View Manager, выбираем пункт View Connection Server (также есть варианты Transfer Server, Replica Server и security Server). Про другие рассказывать пока не буду, как-нибудь потом, остановимся на варианте Replica Server. Зачем он нужен? Это по сути еще один Connection Server, управляемый нашим основным Connection Server. То есть нужна эта реплика для распараллеливания трафика, если наш первый сервер не справляется, то в ход идут реплика, установить их можно несколько. Управляться они все будут из-под консоли нашего View Connection Server на вкладке servers, при установки реплики нас спросят, к какому connection Server ее цеплять.
Ну тут вроде все ясно, но может возникнуть вопрос, как этим трафиком централизованно управлять, ну например мы хотим, чтобы через 1 сервер у нас шел трафик к одним пользователям, а через другую, другой.
VMware предусмотрела такой подход и создала систему тэгирования. Работает она следующим образом: определенным серверам и пулам назначаем тэги, у кого они совпадают, к тем пулам через определенным сервера и будут присоединяться пользователи. Как это настроить:
Для начала заходим на вкладку Servers в консоли управления и жмем Edit. Прописываем через запятую или через «;» любые тэги. После этого сохраняем изменения.
Заходим в тот пул, который хотим привязать к определенному серверу, жмем Edit, заходим на вкладку Pool Settings и выбираем Browse напротив Restriction. Там выбираем нужные нам тэги/рестрикции.
Вот и все, после этого трафик пойдет лишь через выбранный сервер. Мы можем выбрать несколько серверов одному пулу, чтобы если реплика выпала, мы смогли направить трафик через другой сервер.
Categories: View, VMware Tags: