Меню Рубрики

Установка и настройка xen ubuntu

Ubuntu Documentation

The Xen Project hypervisor is an open-source type-1 or baremetal hypervisor, which makes it possible to run many instances of an operating system or indeed different operating systems in parallel on a single machine (or host). The Xen Project hypervisor is the only type-1 hypervisor that is available as open source. It is used as the basis for a number of different commercial and open source applications, such as: server virtualization, Infrastructure as a Service (IaaS), desktop virtualization, security applications, embedded and hardware appliances. The Xen Project hypervisor is powering the largest clouds in production today. 1

As of Ubuntu 11.10 (Oneiric), the default kernel included in Ubuntu can be used directly with the Xen hypervisor as the management (or control) domain (Dom0 or Domain0 in Xen terminology).

During installation of Ubuntu

During the install of Ubuntu for the partitioning method choose «Gu >

Installing Xen

Install a 64-bit hypervisor. (A 64-bit hypervisor works with a 32-bit dom0 kernel, but allows you to run 64-bit guests as well.)

As of Ubuntu 14.04, GRUB will automatically choose to boot Xen first if Xen is installed. If you’re running a version of Ubuntu before 14.04, you’ll have to modify GRUB to default booting to Xen; see below for details.

And then verify that the installation has succeeded:

Network Configuration

It’s assumed that you are using a wired interface for your network configuration. WiFi networks are tricky to virtualize and many times not even possible. If you are feeling adventurous, please start here Xen in WiFi Networks.

For this example, we will use the most common Xen network setup: br >

Disable Network Manager

If you are using Network Manager to control your internet connections, then you must first disable it as we will be manually configuring the connections. Please note that you are about to temporarily lose your internet connection so it’s important that you are physically connected to the machine.

Using br >

Restart networking to enable xenbr0 br >

The brctl command is useful for prov >

Using Open vSwitch

Now bring the interfaces up and acquire an IP address through DHCP. You should have your internet connection back at this point.

Recommended Br >

For performance and security reasons, it’s highly recommended 2 that netfilter is disabled on all br >

Creating vms

There are many options for installing guest images:

virt-builder: A program for building VM disk images; part of the libguestfs set of tools

xen-tools: A set of scripts for creating various PV guests

virt-manager: A management system using libvirt
Converting an existing installation

Or you can manually create one, as described below.

Manually Create a PV Guest VM

In this section we will focus on Paravirtualized (or PV) guests. PV guests are guests that are made Xen-aware and therefore can be optimized for Xen.

As a simple example we’ll create a PV guest in LVM logical volume (LV) by doing a network installation of Ubuntu (other distros such as Debian, Fedora, and CentOS can be installed in a similar way).

List your existing volume groups (VG) and choose where you’d like to create the new logical volume.

Create the logical volume (LV).

Confirm that the new LV was successfully created.

Get Netboot Images

Set Up Initial Guest Configuration

Start the VM and connect to the console to perform the install.

Once installed and back to command line, modify guest configuration to use the pygrub bootloader. These lines will change

Now let’s restart the VM with the new bootloader. (If the VM d >

Quick XL Console Tips

Connect to the VM console

Disconnect from the console

Manually installing an HVM Guest VM

Create a guest config file /etc/xen/ubuntu-hvm.cfg

After the install you can optionally remove the CDROM from the config and/or change the boot order.

For example /etc/xen/ubuntu-hvm.cfg:

Xen Toolstack Choices

Xen and xl

xl is a new toolstack written from the ground up to be a replacement for xend and xm. In Xen 4.4, xl is the default toolstack and xend is deprecated. It is planned to be removed in Xen 4.5.

xl is designed to be command-for-command compatible with xm. You should be able to use the same config file and the same commands you’re used to; just use «xl» instead of «xm».

To switch back to xm, do the following:

xl and xm are very similar in functionality with a few notable exceptions: http://wiki.xen.org/wiki/XL

Xen and Libvirt

Ubuntu 14.04 contains libvirt 1.2.2, which contains support for Xen, both libxl and xend. If you specify «xen:///» as the hypervisor, it will automatically detect which is the appropriate method to use.

Xen and XAPI

Other tips and tricks

Create and format disk image file

Xen and Grub on older versions of Ubuntu

Modify GRUB to default to booting Xen («Xen 4.1-amd64» should be replaced with the appropriate name, in 12.10 the line is «Ubuntu GNU/Linux, with Xen hypervisor». The current string can be obtained by looking for one of the menuentry lines in /boot/grub/grub.cfg. In theory the first element created by the 20_linux_xen script):

See Also

External Links

Xen (последним исправлял пользователь 2-launchpad-joe-philipps-us 2015-04-17 17:45:35)

The material on this wiki is available under a free license, see Copyright / License for details
You can contribute to this wiki, see Wiki Guide for details

источник

Установка и настройка гипервизора Xen (монитора виртуальных машин) с пробросом видеокарты в гостевую ОС (Windows)

Комментарии (29)

fox4, спасибо за статью! Нужно будет попробовать. Ни разу не ставил Xen, всегда считал, что VirtualBox проще в использовании. Конечно, все зависит от поставленных задач. Мне не нужна высокая производительность в гостевой системе. Мне нужно загружаться в установленную винду (т.е. dualboot). С помощью xen это можно реализовать?

По идее да в файле конфигурации vm.cfg нужно указать примерно следующее
disk = [ ‘phy:/dev/sdb,hdc,w’, ‘phy:/dev/cdrom,hdd:cdrom.r’ ]
где /dev/sdb ваш раздел с виндой
определить раздел можно командой
sudo fdisk -l

Супер, только время кончилось, найду время обязательно пробну!

Достаточно интересный и глубокий материал, достойный не просто плюса, а номинации на помещение в подшивку (не знаю как и кем это решается), хотя и мало кому пригодится в силу специфики оборудования.

ЗЫ: Когда-то у меня был руководитель, который, естественно, первым читал все входящие поступления – от служебных инструкций до статей в серьёзных журналах. И своей рукою расставлял недостающие знаки препинания, в основном запятые. Никто не понимал – зачем? А некоторые даже посмеивались над ним. Только что и я почувствовал себя на его месте.

Ну у технарей частенько проблемы со знанием орфографии и пунктуации. Да и прогресс сильно расслабляет — будет время поправлюсь. (Казнить нельзя, помиловать 🙂 ).
А на счёт специфичности оборудования — до 3 пункта статья подойдет многим если нет высоких требований к GPU видеокарта будет эмулироваться.

Да нет, я не в претензии. Можно ничего не менять. Просто, кроме положительных эмоций, пережил и ранее неизведанное ощущение – решил поделиться.

Так в сравнении с Виртуал боксом — летает ?

Если сильно завязан на CPU выигрыш несомненный пробросишь видеокарту разницы нет вообще в остальном вопросы решаемые но есть нюансы будут вопросты задавай.

а блин, пытаюсь пробросить видеокарту, почему-то нифига не выходит, к олдной видеокарте цепляю один монитор, к другой второй монитор, только если не выставлять nomodeset при обычно буте вся картинка сплющивается, когда пытаюсь включить Xen почему-то диалоговое окно появляется на мониторе для гостевой ос, и выводится ошибка low graphic mode, выставляю nomodeset этот пунктик проходит, вроде начинает загружать убунту, но потом вылазит ошибка load fallback graphic devices [fail] или Fixing recursive fault but need reboot или init failsafe-x main process terminated with status 1. Кто знает как решить?

Аппаратную конфигурацию компа в студию пожалуйста.
И посмотрите в биосе у какой графической карты приоритет использования похоже у вас Dom0 пытается использовать сразу обе видеокарты и не может разобраться какую инициализировать первой а какую второй они у вас случайно не одинаковые ?

Возможно ли имея один монитор и одну видяху (INTEL) настроить так что бы можно было просто переключаться между системами (горячими клавишами или как нибудь ещё)?

второй Х сервер, почти всему, вторая видяха, вторая видео карта (не 100%, что будет работать тут. Но попытаться стоит)

второй Х сервер, почти всему, вторая видяха, вторая видео карта (не 100%, что будет работать тут. Но попытаться стоит)
MaximChuvashev пытаться не стоит поскольку работать не будет (уровень привилегий XEN и X сервера скажем так сильно отличаются) скорее инженеры в скором времени реализуют что то типа аппаратной эмуляции видеокарты но это все будет доступно только на новом железе (если вообще реализуют).

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

Ну в общем не вижу препятствий изолируйте обе прокидываемые видюхи (надеюсь обе Radeon ) создайте 2 файла конфигурации для 2 ВМ в одном пропишите одну видяху в другом другую и эксперементируйте должно получиться. И ещё всю ОЗУ память компа распределите между двумя ВМ и Xen-ом грамотно чтоб всем досталось иначе будут дикие тормоза.

Если вы имеете ввиду использование одной графической карты со всеми «прибамбасами» 3D и прочее в обоих системах то это не возможно, по крайней мере сейчас, но для «гостевой» системы XEN эмулирует VGA карточку. (Статья до 3 пункта).

Статья отличная! Но немного полазил по сайту интела, 4930к, 3930к, 4820к Технология виртуализации Intel® для направленного ввода/вывода (VT-d) ‡ = yes. Хотя мой 4700mq VT-d не поддерживает. А как хотелось бы завернуть ЮСБ 3.0 в ВМ. Всё равно автору респект!

Спасибо. Ну так статье уже больше года. За это время Intel мог в своих процах поменять всё что угодно маркировку технологии и так далее. Так что да вы правы если нужен проброс обязательно надо смотреть на присутствие технологии VT-d.

А это на каком этапе — Создание ВМ в virt-manager как я понимаю ?
вот ссылка там в конце статьи решение проблемы и в последующих комментариях вроде похожая ситуация обсуждалась правда язык забугорный.
Ну и версию питона у себя проверьте на всякий случай а то судя по логу 2.7 пытается использовать а сейчас вроде уже выше 3 версии гуляют.

Версии 3 пока ещё гуляют только в умах энтузиастов. Мало питонья на него портировано.

источник

Ещё один блог сисадмина

воскресенье, 1 июня 2014 г.

Памятка по настройке Xen

Xen — довольно распространённая и хорошо зарекомендовавшая себя система виртуализации. В ней можно выделить три главных компонента:

  • Гипервизор — небольшое ядро, осуществляющее управление памятью и процессором,
  • dom0 — система, находящаяся под управлением гипервизора, но определяющая политику распределения памяти и процессоров, которую и реализует гипервизор,
  • domU — система, находящаяся под управлением гипервизора.

dom0, как и гипервизор, в системе может быть только один. domU может быть несколько. Для простоты в статье будем называть dom0 хост-системой, а domU — гостевыми системами, хотя строго говоря — они оба скорее гости, просто один из них имеет право управлять гипервизором.

Сервисы Xen, работающие в dom0 и осуществляющие управление гипервизором, написаны на Python. Соответственно, файлы конфигурации являются фактически исходными текстами на языке Python.

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

Устанавливаем пакет xen-linux-system:
Выставляем приоритет загрузки гипервизора Xen из GRUB:
Для отмены приоритета загрузки Xen из GRUB можно выполнить следующую команду:
Чтобы настройки GRUB вступили в силу, запустим обновление конфигурации GRUB:
2. Настройка хост-системы

Образы гостевых систем будем размещать на логических томах LVM2, поэтому сначала установим утилиты для управления логическими томами:
Создадим новый физический том на специально выделенном для этого разделе:
Установим инструменты для создания образов и управления гостевыми системами:
Пропишем в файле /etc/xen-tools/xen-tools.cfg опции, задающие настройки создаваемой по умолчанию виртуальной машины:
Все гостевые системы будут подключаться к виртуальному сетевому мосту, соединённому с физической сетевой картой. На самом деле сетевой мост является по сути виртуальным коммутатором, поддерживающим протокол STP, но по сложившейся традиции называется сетевым мостом. Установим утилиты для управления сетевым мостом:
Настроим интерфейс xenbr0, подсоединив его к физическому сетевому интерфейсу eth0. Для этого впишем в файл /etc/network/interfaces следующие настройки:
3. Создание образа гостевой системы

Для создания образа новой гостевой системы с именем ns, настройками по умолчанию, но с двумя выделенными системе ядрами процессора, введём на хост-системе следующую команду:
После создания образа будет выведен пароль пользователя root в только что созданной системе. Его необходимо запомнить или записать и поменять при первом запуске созданного образа.

Теперь можно отредактировать конфигурацию только что созданной гостевой машины /etc/xen/ns.cfg:
При запуске гостевой машины её первый интерфейс будет подключен к мосту хост-машины xenbr0. Если необходимо создать несколько сетевых интерфейсов, можно перечислить их внутри квадратных скобок через запятую.

4. Управление гостевыми системами

Запуск гостевой машины:
Просмотр списка активных гостевых машин:
Просмотра потребления ресурсов внутри каждой гостевой машины:
Остановка гостевой машины:
Вход на консоль гостевой машины:
Для отключения от консоли можно нажать Ctrl и ] К сожалению, эта же комбинация клавиш используется в telnet, поэтому я предпочитаю сразу настроить сеть и SSH, а дальнейшую настройку гостевой системы осуществлять уже через SSH.

5. Донастройка гостевых систем

Файл конфигурации гостевой системы может выглядеть примерно следующим образом:
6. Что следует установить в гостевую систему?

Я для себя сформировал следующий контрольный список:
Не всё из этого необходимо, поэтому вы можете оставить из этого списка то, что вам нужно и дополнить его пакетами по своему вкусу. При установке openntpd и postfix стоит подумать об их настройке.

Если вам когда-нибудь понадобится воспользоваться консолью гостевой системы, стоит установить пакеты, ответственные за консоль, клавиатуру и локаль:
Соответственно, можно задать их настройки при помощи следующих команд:
Ниже приведены пункты конфигурирования, отличающиеся от значений по умолчанию, которые я обычно выбираю для настройки этих пакетов:
7. Отключение сохранения-восстановления гостевых систем

При остановке демона xen, а также при выключении и перезагрузке системы, демон по умолчанию пытается сохранить состояние всех гостевых систем в каталог /var/lib/xend/storage, из-за чего может закончиться всё место на диске.

Изменить это поведение можно в файле /etc/default/xendomains настройкой значения XENDOMAINS_SAVE. Можно указать другой каталог, в котором есть достаточно места для сохранения образов оперативной памяти гостевых систем, а можно полностью отключить сохранение, указав пустое значение:
Чтобы удалить сохранённые образы памяти гостевых систем, можно воспользоваться следующими командами:
8. Автозапуск виртуальных машин

По умолчанию при перезагрузке хост-системы восстанавливается сохранённое состояние гостевых систем. Если мы отключили сохранение и восстановление гостевых систем, то гостевые системы запущены не будут. Чтобы гостевые системы автоматически загружались при загрузке хост-системы, нужно создать каталог автозапуска и поместить внутрь него символические ссылки на конфигурации необходимых гостевых систем:
9. Решение проблем

источник

Облако с нуля с использованием XenServer

Недавно мы создали небольшое облако для решения наших внутренних задач и хотим поделиться этим опытом с читателями Хабра. Здесь мы подробно опишем, какое оборудование было выбрано для развёртывания облака и как создать инфраструктуру облачной системы, опираясь на XenServer от компании Citrix. В этом продукте Citrix решила отказаться от стандартного подхода, когда у облака есть некоторый центральный управляющий узел, они разбили его на несколько составляющих и предложили их тоже поместить в облако. Кому интересно, как это всё работает — добро пожаловать под кат!

В нашей статье мы остановимся на таких моментах, как: подготовка аппаратной части, установка XenServer, установка лицензии, создание виртуальной сетевой инфраструктуры, опишем проблемы, возникшие с виртуальными машинами на ОС Ubuntu, расскажем про динамическую балансировку нагрузки, про настройки и разграничение доступа к облаку, и, разумеется, покажем, что у нас получилось.

Подготовка аппаратной части

Первой задачей становится выбор основы для любого облака, а именно — выбор серверов, на которых будет производиться виртуализация. Мы остановили свой выбор на серверах от компании IBM и выбрали IBMx3850 X5.
Каждый IBM основан на IBM X-Architecture и имеет:
• 4 процессора Intel® Xeon® CPUE7- 8860 с тактовой частотой 2.27GHz, что в итоге даёт 40 ядер на сервер (80 потоков);
• 150Гб RAM;
• 2 независимых блока питания;
• карту расширения fibre channel;
• сетевую карту для 10-гигабитного соединения;
• 2 жестких диска по 500Гб, объединённых в RAID1.

Дальше возникает вопрос: где хранить виртуальные машины? Если их хранить на самих серверах, то это уменьшает надёжность системы, т.к. при выходе из строя сервера мы потеряем все виртуальные машины, которые были на нём. Также такой подход сильно усложняет задачу балансировки нагрузки, потому что миграция виртуальной машины потребует перемещения её диска на другой сервер, а это — достаточно долгий процесс. Поэтому в нашем стенде используется внешнее хранилище DELL md3620f, оснащённое 4 выходами fibre channel. Это хранилище поддерживает до 24 жестких дисков, которые могут быть объединены во все популярные типы рейдов(RAID0, RAID1, RAID5, RAID6, RAID01). Мы в нашем случае используем 10 жестких дисков по 1ТБ, объединённых в RAID5.

Что требуется для быстрой миграции? Для обеспечения быстрой миграции между IBMами в состав стенда был добавлен 10гигабитный коммутатор summit x670, это теоретически должно было ускорить миграцию (самый долгий процесс в миграции – передача данных по сети от одного сервера к другому) в 10 раз, но на практике это дало выигрыш только в 5-6 раз. Чтобы у серверов и виртуальных машин был доступ в локальную сеть и Интернет, в состав стенда был добавлен коммутатор HP ProCurve.Также через него идёт трафик к внешним клиентам.

Подводя итог по аппаратной части, мы имеем стенд, включающий в себя:
• 4 сервера IBMx3850 X5
• коммутатор HP ProCurve для соединения до 1000 Мб/сек
• коммутатор Summit x670 для поддержки соединения 10Гбит/сек
• внешнее хранилище DELL md3620f с 10Тб дисковым массивом
• и прочее (источник бесперебойного питания APC Smart-UPS 3000VA, трансиверы для оптоволокна, восемь десятиметровых оптоволоконных кабелей, 50 метров витой пары )

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

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

Если суммировать, то мы имеем:
• 160 вычислительных ядер (320 потоков);
• 600Гб RAM;
• 14ТБ дискового пространства;
• Высокоскоростную сетевую инфраструктуру.

Установка XenServer

Для запуска виртуальных машин на выбранном нами железе, было решено развернуть облачную платформу XenServer Platinum.
Краткая общая информация о XenServer, если кто не сталкивался: XenServer — это самостоятельная операционная система, основанная на ядре Linux. В основе всего лежит гипервизор XEN, последняя на данный момент версия — используемая версия XenServer 6.1 — основана на гипервизоре XEN 4.1. Для нормальной работы системы необходим процессор с поддержкой виртуализации и 1Гб RAM. Ребята из Citrix не любят писать свои минимальные требования, предпочитая писать максимальные системные требования, с ними можно ознакомиться тут. В семейство XenServer входит несколько версий продукта, отличающиеся ценой и дополнительными функциями.

На все сервера IBM необходимо установить XenServer. Сама установка XenServer является совершенно несложным процессом и не очень отличается от установки Ubuntu. Куда больший интерес представляет настройка системы для последующей удобной работы, что и будет рассмотрено дальше, основное внимание будет уделено компонентам расширения для XenServer, которые предоставляет Citrix. После установки XenServer на все хосты необходимо зайти в XenCenter (его можно скачать, зайдя на web-интерфейс установленного XenServer или с сайта Citrix). В XenCentеr необходимо создать пул и добавить к нему сервера.

Установка лицензии

После установки XenServer первым делом нужно установить лицензии на сервера. Это делается не с помощью ввода лицензионных ключей, а с помощью установки сертификата, полученного в личном кабинете на сайте Citrix. Сертификат представляет собой текстовый файл с лицензионными ключами, записанными в специальном формате. Его можно получить сразу на несколько серверов. Сертификат необходимо установить в специальный центр лицензирования. Тут стоит отметить, что если хотя бы один из сертификатов является не валидным, то все сертификаты не будут действовать.

Citrix предлагает установить центр лицензирования либо на отдельном хосте, либо на виртуальной машине в вашем облаке (она почти не потребляет ресурсов процессора и требует всего 256 Мб оперативной памяти). Но если вы установите его как виртуальную машину, вас могут ожидать неприятности. Однажды вы можете столкнуться с проблемой, с которой столкнулись мы, когда отключили сервера нашего стенда для их апгрейда, а вместе с ними выключилась, соответственно, и виртуалка с центром лицензирования. После включения XenServer выдал ошибку «Кончился срок пробной лицензии» (центр лицензирования ведь был не запущен). Вроде проблем быть не должно: просто включить виртуальную машину центра лицензирования с нормальной лицензией и принять её. Но не тут-то было: с истёкшей лицензией нельзя включить НИКАКУЮ виртуальную машину. Правда, после первоначальной паники в меню принятия лицензии была найдена кнопка «активировать бесплатную версию», после нажатия которой мы увидели фразу «у вас осталось 30 дней пробной лицензии». И уже потом можно запустить виртуальную машину с лицензией.

Создание виртуальной сетевой инфраструктуры

Чтобы гибко управлять сетевыми настройками виртуальных машин и чтобы они не были в одной подсети с серверами XenServer, необходимо наладить виртуальную сетевую инфраструктуру. Для этих целей у Citrix предусмотрен компонент Distributed Virtual Switch Controller (DVSC). Он также предоставляется в виде виртуальной машины, но она потребляет уже больше ресурсов: 2 VCPU и 2Гб оперативной памяти. Настройки DVSC не представляют собой ничего сложного: необходимо указать свободный IP-адрес для виртуальной машины, после чего добавить пул к DVSC.Всё это делается через web-интерфейс. После этих действий появляется возможность создавать виртуальные сети между виртуальными машинами, находящимися на разных серверах (Cross-ServerPrivateNetwork), тогда как до этого было возможно создавать виртуальные сети только в рамках одного сервера (Single-ServerPrivateNetwork).

Если зайти на web-интерфейс DVSС, то там можно увидеть много полезной информации о сетевой инфраструктуре: список созданных сетей, список виртуальных машин, подключенных к конкретной сети, сообщения об ошибках в сети, графики сетевой активности (как для конкретной виртуальной машины, так и для всей сети в целом).

Также DVSC может выступать в роли простого межсетевого экрана, правила которого можно создавать во вкладке AccessControl. Все политики сетевой безопасности делятся на 4 уровня: глобальные политики (т.к. к одному DVSC могут быть подключены несколько пулов), политики пула, политики конкретной сети, политики конкретной виртуальной машины. Правила описывают тип действия (разрешить или запретить), протокол (можно задать порты получатели и отправителя или указать известный протокол) и для кого это правило применять.

В работу межсетевой экран вступает сразу после установки, и в нём сразу записаны 4 базовых глобальных правила:
• разрешать все ARP-сообщения в сети
• разрешать виртуальным машинам получать IP-адрес по dhсp
• разрешать виртуальным машинам обращаться к DNS-серверам
• разрешать весь сетевой трафик (это правило применяется после проверки всех правил других уровней)

Вообще DVSC всем хорош, и по функционалу чем-то напоминает vShield Edge от VmWare, но Edge кажется удобнее за счёт разных мелочей: возможности создания DHCP-сервера, удобной организации Nat для виртуальных машин и т.д. Всё это (отсутствие DHCP-сервера и Nat), конечно, решается с помощью создания отдельной виртуальной машины на базе Ubuntu, но удобно, когда всё уже решено заранее.

Проблема с созданием виртуальной машины с Ubuntu

Вообще создание виртуальных машин с Ubuntu в первый раз вызывает шок и непонимание — как такое попало в релизную версию продукта? Дело вот в чём:

После создания виртуальной машины из стандартного шаблона она не может запуститься и пишет указанную выше ошибку (Error code: INVALID_SOURCE). Ошибка связана с параметрами загрузки виртуальной машины. Бороться с ней можно следующим образом(описание взято тут и чуть-чуть модифицировано для работы с большим числом виртуальных машин):
1. Зайти в консоль XenServer, что можно сделать через XenCenter (вкладка Console у сервера) или по ssh.
2. Узнать uu >

3. Дальше необходимо установить параметры загрузки следующей командой: xe vm-param-setuu > 4. После этих несложных манипуляций виртуальная машина успешно запустится.

Но на этом ошибки, связанные с работой Ubuntu, не заканчиваются. При создании нашего стенда было принято решение создать шаблоны виртуальных машин с разными ОС, чтобы не тратить время на установку нужной, а сразу брать готовую и туда ставить уже необходимое ПО. С машинами на базе Windows нет никаких проблем, тогда как с Ubuntu возникает проблема чёрного экрана при создании виртуальной машины из образа. Решение этой проблемы оказалось довольно простым, с одной стороны, и немного неправильным, с другой. Проблема решается простой установкой xen-tools на виртуальную машину. Минус такого решения в том, что невозможно предоставить чистую операционную систему, что иногда требуется в рамках решаемых задач.

Динамическая балансировка нагрузки

В рамках решаемых задач часто нужна динамическая балансировка нагрузки между серверами с XenServer. Для этих целей компания Citrix предоставляет виртуальную машину Citrix WLB Virtual Appliance, которую также необходимо добавить в облако, после чего произвести простую настройку через её консоль (при заходе в консоль все необходимые действия машина подскажет сама). После этого нужно зайти в XenCenter и указать пулу, что именно эта виртуальная машина будет отвечать за балансировку нагрузки между серверами (это действие производится во вкладке WLB).

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

Настройка и разграничения доступа к облаку

Последней задачей, которую необходимо решить для нормальной работы, является предоставление доступа к облаку. И тут у Citrix, на наш взгляд, самые большие проблемы. Citrix предлагает два варианта получения доступа к облаку: через XenCenter и через web-интерфейс.

Доступ через XenCenter

Если к пулу подключить Active Directory (AD), то появляется возможность создавать пользователей в XenCenter. Компания Citrix решила отказаться от дискреционной модели доступа в XenCenter и реализовала ролевую. Отсюда основная проблема: ВСЕ пользователи видят и имеют доступ ко ВСЕМ виртуальным машинам, регулируется только тип доступа, но он применяется ко ВСЕМ виртуальным машинам сразу (т.е. если даётся роль на запуск виртуальных машин, то сразу всех). Также стоит отметить, что AD должен постоянно быть доступен, т.к. при перезагрузке AD автоматически не добавляется к пулу, и его необходимо каждый раз добавлять вручную.

Доступ через web-интерфейс

Для дискреционного доступа компания Citrix предлагает использовать доступ через web-интерфейс. Для настройки доступа через web-интерфейс необходимо установить виртуальную машину Citrix XenServer Web Self Service. После простой настройки виртуальной машины через её консоль (необходимо задать ip-адрес или указать, чтобы он получался по DHCP) необходимо выполнить ряд настроек через web-интерфейс. Тут Citrix выше всяких похвал за доступное и понятное описание: если вы вошли в качестве администратора, вам сразу будет показан список шагов, которые необходимо выполнить, а также подробно описано, как это делать.

В Citrix XenServer Web Self Service могут использоваться те же пользователи, что есть в AD, или создаваться новые. При первой загрузке XenServer Web Self Service администратору необходимо указать, как он хочет действовать, и это решение уже потом никак нельзя изменить (конечно, всегда можно переставить виртуальную машину, но это повлечёт за собой новую настройку прав доступа к виртуальным машинам). После настройки любой пользователь может получить доступ к конкретной виртуальной машине через браузер. И тут Citrix тоже очень радует: для работы может быть использован любой браузер, а не какой-то ограниченный набор, как у облака от Microsoft (только InternetExplorer) или VmWare (не поддерживается Opera). Для того чтобы пользователь получил доступ к виртуальной машине, администратор должен разрешить доступ к этой виртуальной машине для данного пользователя, что легко делается через web-интерфейс.

К большим недостаткам работы через web-интерфейс можно отнести невозможность настройки физических параметров виртуальной машины (количество процессоров, количество RAM, настройка подключённых сетей и жестких дисков). Так что web-интерфейс – это доступ к графическому интерфейсу виртуальной машины, а не к управлению её физическими параметрами. Мы выполнили все необходимые действия: подготовили аппаратуру, настроили лицензии, развернули… И теперь облако готово к работе!

Наш эксперимент

Для оценки реальной вычислительной мощности серверов мы провели эксперимент, целью которого было максимально загрузить все 80 логических ядер на системе. В качестве основы для проведения эксперимента была взята программа, выполняющая Ray-Tracing простой сцены, без операционной системы и использующая все ядра на всех процессорах в компьютере. О том, как работает эта программа и как получить исходные коды этой программы, можно прочитать тут.

Для эксперимента программа была немного доработана: добавили анимацию движения для одной из сфер на рисунке, добавлен подсчет скорости работы, и добавлена буферизация при рисовании каждого кадра. Для сравнения мощности работы полученной программы мы запускали ее на нескольких компьютерах разной конфигурации, в том числе, и на наших IBM серверах. В эксперименте выполнялся рендеринг сцены из 5-ти сфер в разрешении 800×600. Эксперимент увенчался успехом и IBM сервера показали внушительные показатели производительности. Для всех экспериментов мы записали видео, где цифры зеленого цвета в левом верхнем углу экрана означают количество кадров в секунду (FPS), цифры красного цвета — количество секунд на кадр. Вот такие результаты мы получили:

1. Обычный компьютер: Intel i3-2100, 3.1 GHz, всего 2 ядра. Для каждого ядра 800×600/2=240000 точек на кадр. Как видно из видео, скорость составила примерно 0.5 FPS (на один кадр тратилось более 2-х секунд).

2. Компьютер на современном мощном процессоре: Intel i7-4770, 3.4 GHz, всего 8 ядер. Для каждого ядра 800×600/8=60000 точек на кадр. Результат — примерно 2 кадра в секунду, как можно видеть на видео.

3. IBM сервер из стойки: Intel Xeon E7-8860 2.3 GHz, на каждом компьютере по 4 процессора по 10 физических ядер (на каждом ядре 2 логических) — итого 80 ядер. Для каждого ядра 800×600/80=6000 точек на кадр. Результат — 12-14 FPS — что значительно больше, чем у других систем.

Интересно, что если запустить на IBM сервере рендеринг в разрешении 1280×1024, и позволить ядрам процессора работать без буферизации, то можно заметить, как кадр рисуется из 80-ти полосок!

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

источник

Читайте также:  Установка virtualbox не на системный диск

Добавить комментарий