Выпустив первый пакет обновления для SUSE Linux Enterprise Server (SLES) 11, Novell осталась верна своей философии: охватить как можно больше платформ с особым прицелом на разнообразие ролей виртуализационного хоста и клиента.
После OEM-соглашения с VMware по SLES, о котором Novell объявила в июне, и до релиза Service Pack 1 корпоративная версия SUSE Linux проходила опробование в организациях, использующих виртуальную инфраструктуру всех мастей.
Конечно, чем шире вендор охватывает все потенциальные приложения, тем труднее достичь совершенства в отдельно взятой области. При тестировании SLES 11 SP1 я встретил ряд шероховатостей — особенно при работе с KVM и Hyper-V, т. е. за пределами любимой Novell территории Xen. Тем не менее меня впечатлил прогресс, которого достигла Novell, удерживая SLES в роли ведущей корпоративной ОС на фоне всех перемен в отрасли, вызванных виртуализацией и облаками.
SLES 11 предлагается в версиях для платформ x86, x86_64, Itanium, IBM PowerPC и zSeries. Я тестировал SLES 11 SP1 для x86_64 на двухпроцессорном сервере с 4-Гб ОЗУ, который я использовал сначала как хост виртуализации с KVM, а потом как хост с Xen. Я также тестировал SLES 11 SP1 в качестве гостевой ОС под управлением этих хостов с KVM и Xen и как гостевую машину с Windows Server 2008 R2 и Hyper-V.
SLES 11 продается по годовой подписке, цены зависят от уровня поддержки и архитектуры процессоров. Для платформ x86 и x86_64 подписка варьируется от базовой (30 дней поддержки по телефону и электронной почте), которая стоит 349 долл. за сервер, до приоритетной — 1499 долл. за сервер (полная поддержка 24/7 в течение всего срока).
Все подписки включают доступ к обновлениям продукта и разрешают иметь неограниченное число виртуальных машин.
Тестирование с Hyper-V
Я начал свои тесты с Hyper-V. Учитывая печально известное соглашение о сотрудничестве по Linux между Novell и Microsoft, заключенное в 2006 г., я ожидал, что работа SLES в паре с Hyper-V будет особенно гладкой. С самого начала было приятно обнаружить, что так называемые enlightened-драйверы, которые требуются для использования виртуальных компонентов под Hyper-V на полную мощность, были автоматически установлены в мой тестовый экземпляр.
Менее приятно оказалось другое: хотя драйвер, необходимый для использования виртуального сетевого интерфейса, был предустановлен, потребовалась некоторая разведка, чтобы он заработал. Мне пришлось дать команду modprobe hv_netvsc, чтобы мой экземпляр SLES распознал свой сетевой интерфейс. Затем я отредактировал файл /etc/sysconfig/kernel в своем экземпляре, чтобы модуль загружался автоматически при последующих загрузках ОС.
Кроме того, я был немного обескуражен отсутствием поддержки мыши для Linux под Hyper-V, когда SLES загрузилась по умолчанию с графическим интерфейсом. Microsoft не дает драйвера Hyper-V для поддержки мыши, а драйвер ввода, который разработала команда Citrix XenSource в рамках проекта Satori, не работает с версией ядра 2.6.32, на которой построена SLES 11 SP1.
Работать с графическим интерфейсом в своем экземпляре SLES, я смог после того, как вызвал консоль дистанционного администрирования на базе VNC. При этом я мог легко управлять системой в сеансе командной строки SSH (Secure Shell). YAST, утилита установки системы, имеет приятную версию интерфейса для терминала, но оба этих маршрута требуют доступа к сети, и здесь я также столкнулся с кое-какими проблемами.
Их удалось легко разрешить, после чего мой экземпляр SLES под управлением Hyper-V стал нормально работать. Он хорошо послужил мне в качестве сервера для установки последующих тестовых машин со SLES, и я без труда добавил этот экземпляр в домен Active Directory в лаборатории eWeek и провел аутентификацию.
С учетом сказанного я был разочарован тем, сколь скудно описан Hyper-V в документации Novell. В материалах по SLES 11 на вебсайте компании термин “Hyper-V” встретился лишь один раз в контексте запуска гостевых экземпляров на хосте с Xen. Самый полезный источник информации, какой я обнаружил по Linux и Hyper-V, — это блог о запуске гостевых Ubuntu в среде гипервизора Microsoft.
Альтернатива: KVM
Начиная с SP1, организации, использующие SLES 11, могут выбрать KVM в качестве альтернативы Xen (который остается главной платформой виртуализации Novell). Компания поступила правильно, осуществив хотя бы предварительный выход на KVM, так как Red Hat постепенно отходит от Xen, нацеливаясь исключительно на этот гипервизор. Canonical также избрала KVM главной платформой виртуализации для Ubuntu Linux, и можно ожидать всё большего принятия KVM в будущем.
Я установил SLES 11 SP1 на двухпроцессорный сервер и запустил утилиту Install Hypervisor в окне YAST. Утилита предложила выбор: Xen или KVM. Я выбрал KVM, и установщик занялся загрузкой требуемых драйверов и пакетов администрирования — примерно той же группы ПО, к какой я привык в дистрибутивах Red Hat и Canonical Linux, которая привязана к библиотеке администрирования libvirt и включает графическую консоль virt-manager.
Одна из замечательных особенностей библиотеки libvirt это способность управления удаленными хостами из локального экземпляра virt-manager, хотя в прежних версиях мне удавалось это с переменным успехом. На этот раз я сумел управлять экземпляром KVM на базе SLES из клиентов Ubuntu 10.04 и Fedora 13, но лишь после того, как установил в SLES пакет netcatopenbsd из репозиториев родственного дистрибутива, ориентированного на сообщество SLES 11, OpenSUSE 11.3.
Когда я попытался осуществить ту же операцию удаленного доступа из одного экземпляра SLES к другому, то смог соединиться без проблем (и без установки дополнительного пакета), однако не мог создать новую VM. Копия virt-manager, работающая в SLES, пожаловалась, что “гипервизор не запущен”. Похоже, virt-manager не делал различия между клиентом, где не было гипервизора, и удаленным хостом.
Протестировав KVM на SLES 11 SP1, я перешел на Xen на той же машине. Обе платформы виртуализации используют один и тот же набор средств администрирования, и самое большое различие между ними — это выбор между пара-виртуализированной или полностью виртуализированной гостевой ОС при использовании Xen.
