xen exe что это
3 простых шага по исправлению ошибок XEN.EXE
В вашей системе запущено много процессов, которые потребляют ресурсы процессора и памяти. Некоторые из этих процессов, кажется, являются вредоносными файлами, атакующими ваш компьютер.
Чтобы исправить критические ошибки xen.exe,скачайте программу Asmwsoft PC Optimizer и установите ее на своем компьютере
1- Очистите мусорные файлы, чтобы исправить xen.exe, которое перестало работать из-за ошибки.
2- Очистите реестр, чтобы исправить xen.exe, которое перестало работать из-за ошибки.
3- Настройка Windows для исправления критических ошибок xen.exe:
Всего голосов ( 181 ), 115 говорят, что не будут удалять, а 66 говорят, что удалят его с компьютера.
Как вы поступите с файлом xen.exe?
Некоторые сообщения об ошибках, которые вы можете получить в связи с xen.exe файлом
(xen.exe) столкнулся с проблемой и должен быть закрыт. Просим прощения за неудобство.
(xen.exe) перестал работать.
xen.exe. Эта программа не отвечает.
(xen.exe) — Ошибка приложения: the instruction at 0xXXXXXX referenced memory error, the memory could not be read. Нажмитие OK, чтобы завершить программу.
(xen.exe) не является ошибкой действительного windows-приложения.
(xen.exe) отсутствует или не обнаружен.
XEN.EXE
Проверьте процессы, запущенные на вашем ПК, используя базу данных онлайн-безопасности. Можно использовать любой тип сканирования для проверки вашего ПК на вирусы, трояны, шпионские и другие вредоносные программы.
процессов:
Cookies help us deliver our services. By using our services, you agree to our use of cookies.
Citrix Xen Center – Опыт работы с полностью бесплатной виртуализацией
Сразу опишу главный плюс такого решения – Это бесплатно! Любой может более менее полноценно администрировать рабочие места(Windows машины/сервера, linux сервера, любые ОС), работать с бекапами и эффективно использовать мощность железа.
Так уж вышло, что профессиональные решения типа VM Ware стоят очень приличных денег.
Введение
Данная статья преследует цель упростить жизнь таким же энтузиастам, которые по какой-то причине, не являясь большими devOps специалистами, уже развернули визор Xen Server и запустили на нем продакшен проекты.
Как правило, сталкиваясь с проблемами и сложностями на уже запущенной системе, с проектами в продакшене право на ошибку нет.
Здесь мы рассмотрим свой опыт работы, проблемы и их решения, приходящие в процессе эксплуатации Xen Server в полностью бесплатном режиме и без какой-либо подготовки, в формате «разберемся в процессе».
1. Базовая настройка и нюансы установки
Начнем с установки. Процесс довольно прост: скачиваем iso, нарезаем на usb и устанавливаем на свой новоиспеченный сервер, который по нашему плану будет крутить на себе много разных виртуальных машин на разных ip-адресах, позволяя использовать ресурсы оборудования значительно эффективнее и предоставлять нам прекрасные возможности создания снепшотов и работы с ними.
Снепшоты – это образы системы, которые создаются моментально, запоминают точное состояние всей системы (виртуальной машины) на момент снятия и позволяют вернуться к этому состоянию в любой момент, буквально за несколько секунд, сохранив при этом текущее состояние.
Итак, в процессе установки, точнее при ее завершении, будет задан важный вопрос про объединенную файловую систему – Enable thin provisioning (Optimised storage for XenDesktop). Суть всего этого глубже, но нам следует знать важную деталь: если мы ответим да, сможем в дальнейшем при подключении по ssh складывать файлы образов, используя пространство дисков, которые выбрали при установке. Стоит отметить, что в дальнейшем после установки мы сможем прицеплять сколько угодно новых дисков и инициализировать их в системе, но не в общем пространстве, о котором нас спрашивают при установке.
Почему важно иметь возможность использовать общее пространство? Это слегка упрощает разворачивание больших бекапов (снепшотов или образов). Если делать это через интерфейс, то при обрыве соединения весь процесс будет потерян. В случае передачи по sftp вы всегда сможете вернуться к тому же моменту и догрузить файл используя ftp клиент. Можно так же примонтировать сетевой диск и выполнить импорт с него, но здесь важна стабильность сетевого канала.
Есть важный нюанс: доступ к общему пространству, где по совместительству лежат все виртуальные машины основного раздела, происходит по адресу: /run/sr-mount/. Загружая туда файл, нам будет доступно все место из Local storage, но учтите, что в интерфейсе все, что мы займем своими бекапами, учитываться не будет и система в GUI будет говорить, что места больше (на самом деле нет). За этим необходимо следить.
!Важно! Если мы займем все место, а система будет думать, что оно есть, с виртуальными машинами начнет происходить страшная магия, и они начнут выключаться на ровном месте. Самое страшное в этой истории то, что не все машины запустятся после того как мы освободим место. С этим нужно быть предельно внимательными.
Все остальное в процессе установки на дальнейшую работу особо не влияет (по крайней мере в наших сценариях).
2. Запуск, подключение дисков, iso образов и создание машин
После успешного запуска и подключение визора XenCenter из-под Windows (GUI работает только под ним) нам предоставляется возможность пользоваться благами виртуализации и создавать виртуальные машины.
При попытке создать машину нам сразу будет предложено использовать стандартный шаблон, загруженный через импорт снепшот (бекап) или снепшот от текущих машин. Есть так же Xen App, но в нашем бесплатном использовании он не актуален.
Как правило, стандартные шаблоны бесполезны и при создании новой машины, где мы будем устанавливаться с iso, нужно выбирать Other install media. В случае развертывания из снепшотов, разумеется, выбираем снепшот.
Важный момент: при развертывании снепшота системе требуется не только место на диске, на котором мы развертываем виртуальную машину, но и примерно столько же свободного места на основном диске, где лежит снепшот.
Из практических советов: в названии машины пишите ее полный ip-адрес, это упростит процесс администрирования, когда ваших виртуальных машин станет очень много.
Подключение локального репозитория ISO
Для установки любой ОС (а, разумеется, мы захотим поставить всё и вся) необходимо создать репозиторий, куда мы будем складывать свои iso.
Создаем сам репозиторий, через Storage Manager(SR):
$ xe sr-create name-label=LocalISO type=iso device-config:location=/var/opt/xen/ISO_Store device-config:legacy_mode=true content-type=iso
name-label – в данном случае имя репозитория
Сразу после этого в GUI появится новое хранилище:
Чтобы загрузить туда iso нужно загрузить по sftp iso образ в /var/opt/xen/ISO_Store или зайти по ssh в папку и вытянуть образ через wget.
Для активации образов нужно перейти в LocalIso – Storage и нажать кнопку Rescan:
Образ появится в списке.
Так же в список загрузки виртуальной машины(Console – DVD Drive 1) добавится все что инициализировано в локальном репозитории.
Теперь можно выбрать загруженный образ и установить на новую виртуальную машину.
Далее идет обычный процесс установки и использование виртуальной машины. Обратите внимание на то, что лишние виртуальные сетевые карты лучше сразу удалять, чтобы не болтались в системе. По умолчанию там будут все карты сервера.
Подключение дисков к уже настроенной системе
В какой-то момент после запуска и начала использования системы возникнет необходимость подключить новые диски. Сразу отмечу, что есть нюанс с дисками более 2 ТБ, они подключаются немного иначе, ниже это опишу.
Процесс подключения:
Нужно посмотреть список дисков:
2. Далее нужно проверить, есть ли на диске какие-то разделы:
Если разделов нет, этот шаг можно пропустить.
Если разделы есть и нужно использовать весь диск под хранилище, все разделы нужно будет удалить. Делается это просто с помощью fdisk:
Далее нажимаете d, выбираете раздел, который хотите удалить и жмете w, чтобы сохранить изменения.
Если диск больше 2Tb, то следует воспользоваться программой gdisk. Работает так же, как fdisk (gdisk /dev/sdb).
Так как хранилище XenServer использует LVM для разделов, выполним инициализацию диска для работы с LVM:
Если получаем ошибку
Command not permitted while global/metadata_read_only is set,
нужно выполнить ту же команду, но с дополнительным параметром:
Далее нам нужно получить UUID текущего хоста гипервизора:
Копируем полученный uuid и используем его в непосредственно команде по созданию локального хранилища XenServer:
xe sr-create content-type=user host-uuid=27168638-2022-4dcb-aa1c-56de7d59f989 type=lvm device-config-device=/dev/sdb name-label=»Local storage 1.5TB»
Здесь:
host-uuid – uuid гипервизора, полученный из xe host-list
type – тип файловой системы
device-config-device – подключаемый диск
name-label – название диска после подключения (так он будет называться в визоре).
После выполненных манипуляций диск сразу станет виден в XenCenter, его можно использовать для создания виртуальных машин.
После подключения новое хранилище можно выставить как хранилище, используемое по умолчанию.
Небольшое отступление на тему lvm:
Lvm позволяет менять размеры диска на лету, даже если с этого диска запущена система. Это крайне полезная возможность.
Процесс:
Смотрим список томов:
2. Создаем раздел на указанном диске:
В примере *xvdb* – выбранный диск
3. Инициализируем lvm:
В примере *xvdb1* – созданный на предыдущем этапе раздел
4. Отображаем список групп LVM:
5. Включаем новый диск в нужную группу LVM :
В примере *ubuntu-vg* – это выбранная группа LVM.
6. Расширяем выбранную группу на указанный объем:
В данном примере мы увеличиваем объем на 10 ГБ:
В данном примере мы берем весь объем, который доступен, расширяем на максимум доступного пространства:
7. Запускаем сам ресайз в реальном времени, группу нужно посмотреть в /dev/mapper/
В примере */dev/mapper/ubuntu—vg-root * выбранная группа
Нюансы работы со снепшотами
Для создания и администрирования снепшотов требуется довольно много свободного места (больше чем в два раза от размера виртуальной машины).
Если получилось так, что мы создали машину на хранилище, у которого нет достаточного запаса свободного места и создали снепшот, он займет все место.
При попытке его удалить место не вернется назад, но снепшот пропадет (удалится).
Как выйти из этой ситуации?
Есть встроенный механизм для очистки места после удаления снепшотов. Во вкладке Storage есть кнопка «Reclaim free space», но он может не дать желаемого эффекта. Так же стоит учесть, что данная функция создает нагрузку на контроллер и во время выполнения это операции его производительность может сильно упасть.
В этом случае нужно подключить второй диск большего размера, скопировать текущую машину на второй диск, затем удалить ее на первом диске. Virtual Allocated в этом случае исправится сразу, но занятое место не сразу, через некоторое время. На всякий случай можно выполнить команду xe sr-scan uuid
Далее мы копируем машину со второго диска на первый и стартуем ее.
Импорт и экспорт бекапов
При сборке нового сервера стоит учитывать тот факт, что снепшоты снятые с более поздней версии Xen Server. Невозможно импортировать на сервер с более ранней версией Xen Server.
В обратном режиме все работает без проблем, т.е. снепшот, снятый с ранней версии Xen Server корректно импортируется в новую версию.
Также не рекомендуется большие бекапы снепшотов импортировать по сети через визор, надежнее загружать по sftp снепшот и выполнять команду:
xe vm-import filename=/mnt/nfs/TestVM1-compress.xva
filename – адрес расположения бекапа (снепшота)
## 3. Возможности Xen Server и работа с консолью
Здесь мы разберем буквально пару полезных примеров работы с функционалом Xen Server из консоли.
Пример работы с консолью:
Включить автозапуск виртуальной машины после запуска гипервизора:
Получаем uuid нужной виртуальной машины:
Находим виртуальную машину и копируем uuid, далее включаем автозагрузку, подставляя в команду подходящий uuid:
xe vm-param-set uuid=b23sfeefd-aee0-2def-8f15-55b3ef15ea77 other-config:auto_poweron=true
После выполнения команды виртуальная машина будет запускаться вместе с запуском гипервизора.
2. Активировать все доступные ядра для виртуальной машины.
В Citrix XenCenter могут присутствовать некоторые ограничения на выделение количества процессорных ядер. Например, вы можете столкнуться с ограничением в 32 ядра на одну виртуальную машину.
Для того чтобы использовать все доступные ядра, мы так же прибегаем к помощи консоли:
Получаем uuid нужной виртуальной машины:
Выполняем обе команды с указанием количества ядер:
xe vm-param-set VCPUs-max=56 uuid=659795da-49cf-5071-27bd-6eab7b0f5951
xe vm-param-set VCPUs-at-startup=56 uuid=659795da-49cf-5071-27bd-6eab7b0f5951
В итоге получаем виртуальную машину с указанным количеством ядер, точнее, потоков.
4. Удивительные, возможно полезные истории
Здесь я хочу рассказать несколько удивительных историй так или иначе связанных с виртуализацией.
История с нерабочим экраном консоли
Как-то раз при сборке и настройке нового сервера произошло следующее: Xen Server успешно установлен, успешно подключается от Xen Center, создает/редактирует виртуальные машины, все, казалось бы, отлично! Но при попытке запустить какую-либо из машин на вкладке консоли черный экран и потом ошибка, что-то вроде: «Невозможно создать изображение» (точную формулировку не помню).
Множество часов было потрачен на попытку решить эту проблему, подкидывались разные видео карты, отгуглен весь интернет. В процессе разбора было принято решение залезть в конфиги Xen, в которые залезать нельзя и ковыряться именно с настройками адаптера, т.к. все хоть как-то близкие темы вели именно туда.
После редактирования конфигов все закончилось плохо, и в итоге все пришлось устанавливать заново.
Проблема заключалась в закрытом порте у провайдера. Как только переключились на локальную сеть, все заработало. Если столкнетесь с похожей проблемой в первую очередь переключитесь на локальную сеть для проверки!
2. История с рейд массивами, которые спонтанно разлетались
На протяжении долгого времени на одной из машин мы страдали с непонятной проблемой: рейд разных типов периодически рассыпался. Мог отработать 3 месяца корректно и разбиться, мог отработать неделю корректно и рассыпаться.
Материнскую плату (контроллер MegaRaid)
Создавалось впечатление, что это помогало, но потом все снова ломалось. В итоге проблема оказалась с корзиной, а, точнее, с бекплейтом. После ее замены проблема ушла.
3. Подключение удаленных hasp-ключей и других удаленных usb устройств:
При организации виртуальной инфраструктуры может возникнуть потребность в подключении hasp ключей или других устройств, которые проблематично вставлять в сервер в дата центре.
Для решения таких задач есть специальные решения. Например, ПО USB Redirector (бесплатно для Linux).
Эта схема позволяет развернуть сервер на физической машине в офисе и прокинуть на клиент в виртуальную машину любые usb устройства и настроить автоподключение.
Так мы легко прокидывали для решения задач клиентов всякого рода usb на виртуальные машины, хотя когда первый раз услышали про такую задачу в голову приходили дурацкие решения, вроде того, чтобы поехать в ДЦ и вставить usb ключ в сервер.
Тема не новая, но возможно кому то эта информация будет полезна. Очень удобная схема для установки программного обеспечения на виртуальные машины, требующего hasp ключи для работы.
5. Выводы
По моему скромному опыту, для организации полноценной работы с точки зрения обеспечения серверной инфраструктуры для мелко-средней веб-студии бесплатные решения на баз Xen Server отлично подходят.
Они позволяют сэкономить на стоимости Enterprise решений и решить большинство задачи, стоящих перед бизнесом.
Виртуальные машины на платформе Xen
На данный момент этими возможностями обладают платформы компаний VMware, Virtual Iron и, в некоторой степени, SWSoft. Не так давно (в августе 2007 года) к этим участникам рынка присоединилась и компания XenSource, выпустившая после недолгого бета-тестирования четвертую версию своих платформ на основе гипервизора Xen.
О проекте Xen
Разработка некоммерческого гипервизора Xen начиналась как исследовательский проект компьютерной лаборатории Кембриджского университета. Основателем проекта и его лидером был Иан Пратт (Ian Pratt), сотрудник университета, который создал впоследствии компанию XenSource, занимающуюся разработкой коммерческих платформ виртуализации на основе гипервизора Xen, а также поддержкой Open Source сообщества некоммерческого продукта Xen. Основу этой платформы составляет монитор виртуальных машин (гипервизор), работающий в нулевом кольце хостовой системы и управляющий виртуальными системами. Изначально Xen представлял собой самую развитую платформу, поддерживающую технологию паравиртуализации. Эта технология позволяет гипервизору в хостовой системе управлять гостевой ОС посредством гипервызовов VMI (Virtual Machine Interface), что требует модификации ядра гостевой системы. Такой подход обещал высокое быстродействие гостевых систем при малых затратах на поддержание платформы паравиртуализации. Однако, по вполне понятным причинам, далеко не все разработчики проприетарных операционных систем, такие как Microsoft, готовы были пойти на модификацию кода своих платформ, поэтому технология паравиртуализации так и не приобрела популярности. С разработчиками Open Source-систем договориться было проще, однако не все поверили в перспективу технологии. Тем не менее, даже компания VMware, сторонник технологии нативной виртуализации, включила в некоторые свои продукты недокументированную поддержку паравиртуализованных гостевых систем. На данный момент бесплатная версия Xen включена в дистрибутивы нескольких ОС, таких как Red Hat, Novell SUSE, Debian, Fedora Core, Sun Solaris.
Надо отметить, что еще при разработке первой версии гипервизора Xen, сотрудниками Кембриджского университета и лабораторией Microsoft Research был разработан порт операционной системы Windows XP, поддерживающий технологию паравиртуализации, который, однако, не мог быть опубликован в соответствии с лицензионной политикой Microsoft. Тем не менее, опыт, полученный в ходе работы, был зафиксирован и на данный момент доступен в документах проекта Xen. Последний год компания XenSource ведет тесное сотрудничество с компанией Microsoft в рамках партнерских отношений, что позволит XenSource более эффективно виртуализовывать Windows-платформы, а компании Microsoft реализовать полноценную поддержку Linux в платформе Windows Virtualization, которая будет интегрирована в ОС Windows Server 2008 (Longhorn). Уже сейчас XenSource ведет разработку слоя совместимости гипервизора Xen с гипервизором Viridian в Windows Longhorn. Это свидетельствует о наметившейся тенденции объединения усилий различных компаний в конкурентной борьбе с лидером рынка VMware.
В середине августа 2007 года компания XenSource была поглощена компанией Citrix Systems. Сумма проведенной сделки — около 500 миллионов долларов (акциями и денежными средствами) говорит о серьезных намерениях Citrix в отношении виртуализации. Эксперты полагают, что не исключена и покупка Citrix компанией Microsoft, учитывая давнее ее сотрудничество с XenSource.
Платформа Xen
Гипервизор Xen представляет собой открытую платформу виртуализации для архитектур IA-32, x86-64, IA-64 и PowerPC, ведется также работа по портированию его на архитектуру SPARC. Xen может быть развернут на хостах с множеством различных Nix-систем, при этом поддерживаются гостевые Linux, Windows и BSD-системы. В платформе используются как технологии паравиртуализации для запуска паравиртуализованных операционных систем, так и технологии аппаратной виртуализации (VT-x и AMD-V) для поддержки немодифицированных версий ОС в виртуальных машинах. Процессоры, поддерживающие аппаратную виртуализацию, имеют дополнительные инструкции для управления виртуальными машинами, а также два режима работы: root-mode и nonroot-mode. Гипервизор Xen работает в режиме root-mode, напрямую общаясь с аппаратным обеспечением, и управляет гостевыми системами. Платформа Xen поддерживает до 64 процессоров в физической системе (64-way SMP).
Паравиртуализованные системы
Начиная с версии 3.0, гипервизор Xen поддерживает технологии аппаратной виртуализации AMD-V и Intel VT, что позволяет использовать операционные системы Windows в качестве гостевых, а также другие немодифицированные ОС.
Средства управления Xen
Кроме того, для коммерческих изданий Xen компании XenSource существуют такие мощные и многофункциональные средства управления как XenCenter (аналог Virtual Center у VMware для Virtual Infrastructure 3).
Применение бесплатного издания Xen
В настоящее время Open Source версия платформы Xen применяется в основном в образовательных и исследовательских целях. Некоторые удачные идеи, реализованные многочисленными разработчиками со всего мира, находят свое отражение в коммерческих версиях продуктов виртуализации компании XenSource. Сейчас бесплатные версии Xen включаются в дистрибутивы многих Linux-систем, что позволяет их пользователям применять виртуальные машины для изоляции программного обеспечения в гостевых ОС с целью его тестирования и изучения проблем безопасности, без необходимости установки платформы виртуализации. К тому же многие независимые разработчики ПО могут распространять его с помощью виртуальных шаблонов, в которых уже установлена и настроена гостевая система и предлагаемый продукт. Кроме того, Xen идеально подходит для поддержки старого программного обеспечения в виртуальной машине. Для более же серьезных целей, в производственной среде предприятия необходимо использовать платформы компании XenSource.
Платформы компании XenSource
Четвертое поколение продуктов виртуализации компании XenSource на основе гипервизора Xen включает в себя три версии платформы:
XenExpress
Бесплатное стартовое издание системы виртуализации, включающее в себя возможность размещения нескольких виртуальных машин в пределах одного физического сервера. Эта версия является скорее ознакомительной и хорошо подходит для домашних пользователей и небольших компаний, планирующих внедрение виртуализации.
XenServer
Издание платформы для сектора SMB (Small and Medium Business), обеспечивающее решение основных задач по консолидации виртуальных серверов на нескольких физических хостах.
XenEnterprise
Наиболее полная версия платформы виртуализации, включающая в себя, помимо возможностей XenServer, также и необходимые средства по агрегации ресурсов, распределению нагрузки, живой миграции и обеспечению высокой доступности.
Структура возможностей каждого из изданий Xen приведена ниже:
Каждый из продуктов компании XenSource поддерживает 64-битные гостевые операционные системы (это позволяет использовать на полную мощность такие продукты, как Microsoft Exchange x64 или SQL Server x64), обладает открытым интерфейсом для написания приложений, взаимодействующих с виртуальными машинами (XenAPI на языках C, Python и C#), а также позволяет использовать продукт XenCenter для централизованного управления серверами виртуализации. Кроме того, XenServer и XenEnterprise включают в себя техническую поддержку и возможность использования нескольких физических серверов, а XenEnterprise обладает всеми необходимыми возможностями для применения виртуальных машин в производственной среде предприятия. В четвертом квартале 2007 года планируется также реализация поддержки решений компании Symantec для устройств хранения данных, а также «горячего» резервного копирования виртуальных машин. Надо отметить также, что издания XenExpress и XenServer могут быть «прокачаны» до изданий XenServer и XenEnterprise соответственно, путем введения нового лицензионного ключа без необходимости переустановки платформы.
Технические возможности изданий Xen
В приведенной ниже таблице представлены технические характеристики изданий платформ XenSource:
Возможности / Платформа | XenExpress | XenServer | XenEnterprise |
Число управляемых физических серверов | Один сервер | Несколько серверов | Несколько серверов с возможностью создания пулов ресурсов |
Число поддерживаемых процессоров хоста | 2 процессорных гнезда | Не ограничено | Не ограничено |
Объем оперативной памяти хоста | От 1 до 4 ГБ | От 1 до 128 ГБ | От 1 до 128 ГБ |
Число одновременно запущенных виртуальных машин | До 4-х | Не ограничено | Не ограничено |
Объем оперативной памяти, выделенной виртуальной машине | До 4 ГБ | До 32 ГБ | До 32 ГБ |
Возможность добавления в пулы ресурсов | Нет | Нет | Да |
Использование систем хранения | Выделенная система хранения | Выделенная система хранения | Общие и выделенные системы хранения (iSCSI SANs, Fiber Channel SANs, NFS NAS) |
Дополнительные возможности | Нет | Нет | Живая миграция виртуальных машин, конфигурация VLAN, управление выделением ресурсов хостов (CPU, память, сеть) |
Поддерживаемое оборудование
Компания XenSource регулярно обновляет списки поддерживающего платформу Xen оборудования (HCL, Hardware Compatibility Lists), которые можно найти по адресу: http://hcl.xensource.com. Эти списки составляются как на основе тестов самой компании XenSource, так и информации производителей аппаратного обеспечения, а также членов сообщества Xen. Что касается поддерживаемых процессоров, то продукт XenEnterprise в данный момент поддерживает множество серверных платформ.
Системные требования и поддерживаемые гостевые системы
Сейчас платформы Xen поддерживают следующие гостевые системы:
Возможности XenEnterprise и XenCenter
В совокупности эти два продукта компании XenSource позволяют развернуть по-настоящему гибкую и легко управляемую виртуальную инфраструктуру, которая вполне может посоперничать с инфраструктурой VI3 компании VMware. Безусловным плюсом четвертой версии XenEnterprise является возможность использовать системы хранения данных в сетях SAN по протоколам iSCSI и Fiber Channel. Платформы XenSource используют испытанный формат виртуальных дисков компании Microsoft (VHD, Virtual Hard Drive), что позволяет довольно просто осуществлять миграцию между платформами компаний Microsoft и Virtual Iron, использующих этот же формат. Также XenEnterprise позволяет осуществлять живую миграцию виртуальных машин в пределах пула ресурсов между различными хостами в случаях с общей системой хранения, когда требуется остановка серверов для их обслуживания, чрезмерного увеличения нагрузки или износа оборудования. Эта возможность имеет название XenMotion и аналогична по своей сути функциям VMotion компании VMware. При миграции виртуальной машины на другой физический хост, работа виртуальной машины по отношению к внешним источникам не прерывается, что обеспечивает нулевое время простоя критически важных production-серверов.
Продукт XenCenter, обеспечивающий поддержку всех изданий платформ XenSource, позволяет централизованно управлять виртуальными машинами с выделенного сервера, осуществлять мониторинг производительности хостов в реальном режиме времени, выделять физические ресурсы виртуальным машинам в зависимости от приоритетов (QoS, Quality of Service), а также напрямую подключаться к консолям гостевых систем. В ближайшем будущем ожидается появление функций по автоматическому распределению нагрузки между хостами и обеспечению высокой доступности виртуальных серверов посредством XenCenter.
Миграция виртуальных машин Xen
К сожалению, компания XenSource не предоставляет собственного средства для P2V-миграции, в отличие от VMware, предлагающей VMware Converter. Также на данный момент нельзя напрямую конвертировать виртуальные машины бесплатного Xen в формат платформ XenSource, однако в ближайшем будущем ожидается переход компании на формат OVA (Open Virtual Appliances), что позволит использовать виртуальные машины в любом окружении Xen.
Производительность платформ Xen
Поскольку платформы компании XenSource вышли на серьезный Enterprise-уровень, в мире виртуализации разгорелись ожесточенные споры о производительности платформ в отношении продуктов виртуализации компании VMware (в частности ESX Server). В прошлом году VMware провела исследование по сравнению производительности гипервизоров Xen и ESX Server и сделала вывод о том, что последний заметно выигрывает в производительности. По результатам тестов SPECcpu2000, Passmark и прочих, затраты на виртуализацию гипервизора ESX Server в два раза меньше затрат гипервизора Xen версии 3.0.3. Снижение производительности ESX Server по сравнению с нативной составляет от 0 до 6 процентов, в то время как затраты Xen в некоторых тестах доходят до 12 процентов. Результат одного из тестов приведен ниже:
Однако компания XenSource не согласна с таким положением дел и в документе «A Performance Comparison of Commercial Hypervisors» дает понять, что по результатам того же теста разница составляет всего в 1 процент в пользу ESX. При этом по результатам тестов программы Passmark в отношении операций с памятью, гипервизор Xen опережает ESX, в то время как в тестах VMware совершенно обратная ситуация.
Поэтому в аспекте производительности сложно рассчитывать на объективную оценку. Но ясно одно: компания VMware серьезно воспринимает инфраструктуру XenEnterprise как ближайшего конкурента VMware Infrastructure 3.
Виртуальные лаборатории с помощью продуктов XenSource
Одним из главных продуктов компании VMware в корпоративном секторе является решение VMware LabManager (бывший продукт Akimbi Slingshot), позволяющее централизованно развертывать виртуальные машины в пределах виртуальной инфраструктуры, применяемое сейчас, в основном, для целей разработки и тестирования ПО в больших масштабах. VMware LabManager является одним из самых дорогих продуктов компании, на который она возлагает большие надежды. Компания XenSource также решила вторгнуться в сегмент рынка виртуальных лабораторий, заключив партнерское соглашение с компанией VMLogix.
Продукт VMLogix LabManager выполняет те же функции что и LabManager VMware и нацелен на быстрое развертывание виртуальных машин при потоковой разработке ПО для демонстрации дефектов, испытаний программных комплексов в различных многомашинных конфигурациях и быстрой доставки программного обеспечения конечному пользователю. В этой категории продукты VMLogix вполне могут соперничать с решениями VMware.
Заключение
Зародившись как чисто исследовательский проект сообщества Open Source, Xen постепенно эволюционировал в поистине мощную платформу виртуализации благодаря усилиям компании XenSource. Эта компания является одной из немногих, кто предлагает несколько изданий платформ виртуализации для серверов в организациях различного масштаба. Множество энтузиастов по всему миру принимают участие в доработке открытой версии Xen и используют его для запуска виртуальных систем в самых различных целях. Безусловно, Xen имеет большие перспективы, несмотря на то, что технология паравиртуализации, на которую он был изначально нацелен, уже практически умерла. Аппаратная виртуализация, на которую сделала ставку XenSource, набирает обороты и в скором времени, возможно, вытеснит программные техники. По крайней мере, в этом сильно заинтересованы такие крупные вендоры процессоров, как Intel и AMD.
Включение Xen в дистрибутивы многих Linux-систем, бесспорно, будет способствовать росту популярности технологий виртуализации среди конечных пользователей, которым необходимо одновременно работать в двух мирах: Windows и Linux.
Платформы компании XenSource, развивающиеся стремительными темпами, уже сейчас составляют хорошую конкуренцию продуктам VMware. С точки зрения функциональности, им не хватает лишь некоторых решений по обеспечению высокой доступности и целостности виртуальной инфраструктуры, как у VMware. Будем надеяться, что покупка XenSource компанией Citrix даст дополнительный импульс в развитии платформы Xen и подарит рынку технологий виртуализации еще одного сильного конкурента VMware.