Виртуализация рабочих станций на Vmware Server 2
Материал из Xgu.ru
Автор: Casm
На странице описывается каким образом можно организовать работу сети, состоящей из сервера виртуализации под управлением VMware Server 2, и клиентских машин, работающих в режиме тонких клиентов, подключающихся к этому серверу виртуализации.
Содержание
|
[править] Задача
Цель: перенести задачи, выполняемые на слабых клиентских машинах, на более мощные виртуальные машины.
Оборудование:
- клиентские машины – Pentium II, 64 МБ ОЗУ, жесткий диск – 10-20 Гб, клавиатура, мышь, монитор;
- сервер – проверялось на SLES10, Vmware Server 2, память - из расчета 1 Гб под ОС и Vmware Server 2, +350 МБ на каждую виртуальную машину, файловое хранилище – 10 Гб под систему, + 7-15 Гб на каждую виртуальную машину.
Описание.
Для решения данной задачи потребуется:
- сервер с Linux, на котором запуститься Vmware Server 2 (проверялось на SLES10)
- собственно Vmware Server 2 скачать бесплатно можно по ссылке http://www.vmware.com/download/server/
- Linux дистрибутив для установки на клиентские машины (использовался Debian 5.0.1)
В качестве ОС для клиентских машин можно использовать любой дистрибутив, где запустится клиент VMware Remote Console. Глубоко в зависимостях VMware Remote Console (vmware-vmrc) не разбирался, но судя по всему, все необходимые библиотеки у него встроены и ему требуются только X server.
И так после того, как получили вышеназванное ПО приступаем к настройке. Необходимо будет сделать:
- Серверная часть
- Установить Vmware Server 2, создать виртуальные машины.
- Задать права доступа к виртуальным машинам.
- Клиентская часть
- Установить ОС, настроить X Server
- Установить VMware Remote Console
- Настроить автозапуск консоли vmware, при старте X Server
- Настроить автовход пользователя в консоль Linux
- Настроить выключение физической машины клиента, при выключении виртуальной.
[править] Серверная часть.
[править] Установка Vmware Server 2 и создание виртуальных машин.
На сервер устанавливаем Vmware Server 2, настраиваем, запускаем. Тут сложностей возникнуть не должно. Единственное разве, что модуль vsock может не установиться, но он экспериментальный и по-умолчанию предлагается его не устанавливать. В качестве Администратора указываем существующего на сервере Linux пользователя (вовсе не обязательно, чтобы это был root). Открываем в firewall порты, используемые Vmware - если при установке ничего не меняли, то это 902, 8333. Если меняли - смотрите вывод sudo netstat –nap –-inet | grep vmware, или socklist. Порт 902 используется для авторизации подключающихся клиентов, порт 8333 – для доступа к консоли.
Заходим под пользователем, указанным как администратор при установке, на web-консоль (https://vmware.host:8333). Создаём виртуальные машины для работы. В моём случае это были Windows XP, 1 CPU, 256 Мб ОЗУ, HDD 5ГБ. После создания одной вирт. машины и выполнения всех настроек с ОС и ПО, остальные проще скопировать. Заходим на Linux сервере в основное хранилище (по-умолчанию /var/lib/vmware/Virtual Machines), создаём копии, после чего в web-консоли добавляем их в инвентарь Vmware Server ("Add Virtual Machine to Inventory").
Добавленные машины обязательно запускаем – Vmware Server выдаст вопрос, о том скопировали или переместили вы данную машину - отвечаем «Скопировали». В данном случае у неё будет изменены MAC адреса сетевых карт, и возможно другие идентификаторы железа. Как писалось в предупреждении от vmware server 1, это потребует повторную активацию Windows XP (подробности читайте на сайте Vmware про лицензирование Windows, на виртуальных машинах).
Данные о зарегистрированных вирт. машинах хранятся в файле /etc/vmware/hostd/vmInventory.xml, он нам еще потребуется, так как в нём указаны objID машин. Данный objID у клиента будет определять, к какой виртуальной машине он будет подключаться.
[править] Права доступа к машинам.
Если для подключения к виртуальным машинам будет использоваться одна пара логин/пароль для всех клиентских машин, то на Linux сервере создаем этого пользователя (например, vmrc), после чего в web-консоли Vmware Server 2 в Permissions выставляем разрешения для него. Выставить разрешения можно как для всего хоста и всех виртуальных машин, так и для каждой виртуальной машины в отдельности.
Но сначала необходимо создать шаблон прав (по терминологии vmware - Roles). Для этого заходим слева вверху web-консоли в меню Administration –> Manage roles. Создаём новую роль (шаблон прав доступа), например, vmrc-role.
В открывшемся списке прав (Privileges) находим ветку Virtual Machine -> Interaction в ней выставляем галочки у “Power On” (что бы при подключении клиента виртуальная машина автоматом запускалась), “Power Off”, “Reset” (мало ли что бывает с Windows), “Console Interaction” (иначе пользователь вместо рабочего стола, будет наблюдать только черное окно консоли Vmware), и если необходимо “Device connection” (для подключения клиентского CD-ROM к виртуальной машине, но это должно быть ещё настроено в конфигурации виртуальной машины - в свойствах CD-ROM должно быть указано Client Media).
Name: vmrc-role
Privileges
.....
- Virtual Machines
Inventory
- Interaction
+Power on
+PowerOff
Suspend
+Reset
Answer Question
+Console Interaction
+Device Connection
.....
Далее для созданных виртуальных машин в Permissions создаём новое разрешение: для созданного ранее пользователя, для подключения клиентов (vmrc), указываем нашу роль (vmrc-role). Создаём permission любо для каждой машины в отдельности, либо для всего хоста. В итоге в правах будут администратор (указывается при установке vmware) и пользователь с правами, которые задали в Roles для подключения клиентов.
Если для подключения к виртуальным машинам, каждый клиент будет использовать отдельного пользователя, то необходимо их всех завести и на физический сервер (useradd) и в Vmware Server 2 (вкладка Permissions).
При добавлении третьего пользователя в Permissions может возникнуть проблема – vmware выдаст ошибку “Error in the method call SetEntityPermissions : Database temporarily unavailable or has network problems.”. Для решения необходимо отредактировать файл /etc/vmware/hostd/authorization.xml – добавить секцию <ACEData id="12"> </ACEData> и изменить номер в <NextAceId>12</NextAceId> на следующий по порядку (возможно у вас будут другие числа). После повторить добавление пользователя.
[править] Клиентская часть.
Для настройки клиентской части необходимо:
- установить ОС
- установить и настроить X server
- установить VMware Remote Console
- указать в ~/.xinitrc для X server, клиента vmware-vmrc
- настроить автовход в консоль, чтобы все запускалось автоматом.
Выбирайте ОС, какая вам удобнее. Мне для реализации потребовалось Debian 5.0.1 CD1, + пакет mingetty http://packages.debian.org/lenny/mingetty (на первом CD его не нашлось).
[править] Установка ОС, настройка X Server
Я ставил Debian в минимальном наборе, а после доставлял пакеты. Отключил лишние по мне службы (nfs, inetd), доставил openssh-server. Необходимо установить xserver-xorg-core, xauth, xinit, fontconfig, шрифты. Если все же не удастся запустить vmware-vmrc попробуйте, установить Firefox (Iceweasel) и подключиться к web-консоли сначала через Firefox. Настраиваем xorg.conf, проверяем, что X server запускается без ошибок.
[править] Установка VMware Remote Console
Теперь необходимо установить собственно клиента для подключения к виртуальным машинам.
Заходим на клиентскую машину под пользователем, который будет использоваться для работы (я при установке создал пользователя vmware). Есть два способа:
- Запускаем Firefox (iceweasel) с клиента, подключаемся к серверу с Vmware Server 2, запускаем любую вирт. машину, щелкаем по вкладке Console, на ней будет предложение «install plugin», устанавливаем, заходим в профиль firefox в папку с расширениями, ищем расширение «VMwareVMRC@vmware.com» находим в нём папку «plugins», копируем её в более удобной место, например в ~/vmware-vmrc
- Заходим на физический сервер с Linux (где установлен Vmware Server 2), в каталог /usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/webapps/ui/plugin/ в нём должен быть файл vmware-vmrc-linux-x86.xpi, копируем его на клиентскую машину (например: scp vmware-vmrc-linux-x86.xpi vmware@vmware-client:/tmp).
Заходим на клиентскую машину, распаковываем скаченное с сервера расширение:
vmware-client:/tmp$ unzip vmware-vmrc-linux-x86.xpi vmware-client:/tmp$ mv plugins ~/vmware-vmrc
В итоге каталог ~/vmware-vmrc будет иметь следующее содержание:
bin/ lib/ libconf/ share/ xkeymap/ np-vmware-vmrc-2.5.0-122581.so open_source_licenses.txt vmware-desktop-entry-creator vmware-vmrc vmware-vmrc-daemon vmware-vmrc-legacy
Собственно скрипт vmware-vmrc и будет использоваться для подключения к виртуальным машинам. Параметры, которые воспринимает скрипт можно узнать, запустив его с опцией -–help. Мне наиболее интересны были:
-X – запуск консоли в полноэкранном режиме -M – номер виртуальной машины (см. objID в /etc/vmware/hostd/vmInventory.xml на сервере)
Так же есть еще два параметра, которые в справке у меня не отобразились, это
-u – имя пользователя, используемое для подключения к Vmware Server 2, то, что задавали во вкладке Permissions в консоли Vmware, и опция -p – соответствующий пароль пользователя на Linux сервере.
В итоге строка для подключения будет примерно такая:
vmware-vmrc -X -h "vmware-server:8333" -u <login> -p <password> -M "<objID>"
Значение objID, как уже писал можно узнать в файле /etc/vmware/hostd/vmInventory.xml на сервере, оно определяет, к какой виртуальной машине клиент будет подключаться. Например, если vmInventory.xml содержит следующее:
<ConfigRoot> ..... <ConfigEntry id="0003"> <objID>304</objID> <vmxCfgPath>/mnt/vmware/WindowsXP01/Windows XP.vmx</vmxCfgPath> </ConfigEntry> <ConfigEntry id="0004"> <objID>320</objID> <vmxCfgPath>/mnt/vmware/WindowsXP02/Windows XP.vmx</vmxCfgPath> </ConfigEntry> ..... </ConfigRoot>
то vmware-vmrc -X -h "192.168.1.3:8333" -u vmrc -p superpwd -M "304" запустит вирт. машину /mnt/vmware/WindowsXP01/Windows XP.vmx, при условии, что пользователь vmrc на сервере 192.168.1.3 имеет право включать данную машину.
Далее помещаем данную строку в ~/.xinitrc
~/vmware-vmrc/vmware-vmrc -X -h "192.168.1.3:8333" -u vmrc -p superpwd -M "304"
И пробуем запустить X: startx
Если все нормально запустилось, то должно появиться окно “VMware Remote Console”. При подключении клиента к вирт. машине она запустится (если была отключена), и клиент через несколько секунд (у меня 40-60 сек.) увидит загружающуюся вирт. машину. Вверху будет панель инструментов, где можно произвести аварийную перезагрузку, выключение, приостановить работу вирт. машины, а так же подключить/отключить устройства (CD-ROM, а так же сетевая карта, хотя её и нельзя отключить). От лишних вопросов эту панельку лучше скрыть, так как при нажатии на кнопку «Закрыть», X server завершить работу. Настройки VMware Remote Console хранятся в каталоге ~/.vmware.
Если не получилось увидеть рабочий стол виртуальной машины, то проверьте сетевую доступность сервера, доступ к портам 902, 8333 на сервере, ошибки X server, проверьте, что на клиентской машине установлен пакет xauth. Попробуйте в строке подключения vmware-vmrc указать администратора Vmware Server 2, и подключить под ним. Если под администратором удаётся получить доступ к виртуальной машине - проверьте, что пользователю (в моём примере - vmrc) в роли доступа разрешены “Power On” и “Console Interaction”.
[править] Настройка автоматического запуска консоли VMware Remote Console.
Теперь осталось добиться, чтобы всё это запускалось автоматом. Если на клиентской машине linux пользователь использует bash, то в ~/.bashrc дописываем *
if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ] ; then startx fi
Для других шеллов – по аналоги. Далее необходимо настроить автовход в linux-консоль, чтобы не шокировать простых пользователей. Благо на самих клиентских машинах, кроме objID никаких рабочих данных не будет храниться.
Если же зловредный пользователь попытается просмотреть файл .xinitrc, чтобы узнать имя и пароль пользователя для подключения (зная это, он может наблюдать за рабочим столом), ему необходимо будет, либо переключиться на вторую, третью и т.д. консоль, а там его будет ждать приглашение от login, либо завершить X server. Далее будет указан способ, как сделать так, чтобы при завершении работы X server производилось автоматическое выключение компьютера.
Возможно, конечно, загрузиться с livecd и посмотреть данный файл. В таком случае, либо снимайте дисковод, CD-ROM (с флешек компьютеры, работающие на Pentium II, как правило, не умеют загружаться), либо перемещайте клиентские компьютеры и сервер в изолированный vlan, либо все вместе.
Для автовхода можно воспользоваться mingetty. Скачиваем и ставим mingetty (на Debian CD1 пакета не было обнаружено), и редактируем /etc/inittab. Пример, для Debian.
..... #1:2345:respawn:/sbin/getty 38400 tty1 1:2345:respawn:/sbin/mingetty --autologin <vmware-user> tty1 2:23:respawn:/sbin/getty 38400 tty2 .....
где <vmware-user> - пользователь локальной, клиентской ОС, в моём примере это vmware.
Теперь при загрузке клиентской машины c Linux, будет производиться следующее:
- Автоматический вход в систему
- Запуск X Server, с клиентом vmware-vmrc
- Подключение клиента vmware-vmrc к виртуальной машине на Vmware Server 2
- Включение виртуальной машины, и перенаправление вывода на экран клиентской машины.
[править] Настройка автоматического выключения физической машины клиента при выключении виртуальной.
Пользователь ожидает, что если зайти в меню Пуск и нажать Завершение работы, то его машина будет выключена. В нашем же случае, это приведет к завершению работы консоли vmware-vmrc, завершению работы X server и в результате перед пользователем предстанет черно-белая консоль Linux. Это немного не то, что ожидал пользователь. Для того чтобы после виртуальной машины отключалась и физическая, можно поступить следующим образом:
- Установить пакет sudo (если не стоял)
- От root запустить visudo, и добавить правило: vmware ALL = NOPASSWD: /sbin/halt
(если вы используете другого пользователя, то создайте правило для него)
- В файле ~/.xinitrc для пользователя vmware после строки
~/vmware-vmrc/vmware-vmrc -X -h "vmware-server:8333" -u <login> -p <password> -M "<objID>"
необходимо добавить строку:
sudo /sbin/halt
В итоге получим, что при завершении работы виртуальной машины, завершит работу клиент vmware-vmrc и будет выполнена команда sudo /sbin/halt, что приведет к выключению физической машины. Что нам и требовалось.
Однако, здесь есть недостаток: физическая машина выключиться и при случайном завершении X server. Это может случиться при нажатии Ctrl-Alt-Backspace, или если пользователь закроет клиента VMware Remote Console (крестик на панели инструментов). При повторном же включении физической машины, клиент заново подключиться к виртуальной машине и продолжить работу.
[править] Клонирование клиентских машин.
Далее остаётся клонировать настройки на остальные клиентские машины, изменить значение objID, имя и пароль для подключения (если используются для каждой машины свой). Здесь множество вариантов:
- Вручную создать архив, начиная с корня, развернуть его на другой клиентской машине, установить загрузчик и перенастроить X Server.
- Подключить второй жесткий диск и воспользоваться командой dd.
- Воспользоваться Акронисом.
- Любой другой способ :)
Напишу, как думаю делать я, возможно, кому-то пригодиться (пока все, что описал, тестируется на одной клиентской машине и то виртуальной).
[править] Создание архива.
1. Загружаемся на клиентской машине с livecd (для определенности RIPLinux).
2. Монтируем раздел с системой (при установке Debian, я разбивал диск только на два раздела - под swap, и под корень).
3. Переходим в смонтированный раздел (в моём случае в RipLinux, это был каталог /mnt/sda2), удаляем все из tmp, var/tmp.
4. Запускаем архивацию с выводом на удалённую машину (в моём случае это была моя рабочая машина):
/mnt/sda2:# tar cvf - . | ssh user@remote-machine “dd of=~/vmware-vmrc.tar”
В случае использования Debian архив оказался около 550 МБ, после сжатия bzip -9 - 250 Мб. Если удалить часть пакетов из стандартной системы (perl, python, так же стоял Iceweasel), то можно еще высвободить место. Можно конечно было сразу указать tar cvjf - ..., но я сжимал позже на удалённой машине, так как она мощнее.
[править] Развертывание архива.
1. Можно интегрировать полученный архив в livecd, например можно скопировать тот же диск RipLinux во временный каталог, переместить в него созданный архив vmware-vmrc.tar.bz2, создать загрузочный образ, и записать его на CD.
2. Загрузиться с созданного CD, на очередной клиентской машине.
3. Разбить жёсткий диск, создать swap, отформатировать и смонтировать файловую систему (например, в /mnt/target).
4.Развернуть архив:
/mnt/target:# tar –xvjf /путь_к_архиву/vmware-vmrc.tar.bz2
5. Установить загрузчик (например, Grub):
- Предварительно монтируем /dev:
#mount –-bind /dev /mnt/target/dev
- Переходим в клонированную систему:
#chroot /mnt/target
- Если жесткий диск, в клонированной системе имеет другое наименование, то редактируем /boot/grub/device.map, /boot/grub/menu.lst, /etc/fstab
- Устанавливаем Grub:
grub –-no-floppy (с –-no-floppy запускается быстрее) grub> root (hd0,1) # hd0,0 – swap, hd0,1 - корень grub> setup (hd0) # ставим в mbr
если успешно - выходим
grub> quit
- Выходим из chroot: ^D (Ctrl-D)
- Размонтируем, что монтировали:
# umount /mnt/target/dev # umount /mnt/target
6. Перезагружаемся. Если клонированная система не загружается, используем снова LiveCd, правим /mnt/target/boot/grub/menu.lst, /mnt/target/etc/fstab.
Если решили сменить файловую систему (например, в той с которой делали архив корень был под reiserfs, а на той, которой развертываете архив, решили сделать ext3), проверьте, что в initrd есть модуль для файловой системы, на которой развертываете. Как правило, initrd, это архив cpio или gzip (смотрите вывод file initrd). Если модуля нет, то chroot /mnt/target, указываем в файле настроек mkinitrd какие модули включать, собираем initrd:
cd /boot/ mkinitrd -o /boot/initrd.img <версия_ядра> (версии ядра смотрите в /boot/grub/menu.lst, или в /lib/modules).
7. После того, как загрузили клонированную систему, настраиваем X server под новое оборудование (если при старте X server падает и согласно .xinitrc выполняется /sbin/halt, то загружаемся в single mode).
8. Редактируем ~/.xinitrc: изменяем objID, login, password для подключения.
9. Пробуем загрузиться в штатном режиме.
Если все успешно переходим к следующей машине.
[править] Загрузка по сети
Сделать загрузку по сети (bootp) в данном случае проблематично, так как необходимо, чтобы у всех клиентов были указаны различные objID. С бездисковыми станциями я не сталкивался, поэтому напишу только свои идеи, как сделать это. Реализуемо это или нет - решать Вам.
Если все будут загружать один и тот же образ, то получиться, что один пользователь будет пытаться работать за виртуальной машиной, а остальные будут ему мешать :)
Как решение можно, например, в .xinitrc написать скрипт, который в зависимости, например, от MAC адреса сетевой карты, выбирал определенный objID, и подставлялся его в строку подключения. Пример скрипта .xinitrc (я не проверял, можно ли такое помещать в .xinitrc):
#Вот примеры выражений, задающих переменной mac,
#значение MAC адреса сетевой карты
#(предполагается, что карта одна).
# mac=`ip addr | grep link\/ether | cut -d ' ' -f 6`
# mac=`/sbin/ifconfig | grep HWaddr | cut -d ' ' -f 11`
mac=`/sbin/ifconfig | grep HWaddr | cut -d ' ' -f 11`
case $mac in
00:11:22:33:44:01)
objid=304
vmlogin=vmrc1
vmpwd=superpwd1
;;
00:11:22:33:44:02)
objid=320
vmlogin=vmrc2
vmpwd=superpwd2
;;
......
*)echo "Для данной машины настройки не заданы"
return 0 # или sudo /sbin/halt :)
;;
esac
~/vmware-vmrc/vmware-vmrc -X -h "vmware-server:8333" -u $vmlogin -p $vmpwd -M $objid
sudo /sbin/halt
Но, как и говорил ранее, с загрузкой по сети на работал, поэтому работоспособность не проверял.
Примечание: клиент vmware-vmrc способен подключаться и к VMWare ESXi.
|
|
|---|
