Delfit Blog

Если вы пользуетесь бесплатным продуктом для виртуализации VMware Server на CentOS, наверняка вы заметили невероятно отвратительное поведение VMware Infrastructure Web Access после установки последних обновлений системы и самого VMware Server. Достаточно произвести несколько нехитрых действий и Web Access становится недоступным. Помогает лишь ручной перезапуск служб VMware Server (командой /etc/init.d/vmware-mgmt restart) или одна нехитрая модификация, которая описана ниже.

Как оказывается, причиной такому странному поведению есть баг в стандартной библиотеке glibc 2.5-42. Если вы обновляли CentOS до текущей версии 5.4, то наверняка у вас установлена именно эта версия библиотеки. Однако, если использовать версию glibc немного постарее (например, от CentOS 5.3), а еще лучше – исключительно для VMware Server, то Web Access становится абсолютно адекватным.

Вытянуть нужную версию glibc из пакета для CentOS 5.3 можно так :

[root@server1 ~]# mkdir ~/vmwareglibc
[root@server1 ~]# cd ~/vmwareglibc
[root@server1 ~]# wget http://vault.centos.org/5.3/os/x86_64/CentOS/glibc-2.5-34.x86_64.rpm
[root@server1 ~]# rpm2cpio glibc-2.5-34.x86_64.rpm | cpio -ivd
[root@server1 ~]# mkdir /usr/lib/vmware/lib/libc.so.6
[root@server1 ~]# mv lib64/libc-2.5.so /usr/lib/vmware/lib/libc.so.6/libc.so.6

Теперь нужно заставить VMware Server использовать именно эту библиотеку. Для этого в файл /usr/sbin/vmware-hostd перед последней строкой нужно вставить следующее :

export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libc.so.6:$LD_LIBRARY_PATH

В итоге, заключительная часть /usr/sbin/vmware-hostd будет выглядеть так :

if [ ! "@@VMWARE_NO_MALLOC_CHECK@@" = 1 ]; then
     export MALLOC_CHECK_=2
fi

export LD_LIBRARY_PATH=/usr/lib/vmware/lib/libc.so.6:$LD_LIBRARY_PATH

eval exec "$DEBUG_CMD" "$binary" "$@"

Для корректной работы VMware Infrastructure Web Access остается только перезапустить VMware Server :

[root@server1 ~]# /etc/init.d/vmware restart

Popularity: 55% [?]

Виртуализация, Новости Linux, VMware Server

 Распечатать запись

(Еще не оценили)

 Loading ...

Кто бы мог подумать, что запуск виртуальной машины с Windows 7 в VMware Server 2.0.2 на сервере под управлением CentOS 5.4 x86_64 приводит к зависанию железяки? Да еще и такому, что кроме перезагрузки ничего помочь не в силах?

Итак, в чем суть. На сервере должны работать две виртуальных машины с ОС Windows. Изначально это были два экземпляра Windows XP. Работали они без особых нареканий. Но ведь нужно идти в ногу со временем – Windows XP уже не актуальна, Windows 7 покоряет все больше сердец. Однако, если запустить одновременно Windows XP и Windows 7 в VMware Server 2.0.2, хостовая система просто помрет без никаких подсказок в логах. Вы можете долго искать причины почему не дружат CentOS 5.4 и VMware 2.0.2, пробовать множество хаков, но все дело именно в Windows 7. Если закрыть глаза на прогресс операционных систем от Microsoft и продолжать пользоваться Windows XP, все будет замечательно.

Вот еще что : почему до сих пор в списке операционных систем, которые доступны для создания виртуальных машин в VMware Server,  нет Windows 7?

Popularity: 32% [?]

Виртуализация, Новости Linux, VMware Server, Windows 7

 Распечатать запись

(Еще не оценили)

 Loading ...

Процедура монтирования виртуального жесткого диска Xen приведена ниже. С помощью нее можно монтировать отдельные разделы виртуального диска. Главная фишка состоит в том, что название раздела в fdisk (в данном случае – loop1p1) совпадает с устройством, которое создает kpartx в папке /dev/mapper/.

root@server01 [~]# losetup /dev/loop1 /home/domains/delfit/home.img
root@server01 [~]# fdisk -l /dev/loop1
Disk /dev/loop1: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
      Device Boot      Start         End      Blocks   Id  System
/dev/loop1p1               1        1305    10482412   83  Linux
root@server01 [~]# kpartx -a /dev/loop1
root@server01 [~]# mount /dev/mapper/loop1p1 /mnt/xendisk

Отмонтировать виртуальный диск Xen можно так :

root@server01 [~]# umount /mnt/xendisk
root@server01 [~]# kpartx -d /dev/loop1
root@server01 [~]# losetup -d /dev/loop1

Чтобы смонтировать виртуальный жесткий диск VMware, нужно выполнить следующую команду :

root@server01 [~]# vmware-mount /home/domains/home.vmdk /mnt/vmwaredisk

Однако, приведенный выше пример не поможет смонтировать LVM-раздел на виртуальном жестком диске VMware. Для этого нужно выполнить следующее :

root@server01 [~]# wget http://download3.vmware.com/software/vmserver/VMware-server-1.0.9-156507.tar.gz
root@server01 [~]# tar xvfz VMware-server-1.0.9-156507.tar.gz
root@server01 [~]# cp vmware-server-distrib/bin/vmware-loop /usr/bin/
root@server01 [~]# modprobe nbd
root@server01 [~]# vmware-mount -p /home/domains/vds.vmdk
Nr      Start       Size Type Id Sytem
-- ---------- ---------- ---- -- ------------------------
 1         63     208782 BIOS 83 Linux
 2     208845    8177085 BIOS 8E Unknown
root@server01 [~]# vmware-loop /home/domains/vds.vmdk 2 /dev/nbd0
root@server01 [~]# vgscan
root@server01 [~]# vgchange -ay VolGroup00
root@server01 [~]# mount /dev/VolGroup00/LogVol00 /mnt/vmwaredisk

Основная проблема при монтирования LVM-раздела VMware состоит в том, что для этого необходима утилита vmware-loop, которая доступна только в первой версии VMware Server. Однако, VMware Server 1 можно скачать с сайта разработчика, а вытянуть нужную утилиту из архива не составляет никаких проблем.

Как видно из примера, vmware-mount не видит никакой файловой системы на втором разделе виртуального диска vds.vmdk. Именно он и является LVM-разделом, его номер следует передать утилите vmware-loop. Данная утилита вынуждена работать постоянно, завершить ее можно с помощью Ctrl+C после окончания всех нужных операций с виртуальным диском, поэтому продолжать монтирование придется в новой консоли.

Отмонтировать виртуальный жесткий диск VMware с LVM можно так :

root@server01 [~]# umount /mnt/vmwaredisk
root@server01 [~]# vgchange -an VolGroup00

Popularity: 53% [?]

Виртуализация Linux, VMware Server, Xen

 Распечатать запись

(Еще не оценили)

 Loading ...

Недавно компания Microsoft сделала собственный вклад в развитие ядра Linux, опубликовав более 20 000 строк кода под лицензией General Public License (GPL) 2. Звучит невероятно, но факт.

Речь идет о специальных паравиртуализованных драйверах для повышения производительности виртуальных Linux-машин в среде гипервизора Hyper-V. Следует заметить, что для виртуальных машин с Linux уже существовали службы интеграции с Hyper-V. Однако, их первая версия была написана компанией Citrix, поддерживала только первую версию Hyper-V и работала через адаптер гиперывзовов, используя расширения Xen для ядра Linux. Именно благодаря отказу от работы посредством адаптера гипервызовов, по словам Microsoft, удалось добиться увеличения производительности сетевой подсистемы на 500% и системы работы с хранилищами на 200%.

Linux Integration Components v2 доступна в двух вариантах : как готовый дистрибутив и как набор открытых исходных кодов. Казалось бы : для чего Microsoft облегчать жизнь разработчикам конкурента Windows? Все просто. Ожесточенная конкуренция на рынке ОС осталась в прошлом. Сегодня мы имеем ситуацию, когда ниши между основными производителями ОС уже четко определены. Отвоевывать доли процентов пользователей у конкурентов за счет огромных усилий (даже очень огромных), судя по всему,  никто не будет. Однако, такую борьбу можно успешно вести в отрасли виртуализации. Поэтому, желание Microsoft обеспечить возможность установки любого продукта внутри своей системы виртуализации вполне обосновано.

Если все пойдет хорошо, можно даже предположить, что в недалеком будущем любой дистрибутив Linux будет поддерживать Hyper-V прямо из коробки. Это даст Microsoft огромные преимущества перед конкурентами (которые разрабатывают лишь подключаемые модули ядра) и гарантию того, что службы интеграции Hyper-V для Linux не будут отключены. Однако, перед тем, как код служб интеграции войдет в ядро Linux, ему нужно будет пройти огромное множество формальных проверок и быть отшлифованным до блеска (вот гневная статья на Хабрахабре по этому поводу).

Для дальнейшей поддержки и развития кода служб интеграции Microsoft специально выделила двоих сотрудников из своей лаборатории в Кэмбридже, штат Массачусетс. Может, именно они реализуют поддержку симметричной многопроцессорности (SMP) в службах интеграции для Linux – на сегодня Hyper-V поддерживает только один виртуальный процессор для виртуальных машин с Linux.

Мнения аналитиков и Линуса Торвальдса можно прочитать здесь и здесь.

Что ж, Microsoft затеяла большую игру. Надеюсь, ее результат пойдет как на пользу Microsoft, так и на пользу Open Source сообществу.

Popularity: 15% [?]

Виртуализация, Новости Hyper-V, Linux

 Распечатать запись

(Еще не оценили)

 Loading ...

Сегодня технологии виртуализации используются для реализации различных решений. При этом, одним из перспективно-развивающихся направлений, которые реализуются за счет технологий виртуализации, является организация виртуальных выделенных серверов для предоставления услуг в сфере хостинга. Таким образом, тестирование VMware Server 2  в данной статье направлено в первую очередь на определение “скользких” моментов, которые могут возникнуть при организации виртуальных выделенных серверов на основе VMware Server 2 в операционной системе CentOS 5.1 (всеми любимая операционная система для хостинга). Хотя теоретически переход снизу-вверх не должен составить особого труда, мы все же решили протестировать миграцию с VMware Server 1 на VMware Server 2.

Итак, начнем тестирование.

Этап 1 – Загрузка релиза VMware Server 2.0.1 с официального сайта VMware. Не сказал бы, что  это самый сложный этап, но скачать заветный релиз удалось только с третьего раза – первые два загрузка обрывалась на 80-90%  по неопределенным причинам (RMP-версия VMware Server 2.0.1 весит 465 Мб, а на 512 Кб/сек это как-ни-как около 2х часов чистой загрузки).

Этап 2 – Установка CentOS 5.1 без графической оболочки и минимальным набором программного обеспечения.

Для простоты дальнейшей работы  имеет смысл установить парочку дополнительных репозиториев и несколько программ.

Для этого выполним такие команды :

# cd /etc/yum.repos.d/

# wget http://centos.karan.org/kbsingh-CentOS-Extras.repo

# rpm -Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

# yum install gcc

# yum install kernel-devel

# yum install xinetd

Этап 3 – Установка VMware Server 2.0.1. Находясь в папке с файлом VMware-server-2.0.1-156745.i386.rpm , выполняем команду установки VMware Server 2.0.1 :

# rpm -Uvh ./VMware-server-2.0.1-156745.i386.rpm

Установка пакета проходит гладко и быстро. Никаких перекомпиляций ядра, никаких неприятностей. Переходим к следующему этапу.

Этап 4 – Конфигурирование VMware Server 2. Для конфигурирования VMware Server используется стандартный скрипт, предоставляемый вместе с VMware Server :

# /usr/bin/vmware-config.pl

Конфигурирование представляет собой процесс немного посложнее установки: нужно прочитать/пролистать лицензионное соглашение, настроить сеть для будущих виртуальных машин, определить путь к папке для храниния виртуальных машин, ввести лицензионный код (который беплатно выдается на странице загрузки VMware Server 2.0.1 с официального сайта VMware), посоглашаться на служебные пути по-умолчанию – да и все. На данном этапе проблем тоже не возникает.

Этап 5 – Настройка доступа к веб-консоли. Так как доступ к  VMware Server 2 через VMware Server Console пока не поддерживается (а все попытки подключения заканчиваются ошибкой “501 Global command GLOBAL server to non-host agent targets not supported”), то настройка доступа через веб-интерфейс является единственной возможностью для управления виртуальными машинами на уровне средств визуализации.

Для доступа к VMware Server 2.0.1 через веб-интерфейс нужно открыть 8222-й, 8333-й и 902-й порты с помощью iptables (902-й используется для доступа через VMware Server Console -  он ведь может начать поддерживаться). Для этого следует выполнить следующие действия :

• Открыть для редактирования файл /etc/sysconfig/iptables:

# vi /etc/sysconfig/iptables

• Вставить перед первой строчкой со словом REJECT (к примеру, -A RH-Firewall-1-INPUT -j REJECT –reject-with icmp-host-prohibited) такой код:

-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 8222 -j ACCEPT

-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 8333 -j ACCEPT

-A RH-Firewall-1-INPUT -m state –state NEW -m tcp -p tcp –dport 902 -j ACCEPT

• Сохранить изменения и перезапустить службу iptables (а лучше перезагрузить систему)

Теперь можно пробовать достучаться через браузер к веб-консоли на порт 8333 по такому адресу (в данном случае, IP-адрес сервера – 192.168.1.5) :

https://192.168.1.5:8333

На ругань браузера по поводу неправильного сертификата закрываем глаза. На этом этапе есть несколько особенностей. В Firefox 3.0.6 под MacOS X каждые несколько секунд у меня выскакивало сообщение о том, что сайту необходимо определить с каким сертификатом меня ассоциировать. Кроме этого, как оказалось в ходе тестирования, для MacOS X нет поддержки плагина VMware Remote Console, что окончательно меня переубедило в сторону использования Internet Explorer 8 на Windows XP.  Напомню, что без поддержки VMware Remote Console невозможно увидеть изображение с “дисплея” виртуальной машины и, следовательно, нормально установить в нее операционную систему. В IE 8, к моему счастью, не выскакивало никаких сообщений о необходимости определения с каким сертификатом меня ассоциировать – все работало четко и правильно, включая VMware Remote Console.

VMware Server 2.0.1 под IE 8

Этап 6 – Установка гостевой операционной системы. В качестве гостевой операционной системы был выбран новейший релиз – CentOS 5.3. Но после нескольких неудачных попыток его установки на виртуальную машину со стандартными, казалось бы, параметрами я отказался от этой идеи. Пусть лучше будет не такой свежий CentOS 5.2, зато он будет работать. Установка CentOS 5.3  в качестве гостевой операционной системы пока что остается загадкой.

Стандартные параметры для установки семейства CentOS 5

Ошибка при установке CentOS 5.3 на VMware Server 2.0.1

Ну а CentOS 5.2 оказался вполне жизнеспособной системой и установился без каких-либо проблем и ошибок.

Удачная установка CentOS 5.2

Теперь можно приступать к тестированию совместимости виртуальных машин.

Этап 7 – Тестирование совместимости виртуальных машин. Целью тестирования является определение возможности (наверняка) использования виртуальных машин, созданных в 1-й версии, со 2-й версией VMware Server. В качестве теста была выбрана виртуальная машина с тем же CentOS, созданная в VMware Server 1. Она была легко добавлена в список виртуальных машин VMware Server 2 и легко запущена без каких-либо вопросов.Чтобы окончательно убедиться в совместимости я решил подключить виртуальный жесткий диск из 1-й версии к виртуальной машине, созданной во 2-й. Таким образом, предположение о совместимости оправдало надежды.

Удачное подключение виртуального жесткого диска из VMware Server 1

На скриншоте выше видно, что виртуальный жесткий диск, созданный в VMware Server 1, успешно определился системой, созданной в VMware Server 2, как устройство /dev/hda.

К слову о совместимости: что-то мне взбрело в голову посмотреть, как поведет себя виртуальная машина из VMware Fusion 2 в VMware Server 2. В этот раз было выбрано имеющееся под руками решение – дистрибутив Fedora Core 9, установленный под управлением VMware Fusion 2. После копирования на тестовый компьютер последовал запуск. И снова очередной этап пройден успешно.

Fedora Core 9 в VMware Fusion 2

Та же Fedora Core 9 в VMware Server 2

Итак, в результате тестирования мы получили такие результаты:

1) VMware Server 2.0.1 достаточно просто устанавливается в операционной системе CentOS 5.1.

2) Для корректной работы в CentOS 5.1, VMware Server 2.0.1 не требует перекомпиляции ядра, использования патчей и других манипуляций.

3)  Доступ через веб-консоль к VMware Server 2.0.1 настраивается достаточно просто, но нужно быть осторожным с выбором “правильного” браузера, который поддерживает плагин VMware Remote Console.

4) Гостевая операционная система CentOS 5.3 по непонятным причинам не установилась. Вместо нее была успешно установлена операционная система CentOS 5.2, что вполне достаточно для решения поставленных задач.

5) Виртуальные машины, созданные в VMware Server 1, вполне жизнеспособны в VMware Server 2.0.1. Тоже самое можно сказать и о виртуальных жестких дисках.

Таким образом, VMware Server 2.0.1 является достаточно перспективным инструментом, который пришел на смену VMware Server 1. Новая версия VMware Server без проблем устанавливается, легко настраивается и надежно функционирует, обеспечивая полную совместимость с ранними версиями VMware Server. Несомненно, для полноценного использования VMware Server 2.0.1 требует дополнительного тестирования, но результаты, которые были получены в ходе тестирования, можно считать достаточными для начала использования VMware Server 2.0.1 для решения ряда задач.

Popularity: 70% [?]

Виртуализация Linux, VMware Server

 Распечатать запись

(2 голосов, средний: 5.00 из 5)

 Loading ...