Архив

Архив Январь 2012

Отмена синхронизации времени агента 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: , ,

8 версия продукта Deep Security уже вышла!

Вчера, 30.01.11 вышла новая версия продукта TrenMicro Deep Security.

TrendMicro – мировой лидер в области антивирусной защиты данных, используемый в виртуальных средах. Deep Security применяется именно с решением VShield EndPoint.

В новой версии нас ждет:

  • Антифишинговая система;
  • Поддержка агентом Deep Security антивирусной защиты;
  • Автоматизированная установка агентов на нужные нам ВМ.

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

Более подробно об этом продукте Вы можете прочесть у нас на сайте.

Categories: Security, 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: , , ,

Альтернатива команде vihostupdate

В 4 версии, если нам нужно было:

  • Произвести апгрейд ESX/ESXi;
  • Добавить драйвера для оборудования в гипервизор;
  • Добавить драйвера для сторонних производителей;

Мы использовали команду vihostupdate, либо Update Manager.


В 5 версии нам предложено использовать локальную команду esxcli, либо vMA. Теперь, скажем, чтобы установить новую версию гипервизора, нам придется писать примерно следующее:

esxcli —server=x.x.x.x —username=root software vib update —depot=/vmfs/volumes/datastore/ESXi500-201109001.zip

Categories: VMware Tags: , ,

Новое лицензирование Виртуальных Машин

Немного хочу затронуть аспекты нового лицензирования в версии VSphere 5, а именно нюансы лицензирования “тяжелых” ВМ с большим количеством RAM. Как известно, теперь само ограничение на количество ядер снято, то есть теперь мы на это не обращаем внимания, зато появилось новое ограничение на общее количество сконфигурированной памяти, не путать с памятью в пуле (vRAM)! Общая память в пуле – это сколько всего оперативной памяти на всех серверах с установленными лицензиями VSphere, сконфигурированными через VCenter Server, либо отдельно, на каждом хосте ESXi. А вот сконфигурированная память – это количество выданной оперативной памяти всем запущенным ВМ в пуле vRAM, то есть если у нас лицензиями доступно, скажем, 96 Гб, а на серверах у нас 192 Гб, это не нарушение лицензии, это всего-лишь значит, что мы не можем запустить ВМ более чем на 96 Гб в сумме. Но и это не до конца правильно, такое утверждение справедливо лишь для лицензий Essentials и Essentials Plus. У лицензий Standard, Enterprise и Enterprise Plus нет явных ограничений по запуску ВМ, там расчет идет среднего использования памяти в год, если порог за год превышен, то это уже нарушение лицензии. Допустим, у нас лицензиями разрешено использовать 32 Гб, мы полгода использовали 64 Гб, а полгода вообще не использовали сервера, в среднем у нас за год – 32 Гб, и нарушения лицензии не будет. У Essentials китов такой свободы нет, если мы перейдем порог в 192 Гб, а именно столько разрешено использовать в начальных китах, далее ВМ просто не будут запускаться.

Так вот, вернемся к лицензированию “тяжелых” ВМ. Дело в том, что ВМ в новой версии VSphere мы теперь можем выдавать оперативной памяти вплоть до 1 Тб. Но лицензироваться, отбирать vRAM у пула ВМ будет лишь до 96 Гб, далее все будет бесплатно. Например, у нас лицензиями выдано 256 Гб, у нас 2 ВМ по 128 Гб RAM. По идее, вся лицензированная память закончена, но VMware сделала некий бонус, ограничивая снятие памяти с лицензий до 96 ГБ, тем самым 2 ВМ будут работать как 128 Гб памяти но лицензия будет видеть их, как 96 Гб, то есть в сумме 192 Гб, оставив нам еще 64 Гб. Такой бонус не работает для Essentials и Essentials Plus, там если мы используем ВМ 192 Гб, а это значит что она должна исполняться на одном сервере, всего у нас будет 1 сервер, то и вся лицензия будет использована. Это сделано потому, что уровень консолидации будет 1к1, а значит и виртуализироваться смысла не будет. Привожу ссылку на данные ограничения:
Блог VMware
Есть еще один интересный нюанс, меня как то спросили, а что будет если у нас есть 256 Гб в лицензии, и мы включим ВМ 1 Тб, что будет первее, VSphere поймет, что это всего лишь 96 Гб лицензии и пропустит такую ВМ, или скажет что нам выдано 256 Гб и может нам столько не выдать, например нужно создать ВМ с 100 Гб RAM и потом повысить до нужного нам 1 Тб. Тут все просто и ничего не меняется: как я уже писал выше, мы можем включить ВМ даже, если у нас не будет столько в лицензии (для Std, Ent, Ent+), ограничение считается в среднем за год, поэтому все пропустится, включится и ничего дополнительного делать не надо, может быть это еще одна из причин, почему на редакциях Ess, Ess+ данное правило не работает.

Categories: VMware Tags: , , ,

Запуск ESXi внутри виртуальной машины

Очень популярная в последнее время тема, но запишу себе ее в блог, дабы не забыть параметры. Может быть такое, что у нас в наличии есть один сервер ESXi, но в тестовых целях мы хотим использовать несколько гипервизоров, дабы продемонстрировать возможности vSphere. Для этого нам нужно установить гипервизор ESXi как гостевую ОС на ВМ.
Это можно сделать, но по умолчанию аппаратная виртуализация, необходимая для установки гипервизоров VMware, отключена в 4 версии VSphere, нам придется ставить гипервизор и указывать ОС гостевой ВМ, как, например Other Linux (32bit).
Если у Вас уже VSphere 5, то это существенно упрощает задачу, там все гораздо проще.  Нам достаточно лишь выбрать гостевую ОС, как гипервизор ESXi (в ближайшее время выложу скрин, но Вы и сами можете это сделать, найдя в списке гостевых ОС наш гипервизор). Также, чтобы позволить включать внутри виртуального гипервизора ESXi, достаточно добавить внутрь файла /etc/vmware/config параметр (подсказано Михаилом Михеевым):
vhv.allow = «TRUE»
В VSphere 4 нам приходилось изменять конфиг файла .vmx нашей ВМ. Чтобы включить аппаратную виртуализацию на 4 версии, заходим в Edit Settings ВМ (машина должна быть выключена), далее вкладка Options->General->Configuration Parametrs..
Мы попадаем в меню отладки ВМ, вписываем следующие три строки, если их нет в наличии, если какая-то есть, меняем значение:
guestOS = "vmkernel"
monitor_control.vt32 = "TRUE"
monitor_control.restrict_backdoor = "TRUE"
 Выглядеть это будет следующим образом:
После этого сохраняем изменения и включаем ВМ. Теперь ВМ будет считать, что имеет аппаратную виртуализацию, на самом деле мы просто прокинули ее на программном уровне.
Также можно изменить этот файл, зайдя в Tech Support Mode и командой vi изменить .vmx файл нашей ВМ, данные будут расположены там в столбик, разделенные табуляцией. Также можно воспользовавшись просмотром датастора, скачать файл на ПК и изменить его блокнотом.

Проблемы с удалением старых портгрупп ВМ

Проблема:
Может получиться так, что Вы создадите со временем другую портгруппу ВМ (первоначально она называется VM Network), а старую решите удалить. И может возникнуть так, что vSphere Client будет писать, что старая портгруппа приатачена к Вашим, ВМ, хотя Вы все уже перевели на новую. У Вас один адаптер, он «смотрит» в новую портгруппу, а старая все равно показана, что она у этой ВМ есть. Как же тут быть?
Решение:
Тут все очень просто. Дело в том, что до этого вы создавали снэпшоты (снимки) ВМ, которые были еще со старой группой на адаптерах. Дело в том, что снэпшоты сохраняют все старое виртуальное железо, и пока Вы не удалите их, либо откатитесь к ним и поставите новую портгруппу для всех адаптеров, старая портгруппа не удалится.
В принципе тут нет ничего страшного, проще не обращать внимания и не трогать старую портгруппу, даже если Вы переносите ВМ между хостами с разными портгруппами, максимум что будет, это адаптер ВМ не сразу приатачится к новой портгруппе, что конечно же может быть страшно, если требуется от ВМ бесперебойная работа в сети. В этом случае Вам и нужно создавать одинаковые портгруппы, либо переходить на virtual Distributed Switches :)
Categories: 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:

Что такое виртуализация

Решил начать свой блог с самых основ понятия виртуализация, дабы немного ввести людей, несведущих в этом, в курс дела. В большинстве случаев, за процесс консолидации серверного парка в компании в виртуальную среду отвечает ИТ-отдел, а во многих небольших компаниях, даже может один человек, ИТ-директор, он же администратор. И если этот человек не знает ничего о виртуализации, эта компания не будет применять технологии VSphere, Hyper-V, XenDesktop и других гипервизоров. Но давайте по порядку, что же такое виртуализация.
Виртуализация - это процесс представления физических ресурсов в виде некоего набора параметров, объединенных логическим смыслом. Виртуализация может относиться к разным отраслям, например к серверному оборудованию, рабочим станциям, приложениям, виртуализации как услуги (SaaS) и т.д. В моем блоге мы будем чаще останавливаться на этих пунктах, а именно эти услуги и предоставляет компания VMware.
VMware – дочерняя компания корпорации EMC, одной из крупнейших компаний в сфере хранения информации. В 1998 году VMware представила на рынках технологию виртуализации x86 платформ Windows, то есть возможность запуска в одной операционной системе другой. Чтобы было легче понимать, это что-то наподобие эмулятора, когда в окне мы запускаем программу, только вместо программы мы можем запускать другую ОС Windows.
Данная технология стала очень популярной и VMware начала разработки в эту сторону, и уже в 2001 году была выпущена платформа VMware GSX, позволяющая запускать в ОС Windows или Linux несколько других операционных систем. Это позволило запустить на одном сервере несколько серверов.
У серверов всегда было большой проблемой огромное неиспользование процессорных ресурсов, обычно один сервер использовал меньше 10% всего CPU. Большие, мощные сервера зачастую простаивают. В традиционной архитектуре на одном физическом сервере мы используем один, может быть несколько сервисов. В основном мы не можем установить несколько приложений на одной ОС по причине использования одинаковых портов, служб или необходимостью использовать разные ОС. В итоге, мы получаем несколько серверов, которые не загружены и на пятую часть.
Так вот компания VMware решила эту проблему, создав программу GSX, впоследствии переименованную в VMware Server. Но эта программа должна была устанавливаться на стороннюю ОС, либо Windows Server, либо Linux. Материнская ОС также использовала ресурсы и значительно урезала возможности виртуализации.
Также, в том же 2001 году VMware создает свой первый гипервизор, VMware ESX (версия 1.0).
Гипервизор – полноценная, законченная операционная система, обеспечивающая одновременное исполнение нескольких операционных систем, которые называются виртуальными машинами.
Виртуальная машина – программная реализация компьютера для выполнения программ аналогично физическому компьютеру. То есть другими словами, это полноценный компьютер со своим оборудованием, только существующий в виде программы внутри гипервизора. На нем установлена гостевая ОС, то есть ОС внутри виртуальной машины (ВМ).
VMware ESX – это некая оболочка на базе ОС Red Hat Linux Enterprise, имеет свою сервисную консоль, то есть командную строку Linux, очень похожа на обычный линукс, только со своими дополнительными возможностями.
Такой гипервизор весил несколько гигабайт и “ел” дополнительные ресурсы, и уже в 2007 году VMware выпускает свой флагманский продукт, по сей день существующий (ESX летом 2011 года прекратил свое существование, остановившись на версии 4.1) – VMware ESXi, в котором отсутствует сервисная консоль, то есть большинство команд Linux там порезано, а в режим ввода команд можно зайти, лишь нажав Alt+F1.

Таким образом, через 2 года после основания VMware создает независимый гипервизор, правда на нем исполняются те же гостевые ОС, Windows, Linux и т.д. (В 2003 вышел гипервизор ESX 2.0с поддержкой vSMP (virtual symmetric multiprocessing)).
В данный момент гипервизоры компании VMware по данным http://www.v-index.com/ , используют более двух третьих компаний, в которых внедрена виртуализация, и в мире более трети компаний, где виртуализация внедрена. Таким образом, в мире каждая пятая компания уже внедрила виртуализацию.
Расчеты требуют более детального изучения, как-нибудь мы все это рассчитаем, но уже понятно, что благодаря гипервизорам, можно на один сервер “засунуть” огромное количество виртуальных серверов, то есть консолидировать физический парк серверов в виртуальную среду. По данным все того же v-index’а, до 5 ВМ на сервер, в действительности же, в данный момент можно на 1 сервер установить до 512 ВМ на хосте, в зависимости от мощности физического сервера. Для примера, на однопроцессорном 4-ядерном хосте с 16Гб памяти помещается до 10ВМ, что экономит как минимум еще 5 серверов, если бы все это было воспроизведено на физике. Выводы делайте сами.
Еще раз повторюсь, все это относится лишь к серверной виртуализации, существует множество других видов виртуализации, о которых я расскажу немного позднее.

Новый блог виртуализации

Вот и решил открыть свой личный блог, в данный момент моим официальным сайтом также остается: http://www.vsphere5.ru
Но сюда буду сбрасывать временные заметки, довольно простого содержания.

Categories: VMware Tags: