Linux как работает vmware

Как установить VMware Workstation в Linux

VMware Workstation – один из самых популярных продуктов виртуализации для десктопа. Посредством него пользователь сможет создавать «виртуалки» с практически любой гостевой «операционкой» – Windows, Linux, Solaris и др.

Загрузка и запуск инсталлятора

Первым делом нужно скачать файл инсталлятора VMware по ссылке. На данный момент (версия 14.0) инсталлятор «весит» 440 Мб.

После загрузки инсталлятора нужно сделать его файл исполнимым, чтобы операционная система могла его выполнить. Для этого нужно перейти в папку Downloads – именно в нее будет загружен этот файл (если вы загружали его посредством браузера) – и выполнить команду chmod для изменения прав доступа к нему:

Рис. 1. Подготовка к запуску инсталлятора VMware Workstation Linux

Запуск самого инсталлятора осуществляется так:

Установка VMware на Linux

Учитывая размер файла установщика, нужно немного подождать, пока он запустится. На первом экране инсталлятора необходимо принять условия лицензии и нажать кнопку Next.

Рис. 2. Инсталлятор VMware Workstation Linux

Далее установщик спросит, хотите ли вы получать апдейты VMware при запуске. Здесь решать только вам, обычно обновления – штука хорошая, но если все устраивает и нормально работает, то особого смысла в них тоже нет.

Рис. 3. Проверять ли обновления VMware при запуске

Затем вас спросят, хотите ли вы участвовать в программе улучшения качества (CEIP). Как и в предыдущем случае – решать только вам. Если не желаете заморачиваться, просто выберите No. Далее более важный вопрос – нужно ввести имя пользователя, который будет подключаться к Workstation Server. Как правило, это пользователь, от имени которого вы сейчас работаете.

Рис. 4. VMware Workstation установка на Linux

Следующий шаг – выбор каталога для хранения общих виртуальных машин (далее — ВМ). Если имеется только один раздел, содержащий и файлы ОС, и пользовательские данные, то этот каталог можно не изменять. А вот создано несколько разделов, то желательно выбрать каталог, находящийся на самом большом и самом быстром накопителе. Для виртуальных машин должно быть достаточно дискового пространства (в среднем для Linux нужно 5-10 Гб, для Windows – от 20 Гб – в зависимости от поставленных задач). Что же касается скорости, желательно размещать файлы виртуальных машин на SSD-диске: так ВМ будут работать быстрее.

Рис. 5. Выбор каталога для общих (shared) ВМ

Следующие два вопроса – номер порта HTTPS — не нужно изменять это значение, особенно, если вы не понимаете, зачем это нужно – и серийный номер продукта. Если VMware Workstation пока не приобреталась, серийный номер можно не вводить.

Рис. 6. Установка VMware на Linux: все готово к установке

Осталось только нажать кнопку Install для установки программы. Установка проходит быстро, поэтому долго ждать не придется – через несколько минут программа будет установлена. Как только установка будет завершена, нажмите Close, чтобы закрыть инсталлятор.

Рис. 7. Установка VMware Workstation в Linux завершена

Запускаем VMware

Воспользуйтесь средством поиска, чтобы запустить VMware Workstation. При желании можно добавить кнопку запуска на десктоп. При первом запуске программа попросит указать лицензионный ключ. Для тестового периода нужно выбрать I want to try VMware Workstation 14 for 30 days, что позволит бесплатно использовать программный продукт 1 месяц.

Рис. 8. Запуск VMware Workstation в Ubuntu

Рис. 9. Ввод лицензионного ключа

При запуске будет запрошен пароль пользователя. Нужно ввести пароль пользователя, указанного при установке программы.

Рис. 10. VMware Workstation запущена

Создаем и запускаем «виртуалку»

Нажмите кнопку Create a New Virtual Machine. В появившемся окне выберите метод конфигурации ВМ: Typical или Custom. В первом случае вам будет задано меньше вопросов, во втором – больше – все просто.

Рис. 11. Создаем виртуальную машину

Установка гостевой ОС может быть выполнена или с привода CD/DVD или путем указания ISO-файла инсталляционного DVD, который можно найти без проблем в Интернете. В первом случае нужно выбрать Use a physical drive и указать имя устройства CD/DVD (обычно это /dev/sr0), во втором – Use ISO image и нажать кнопку Browse для выбора ISO-файла с гостевой ОС. Можно также выбрать переключатель I will install the operation system later, если необходимо установить гостевую систему позже.

Рис. 12. Откуда установить гостевую ОС?

Затем нужно выбрать тип гостевой ОС (рис. 13). Поддерживаются различные варианты Microsoft Windows, Linux и другие системы.

Рис. 13. Выбор типа гостевой ОС

Следующий шаг – выбор имени виртуальной машины и каталога для хранения ее файлов. Обратите внимание: ранее мы выбирали каталог для общих ВМ, а сейчас выбираем каталог для конкретной виртуальной машины. Впрочем, рекомендации те же – должно быть достаточно дискового пространства и накопитель должен быть достаточно быстрым (желательно SSD).

Рис. 14. Имя виртуальной машины и ее расположение

Размер дискового пространства – имеет значение. К счастью, VMware экономно расходует место на диске, поэтому можете указать размер дискового пространства с запасом – будет использовано ровно столько, сколько нужно. Другими словами, вы указываете верхнюю границу, а реально виртуальная машина займет дисковое пространство по факту потребления.

Рис. 15. Размер диска

Также выберите режим виртуального диска – Store virtual disk as a single file (хранить диск ВМ в одном файле) или Split virtual disk into multiple files (разбить диск ВМ на несколько файлов). В первом случае ВМ (из-за размера файла) будет сложнее перенести на другой компьютер, но ее производительность будет выше. Если не планируете переносить виртуальную машину, можно выбрать первый вариант.

Далее мастер предоставит сводку по параметрам виртуальной машины (рис. 16). Нажав кнопку Customize Hardware можно изменить параметры оборудования, например, указать количество процессоров, размер оперативной памяти, тип работы сетевого адаптера и т.д. В большинстве случаев мастер подбирает оптимальные параметры, исходя из выбранной гостевой ОС. При желании вы можете изменить данные параметры, а вообще можно прямо сейчас нажать кнопку Finish для завершения работы мастера.

Рис. 16. Все готово: нажмите кнопку Finish

Переключатель Automatically power on this virtual machine after creation говорит о том, что виртуальная машина будет автоматически запущена сразу после создания.

Рис. 17. ВМ создана и запущена

Поставленная задача выполнена: VMware установлена, создана виртуальная машина. Ваши вопросы и комментарии приветствуются.

Источник

Как установить VMware Workstation Player на Linux

В этой инструкции мы расскажем, как установить VMware на Linux.

Для начала разберемся, что такое виртуальная машина и зачем устанавливать VMware.

Зачем нужна виртуальная машина

Иногда нужно, чтобы на одном компьютере была установлена не одна операционная система. Например, на вашем ноутбуке установлена Linux — эта операционная система нужна вам для работы. Также вы планируете освоить новое хобби — создание музыки и видеороликов. Для этого на компьютер нужно установить программы FL Studio Sony и Vegas Pro. Однако сделать это невозможно, так как программы не адаптированы под Linux.

В этой ситуации можно поступить несколькими способами. Например, загрузить вторую операционную систему на флешку и вставить её в системный блок перед тем, как включить компьютер. Однако в этом случае вы сможете работать только с одной операционной системой, что не очень удобно.

Чтобы работать одновременно с двумя операционными системами, можно установить специальную программу и с её помощью настроить виртуальную машину. Виртуальная машина (ВМ или VM) — это виртуальный компьютер, который использует ресурсы реального компьютера.

ВМ работает благодаря виртуализации: создаёт особое окружение для операционной системы и программного обеспечения, которое в ней запускается. По принципу работы это окружение похоже на обычный компьютер: оно состоит из виртуального жёсткого диска, видеокарты, процессора, контроллеров устройств и оперативной памяти. Также окружение может взаимодействовать с реальными устройствами, например, веб-камерой или DVD-приводом.

Получается, что с помощью виртуальной машины на одном компьютере можно пользоваться несколькими операционными системами. При этом операционная система, в которой запускают виртуальную машину, будет называться хостовой. А система, которая установлена на виртуальной машине — гостевой операционной системой.

В процессе создания виртуального окружения создается также специальный компонент — монитор виртуальной машины, или гипервизор. От гипервизора зависит стабильная работа гостевой операционной системы: он получает и распределяет ресурсы между запущенными операционными системами, а также изолирует системы друг от друга. Благодаря этому гостевая ОС не «догадывается» о существовании гипервизора и «думает», что она работает на реальном компьютере. Это позволяет двум разным операционным системам работать автономно, несмотря на то, что гостевая использует для работы ресурсы и мощности хостовой системы. Подробнее о том, что такое виртуальная машина и как она устроена, читайте в статье.

Чтобы установить на компьютер виртуальную машину, сначала нужно создать для неё виртуальную среду. Для этого существуют специальные программы, одна из которых— VMware Workstation Player.

VMware Workstation Player — это программное обеспечение, с помощью которого можно создать виртуальную машину. Оно позволяет работать с несколькими операционными системами одновременно — каждую виртуальную машину можно свернуть, как обычную программу.

Основные преимущества VMware:

• техническая поддержка программы;
• встроенный драйвер универсальной печати .ThinPrint, благодаря нему драйвер не придется устанавливать на гостевую ОС;
• функция AutoProtect, которая создаёт снэпшоты через заданные промежутки времени. Это работает по принципу автосохранения в Microsoft Office Word;
• защита виртуальной машины 256-битным шифрованием;
• функция Compact Virtual Disks сжимает виртуальные диски, для того чтобы отдать их под нужды других систем;
• запись активности виртуальной машины. Это может быть как видеоформат, так и формат последовательности действий пользователя: файл, в котором описаны все действия пользователя в виртуальной машине.

Системные требования к VMware Workstation Player:

• совместимый 64-разрядный процессор x86 или AMD64, выпущенный в 2011 году или позже,
• тактовая частота 3 ГГц или выше,
• минимум 2 ГБ ОЗУ; рекомендуется 4 ГБ или более.

Ниже мы подробно описали процесс установки VMware Workstation на Linux.

Источник

Linux.yaroslavl.ru

VMware — виртуальный полигон для администратора и разработчика на основе Linux и VMWare

В первой статье этого цикла, опубликованной в сентябрьском номере журнала «Системный администратор», я довольно подробно описал, что такое технология виртуальных машин Vmware и каково ее предназначение. Также мы изучили теоретические основы функционирования, способы и возможные цели практического применения vmware в повседневной деятельности администратора. Свою точку зрения на вопрос, для решения каких задач стоит применять подобный комплекс программного обеспечения, я высказывал в предыдущей статье. Ну а для тех, кто присоединился к нам только сейчас кратко повторим содержание сказок тысячи и одной ночи, прозвучавших раньше. Таким образом, тем, кто еще не в курсе, я намекаю, что она была посвящена установке, настройке и опыту успешного применению vmware на платформе Windows. Господам линуксоидам просьба перестать плеваться и все же найти в себе силы прочесть вышеуказанную статью. Сделать это необходимо хотя бы по той простой причине, что в данной статье я сознательно буду говорить только о необходимом минимуме теории функционирования Vmware. Вместо этого мы обсудим особенности дизайна виртуальных машин и множество прочих полезных вещей. Думаю, лучше потратить время на изложение новых знаний, чем на повторение пройденного материала.

Перед тем, как пуститься в обсуждение всего разнообразия полезных применений продукта, которому посвящена наша сегодняшняя беседа, разберемся с некоторыми наиболее важными базовыми идеями и терминами, проходящими красной нитью через текст всей статьи.

Операционная система, под управлением которой работает программа vmware, называется «основной» системой. Такие системы, в свою очередь, делятся на официально поддерживаемые и тех, кому не повезло. Начнем с перечисления имен титулованных особ из рода Linux:

• Mandrake Linux 8.2, 9.0
• Red Hat Advanced Server 2.1
• Red Hat Linux 7.0, 7.1, 7.2, 7.3, 8.0
• SuSe Linux Enterprise Server 7,8
• SuSe Linux 7.3, 8.0, 8.1

Официально поддерживаемыми называются те виды Linux, для которых разработчики vmware создали бинарные файлы модулей, загружаемых в ядро. Пользователи всех остальных версии Linux должны компилировать такие модули из исходных текстов самостоятельно.

В качестве основной Linux-системы ALT Linux Master 2.2 был выбран не случайно, а вопреки тому факту, что он отсутствует в приведенном выше списке, но в то же время довольно широко распространен среди русскоязычных пользователей, и наконец за то, что вовремя оказался под рукой. Процедура установки на любой из официальных Linux-дистрибутивов слишком проста, чтобы научить читателя чему-то полезному. Многие подводные камни пройдут мимо и не будут замечены до тех пор, пока не придется самостоятельно устанавливать виртуальные машины для работы под управлением варианта Linux, неизвестного авторам vmware. Пользуясь моим опытом, читатель ценой малой крови научится устанавливать VMware Workstation на любое множество разновидностей Linux.

Теперь перейдем ко второму виду систем. Системы, запущенные внутри контейнера виртуальной машины vmware, называются «гостевыми» .

Я уверен, что с задачей, которую мы будем решать, в той или иной степени приходилось сталкиваться большинству администраторов. Нужно создать действующий макет сети предприятия с несколькими компьютерами, благополучно проживающими внутри этих виртуальных сетей. И, вдобавок ко всему, нужно обеспечить всю веселую компанию доступом в Интернет. Для облегчения восприятия учебного материала упростим рабочий макет, поместив в каждую сеть только необходимый минимум компьютеров. Я думаю, этого будет достаточно для успешного усвоения обсуждаемых концепций.

На приведенной выше схеме мы видим, что в сетях 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. На ней для демонстрации работы сетевых служб установлен web-сервер Apache. Между собой все три сети, перечисленные выше, соединены с помощью шлюза, как ни странно имеющего так же три сетевых интерфейса и функционирующего под управлением FreeBSD 4.7. Я надеюсь, всем понятно, что для облегчения стыковки наших сетей все три интерфейса машины FreeBSD должны иметь фиксированные адреса. Ну и в роли нашего последнего героя выступает машина NetBSD с двумя интерфейсами. Первый из них с адресом 192.168.40.57 смотрит в демилитаризованную зону, а второй является шлюзом в Интернет. На втором интерфейсе 192.168.32.128 работает механизм преобразования сетевых адресов (NAT), это, в свою очередь, дает возможность предоставить доступ к web-серверу клиентам, находящимся в Интернет. Частично благодаря этому машины, находящиеся в наших локальных сетях, могут легко пользоваться услугами не только Linux web-сервера, но и какого угодно другого web-сервера, расположившегося в любой точке Интернет.

С точки зрения vmware наши тестовые сети будут выглядеть так.

На первый взгляд схема сетевых взаимодействий выглядит устрашающе сложно, но на самом деле это не так, и через несколько минут вы будете с легкостью ориентироваться в топологии наших сетей. Итак, на рисунке мы видим все перечисленные ранее хосты и их интерфейсы. Присмотревшись внимательно, легко разобраться в соответствии между 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 для Linux распространяется в двух форматах — rpm и tar.gz. Скачать их можно по этому адресу http://www.vmware.com/download/workstation.html. Также не забудьте взять фирменную документацию в формате pdf. Я расскажу о процедуре установки каждого из этих дистрибутивов vmware. Таким образом, вы сможете выбрать способ, наиболее подходящий лично вам. Ну а процедура конфигурирования, которая воспоследует сразу за инсталляцией, одинакова для обоих видов дистрибутивов.

Первым делом давайте рассмотрим наиболее простой способ. Для установки из rpm нужно выполнить всего одну команду.

Убеждаемся, что все установилось правильно.

На этом действия с rpm можно считать законченными. Переходим к инсталляции из tar.gz

Распаковываем дистрибутив и в результате получаем директорию vmware-distrib. Переходим в нее и запускаем скрипт инсталляции.

Скрипт будет задавать нам вопросы. В большинстве случаев нам подойдут ответы, предлагаемые по умолчанию. Они заключены в квадратные скобки и, чтобы согласиться с ними, нужно просто нажать клавишу «Enter». Итак, приступим.

Скрипт спрашивает, куда складывать выполняемые файлы. Ответ по умолчанию нас вполне удовлетворяет.

Следующим вопрос касается того, куда нужно поместить библиотечные файлы. Поступаем так же, как и в предыдущем случае.

А здесь мы будем хранить документацию для vmware в формате man.

Скрипт предложил поместить документацию в формате txt в директорию /usr/share/doc/vmware/. Пусть будет так, я не против, да и места на жестком диске не жалко.

Жалуется на то, что директории /usr/share/doc/vmware не существует, и спрашивает, создавать ли ее. Отвечаем «yes». Кстати, после инсталляции, сходив в директорию /usr/share/doc/vmware/ , видим, что, кроме лицензий и инструкций по установке, там больше ничего нет. Все то же самое можно увидеть внутри директории doc дистрибутива vmware. Ну что же, не будем останавливаться и продолжим настройку.

Тут нужно указать, где находится директория со скриптами для разных уровней загрузки системы. Для используемого мною дистрибутива это директория /etc/rc.d/. Для большинства других она будет называться так же.

Ну а тут находятся скрипты запуска демонов, используемые при начальной загрузке системы.

Можно считать инсталляцию завершенной. Скрипт спрашивает, нужно ли приступить к конфигурированию. Оно производится с помощью скрипта /usr/bin/vmware-config.pl. Теперь к нам присоединяются те, кто проводили установку из rpm. Они должны запустить этот скрипт вручную.

Узнаем версию ядра. Чуть позже эти знания обязательно пригодятся нам.

Запускаем скрипт конфигурирования /usr/bin/vmware-config.pl

Нажимаем Enter и читаем лицензионное соглашение. Переход между страницами соглашения осуществляется клавишей «Пробел» Дойдя до конца, видим приглашение принять лицензию.

Отвечаем «yes» и движемся дальше.

Система рапортует о том, что не смогла найти модули, подходящие к нашему ядру. Список доступных модулей можно увидеть в директории /usr/lib/vmware/modules/binary. Далее система хочет убедиться в том, что у нас установлен работоспособный компилятор языка C.

Говорит, что не может найти утилиту make на нашей машине, и предлагает поискать ее самостоятельно, а затем сообщить правильный путь. Ну что же, попробуем найти то, что нам нужно.

Теперь посмотрим в списке установленных пакетов.

Как ни грустно признать такой факт, но, судя по всему, этой утилиты у нас и вправду нет. Конечно для поиска можно воспользоваться утилитой locate, но результат скорее всего будет столь же неутешителен. Вставляем в привод первый диск дистрибутива и переходим в директорию с пакетами. А затем ставим то что нужно.

Те, у кого под рукой нет дисков с Alt Linux, но есть постоянное подключение к Интернет, могут воспользоваться репозитарием пакетов сайта altlinux.ru. Устанавливать пакеты в этом случае можно с помощью программы apt-get или synaptic.

После инсталляции make прерываем сценарий vmware-config нажатием клавиш Ctrl+C и запускаем его опять. Скрипт снова спрашивает о наличии компилятора, на это мы ему вновь отвечаем «yes». И в ответ получаем вот такую неприятную ошибочку.

Начинаем разбираться с проблемой. Давайте посмотрим как поживает gcc.

Судя по всему, компилятор действительно отсутствует, в наличии только служебные пакеты для gcc. В alt linux для удобства администрирования используется концепция альтернатив. Это означает что все наиболее важные системные утилиты должны иметь ссылки на свои бинарные файлы из каталога /etc/alternatives/. Такой механизм позволяет держать в системе несколько разных версий тех или иных утилит. А использовать те из них на которые указывает ссылка.

Таким образом, мы видим, что файл /etc/alternatives/gcc указывает на файл /usr/bin/gcc_wrapper , который не является полноценным компилятором. А служит лишь для того, чтобы выводить сообщение об ошибке на случай, если пользователь попытается запустить его.

Вот такая вот своеобразная заглушка. Ну что же, значит, придется снова ставить все самому. Переходим на диск 3 дистрибутива и пытаемся устанавливать пакет gcc2.96-2.96-alt3.i586.rpm. Внимательный читатель может задать вопрос, почему мы используем gcc именно этой версии, когда нам доступна гораздо более новая версия 3.2. Ответ очень прост: ядро, на котором работает система, собрано версией 2.96 компилятора gcc. Так что если попытаться поставить что-то другое, скрипт инсталляции vmware наотрез откажется работать.

Итак, судя по результатам работы команды rpm, у нас неудовлетворенные зависимости между пакетами. Начнем разрешение конфликтов. Как всегда, ехидно замечаем, что счастливчики, пользующиеся apt-get или synaptic, подобных проблем не почувствуют. Мое нежелание использовать apt-get связано с тем, что я предпочитаю делать все самостоятельно. Каким из перечисленных способов добавлять программное обеспечение в систему, оставляю на ваше усмотрение. Ну а я займусь увлекательной игрой, суть которой сводится к поиску и установке следующих пакетов.

Вновь запускаем скрипт, система снова спросит о компиляторе, а мы опять нажмем «Yes», соглашаясь с тем, что вот теперь-то у нас точно есть компилятор.

На экране появится надпись о том, что в качестве компилятора будет использоваться /usr/bin/gcc. Нас такой поворот событий вполне удовлетворяет, поэтому с легким сердцем переходим к следующему шагу.

Смотрим, куда установились заголовочные файлы нашего ядра, на основе которых vmware будет собирать модули, загружаемые в работающее ядро.

Судя по всему, это директория /usr/lib/kernel/2.4.20-alt5/include/. Пишем ее в ответ на приглашение и снова жмем «Enter». Система начнет компиляцию, и на экране начнут появляться надписи вроде:

Система закончит сборку модуля vmmon и перейдет к следующему модулю по имени vmnet. В результате сборки каждого модуля должна появляться вот такая надпись:

А это в свою очередь означает, что созданный модуль включается в ядро без конфликтов.

Далее отвечаем на вопрос, хотим ли мы, чтобы наши виртуальные машины могли работать с сетью.

Как обычно, радостно соглашаемся и переходим на следующую ступеньку.

Сеть vmnet0 используется для работы с устройствами типа мост и конфигурируется автоматически, поэтому нам о правильности ее настроек заботиться нет нужды.

Сеть vmnet8 по умолчанию используется для работы с устройством NAT. Скрипт спрашивает, не желаем ли мы автоматически выбрать свободную частную подсеть. Мы этого не хотим, потому как в наших планах построения макета записано, что для данной цели будет использоваться сеть 192.168.32.0.

Соответственно, описываем нужную нам для NAT сеть и ее маску.

Нажав «Enter», приступаем к изучению лицензии на усеченной версии сервера DHCP, поставляющегося в комплекте с vmware.

Разрешаем использовать сети типа 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. Проверить, правда ли это, можно, запустив на другой консоли следующие команды:

Ну что же, вернемся обратно к установке. Как всегда, сначала рассказали о лицензии на сервер Samba, с помощью которого будет идти обмен файлами, а затем уведомили, что Samba у нас функционирует нормально. Затем прошел автоматический запуск демона vmware.

Теперь нужно решить, от имени какого пользователя samba будет получать доступ к файлам, находящимся на диске основной операционной системы.

Мне показалось, что создавать еще одного пользователя только для того, чтобы разграничить доступ к файлам основной системы нецелесообразно. Особенно учитывая тот факт, что я пользуюсь этой машиной единолично. Таким образом, samba будет работать от имени пользователя root, запустившего серверную часть vmware. Наверно стоит признать что такой подход потенциально опасен.

Проверить, как функционируют подсистемы vmware, и какой у каждой из них статус можно с помощью следующей команды:

Итак, первоначальная настройка vmware закончена, и мы можем позволить себе посмотреть, как выглядят добавочные сетевые адаптеры, на основе которых работают наши виртуальные сети.

Теперь проверим, какие процессы работают в системе от имени vmware:

Если вы помните, то выше по тексту мы говорили что в сетях vmnet1 и vmnet3 все клиенты работают со статическими адресами, поэтому DHCP сервера этих сетей работают вхолостую. Желательно не забыть отключить DHCP компоненты вышеназванных сетей. Впрочем, если вы этого не сделаете, то ничего страшного не произойдет, но дизайн сети будет уже не таким опрятным, да и системные ресурсы все же не бесконечны.

Все настройки vmware хранятся внутри каталога /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 есть вот такая секция:

Иногда скрипт конфигурирования сети vmware забывает дописать в эту секцию строку option routers, отвечающую за адрес шлюза по умолчанию. Соответственно, клиенты при работе с DHCP сервером успешно получают ip адреса, но дальше своей родной сети пойти не могут, потому что не знают адреса маршрутизатора. Поэтому после работы этого скрипта лучше всего убедиться самостоятельно что содержимое конфигурационных вайлов выглядит именно так как вы приказали. Осталось подправить одну крохотную, но в тоже время очень важную настройку. Если мы хотим, чтобы люди из внешнего мира видели наш виртуальный Web-сервер, работающий на машине Linux Mandrake, то нам нужно организовать проброс входящих соединений. Получается, что все соединения, приходящие на 80-й порт реальной машины, нужно заворачивать на 80 порт виртуального Web сервера. Делается это очень просто, хотя и не так элементарно, как если бы vmware работала под управлением Windwos. Нужно добавить в файл /etc/vmware/vmnet8/nat/nat.conf внутрь секции [incomingtcp] следующие строки.

Затем необходимо перезапустить серверную часть vmware, заставив применить внесенные изменения.

# service vmware restart Stopping VMware services: Virtual machine monitor [ OK ] Bridged networking on /dev/vmnet0 [ OK ] DHCP server on /dev/vmnet1 [ OK ] SMB share server on /dev/vmnet1 [ OK ] SMB name server on /dev/vmnet1 [ OK ] Host-only networking on /dev/vmnet1 [ OK ] DHCP server on /dev/vmnet2 [ OK ] Host-only networking on /dev/vmnet2 [ OK ] DHCP server on /dev/vmnet3 [ OK ] Host-only networking on /dev/vmnet3 [ OK ] DHCP server on /dev/vmnet8 [ OK ] NAT networking on /dev/vmnet8 [ OK ] Host-only networking on /dev/vmnet8 [ OK ] Virtual ethernet [ OK ] Starting VMware services: Virtual machine monitor [ OK ] Virtual ethernet [ OK ] Bridged networking on /dev/vmnet0 [ OK ] Host-only networking on /dev/vmnet1 (background) [ OK ] Host-only networking on /dev/vmnet2 (background) [ OK ] Host-only networking on /dev/vmnet3 (background) [ OK ] Host-only networking on /dev/vmnet8 (background) [ OK ] NAT networking on /dev/vmnet8

Судя по выводу скрипта, DHCP сервера отключились во всех виртуальных сетях разом. На самом деле это не так. Давайте проверим наличие демонов vmware в памяти. Делать это нужно все той же доброй старой командой ps:

Затаив дыхание, рассматриваем вывод команды. И — о чудо! — судя по надписям, демоны DHCP сервера вполне нормально обслуживают сети vmnet2 и vmnet8. С начальной настройкой покончено, можно двигаться дальше.

Также стоит посмотреть, что появилось в директории /usr/bin/ после инсталляции:

• vmnet-bridge — программа для создания устройств «мост»
• vmnet-dhcpd — усеченная версия демона dhcp
• vmnet-natd — демон, реализующий функции устройства NAT
• vmnet-netifup — программа для создания виртуальных сетевых интерфейсов
• vmnet-sniffer — перехватчик трафика для виртуальных интерфейсов, например прослушивать данные, передаваемые через сеть vmnet3 можно с помощью команды vmnet-sniffer -e /dev/vmnet3. Это бывает очень полезно для отладки разных проблем сетевой подсистемы.
• vmstat — показывает состояние виртуальной машины
• vmware — собственно главный исполняемый файл системы vmware
• vmware-config.pl — наш старый знакомый скрипт настройки
• vmware-loop — программа для экспорта данных из виртуальной файловой системы в реальную
• vmware-mount.pl — инструмент для управления монтированием разделов виртуальных дисков
• vmware-nmbd — усеченная версия сервера имен NETBIOS
• vmware-ping — служит для проверки виртуальных сетей
• vmware-smbd — усеченная версия демона для работы с SMB/CIFS (Samba)
• vmware-smbpasswd — программа управления пользователями и паролями из комплекта Samba
• vmware-uninstall.pl — скрипт деинсталляции vmware
• vmware-wizard — программа, используемая внутри vmware для создания новых виртуальных машин

Как вы могли убедиться, vmware поставляется с довольно богатым набором инструментов. Возможно, некоторые из них мы будем использовать для диагностики и устранения неполадок, ежели таковые возникнут в наших виртуальных сетях.

Продолжать злоупотреблять полномочиями пользователя root больше нет необходимости, поэтому нам стоит превратиться в обычного пользователя, под которым мы и будем ежедневно работать с vmware.

Программа должна отработать нормально, и на экране появится главное окно клиентской части vmware. Пользуясь меню Help->Enter Serial Number, активируем установленное программное обеспечение с помощью тестового серийного номера, присланного нам по почте.

В ответ получаем предложение зарегистрироваться в качестве пользователя на сервере vmware.com. Я решил, что делать этого не желаю, и нажал «Cancel». Вы же можете поступать, как захотите, потому что регистрация на сайте — мероприятие сугубо добровольное и на работу никак не влияющее.

Теперь необходимо проверить, правильно ли сработала активация лицензии. Для этой цели нам пригодится меню Help->About. Если у вас появилось на экране что-то подобное следующему рисунку, значит, дела идут, как положено.

Особое внимание cтоит обратить на дату, расположившуюся за надписью Expiration. Она указывает, до какой даты мы сможем пользоваться лицензией, а значит, и самой программой vmware.

Итак, закончив с первоначальной настройкой vmware, перейдем к созданию наших виртуальных машин. Этот процесс очень подробно описывался в первой статье данного цикла. Если есть желание, можете выполнить его снова. Хотя я думаю, что ничего нового вы для себя не откроете. Ну а я, как человек, искренне верящий в слова: » лень двигатель прогресса», поступлю иначе. Если вы помните, от предыдущей статьи нам в наследство остались комплекты файлов виртуальных машин, созданных под 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. Именно он хранит в себе набор необходимых для работы виртуальной машины данных. В качестве таких данных могут выступать:

• список устройств и их характеристики
• количество виртуальных жестких дисков
• соответствие между файлами виртуальных жестких дисков и устройствами гостевой системы
• перечень сетевых адаптеров и их MAC адреса
• настройки вспомогательного программного обеспечения

В случае, если vmware в данный момент производит какие-либо действия с нашей виртуальной машиной, в директории появится еще и файл блокировки доступа win98.vmx.WRITELOCK. Ну а если, вдобавок ко всему, еще и гостевая система выполняется, то для каждого файла виртуального диска создается дополнительный файл блокировки win98.vmdk.WRITELOCK. Также внутри директории можно встретить файлы вида win98.vmss и win98.vmsn. Соответственно, первый из них содержит данные, полностью описывающие состояние виртуальной машины на тот момент, когда ее функционирование было приостановлено с помощью команды Power->Suspend. Ну а второй хранит данные моментального снимка виртуальной машины, получаемого с помощью команды Snapshot->Save Snapshot. Время от времени внутри директории с файлами гостевой системы на короткие промежутки времени будут появляться различные служебные файлы, но вы их, скорее всего, никогда не увидите.

Разобравшись с устройством виртуальной машины на файловом уровне, перейдем от теории к действиям. Для того, чтобы мы могли работать с выбранной машиной, нужно объяснить vmware, где находятся необходимые нам файлы. Используем меню File->Open, получаем следующую картинку.

Выбираем файл win98.vmx и обязательно используем по прямому назначению кнопку «ОК». После того, как vmware выполнит открытие всех нужных файлов, можно запускать виртуальную машину с полученной только что гостевой системой.

Тут нас ждет несколько неприятных неожиданностей. Как из рога изобилия, начинают сыпаться ошибки и предупреждения. Возможно, на вашей системе некоторые из них никак не проявят себя, а взамен появятся какие-либо новые конфликты. Но бояться этого все же не стоит. Большинство из таких проблем поддаются коррекции довольно просто.

Итак, тут мы видим конфликтную ситуацию, возникшую внутри подсистемы сетевого оборудования. А если говорить точнее, то vmware сообщает, что у нее отсутствует сетевой адаптер VMnet3. Нажимаем «OK» и переходим к следующей ошибке.

Теперь жалоба касается CD-ROM. Нас предупреждают, что не все режимы работы будут доступны из-за конфликтов с настройками реального и проецируемого на него виртуального устройства.

Совсем не понравилась vmware моя ps/2 мышь glidepoint. Но это не беда, доктор сказал, что на этом свете почти все неприятности поправимы.

В связи с разницей в имени гибкого диска между Windows и Linux, диск A:\ тоже не хочет работать.

Снова не совпадает наименование устройств системы. На этот раз нам отказала звуковая карта.

Эта ошибка единственная, с которой я не смог справиться, но она некритична. Дело в том, что моя устаревшая видеокарта и установленный на машину X сервер не поддерживают аппаратную акселерацию режима DGA, поэтому во время работы гостевой системы в полноэкранном режиме возможны проблемы с быстродействием. Ради интереса я проверил, так ли это. Невооруженным глазом заметить какое либо замедление не удалось.

После того как гостевая система с горем пополам закончила загрузку, вся панель устройств похожа на выездной пикник красного креста. Просмотрев весь список ошибок, который vmware посчитала необходимым показать нам, приступим к исправлению оных.

Первым делом беремся за настройку сетевого адаптера. Проходим через меню Edit->Virtual Machine Settings и выбираем устройство Network Adapter. Точно такого же эффекта можно добиться с помощью меню Edit->Removable Devices->Ethernet0->Edit.

Итак, нам нужно вместо VMnet3 выбрать из ниспадающего меню /dev/vmnet3. Затем с помощью переключателя «Connect» подключить устройство к работающей гостевой системе. Дело в том, что vmware позволяет подключать и отключать многие устройства прямо на ходу. В качестве таких устройств могут выступать 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 сервера. Ищем внутри него секцию, отвечающую за работу мыши, и вносим вместо нее следующие строки:

Вешаем на стену скальп еще одной решенной проблемы и переходим к следующей. Сейчас нам нужно починить устройство для работы с гибкими дисками. Под Windows оно называется A:\ , ну а под Linux это будет одно из устройств семейства /dev/fd. В моей системе это устройство называется /dev/fd0.

Налюбовавшись рисунками с изображением настроек «до» и «после», перейдем к решению следующей проблемы. У нас на очереди звуковая карта. Посмотрим, что именно вписано в конфигурацию этого устройства.

Неудивительно, что оно не работает при таком странном названии «-1» . Вместо этого, слегка задумавшись, но ничтоже сомневаясь, выбираем /dev/dsp

Разобравшись со всеми проблемами, закрываем vmware и все остальные приложения. Теперь нужно перезапустить X сервер для того, чтобы изменения в настройках мыши вступили в действие. Нажимаем комбинацию кнопок Ctrl+Alt+BackSpace. После перезагрузки X сервера снова входим в систему и запускаем vmware и внутри нее гостевую машину 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, узнаем, что операционные системы семейства Windows в процессе работы постоянно опрашивают это устройство. Подобное поведение, в свою очередь, может привести к весьма чувствительному повышению нагрузки на основную систему. Далее в документации говорится, что теоретически Windows должна нормально работать и без использования таймера реального времени. Отключаем устройство RTC и проверяем. По крайней мере, мои виртуальные машины, подвергшись такой вивисекции, не утратили стабильного функционирования. Кстати, иногда редактирование конфигурации выключенной виртуальной машины может привести к такой ошибке.

Пугаться этого не стоит, вероятность того, что вы испортите свою гостевую систему, слишком мала. Просто по непонятным причинам конфигурационный файл оказывается заблокирован для записи. Чтобы решить эту проблему, нужно закрыть вкладку виртуальной машины внутри vmware и открыть ее снова.

На следующей картинке можно увидеть одновременную работу всех систем, на импортирование которых мы потратили столько труда. Для наглядности каждая из них запущена в отдельном окне. Конечно, можно было запустить их внутри разных вкладок родительского окна, но я решил, что так картинка будет выглядеть недостаточно эффектно. Добиться подобного вида можно, используя меню File->New->New Window. Во вновь появившемся окне, следуя укоренившейся привычке, выбираем File->Open. Внимательный читатель может спросить, зачем все эти сложности. Мой ответ будет довольно прост. Такой подход позволяет разложить виртуальные машины в нужном порядке по виртуальным столам оконного менеджера. Лично мне это кажется весьма удобным.

У подобной методики работы есть один щекотливый момент. Если внутри любого окна создана вкладка с гостевой операционной системой, то эта система становится недоступна для запуска из другого окна. Все дело в том, что vmware в момент открытие конфигурации виртуальной машины создает файл эксклюзивной блокировки. Называется такой файл обычно «имя гостевой системы.vmx.WRITELOCK». Причем файл создается еще до запуска гостевой системы и остается до тех пор, пока не будет закрыта вкладка гостевой системы или завершится работа vmware. Получается, что конфигурация гостевой системы будет заблокирована в любом случае, вне зависимости от того, работает гостевая система или нет. Если попытаться открыть эту гостевую систему еще раз, то получим по рукам.

В свою очередь, признаком работы системы служит появление дополнительного файла блокировок файлов жестких дисков, называющегося «имя гостевой системы .vmdk.WRITELOCK». Видимо, разработчики vmware не смогли придумать более надежного способа для проверки факта запуска той или иной гостевой системы. Кстати, если во время работы гостевой системы удалить все фалы WRITELOCK, то ее легко можно запустить повторно. Например, на следующем рисунке можно видеть два экземпляра гостевой системы Windows 98, запущенных из одного и того же файла и работающих одновременно довольно-таки стабильно.

Впрочем, использовать такие приемы в практической работе не стоит, потому что совершенно непонятно, как поведут себя обе гостевые системы, если им одновременно потребуется записать какие-либо данные в файл виртуального диска.

Мы немного отвлеклись от темы нашего повествования. После переноса и успешного запуска всех гостевых систем настал момент проверить, насколько правильно работает наш макет. Для этого на Windows машинах выполняем команду ipconfig /all и смотрим, какие настройки у нашей сетевой подсистемы. Например, на следующем снимке можно увидеть результат выполнения вышеуказанной команды на машине Win2000.

Так как все остальные системы, используемые в нашем макете, являются диалектами Unix, то для просмотра состояния их сетевых интерфейсов нужно использовать команду ifconfig. Например, для машины FreeBSD вывод команды выглядел вот так:

Таким образом, проверив правильность настройки сетевых компонентов всех подопытных систем, начинаем смотреть, как по тестовым сетям передаются данные. Для этого на любой машине выполняем команду ping с адресами всех остальных машин. Если ping работает, то переходим к следующему этапу. Теперь любым браузером заходим на адрес 192.168.40.32. Должны увидеть что-то вроде такой страницы с приветствием от web сервера apache.

Затем с любой машины, находящейся за пределами созданной виртуальной сети, пытаемся сходить браузером на адрес нашей реальной машины. В ответ должны получить тот же самый привет от apache. Судя по всему, задача по созданию виртуального полигона, полностью соответствующего схеме, наконец-то выполнена. Как всегда, прощаемся до следующей статьи, которая будет посвящена разным трюкам, заметно облегчающим жизнь при работе с vmware.

Источник