OpenNET: статья - Виртуализация рабочих станций на Vmware Server 2. (vmware virtual linux)

Ключевые слова: vmware, virtual, linux, (найти похожие документы)
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). 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 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-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/vmware-vmrc и будет использоваться для подключения к виртуальным машинам. Параметры, которые воспринимает скрипт можно узнать, запустив его с опцией --help. Мне наиболее интересны были: -X - запуск консоли в полноэкранном режиме -M - номер виртуальной машины (см. objID в /etc/vmware/hostd/vmInventory.xml на сервере) Так же есть еще два параметра, которые в справке у меня не отобразились, это -u - имя пользователя, используемое для подключения к Vmware Server 2, то, что задавали во вкладке Permissions в консоли Vmware, и опция -p - соответствующий пароль пользователя на Linux сервере. В итоге строка для подключения будет примерно такая: ~/vmware-vmrc/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 (взято с 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. Пример, для 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, будет производиться следующее: 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/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, имя и пароль для подключения (если используются для каждой машины свой). Здесь множество вариантов: 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 запускается быстрее) grub> root (hd0,1) # hd0,0 - swap, hd0,1 - корень grub> setup (hd0) # ставим в mbr если успешно - выходим grub> quit e) Выходим из chroot: ^D (Ctrl-D) f) Размонтируем, что монтировали: # 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 Но, как и говорил ранее, с загрузкой по сети на работал, поэтому на этом и закончу. Если есть замечания, предложения - интересно было бы их услышать.

2.8, casm (ok), 19:00, 12/09/2009 [^] [^^] [^^^] [ответить]

+/–

>как минимизировать трафик, какие решения
>предложите?

Трафик не замерял, тут ничего не могу сказать.
У меня при 1280х1024 задержек не наблюдается.
Судя по логам wireshark, весь обмен идет с использованием ssl, tls - сжать никак не получиться. Думаю тут лучше разработчиков vmware спросить.

3.11, muirdok (??), 20:21, 16/11/2009 [^] [^^] [^^^] [ответить]	+/–
??? а можно отрубить шифрацию ...тлс и ссл ...чтобы трафик "уменьшить" или я глупости говорю?

4.12, casm (ok), 21:09, 16/11/2009 [^] [^^] [^^^] [ответить]	+/–
>??? а можно отрубить шифрацию ...тлс и ссл ...чтобы трафик "уменьшить" или >я глупости говорю? В настройках такого не видел, разве что где-то в файлах указано. Чтобы сэкономить на трафике можно выставить в виртуальной машине меньшее качество графики. Как правило используется 24 бита, плюс эффекты. Если выставить глубину цвета 16 бит, и отключить все эффекты окон (отрисовка при перемещении, тени и т.п.), то трафик уменьшится. У меня так поток снизился с 7 до 3-4 мб/с.

2.9, m0ps (ok), 18:28, 09/10/2009 [^] [^^] [^^^] [ответить]	+/–
>и еще один попутный вопрос - как сделать так, чтобы сетевой интерфейс >в гостевой ОС не был предствален как съемное устройство? сетевая карточка usb-шная... так что от этого не избавиться.

2.13, casm (ok), 21:17, 16/11/2009 [^] [^^] [^^^] [ответить]

+/–

>Уже давно присматриваюсь к этому способу ...
>А не смущает медленная и местами нестабильная работа вебинтерфейса "админки"???

Есть такое. Но на работе виртуальных машин это не сказывается (по крайней мере не замечал).
Аналогично можно настроить работу и с ESXi, то здесь потребуется windows клиент.

Если считать, vmware server 2 как испытательную версию ESXi, то думаю когда доработают веб-интерфейс, ESXi будет управляться аналогично (очень уж похожи стали). Возможно позже и ESX. Но это мои предположения.