Архив

Публикации с меткой ‘trouble’

Ошибка клонирования при разном времени на хостах ESXi

Недавно столкнулся с небольшой проблемой, при клонировании ВМ на другой хост на 99% появляется ошибка:

Failed to clone a VM, error: Invalid configuration for device «0″

Дело в том, что время у гипервизоров, между которыми осуществляется клонирование не должно различаться более чем на 5 минут. Если же время сбито, может появиться подобная ошибка. В этом случае все хосты нужно синхронизировать с одним NTP сервером и клонирование пройдет без каких-либо проблем.

Categories: VMware Tags: , ,

Бэкап конфигурации 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: , ,

Запуск 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: , , ,