From: Махнёв Александр <casm82@gmail.com.>
Newsgroups: email
Date: Mon, 30 Jun 2009 17:02:14 +0000 (UTC)
Subject: Виртуализация рабочих станций на 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.
И так после того, как получили вышеназванное ПО приступаем к настройке.
Необходимо будет сделать:
1.Серверная часть
a. Установить Vmware Server 2, создать виртуальные машины.
b. Задать права доступа к виртуальным машинам.
2.Клиентская часть
a. Установить ОС, настроить X Server
b. Установить VMware Remote Console
c. Настроить автозапуск консоли vmware, при старте X Server
d. Настроить автовход пользователя в консоль Linux
e. Настроить выключение физической машины клиента, при выключении виртуальной.
Серверная часть.
Установка Vmware Server 2 и создание виртуальных машин.
На сервер устанавливаем Vmware Server 2, настраиваем, запускаем. Тут
сложностей возникнуть не должно. Единственное разве, что модуль vmsock
может не установиться, но он экспериментальный и по-умолчанию
предлагается его не устанавливать. В качестве Администратора указываем
существующего на сервере 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).
Далее для созданных виртуальных машин в 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 Server2), в каталог
/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-vmrc/vmware-vmrc и будет использоваться для
подключения к виртуальным машинам. Параметры, которые воспринимает
скрипт можно узнать, запустив его с опцией --help. Мне наиболее
интересны были:
-X - запуск консоли в полноэкранном режиме
-M - номер виртуальной машины (см. objID в /etc/vmware/hostd/vmInventory.xml на сервере)
Так же есть еще два параметра, которые в справке у меня не отобразились, это
-u - имя пользователя, используемое для подключения к Vmware Server 2, то,
что задавали во вкладке Permissions в консоли Vmware, и опция
-p - соответствующий пароль пользователя на Linux сервере.
В итоге строка для подключения будет примерно такая:
Значение objID, как уже писал можно узнать в файле
/etc/vmware/hostd/vmInventory.xml на сервере, оно определяет, к какой
виртуальной машине клиент будет подключаться.
Например, если vmInventory.xml содержит следующее:
запустит вирт. машину /mnt/vmware/WindowsXP01/Windows XP.vmx, при
условии, что пользователь vmrc на сервере 192.168.1.3 имеет право
включать данную машину.
Если все нормально запустилось, то должно появиться окно "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".
Теперь осталось добиться, чтобы всё это запускалось автоматом.
Если на клиентской машине linux пользователь использует bash, то в
~/.bashrc дописываем
if [ -z "$DISPLAY" ] && [ $(tty) == /dev/tty1 ] ; then
startx
fi
(взято с http://www.xserver.ru/computer/os/linux/98/).
Для других шеллов - по аналоги.
Далее необходимо настроить автовход в linux-консоль, чтобы не шокировать
простых пользователей. Благо на самих клиентских машинах, кроме objID
никаких рабочих данных не будет храниться.
Если же зловредный пользователь попытается просмотреть файл .xinitrc,
чтобы узнать имя и пароль пользователя для подключения (зная это, он
может наблюдать за рабочим столом), ему необходимо будет, либо
переключиться на вторую, третью и т.д. консоль, а там его будет ждать
приглашение от login, либо завершить X server. Далее будет указан
способ, как сделать так, чтобы при завершении работы X server
производилось автоматическое выключение компьютера.
Возможно, конечно, загрузиться с livecd и посмотреть данный файл. В
таком случае, либо снимайте дисковод, CD-ROM (с флешек компьютеры,
работающие на Pentium II, как правило, не умеют загружаться), либо
перемещайте клиентские компьютеры и сервер в изолированный vlan, либо
все вместе.
Для автовхода можно воспользоваться mingetty. Скачиваем и ставим
mingetty (на Debian CD1 пакета не было обнаружено), и редактируем
/etc/inittab.
где <vmware-user> - пользователь локальной, клиентской ОС, в моём
примере это vmware.
Теперь при загрузке клиентской машины c Linux, будет производиться следующее:
1. Автоматический вход в систему
2. Запуск X Server, с клиентом vmware-vmrc
3. Подключение клиента vmware-vmrc к виртуальной машине на Vmware Server 2
4. Включение виртуальной машины, и перенаправление вывода на экран клиентской машины.
Настройка автоматического выключения физической машины клиента при выключении виртуальной.
Пользователь ожидает, что если зайти в меню Пуск и нажать Завершение
работы, то его машина будет выключена. В нашем же случае, это приведет к
завершению работы консоли vmware-vmrc, завершению работы X server и в
результате перед пользователем предстанет черно-белая консоль Linux. Это
немного не то, что ожидал пользователь.
Для того чтобы после виртуальной машины отключалась и физическая, можно
поступить следующим образом:
1. Установить пакет sudo (если не стоял)
2. От root запустить visudo, и добавить правило: vmware ALL = NOPASSWD: /sbin/halt
(если вы используете другого пользователя, то создайте правило для него)
3. В файле ~/.xinitrc для пользователя vmware после строки
В итоге получим, что при завершении работы виртуальной машины, завершит
работу клиент vmware-vmrc и будет выполнена команда sudo /sbin/halt, что
приведет к выключению физической машины. Что нам и требовалось.
Однако, здесь есть недостаток: физическая машина выключиться и при
случайном завершении X server. Это может случиться при нажатии
Ctrl-Alt-Backspace, или если пользователь закроет клиента VMware Remote
Console (крестик на панели инструментов). При повторном же включении
физической машины, клиент заново подключиться к виртуальной машине и
продолжить работу.
Клонирование клиентских машин.
Далее остаётся клонировать настройки на остальные клиентские машины,
изменить значение objID, имя и пароль для подключения (если используются
для каждой машины свой).
Здесь множество вариантов:
1. Вручную создать архив, начиная с корня, развернуть его на другой
клиентской машине, установить загрузчик и перенастроить X Server.
2. Подключить второй жесткий диск и воспользоваться командой dd.
3. Воспользоваться Акронисом.
4. Любой другой способ :)
Напишу, как думаю делать я, возможно, кому-то пригодиться (пока все, что
описал, тестируется на одной клиентской машине и то виртуальной).
Создание архива.
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):
a) Предварительно монтируем /dev:
#mount --bind /dev /mnt/target/dev
b) Переходим в клонированную систему:
#chroot /mnt/target
c)Если жесткий диск, в клонированной системе имеет другое наименование,
то редактируем /boot/grub/device.map, /boot/grub/menu.lst, /etc/fstab
d) Устанавливаем Grub: grub --no-floppy (с --no-floppy запускается быстрее)
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):
Vova
