 |
|
|
|
Виртуальный полигон для разработчика и администратора на основе Linux и VMware
Виртуальный полигон для разработчика и администратора на основе Linux и VMware В первой статье этого цикла, опубликованной в сентябрьском номере журнала «Системный администратор», я довольно подробно описал, что такое технология виртуальных машин VMware Workstation и каково ее предназначение. Также мы изучили теоретические основы функционирования, способы и возможные цели практического применения VMware Workstation в повседневной деятельности администратора. Свою точку зрения на вопрос, для решения каких задач стоит применять подобный комплекс программного обеспечения, я высказывал в предыдущей статье. Ну а для тех, кто присоединился к нам только сейчас, кратко повторим содержание сказок тысячи и одной ночи, прозвучавших раньше. Таким образом, тем, кто еще не в курсе, я намекаю, что она была посвящена установке, настройке и опыту успешного применения VMware Workstation на платформе Windows. Господам линуксоидам просьба перестать плеваться и все же найти в себе силы прочесть вышеуказанную статью. Сделать это необходимо хотя бы по той простой причине, что в данной статье я сознательно буду говорить только о необходимом минимуме теории функционирования VMware Workstation. Вместо этого мы обсудим особенности дизайна виртуальных машин и множество прочих полезных вещей. Думаю, лучше потратить время на изложение новых знаний, чем на повторение пройденного материала. Перед тем как пуститься в обсуждение всего разнообразия полезных применений продукта, которому посвящена наша сегодняшняя беседа, разберемся с некоторыми наиболее важными базовыми идеями и терминами, проходящими красной нитью через текст всей статьи. Операционная система, под управлением которой работает программа VMware Workstation, называется «основной» системой. Такие системы, в свою очередь, делятся на официально поддерживаемые и те, кому не повезло. Начнем с перечисления имен титулованных особ из рода Linux:
Официально поддерживаемыми называются те виды Linux, для которых разработчики VMware Workstation создали бинарные файлы модулей, загружаемых в ядро. Пользователи всех остальных версий Linux должны компилировать такие модули из исходных текстов самостоятельно. В качестве основной Linux-системы ALT Linux Master 2.2 был выбран вопреки тому факту, что он отсутствует в приведенном выше списке, но в то же время довольно широко распространен среди русскоязычных пользователей, и, наконец, за то, что вовремя оказался под рукой. Процедура установки на любой из официальных Linux-дистрибутивов слишком проста, чтобы научить читателя чему-то полезному. Многие подводные камни пройдут мимо и не будут замечены до тех пор, пока не придется самостоятельно устанавливать виртуальные машины для работы под управлением варианта Linux, неизвестного авторам VMware Workstation. Пользуясь моим опытом, читатель ценой малой крови научится устанавливать VMware Workstation на любое множество разновидностей Linux. Теперь перейдем ко второму виду систем. Системы, запущенные внутри контейнера виртуальной машины VMware Workstation, называются «гостевыми». Я уверен, что с задачей, которую мы будем решать, в той или иной степени приходилось сталкиваться большинству администраторов. Нужно создать действующий макет сети предприятия с несколькими компьютерами, благополучно проживающими внутри этих виртуальных сетей. И, вдобавок ко всему, нужно обеспечить всю веселую компанию доступом в Интернет. Для облегчения восприятия учебного материала упростим рабочий макет, поместив в каждую сеть только необходимый минимум компьютеров. Я думаю, этого будет достаточно для успешного усвоения обсуждаемых концепций.
На приведенной выше схеме мы видим, что в сетях VMnet3 и VMnet2 находятся машины, работающие под управлением операционных систем Windows 98SE и Windows 2000, символизирующие обычные рабочие станции. Машина Windows 98SE имеет статический адрес 192.168.120.15, а Windows 2000 получает адрес 192.168.80.128 динамически с помощью DHCP. Сеть Vmnet1 используется нами как демилитаризованная зона (DMZ). Внутри нее обитает машина со статическим адресом 192.168.40.32 под управлением Linux Mandrake 9.0. На ней для демонстрации работы сетевых служб установлен веб-сервер Apache. Между собой все три сети, перечисленные выше, соединены с помощью шлюза, как ни странно, имеющего также три сетевых интерфейса и функционирующего под управлением FreeBSD 4.7. Я надеюсь, всем понятно, что для облегчения стыковки наших сетей все три интерфейса машины FreeBSD должны иметь фиксированные адреса. Ну и в роли нашего последнего героя выступает машина NetBSD с двумя интерфейсами. Первый из них с адресом 192.168.40.57 смотрит в демилитаризованную зону, а второй является шлюзом в Интернет. На втором интерфейсе 192.168.32.128 работает механизм преобразования сетевых адресов (NAT), это, в свою очередь, дает возможность предоставить доступ к веб-серверу клиентам, находящимся в Интернете. Частично благодаря этому машины, находящиеся в наших локальных сетях, могут легко пользоваться услугами не только Linux веб-сервера, но и какого угодно другого веб-сервера, расположившегося в любой точке Интернета. С точки зрения VMware Workstation наши тестовые сети будут выглядеть так.
На первый взгляд схема сетевых взаимодействий выглядит устрашающе сложно, но на самом деле это не так, и через несколько минут вы будете с легкостью ориентироваться в топологии наших сетей. Итак, на рисунке мы видим все перечисленные ранее хосты и их интерфейсы. Присмотревшись внимательно, легко разобраться в соответствии между IP-адресами и интерфейсами. Далее изображены три виртуальных коммутатора для сетей host-only VMnet1 (192.168.40.0), VMnet2 (192.168.80.0), VMnet3 (192.168.120.0). Соответственно для работы с устройством NAT (192.168.32.2) предназначена сеть VMnet8, для которой по умолчанию используется адресное пространство 192.168.32.0. Также обратите внимание на тот факт, что виртуальные DHCP-сервера работают только в сетях VMnet2 и VMnet8. Исходя из того факта, что в сетях VMnet1 и VMnet3 используются статические IP-адреса, DHCP-сервера этих сетей отключены за ненадобностью. Итак, приступим к установке. На сайте производителя заказываем себе тестовый серийный номер для Linux. Все подобные лицензии действуют в течение 30 дней с момента заказа. Таким образом, мы получаем в свое распоряжение на целый месяц полнофункциональную версию программы. Через несколько минут в наш ящик электронной почты упадет два письма с серийными номерами для разных платформ. Запрашивать новые тестовые лицензии можно неограниченное количество раз, но на разные почтовые ящики. Таким образом, можно использовать VMware Workstation, не нарушая никаких законов, сколько угодно долго. Подобная лояльная политика персонала VMware.inc вызывает искреннее уважение. Дело в том, что дистрибутив VMware Workstation для Linux распространяется в двух форматах – rpm и tar.gz. Скачать их можно тут: http://www.vmware.com/download/workstation.html. Также не забудьте взять фирменную документацию в формате pdf. Я расскажу о процедуре установки каждого из этих дистрибутивов VMware Workstation. Таким образом, вы сможете выбрать способ, наиболее подходящий лично вам. Ну а процедура конфигурирования, которая последует сразу за инсталляцией, одинакова для обоих видов дистрибутивов. Первым делом давайте рассмотрим наиболее простой способ. Для установки из rpm нужно выполнить всего одну команду. # rpm -i VMware-workstation-4.0.0-4460.i386.rpm Убеждаемся, что все установилось правильно. # rpm -qa | grep VMware
На этом действия с rpm можно считать законченными. Переходим к инсталляции из tar.gz: # tar zxvf VMware-workstation-4.0.0-4460.tar.gz Распаковываем дистрибутив и в результате получаем директорию vmware-distrib. Переходим в нее и запускаем скрипт инсталляции. # cd vmware-distrib # ./vmware-install.pl Скрипт будет задавать нам вопросы. В большинстве случаев нам подойдут ответы, предлагаемые по умолчанию. Они заключены в квадратные скобки и, чтобы согласиться с ними, нужно просто нажать клавишу «Enter». Итак, приступим.
Скрипт спрашивает, куда складывать выполняемые файлы. Ответ по умолчанию нас вполне удовлетворяет.
Следующий вопрос касается того, куда нужно поместить библиотечные файлы. Поступаем так же, как и в предыдущем случае.
А здесь мы будем хранить документацию для VMware Workstation в формате man.
Скрипт предложил поместить документацию в формате txt в директорию /usr/share/doc/vmware/. Пусть будет так, я не против, да и места на жестком диске не жалко.
Жалуется на то, что директории /usr/share/doc/vmware не существует, и спрашивает, создавать ли ее. Отвечаем «yes». Кстати, после инсталляции, сходив в директорию /usr/share/doc/vmware/, видим, что кроме лицензий и инструкций по установке там больше ничего нет. Все то же самое можно увидеть внутри директории doc дистрибутива VMware Workstation. Ну что же, не будем останавливаться и продолжим настройку.
Тут нужно указать, где находится директория со скриптами для разных уровней загрузки системы. Для используемого мною дистрибутива это директория /etc/rc.d/.
Ну а тут находятся скрипты запуска демонов, используемые при начальной загрузке системы.
Можно считать инсталляцию завершенной. Скрипт спрашивает, нужно ли приступить к конфигурированию. Оно производится с помощью скрипта /usr/bin/vmware-config.pl. Теперь к нам присоединяются те, кто производили установку из rpm. Они должны запустить этот скрипт вручную. Узнаем версию ядра. Чуть позже эти знания обязательно пригодятся нам. # uname –a
Запускаем скрипт конфигурирования: /usr/bin/vmware-config.pl
Нажимаем Enter и читаем лицензионное соглашение. Переход между страницами соглашения осуществляется клавишей «Пробел». Дойдя до конца, видим приглашение принять лицензию.
Отвечаем «yes» и движемся дальше.
Система рапортует о том, что не смогла найти модули, подходящие к нашему ядру. Список доступных модулей можно увидеть в директории /usr/lib/vmware/modules/binary. Далее система хочет убедиться в том, что у нас установлен работоспособный компилятор языка C.
Говорит, что не может найти утилиту make на нашей машине, и предлагает поискать ее самостоятельно, а затем сообщить правильный путь. Ну что же, попробуем найти то, что нам нужно. # which make
Теперь посмотрим в списке установленных пакетов: # rpm -qa | grep make Как ни грустно признать такой факт, но, судя по всему, этой утилиты у нас и вправду нет. Вставляем в привод первый диск дистрибутива и переходим в директорию с пакетами. # cd /mnt/cdrom/auto/ALTLinux/RPMS Ставим make: # rpm -i make-3.79.1-ipl6mdk.i586.rpm Те, у кого под рукой нет дисков с Alt Linux, но есть постоянное подключение к Интернету, могут воспользоваться репозитарием пакетов сайта altlinux.ru. Устанавливать пакеты в этом случае можно с помощью программы apt-get или synaptic. После инсталляции make прерываем сценарий vmware-config нажатием клавиш и запускаем его опять. Скрипт снова спрашивает о наличии компилятора, на это мы ему вновь отвечаем «yes». И в ответ получаем вот такую неприятную ошибочку.
Начинаем разбираться с проблемой. # rpm -qa | grep gcc
Судя по всему, компилятор действительно отсутствует, в наличии только служебные пакеты для gcc. В ALT Linux для удобства администрирования используется концепция альтернатив. Это означает, что все наиболее важные системные утилиты должны иметь ссылки на свои бинарные файлы из каталога /etc/alternatives: #ll /etc/alternatives/gcc
Таким образом, мы видим, что файл /etc/alternatives/gcc указывает на файл /usr/bin/gcc_wrapper, который не является полноценным компилятором. А служит лишь для того, чтобы выводить сообщение об ошибке на случай, если пользователь попытается запустить его. # ./gcc_wrapper
Такая вот своеобразная заглушка. Ну что же, значит, придется снова ставить все самому. Переходим на диск 3 дистрибутива и пытаемся устанавливать пакет gcc2.96-2.96-alt3.i586.rpm. Внимательный читатель может задать вопрос, почему мы используем gcc именно этой версии, когда нам доступна гораздо более новая версия 3.2. Ответ очень прост: ядро, на котором работает система, собрано версией 2.96 компилятора gcc. Так что если попытаться поставить что-то другое, скрипт инсталляции VMware Workstation наотрез откажется работать. # rpm -i gcc2.96-2.96-alt3.i586.rpm
Итак, судя по результатам работы команды rpm, у нас неудовлетворенные зависимости между пакетами. Начнем разрешение конфликтов. Как всегда, ехидно замечаем, что счастливчики, пользующиеся apt-get или synaptic, подобных проблем не почувствуют. Мое нежелание использовать apt-get связано с тем, что я предпочитаю делать все самостоятельно. Каким из перечисленных способов добавлять программное обеспечение в систему, оставляю на ваше усмотрение. Ну а я займусь увлекательной игрой, суть которой сводится к поиску и установке следующих пакетов. # rpm -i cpp2.96-2.96-alt3.i586.rpm # rpm -i kernel-headers-common-1.0-alt2.noarch.rpm # rpm -i kernel24-headers-2.4.20-alt5.i586.rpm # rpm -i glibc-devel-2.2.6-alt0.6.i586.rpm # rpm -i libbfd-2.13.90.0.4-alt2.i586.rpm # rpm -i binutils-2.13.90.0.4-alt2.i586.rpm # rpm -i gcc2.96-2.96-alt3.i586.rpm Вновь запускаем скрипт, система снова спросит о компиляторе, а мы опять нажмем «Yes», соглашаясь с тем, что вот теперь-то у нас точно есть компилятор.
На экране появится надпись о том, что в качестве компилятора будет использоваться /usr/bin/gcc. Нас такой поворот событий вполне удовлетворяет, поэтому с легким сердцем переходим к следующему шагу.
Смотрим, куда установили заголовочные файлы нашего ядра, на основе которых VMware Workstation будет собирать модули, загружаемые в работающее ядро. # rpm -qpl kernel24-headers-2.4.20-alt5.i586.rpm Судя по всему, это директория /usr/lib/kernel/2.4.20-alt5/include/. Пишем ее в ответ на приглашение и снова жмем «Enter». Система начнет компиляцию, и на экране начнут появляться надписи вроде:
Система закончит сборку модуля vmmon и перейдет к следующему модулю по имени vmnet. В результате сборки каждого модуля должна появляться вот такая надпись: «The module loads perfectly in the running kernel», говорящая, что созданный модуль загружается в ядро без конфликтов. Далее отвечаем на вопрос, хотим ли мы, чтобы наши виртуальные машины могли работать с сетью.
Как обычно, радостно соглашаемся и переходим на следующую ступеньку.
Сеть vmnet0 используется для работы с устройствами типа мост и конфигурируется автоматически, поэтому нам о правильности ее настроек заботиться нет нужды.
Сеть vmnet8 по умолчанию используется для работы с устройством NAT. Скрипт спрашивает, не желаем ли мы автоматически выбрать свободную частную подсеть. Мы этого не хотим, потому как в наших планах построения макета записано, что для данной цели будет использоваться сеть 192.168.32.0.
Соответственно описываем нужную нам для NAT-сеть и ее маску.
Нажав «Enter», приступаем к изучению лицензии на усеченной версии сервера DHCP, поставляющегося в комплекте с VMware Workstation.
Разрешаем использовать сети типа host-only. Что это за сети и каково их предназначение, читайте в первой статье.
Запрещаем автоматический поиск свободных сетей, потому что мы хотим самостоятельно выбирать адреса раздаваемых сетей. Главное – случайно не напороться на уже существующую в локальной сети подсеть. Иначе некоторое количество «приятных» минут вам обеспечено.
Вот так мы создали сеть Vmnet1 с адресным пространством 192.168.40.0 и маской сети 255.255.255.0. Повторяем те же действия для сетей vmnet2 и vmnet3. Только теперь в качестве адресов сетей используем соответственно 192.168.80.0 и 192.168.120.0.
Cкрипт рапортует об успешном создании сетей vmnet1, vmnet2, vmnet3. В ответ на вопрос, не хотим ли мы настроить еще несколько сетей, отвечаем «no».
Хотим ли мы, чтобы виртуальные машины могли прозрачно работать с файлами, находящимися на файловых системах основной операционной системы? Реализуется это через запуск под управлением основной операционной системы усеченной версии программного обеспечения Samba. Эта версия создана специально для подобной цели, и, скорее всего, ни для чего другого не годится. Мне такая возможность показалось полезной, и я разрешил ее включение. Кстати, в фирменной документации сказано, что если на вашей машине уже работает Samba, то в этом случае нужно в ответ на вопрос сказать «no», потому что иначе в системе начнутся конфликты между полной и усеченной версиями Samba.
Кстати, стоит отметить, что скрипт самостоятельно нашел на моей машине установленную, но не запущенную в данный момент полноценную версию Samba. Проверить, правда ли это, можно, запустив на другой консоли следующие команды: # rpm -qa | grep samba
Ну что же, вернемся обратно к установке. Как всегда, сначала рассказали о лицензии на сервер Samba, с помощью которого будет идти обмен файлами, а затем уведомили, что Samba у нас функционирует нормально. Затем прошел автоматический запуск демона VMware Workstation.
Снова принимаем поздравления с удачной установкой. Кстати, убедиться, что работает именно усеченная версия Samba, можно с помощью запуска на другой консоли вот такой команды. # ps -ax | grep -v grep | grep mbd
Теперь нужно решить, от имени какого пользователя samba будет получать доступ к файлам, находящимся на диске основной операционной системы.
Мне показалось, что создавать еще одного пользователя только для того, чтобы разграничить доступ к файлам основной системы, нецелесообразно. Особенно учитывая тот факт, что я пользуюсь этой машиной единолично. Таким образом, Samba будет работать от имени пользователя root, запустившего серверную часть VMware Workstation. Проверить, как функционируют подсистемы VMware Workstation и какой у каждой из них статус, можно с помощью следующей команды: # service vmware status
Итак, первоначальная настройка VMware Workstation закончена, и мы можем позволить себе посмотреть, как выглядят добавочные сетевые адаптеры, на основе которых работают наши виртуальные сети. # ifconfig
Теперь проверим, какие процессы работают в системе от имени VMware Workstation # ps -ax | grep -v grep | grep vm
Если вы помните, мы уже говорили, что в сетях vmnet1 и vmnet3 все клиенты работают со статическими адресами, поэтому DHCP-сервера этих сетей работают вхолостую. Желательно не забыть отключить DHCP-компоненты вышеназванных сетей. Впрочем, если вы этого не сделаете, то ничего страшного не произойдет, но дизайн сети будет уже не таким опрятным, да и системные ресурсы все же не бесконечны. Все настройки VMware Workstation хранятся внутри каталога /etc/vmware. Каждая из сетей имеет свою папку внутри вышеназванного каталога. Для наглядности давайте посмотрим на содержимое папки /etc/vmware/vmnet1, в которой хранятся настройки для сети vmnet1. Как вы могли бы догадаться, /etc/vmware/vmnet1/dhcpd/ содержит настройки сервера dhcp, а /etc/vmware/vmnet1/smb/ соответственно является местом хранения конфигурационных файлов усеченной версии сервера Samba. Для того чтобы остановить сервера DHCP, обслуживающие сети vmnet1 и vmnet3, нужно удалить каталоги /etc/vmware/vmnet1/dhcpd/ и /etc/vmware/vmnet3/dhcpd/. Ну и напоследок стоит убедиться, что в файле /etc/vmware/vmnet2/dhcpd/dhcpd.conf есть вот такая секция: subnet 192.168.80.0 netmask 255.255.255.0 { range 192.168.80.128 192.168.80.254; option broadcast-address 192.168.80.255; option domain-name-servers 192.168.80.1; option domain-name "localdomain"; option routers 192.168.80.2; } Иногда скрипт конфигурирования сети VMware Workstation забывает дописать в эту секцию строку option routers, отвечающую за адрес шлюза по умолчанию. Соответственно клиенты при работе с DHCP-сервером успешно получают IP-адреса, но дальше своей родной сети пойти не могут, потому что не знают адреса маршрутизатора. Осталось подправить одну крохотную, но в то же время очень важную настройку. Если мы хотим, чтобы люди из внешнего мира видели наш виртуальный веб-сервер, работающий на машине Linux Mandrake, то нам нужно организовать проброс входящих соединений. Получается, что все соединения, приходящие на 80-й порт реальной машины, нужно заворачивать на 80-й порт виртуального веб-сервера. Делается это очень просто, хотя и не так элементарно, как если бы VMware Workstation работала под управлением Windwos. Нужно добавить в файл /etc/vmware/vmnet8/nat/nat.conf внутрь секции [incomingtcp] следующие строки. # incoming www from outside on port 80 80 = 192.168.40.32:80 Затем необходимо перезапустить серверную часть VMware Workstation, заставив применить внесенные изменения. # service vmware restart
Судя по выводу скрипта, DHCP-сервера отключились во всех виртуальных сетях разом. На самом деле это не так. Давайте проверим наличие демонов VMware Workstation в памяти. Делать это нужно все той же доброй старой командой ps: # ps -ax | grep -v grep | grep vm
Затаив дыхание, рассматриваем вывод команды. И – о чудо! – судя по надписям, демоны DHCP-сервера вполне нормально обслуживают сети vmnet2 и vmnet8. С начальной настройкой покончено, можно двигаться дальше. Также стоит посмотреть, что появилось в директории /usr/bin/ после инсталляции:
Как вы могли убедиться, VMware Workstation поставляется с довольно богатым набором инструментов. Возможно, некоторые из них мы будем использовать для диагностики и устранения неполадок, если таковые возникнут в наших виртуальных сетях. Продолжать злоупотреблять полномочиями пользователя root больше нет необходимости, поэтому нам стоит превратиться в обычного пользователя, под которым мы и будем ежедневно работать с VMware Workstation. $ /usr/bin/vmware Программа должна отработать нормально, и на экране появится главное окно клиентской части VMware Workstation. Пользуясь меню «Help –> Enter Serial Number», активируем установленное программное обеспечение с помощью тестового серийного номера, присланного нам по почте.
Программа предложит зарегистрироваться в качестве пользователя на сервере vmware.com. Я решил, что делать этого не желаю, и нажал «Cancel». Вы же можете поступать, как захотите, потому что регистрация на сайте – мероприятие сугубо добровольное и на работу не влияющее.
Теперь необходимо проверить, правильно ли сработала активация лицензии. Для этой цели нам пригодится меню «Help –> About». Если у вас появилось на экране что-то подобное следующему рисунку, значит, дела идут как положено.
Особое внимание cтоит обратить на дату, расположившуюся за надписью Expiration. Она указывает, до какой даты мы сможем пользоваться лицензией, а значит, и самой программой VMware Workstation. Итак, закончив с первоначальной настройкой VMware Workstation, перейдем к созданию наших виртуальных машин. Этот процесс очень подробно описывался в первой статье данного цикла. Если есть желание, можете выполнить его снова. Хотя я думаю, что ничего нового вы для себя не откроете. Ну а я как человек, искренне верящий в слова «лень – двигатель прогресса», поступлю иначе. Если вы помните, от предыдущей статьи нам в наследство остались комплекты файлов виртуальных машин, созданных под Windows. Сейчас мы займемся их переносом под Linux. Машина, на которой происходят все безобразия, описанные в этой статье, имеет на борту две операционных системы – ALT Linux и Windows 2000 Professional. Таким образом, нам нужно примонтировать файловую систему Windows к дереву Linux в директорию /mnt/win_d/VirtualMachines. Выполнив эту задачу, мы получим доступ к файлам наших виртуальных машин. Итак, давайте посмотрим, из каких файлов состоит любая виртуальная машина. В качестве примера возьмем машину Windows 98. Файлы win98-f001.vmdk и win98.vmdk отвечают за работу с жестким диском. Первый из них содержит образ диска, а второй – его конфигурацию. Далее идет файл nvram, в котором хранится образ и настройки BIOS данной виртуальной машины. Как вы, наверное, уже догадались по названию, vmware.log хранит протоколы работы. Поэтому в случае возникновения каких-либо сбоев в функционировании гостевой системы, устранение неполадок лучше всего начать с просмотра именно этого файла. И наконец, мы подходим к самому интересному из всей коллекции – файлу win98.vmx. Именно он хранит в себе набор необходимых для работы виртуальной машины данных. В качестве таких данных могут выступать:
В случае если VMware Workstation в данный момент производит какие-либо действия с нашей виртуальной машиной, в директории появится еще и файл блокировки доступа win98.vmx.WRITELOCK. Ну а если вдобавок ко всему еще и гостевая система выполняется, то для каждого файла виртуального диска создается дополнительный файл блокировки win98.vmdk.WRITELOCK. Также внутри директории можно встретить файлы вида win98.vmss и win98.vmsn. Соответственно первый из них содержит данные, полностью описывающие состояние виртуальной машины на тот момент, когда ее функционирование было приостановлено с помощью команды «Power –> Suspend». Ну а второй хранит данные моментального снимка виртуальной машины, получаемого с помощью команды «Snapshot –> Save Snapshot». Время от времени внутри директории с файлами гостевой системы на короткие промежутки времени будут появляться различные служебные файлы, но вы их, скорее всего, никогда не увидите. Разобравшись с устройством виртуальной машины на файловом уровне, перейдем от теории к действиям. Для того чтобы мы могли работать с выбранной машиной, нужно объяснить VMware Workstation, где находятся необходимые нам файлы. Используем меню «File –> Open», получаем следующую картинку.
Выбираем файл win98.vmx и обязательно используем по прямому назначению кнопку «ОК». После того, как VMware Workstation выполнит открытие всех нужных файлов, можно запускать виртуальную машину с полученной только что гостевой системой. Тут нас ждет несколько неприятных неожиданностей. Как из рога изобилия, начинают сыпаться ошибки и предупреждения. Возможно, на вашей системе некоторые из них никак не проявят себя, а взамен появятся какие-либо новые конфликты. Но бояться этого все же не стоит. Большинство из таких проблем поддаются коррекции довольно просто.
Итак, тут мы видим конфликтную ситуацию, возникшую внутри подсистемы сетевого оборудования. А если говорить точнее, то VMware Workstation сообщает, что у нее отсутствует сетевой адаптер VMnet3. Нажимаем «OK» и переходим к следующей ошибке.
Теперь жалоба касается CD-ROM. Нас предупреждают, что не все режимы работы будут доступны из-за конфликтов с настройками реального и проецируемого на него виртуального устройства.
В связи с разницей в имени гибкого диска между Windows и Linux, диск A: тоже не хочет работать.
Совсем не понравилась VMware Workstation моя ps/2 мышь glidepoint. Но это не беда, доктор сказал, что на этом свете почти все неприятности поправимы.
Снова не совпадает наименование устройств системы. На этот раз нам отказала звуковая карта.
Эта ошибка единственная, с которой я не смог справиться, но она некритична. Дело в том, что моя устаревшая видеокарта и установленный на машину X-сервер не поддерживают аппаратную акселерацию режима DGA, поэтому во время работы гостевой системы в полноэкранном режиме возможны проблемы с быстродействием. Ради интереса я проверил, так ли это. Невооруженным глазом заметить какое-либо замедление не удалось.
После того как гостевая система с горем пополам закончила загрузку, вся панель устройств похожа на выездной пикник красного креста. Просмотрев весь список ошибок, который VMware Workstation посчитала необходимым показать нам, приступим к исправлению оных. Первым делом беремся за настройку сетевого адаптера. Проходим через меню «Edit –> Virtual Machine Settings» и выбираем устройство Network Adapter. Точно такого же эффекта можно добиться с помощью меню «Edit –> Removable Devices –> Ethernet0 –> Edit».
Итак, нам нужно вместо VMnet3 выбрать из ниспадающего меню /dev/vmnet3. Затем с помощью переключателя «Connect» подключить устройство к работающей гостевой системе. Дело в том, что VMware Workstation позволяет подключать и отключать многие устройства прямо на ходу. В качестве таких устройств могут выступать CD-ROM, Ethernet-адаптер, гибкие диски, SCSI-устройства, звуковая карта, высокоточный таймер реального времени. Это, в свою очередь, позволяет более оперативно исправлять проблемы, обходясь без перезагрузки гостевой системы. В общем, должна получиться комбинация настроек, отображенная на следующем рисунке.
Теперь займемся лечением устройства CD-ROM. Сразу же после переноса гостевой системы с Windows на Linux это виртуальное устройство представляет собой следующую совокупность настроек.
Для начала указываем, что нужное нам физическое устройство называется /dev/cdrom/. И обязательно устанавливаем переключатель опции «Legacy emulation». Таким образом, включается режим совместимости со старыми образцами устройств CD-ROM. Это дает дополнительную стабильность функционирования. Затем выбираем один из двух путей: либо приказываем работать с виртуальным CD-ROM в формате IDE-устройства, либо маскируем его под SCSI-устройство. В результате должна получиться одна из двух изображенных ниже комбинаций настроек.
Выбрав тот или иной путь для разрешения проблемы с CD-ROM устройством, идем дальше. Теперь нужно разобраться с PS/2 мышью, установленной на основной системе. Запускаем программу настройки общесистемных параметров (для моего дистрибутива это drakconf ) и выбираем в качестве мыши устройство «Стандартная PS2 мышь с колесом (IMPS2)».
Настраивать мышь можно и вручную: для этого нужно открыть файл /etc/X11/XF86Config-4, в котором находятся настройки X-сервера. Ищем внутри него секцию, отвечающую за работу мыши, и вносим вместо нее следующие строки: Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol" "IMPS/2" Option "Device" "/dev/psaux" Option "ZAxisMapping" "4 5" EndSection Вешаем на стену скальп еще одной решенной проблемы и переходим к следующей. Сейчас нам нужно починить устройство для работы с гибкими дисками. Под Windows оно называется A: , ну а под Linux это будет одно из устройств семейства /dev/fd. В моей системе это устройство называется /dev/fd0.
Налюбовавшись рисунками с изображением настроек «до» и «после», перейдем к решению следующей проблемы. У нас на очереди звуковая карта. Посмотрим, что именно вписано в конфигурацию этого устройства.
Неудивительно, что оно не работает при таком странном названии «-1». Вместо этого, слегка задумавшись, но ничуть не сомневаясь, выбираем /dev/dsp:
Разобравшись со всеми проблемами, закрываем VMware Workstation и все остальные приложения. Теперь нужно перезапустить X-сервер для того, чтобы изменения в настройках мыши вступили в действие. Нажимаем комбинацию кнопок . После перезагрузки X-сервера снова входим в систему и запускаем VMware Workstation и внутри нее гостевую машину Windows 98. Уж теперь-то все должно заработать на ура. Используя вышеописанную методику, чиним все остальные гостевые системы. Таким образом, у нас появятся работоспособные виртуальные машины с FreeBSD, NetBSD, Linux, Windows 2000. Кстати, перед запуском каждой из них вы будете видеть вот такую картинку, предупреждающую о том, что в системе работает несколько гостевых систем, и совместный доступ к аппаратным устройствам может работать некорректно.
К таким устройствам можно отнести CD-ROM, гибкие диски и таймер реального времени. Если не хотите, чтобы подобные надписи впредь появлялись на экране, воспользуйтесь переключателем «Never show this hint again». Хотя такой подход все равно не спасет от конфликтов, зато избавит от постоянного лицезрения данной надписи. Загрузив первую гостевую систему, сразу же запускаем вторую и моментально получаем первый конфликт.
Судя по всему, гостевая система, запущенная первой, заблокировала устройство /dev/fd0, и теперь ни одна другая система не сможет работать с ним до тех пор, пока оно не будет освобождено. Дабы избежать подобных коллизий в будущем, сделайте так, чтобы переключатели «Connected» и «Connected at power on» были отключены.
Таким образом, устройство для работы с гибкими дисками будет отключено по умолчанию. Мы сможем включить его обратно в любой момент, когда нам нужно будет поработать с ним. А затем, когда необходимость в его услугах отпадет, будем возвращать его в первозданное состояние. Самый простой способ включить или выключить устройство – это воспользоваться меню «Edit –> Removable Devices», а затем выбрать нужное устройство и вид действия, производимого над ним. Например, для отключения обсуждавшего выше дисковода гибких дисков нужно пройти через следующую цепочку меню «Edit –> Removable Devices –> floppy0 –> Disconnect».
Разобравшись с первым конфликтом, переходим к следующему. Тут мы видим, что таймер реального времени, в качестве которого выступает устройство /dev/rtc, также заблокирован первой гостевой системой.
Прочитав фирменную документацию по VMware Workstation, узнаем, что операционные системы семейства Windows в процессе работы постоянно опрашивают это устройство. Подобное поведение, в свою очередь, может привести к весьма чувствительному повышению нагрузки на основную систему. Далее в документации говорится, что теоретически Windows должна нормально работать и без использования таймера реального времени. Отключаем устройство RTC и проверяем. По крайней мере, мои виртуальные машины, подвергшись такой вивисекции, не утратили стабильного функционирования. Кстати, иногда редактирование конфигурации выключенной виртуальной машины может привести к такой ошибке.
Пугаться этого не стоит, вероятность того, что вы испортите свою гостевую систему, слишком мала. Просто по непонятным причинам конфигурационный файл оказывается заблокирован для записи. Чтобы решить эту проблему, нужно закрыть вкладку виртуальной машины внутри VMware Workstation и открыть ее снова. На следующей картинке можно увидеть одновременную работу всех систем, на импортирование которых мы потратили столько труда. Для наглядности каждая из них запущена в отдельном окне. Конечно, можно было запустить их внутри разных вкладок родительского окна, но я решил, что так картинка будет выглядеть недостаточно эффектно. Добиться подобного вида можно, используя меню «File –> New –> New Window». Во вновь появившемся окне, следуя укоренившейся привычке, выбираем «File –> Open». Внимательный читатель может спросить, зачем все эти сложности. Мой ответ будет довольно прост. Такой подход позволяет разложить виртуальные машины в нужном порядке по виртуальным столам оконного менеджера. Лично мне это кажется весьма удобным. У подобной методики работы есть один щекотливый момент. Если внутри любого окна создана вкладка с гостевой операционной системой, то эта система становится не доступна для запуска из другого окна. Все дело в том, что VMware Workstation в момент открытия конфигурации виртуальной машины создает файл эксклюзивной блокировки. Называется такой файл обычно «имя гостевой системы.vmx.WRITELOCK». Причем файл создается еще до запуска гостевой системы и остается до тех пор, пока не будет закрыта вкладка гостевой системы или завершится работа VMware Workstation. Получается, что конфигурация гостевой системы будет заблокирована в любом случае, вне зависимости от того, работает гостевая система или нет. Если попытаться открыть эту гостевую систему еще раз, то получим по рукам.
В свою очередь, признаком работы системы служит появление дополнительного файла блокировок файлов жестких дисков, называющегося «имя гостевой системы .vmdk.WRITELOCK». Видимо, разработчики VMware Workstation не смогли придумать более надежного способа для проверки факта запуска той или иной гостевой системы. Кстати, если во время работы гостевой системы удалить все файлы WRITELOCK, то ее легко можно запустить повторно. Например, на следующем рисунке можно видеть два экземпляра гостевой системы Windows 98, запущенных из одного и того же файла и работающих одновременно довольно-таки стабильно.
Впрочем, использовать такие приемы в практической работе не стоит, потому что совершенно непонятно, как поведут себя обе гостевые системы, если им одновременно потребуется записать какие-либо данные в файл виртуального диска. Мы немного отвлеклись от темы нашего повествования. После переноса и успешного запуска всех гостевых систем настал момент проверить, насколько правильно работает наш макет. Для этого на Windows-машинах выполняем команду ipconfig /all и смотрим, какие настройки у нашей сетевой подсистемы. Например, на следующем снимке можно увидеть результат выполнения вышеуказанной команды на машине Win2000.
Так как все остальные системы, используемые в нашем макете, являются диалектами UNIX, то для просмотра состояния их сетевых интерфейсов нужно использовать команду ifconfig. Например, для машины FreeBSD вывод команды выглядел вот так:
Таким образом, проверив правильность настройки сетевых компонентов всех подопытных систем, начинаем смотреть, как по тестовым сетям передаются данные. Для этого на любой машине выполняем команду ping с адресами всех остальных машин. Если ping работает, то переходим к следующему этапу. Теперь любым браузером заходим на адрес 192.168.40.32. Должны увидеть что-то вроде такой страницы с приветствием от веб-сервера Apache.
Затем с любой машины, находящейся за пределами созданной виртуальной сети, пытаемся сходить браузером на адрес нашей реальной машины. В ответ должны получить тот же самый привет от Apache. Судя по всему, задача по созданию виртуального полигона, полностью соответствующего схеме, наконец-то выполнена. Как всегда, прощаемся до следующей статьи, которая будет посвящена разным трюкам, заметно облегчающим жизнь при работе с VMware Workstation. |
АНДРЕЙ БЕШКОВ
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
