Виртуализация рабочих станций на Vmware Server 2
Материал из Xgu.ru
Автор: Casm
На странице описывается каким образом можно организовать работу сети, состоящей из сервера виртуализации под управлением VMware Server 2 (а так же Vmware ESXi), и клиентских машин, работающих в режиме тонких клиентов, подключающихся к этому серверу виртуализации.
Содержание
|
[править] Задача
Цель: перенести задачи, выполняемые на слабых клиентских машинах, на более мощные виртуальные машины.
Оборудование:
- клиентские машины – Pentium II, 64 МБ ОЗУ, жесткий диск – 10-20 Гб, клавиатура, мышь, монитор;
- сервер – проверялось на SLES10, Vmware Server 2, память - из расчета 1 Гб под ОС и Vmware Server 2, +350 МБ на каждую виртуальную машину, файловое хранилище – 10 Гб под систему, + 7-15 Гб на каждую виртуальную машину. Так же возможна работа с Vmware ESXi.
Описание.
Для решения данной задачи потребуется:
- сервер с Linux, на котором запустится Vmware Server 2 (проверялось на SLES10) или хост с Vmware ESXi
- после регистрации на сайте Vmware можно получить ссылки на скачивание Vmware Server 2 Vmware ESXi
- 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 ESXi) и создание виртуальных машин.
На сервер устанавливаем 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, на виртуальных машинах).
Установка Vmware ESXi осуществляется согласно инструкций на экране.
Данные о зарегистрированных вирт. машинах хранятся в файле /etc/vmware/hostd/vmInventory.xml, он нам еще потребуется, так как в нём указаны objID машин. Данный objID у клиента будет определять, к какой виртуальной машине он будет подключаться.
Возможно на Vmware ESXi придётся включить SSH. Как это сделать зависит от версии ESXi и подробно описано документе в http://www.vmgu.ru/news/vmware-esxi-5-ssh-enable
[править] Права доступа к машинам.
Если для подключения к виртуальным машинам будет использоваться одна пара логин/пароль для всех клиентских машин, то на 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> на следующий по порядку (возможно у вас будут другие числа). После повторить добавление пользователя.
Для ESXi права задаются аналогично, но через консоль из Windows.
[править] Клиентская часть.
Для настройки клиентской части необходимо:
- установить ОС
- установить и настроить 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 ESXi попробуйте скачать по адресу
wget --no-check-certificate https://<IP ESXi>/ui/plugin/vmware-vmrc-linux-x86.xpi
Заходим на клиентскую машину, распаковываем скаченное с сервера расширение:
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>" - для Vmware Servre2 vmware-vmrc -X -h "vmware-esxi" -u <login> -p <password> -M "<objID>" - для Vmware ESXi
Значение 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" запустит вирт. машину c Vmware Server 2/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
Но, как и говорил ранее, с загрузкой по сети на работал, поэтому работоспособность не проверял.
