Проектирование и построение учебного класса на основе виртуальных машин

Проектирование и построение учебного класса

на основе виртуальных машин

Введение

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

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

В связи с этим актуальным является проведение анализа различных версий программных эмуляторов (виртуальных машин) для ПК и выбор наиболее подходящего варианта для построения учебного класса на основе виртуальных машин.

Целью настоящей работы является проектирование и создание учебного класса на основе виртуальных машин для изучения следующих дисциплин:

— установка и конфигурирование MS Windows XP Professional;

— программирование на языке Ассемблера;

— введение в операционные системы семейства UNIX.

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

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

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

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

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

В третьей главе рассматриваются вопросы организации труда и безопасности жизнедеятельности.

В заключении приводятся основные результаты проведенной работы.

1. Общая концепция эмулятор виртуальный класс

1.1 Концепция и теория виртуальных машин (эмуляторов) Виртуальной машиной (англ. virtual machine) называют программную или аппаратную среду, исполняющую некоторый код (например, байт-код, шитый код, p-code или машинный код реального процессора), или спецификацию такой системы. Виртуальная машина эмулирует работу реального компьютера.

Эмулямция (англ. software emulation) позволяет выполнять компьютерную программу на платформе (компьютерной архитектуре и/или операционной системе), отличной от той, для которой она была написана в оригинале. Эмуляцией также называют сам процесс этого выполнения. В отличие от симуляции, которая лишь воспроизводит поведение программы, при эмуляции ставится цель точного моделирования состояния эмулируемой системы, т. е. сохранение оригинального машинного кода.

Одно из популярных применений эмуляции — выполнение на персональном компьютере игр, написанных для игровых автоматов или игровых консолей.

Теоретически, согласно тезису Чёрча—Тьюринга, любая операционная среда может быть эмулирована в любой другой среде. На практике, однако, встречается ряд трудностей, в частности, точное поведение эмулируемой системы часто не документировано, и должно быть выведено с помощью обратной разработки.

На виртуальную машину, так же как и на реальный компьютер можно инсталлировать операционную систему, у виртуальной машины так же есть BIOS, оперативная память, жёсткий диск (выделенное место на жёстком диске реального компьютера), могут эмулироваться периферийные устройства. На одном компьютере может функционировать несколько виртуальных машин.

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

В принципе, система виртуальных машин может быть построена с использованием микро-ОС (либо микроядра — как в проекте L4Ka), которая взяла бы на себя функции управления устройствами и системными свойствами процессора. Операционные системы второго уровня и их приложения могли бы работать одновременно и без какой-либо виртуализации, используя микро-ОС для выполнения системных операций и работы с внешними устройствами.

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

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

Общая системная архитектура виртуальной машины построена на взаимодействии трех основных компонентов: приложение виртуальной машины; драйвер виртуальных машин; монитор виртуальной машины.

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

Приложение виртуальной машины построено по многопоточной технологии и поддерживает три основных потока:

— поток виртуализации для передачи управления монитору и обмена информационными сообщениями с ним;

— графический поток для отображения видеобуфера гостевой операционной системы;

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

Для каждой виртуальной машины запускается своя копия приложения виртуальной машины. Приложение виртуальной машины выполняет следующие основные функции:

а) создание, удаление и конфигурирование виртуальных машин;

б) включение, выключение и управление работой виртуальных машин;

в) обеспечение интерфейса пользователя с гостевой операционной системой ввод с клавиатуры (мыши) и отображение экрана гостевой операционной системы;

г) выделение памяти для виртуальной машины и загрузка (инициализация) монитора виртуальной машины;

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

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

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

Монитор может взаимодействовать с приложением двумя способами:

— синхронно при помощи обмена информационными сообщениями через драйвер виртуальных машин;

— асинхронно при помощи разделяемых системных структур и участков памяти.

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

1.2 Краткий экскурс в историю виртуальных машин Первым проектом, в котором возникла концепция системы виртуальных машин, был проект IBM 7044Х-7044М. А в IBM System/370 появился уже полноценный продукт VM/370. Эта система виртуальных машин претерпела впоследствии немало изменений (версии VM/SP, VМ/ХА, VN/ЕSА) и стала самой распространенной в компьютерной индустрии.

В операционной системе VM/370 пользователь получал в свое распоряжение полноразмерный и полнофункциональный виртуальный компьютер, на который он мог поставить собственную версию операционной системы и установить собственное прикладное программное обеспечение. Этот компьютер включал оперативную память, ресурсы процессора, собственные виртуальные периферийные устройства — практически все то, чем обладает обычный компьютер, только в виртуальном виде. Количество обслуживаемых виртуальных компьютеров определялось лицензией, доступными ресурсами памяти, диска, центрального процессора и т. д.

Операционная система VM/370 стала прототипом для отечественной разработки системы СВМ (система виртуальных машин). Первая версия системы СВМ 1.1 была выпущена в1982 году комбинатом «Роботрон». В 1983 г. операционную систему СВМ 2.2, базирующуюся на шестом релизе VM/370, выпустил Минский НИИЭВМ. С этого момента система СВМ, не подменяя систем ДОС и ОС, заняла прочное место в базовом программном обеспечении для ЕС ЭВМ. В качестве операционной системы, управляющей работой виртуальной машины, могли использоваться любые операционные системы, разработанные для ЕС ЭВМ (например, ОС ЕС, ДОС ЕС и МОС ЕС).

Совершенствование СВМ в НИИЭВМ в начале 90-х годов привело к разработке операционной системы VM/СВМ. Минская компания IВА, основанная компанией IBM на базе МПО ВТ и НИИЭВМ, до сих пор ведет разработку новых изданий VM/СВМ для мэйнфреймов IВМ.

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

Пионером технологии виртуальных машин на платформе Intel х86 стала компания VMware. Она была создана на базе Стэндфордского университета профессором Менделем Розенблюмом и его супругой Дианой Грин в 1998 году. Компания разработала технологию Virtual Platform для виртуализации IA-32 систем, и уже в 1999 году выпустила первую виртуальную машину VMware Workstation для операционной системы Linux. Чем произвела немалый переполох и снискала себе вечную славу в Linux сообществе.

В тоже самое время задачей виртуализации процессоров Intel х86 занималась небезызвестная компания Connectix. В 1997 году она выпустила эмулятор Virtual PC для Мас, позволяющий запускать операционные системы DOS и Windows на макинтошах. А в 1999 году вышла виртуальная машина Virtual PC для Windows, исполняющая различные операционные системы под Windows NT/9х. Большую популярность компания Connectix снискала в OS/2 сообществе после выхода Virtual РС для OS/2, разработанного совместно с немецкой компанией InnoTek.

1.3 Методы запуска приложений других Операционных Систем Для функционирования современных виртуальных машин требуется средство управления виртуальными машинами, являющееся Windows-, Linuxили UNIX-приложением, функционирующим на реальном компьютере, называемом хостом. Сама виртуальная машина представляет собой образ файловой системы, формирующийся при установке какой-либо операционной системы (в общем случае отличной от той, под управлением которой функционирует средство управления виртуальными машинами) и хранящийся в виде файла или расположенный в выделенном разделе жесткого диска. С помощью средства управления виртуальными машинами можно загрузить в выделенное адресное пространство образ операционной системы виртуальной машины (такая операционная система носит название Guest Operating System — гостевая операционная система, в отличие от исходной операционной системы, носящей название Host Operating System — операционная система хоста). После этого операционная система виртуальной машины будет способна взаимодействовать с аппаратным обеспечением компьютера (например, с видеоадаптером, звуковой картой, клавиатурой, мышью, сетевыми адаптерами). Таким способом можно, например, при работающей операционной системе Windows XP загрузить операционную систему Linux в выделенное для нее адресное пространство и переключаться между обеими операционными системами, не занимаясь перезагрузкой компьютера. Кроме того, в ряде случаев можно использовать буфер обмена для обмена данными между этими операционными системами или осуществлять сетевое взаимодействие между ними, как если бы это были два разных компьютера. Можно одновременно загрузить и более одной виртуальной машины — лишь бы для этого было достаточно оперативной памяти (ее, естественно, должно быть много, ведь в оперативной памяти при загрузке виртуальной машины оказывается еще одна операционная система).

1.3.1 Эмуляция API операционной системы Обычно приложения работают в изолированном адресном пространстве и взаимодействуют с оборудованием при помощи API, предоставляемым операционной системой. Если две операционные системы совместимы по своим АРI (например, Windows 98 и Windows 2000), то приложения, разработанные для одной из них, будут работать и на другой. Если две операционные системы несовместимы по своим API (например, Windows 2000 и Linux), то существует способ перехватить обрашения приложений к АРI и сымитировать поведение одной операционной сисгемы средствами другой операционной системы.

При таком подходе можно поставить одну операционную систему и работать одновременно как с ее приложениями, так и с приложениями друтой операционной системы. Поскольку весь код приложения исполняется без эмуляции и лишь вызовы API эмулируются, потеря в производительности незначительная. Но из-за того, что многие приложения используют недокументированные функции API или обращаются к операционной системе в обход API, даже очень хорошие эмуляторы API имеют проблемы совместимости и позволяют запустить не более 70% от общего числа приложений. Кроме того, поддерживать эмуляцию API бурно развиваюищейся операционной системы (например, такой как Windows) очень нелегко, и большинство эмуляторов АРI так и остаются эмуляторами какой-то конкретной версии операционной системы. Так, в Windows NT/2000 до сих пор встроен эмулятор для приложений OS/2 версии I. х, а в последних версиях OS/2 Warp 4 есть возможность запуска приложений Windows 3.11. Но самый большой минус способа эмуляции API — это его строгая ориентация на конкретную операционную систему. Для того, чтобы запустить в нем приложения другой операционной системы, необходимо все переписывать с нуля.

Примеры продуктов, выполненных по технологии эмуляции АР1 операционной системы:

— проект с открьпым кодом Wine (Wine Is Not an Emulator), позволяющий запускать приложения DOS, Win16 и Win32 под операционными системами Unix;

— продукт Win4Lin компании Netraverse, позволяющий запускать операционные системы семейства Windows под операционной системой Linux;

— проект с открытым кодом DOSEMU, позволяюший запускать приложения MS DOS под операционной системой Linux;

— проект с открытым кодом User Mode Linux (UМL), позволяющий запускать несколько копий операционной системы Linux на одном компьютере (в настоящее время встроен в ядро Linux версий 2.6);

— технология Virtuozzo, разработанная российской компанией SWsoft и позволяющая запускать несколько копий операционной системы Linux на одном компьютере;

— технология, используемая во FreeBSD для запуска приложений Linux.

Проект SoftPear, в перспективе позволяющий запускать приложения Mac OS X на Linux и FreeBSD

1.3.2 Полная эмуляция Проекты, выполненные по технологии полной эмуляции работают как интерпретаторы. Они последовательно выбирают код гостевой операционной системы и эмулируют поведение каждой отдельно взятой инструкции. Поскольку при этом полностью эмулируется поведение как процессора, так и всех внешних устройств виртуального Intel х86 компьютера, то существует возможность запускать эмулятор на компьютерах с совершенно другой архитектурой, например, на рабочих станциях Mаc или на RISC’овых серверах Sun.

Самый серьезный недостаток этого подхода заключается в катастрофической потере производительности гостевой операционной системы. Скорость работы гостевых приложений может упасть в 100−1000 раз, что означает практическую невозможность нормальной работы с гостевой операционной системой внутри эмулятора. Тем не менее, существуют некоторые технологии, такие как динамическая трансляция, позволяющие увеличить скорость полной эмуляции. Полные эмуляторы чаще всего используются в качестве низкоуровневых отладчиков для исследования и трассировки операционных систем.

Примеры проектов, выполненных по технологии полной эмуляции:

— проект с открытым кодом Bochs, позволяющий запускать различные операционные системы Intel х86 под Linux, Windows, BeOS и Мас OS;

— продукт Simics компании Virtutech, позволяющий запускать и отлаживать различные операционные системы Intel х86 под Windows и другими операционными системами;

— продукт Virtual PC фирмы Connectix (ныне купленной Microsoft) позволяющий запускать различные x86-ОС на PC и Mac;

— проект Qemu — самый быстрый эмулятор различных архитектур на PC. При использовании модуля Accelerator практически сравнивается по производительности с виртуальными машинами.

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

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

Примеры проектов, выполненных по технологии квази-эмуляции. Виртуальная машина Serenity Virtual Station (SVISTA)(бывшая twoOStwo), разработанная российской компанией Параллели по заказу немецкой компании NetSys GmbH. SVISTA позволяет запускать такие гостевые операционные системы, как OS/2, Linux, QNX, MSDOS и другие. В настоящий момент существует три продукта: SVISTA для Windows NT/2000/XP, twoOStwo для Linux и twoOStwo для FreeBSD. Технология квази-эмуляции заключается в том, чтобы обнаружить и сымитировать поведение второго множества инструкций и исполнять инструкции первого множества без эмуляции.

Технология Virtual Platform компании VMware, позволяющая запускать большое количество Intel х86 гостевых операционных систем. Компания VMware предлагает четыре продукта: VMware Workstation для Windows NT/2000/XР, VMware Workstation для Linux, VMware GSX Server (group server) и VMware ESX Server (enterprise server).

Проект с открытым кодом Plex86, позволяющий запускать различные операционные системы Intel х86 под Linux. Проект с открытым кодом L4Ka, использующий микроядро. Проект с открытым кодом Xen, позволяет запускать модифицтрованные ОС Linux, FreeBSD, NetBSD и Windows XP под Linux, FreeBSD, NetBSD. При соблюдении некотрых условий позволяет получить даже прирост производительности.

1.4 Обзор продуктов на рынке виртуальных машин и их характеристики Сегодня виртуальные машины насчитывают несколько сфер применения вот некоторые из них.

Использование ВМ для защиты информации и ограничения возможностей процессов. В качестве примера предлагаю рассмотреть широко известный в компьютерной безопасности термин «песочница». Песомчница (англ. sandbox, также существуют схожие понятия — англ. honeypot, англ. fishbowl) — в компьютерной безопасности, механизм для безопасного исполнения программ. Песочницы часто используют для запуска непротестированного кода, непроверенного кода из неизвестных источников, а также для запуска и обнаружения вирусов. Песочница обычно предоставляет жестко контролируемый набор ресурсов для исполнения гостевой программы — например, место на диске или в памяти. Доступ к сети, возможность сообщаться с главной операционной системой или считывать информацию с устройств ввода обычно либо частично эмулируют, либо сильно ограничивают. Песочницы представляют собой пример виртуализации. Повышенная безопасность исполнения кода в песочнице зачастую связана с большой нагрузкой на систему — именно поэтому некоторые виды песочниц используют только для неотлаженного или подозрительного кода. Песочницы часто встречаются в следующих видах:

а) апплеты, которые исполняются в виртуальной машине или интерпретаторе, позволяющие запускать Java-код с любых веб-сайтов без угрозы операционной системе;

б) так называемые «тюрьмы» (jail, chroot jail) также позволяют вводить ограничения ресурсов для пользователей и процессов некоторых ОС;

в) виртуальные машины, эмулирующие полномасштабную операционную систему (например, VMware);

г) Системы, основанные на «возможностях» (capability-based security) также позволяют ограничивать ресурсы программ, в зависимости от назначенных им «возможностей». Помимо ограничения вредоносного и непроверенного кода, песочницы также используются в процессе разработки для запуска «сырого» кода, который может случайно повредить систему или испортить сложную конфигурацию. Такие «тестировочные» песочницы копируют основные элементы среды, для которой пишется код, и позволяют разработчикам быстро и безболезненно экспериментировать с неотлаженным кодом.

Исследования производительности ПО или новой компьютерной архитектуры. Эмуляция различных архитектур. В этой области широкую популярность приобрели эмуляторы игровых приставок, позволяющие пользователю играть в полюбившиеся игры, первоначально написанные для игровых приставок на своем домашнем компьютере. Оптимизация использования ресурсов мэйнфреймов и прочих мощных компьютеров. К примеру такие как IBM e-Server. Серверные компьютеры построенные по технологии IBM и поддерживающие виртуализацию на аппаратном уровне.

Также технология виртуализации может быть использована вредоносным кодом для управления инфицированной системой: вирус PMBS, обнаруженный в 1993 году, а также руткит SubVirt, созданный в 2006 году Microsoft Research, создавали виртуальную систему, которой ограничивался пользователь и все защитные программы (антивирусы и прочие).

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

В качестве дополнительных можно выделить еще две сферы применения виртуальных машин:

— тестирование приложений под управлением разных операционных систем (например, Windows 2000, Windows XP и Windows 98 различных языковых версий). Подобное тестирование обычно производится при разработке коробочных продуктов и в проектах, предполагающих наличие у заказчика парка действующих рабочих станций и серверов, приобретенных в различные годы;

— использование программного продукта неработоспособного на имеющейся платформе. К примеру, использование программ написанных для старых версий DOS и т. д.

Обзор существующих на рынке программных средств для создания виртуальных машин:

1.4.1 Microsoft Virtual PC

Cредство управления виртуальными машинами Microsoft Virtual PC основано на технологиях, разработанных компанией Connectix. Один из первых продуктов Connectix был предназначен для выполнения Windows-приложений на компьютерах под управлением Mac OS, а Windows-версия этого продукта появилась в 2001 году. Компания Connectix была приобретена корпорацией Microsoft в 2003 году, и вскоре после этого была выпущена версия Virtual PC 2004. Microsoft Virtual PC предназначен главным образом для работы с различными версиями Windows. Сам продукт выполняется под управлением Windows XP Professional, Windows 2000 Professional или Windows XP Tablet PC Edition, а операционные системы для виртуальных машин, полностью поддерживаемые данным продуктом, включают Windows 95, Windows 98, Windows Me, Windows NT 4.0 Workstation, Windows 2000 Professional, Windows XP, MS-DOS, OS/2 Warp Version 4 Fix Pack 15, OS/2 Warp Convenience Pack 1, OS/2 Warp Convenience Pack 2 (рис. 1 и 2).

Рисунок 1.1. Средство управления виртуальными машинами Рисунок 1.2. Тестирование приложения, выполняющегося под управлением различных операционных систем, с помощью Virtual PC

При необходимости Virtual PC позволяет создавать виртуальные машины и с серверными версиями Windows, а также с некоторыми другими операционными системами, такими как Red Hat Linux, Novell NetWare и др.

Технические требования для Microsoft Virtual PC невысоки: процессор AMD Athlon/Duron, Intel Celeron или Pentium II/III/4 с тактовой частотой от 400 МГц, CD-ROM, монитор с разрешением 800×600. Однако сами по себе виртуальные машины могут быть весьма требовательны к ресурсам — это зависит от операционных систем, которые загружаются в виртуальные машины (см. таблицу 1). При этом следует иметь в виду, что для определения реальной потребности в оперативной и дисковой памяти следует просуммировать требования, предъявляемые к ним исходной операционной системой и операционными системами всех виртуальных машин, которые предполагается запускать одновременно.

Из технических особенностей Microsoft Virtual PC следует отметить разнообразные способы эмуляции сетевого взаимодействия, начиная с ее отсутствия и заканчивая интеграцией в локальную сеть, в которую включен хост (эмулируется до четырех виртуальных сетевых адаптеров), а также поддержка эмуляции сетевого взаимодействия с другими виртуальными машинами как с отдельными компьютерами и трансляции адресов NAT. Microsoft Virtual PC поддерживает до 4 Гбайт оперативной памяти, обмен данными между виртуальными машинами и операционной системой хоста с помощью буфера обмена и операций drag-and-drop, синхронизацию времени. В качестве виртуальных жестких дисков данный продукт позволяет использовать файлы как фиксированного, так и плавающего размера, а также реальные жесткие диски или их разделы. Отметим, что при наличии на жестком диске нескольких операционных систем, установленных в разных разделах, Virtual PC позволяет загрузить неактивную операционную систему в качестве гостевой.

Таблица 1.1 Минимальные требования различных операционных систем для их выполнения под управлением виртуальных машин

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

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

Рисунок 1.3. Средства конфигурирования виртуальной машины

1.4.2 VMware Workstation

Компания VMware производит разнообразное программное обеспечение для создания виртуальных машин, в том числе и средства для выполнения серверных операционных систем, широко применяющиеся, в частности, в некоторых решениях, поставляемых корпорацией IBM. За последние годы он претерпел значительные изменения, став, по существу, законодателем мод в области ПО подобного класса. Ниже мы рассмотрим некоторые особенности его последней версии — VMware Workstation 4.5.

В отличие от рассмотренного нами в предыдущем разделе Virtual PC, продукт VMware Workstation 4.5 поддерживает более разнообразный спектр как операционных систем хоста, так и гостевых операционных систем. Он предназначен для работы не только с различными версиями Windows, но и с разнообразными версиями Linux, Novell NetWare, DOS, Sun Solaris, FreeBSD. Помимо Windows-версии существует и Linux-версия этого продукта.

Windows-версия выполняется под управлением Microsoft Windows NT Server 4.0, Windows NT Workstation 4.0, Windows 2000 Server, Windows 2000 Professional, Windows XP Professional, Windows XP Home Edition, Windows Server 2003. Linux-версия VMware Workstation 4.5 поддерживает Mandrake Linux 8.2 и 9.0, Red Hat Enterprise Linux 2.1 и 3.0, Red Hat Linux Advanced Server 2.1, Red Hat Linux 7.0, 7.1, 7.2, 7.3, 8.0, 9.0, SuSE Linux Enterprise Server 7 и 8, SuSE Linux 7.3, 8.0, 8.1, 8.2, 9.0 и 9.1.

Операционные системы для виртуальных машин, полностью поддерживаемые данным продуктом, включают бета-версии Windows Longhorn, Windows Server 2003, Windows XP Professional и Windows XP Home Edition, Windows 2000 Professional, Windows 2000 Server; Windows 2000 Advanced Server, Windows NT Workstation 4.0 Service Pack 6a, Windows NT Server 4.0 Service Pack 6a, Windows NT 4.0 Terminal Server Edition Service Pack 6, Windows Me, Windows 98, Windows 95, Windows for Workgroups 3.1, Windows 3.1, MS-DOS 6. x, Mandrake Linux 8.2 и 9.0, Red Hat Linux 7.0, 7.1, 7.2, 7.3, 8.0 и 9.0, Red Hat Enterprise Linux 2.1 и 3.0, Red Hat Linux Advanced Server 2.1, SuSE Linux 7.3, 8.0, 8.1, 8.2, 9.0 и 9.1, SLES 7, Turbolinux Server 7.0, Turbolinux Enterprise Server 8, Turbolinux Workstation 8, Novell NetWare 5.1, 6 и 6.5, FreeBSD 4.0−4.6.2, 4.8 и 5.0, Solaris 9 и 10 для платформы x86. Список этот пополняется по мере выхода новых версий операционных систем, и пользователи продукта могут загружать с сайта производителя дополнительные модули для поддержки новых ОС и их версий.

Как и для Microsoft Virtual PC, технические требования для WMware Workstation 4.5 невысоки: процессор AMD Athlon/Duron, Intel Celeron или Pentium II, III, 4 с тактовой частотой от 500 МГц, оперативная память от 128 Мбайт CD-ROM. Для работы Linux-версии требуются X-сервер, удовлетворяющий стандарту X11R6, и поддерживаемый им видеоадаптер. Однако сами по себе виртуальные машины могут быть достаточно требовательны к ресурсам — это зависит от операционных систем, которые загружаются в виртуальные машины (как минимум, каждой гостевой операционной системе выделяется 1 Гбайт места на жестком диске). Напомним, что для определения реальной потребности в оперативной и дисковой памяти следует просуммировать требования, предъявляемые к ним исходной операционной системой и операционными системами всех виртуальных машин, которые предполагается запускать одновременно.

Для виртуальных машин под управлением WMware Workstation 4.5 доступно применение процессоров Intel Pentium II и выше, AMD Athlon и выше (в зависимости от процессора компьютера-хоста), при этом поддерживаются и 64-разрядные процессоры AMD Opteron и Intel Athlon. Виртуальным машинам доступно до 3,6 Гбайт оперативной памяти (если, конечно, таковая доступна операционной системе хоста), что несколько меньше, чем память, доступная виртуальным машинам Virtual PС, а в сумме память, занимаемая всеми одновременно запущенными виртуальными машинами, не должна превышать 4 Гбайт.

Виртуальные машины могут располагаться как в файле, так и на отдельном жестком диске или в его специальном разделе, при этом размер виртуального жесткого диска может достигать 256 Гбайт.

WMware Workstation 4.5 поддерживает до четырех IDE-устройств, в том числе виртуальные IDE-диски до 128 Гбайт, до двух накопителей на гибких дисках, дисководы CD-ROM, DVD-ROM компьютера-хоста. Кроме реальных дисководов, WMware Workstation 4.5 умеет работать с образами дисков формата ISO, рассматривая их как дисководы CD-ROM. Что касается поддержки таких SCSI-устройств, как сканеры, ленточные накопители, CD-ROM и DVD-ROM, то она может осуществляться даже при отсутствии драйверов этих устройств в операционной системе хоста.

WMware Workstation 4.5 поддерживает до двух LPT-портов и до четырех COM-портов, при этом вывод данных в COM-порт виртуальной машиной может реально представлять собой запись в файл хост-компьютера. Поддерживаются и динамически подключаемые к хосту USB-устройства, такие как сканеры, принтеры, жесткие диски и флэш-карты, подключаемые КПК, фотоаппараты. WMware Workstation 4.5 поддерживает видеорежимы VGA и SVGA, запись и вывод звука.

В части поддержки сетевого взаимодействия возможности WMware Workstation сравнимы с возможностями Virtual PC — этот продукт поддерживает разнообразные способы эмуляции сетевого взаимодействия (начиная с ее отсутствия и заканчивая интеграцией в локальную сеть, в которую включен хост), эмуляцию сетевого взаимодействия с другими виртуальными машинами как с отдельными компьютерами, трансляцию адресов NAT, виртуальный DHCP-сервер, организацию сетевых мостов с помощью беспроводных соединений, широкий спектр сетевых протоколов, переключение между разными виртуальными сетями.

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

Как и Virtual PC, VMware Workstation позволяет создавать «моментальные снимки» виртуальных машин, сохраняя в виде файла компьютера-хоста сведения об их состоянии, о запущенных приложениях и их данных, а также поддерживает обмен данными между виртуальными машинами и операционной системой хоста с помощью буфера обмена и операций drag-and-drop, синхронизацию времени гостевой ОС и ОС хоста и, наконец, возможность отмены всех изменений, сделанных пользователем в данном сеансе работы.

1.4.3 — Bochs

Bochs (произносится «бокс») (рис. 4) — open source программа для эмуляции аппаратного обеспечения PC. Включает в себя эмуляцию ЦПУ Intel x86, устройства ввода-вывода, и возможность использовать различный BIOS PC и видеоадаптера. Может эмулировать 386, 486, Pentium, Pentium Pro, AMD64 CPU и другие x86-совместимые процессоры, поддерживает MMX, SSE, SSE2, 3DNow! (в ближайшем будущем планируется и SSE3 и др.) Написана на C++ и работает на Windows 9x, Windows 2k, Linux, *BSD и др. Отличается очень тщательной эмуляцией процессора, может быть запущен на любой аппаратной платформе.

Рисунок 1.4. Внешний вид ВМ Bochs

1.4.5 Microsoft Virtual Server

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

Отметим, однако, что многие приложения масштаба предприятия требуют достаточно объемной обработки данных и, следовательно, наличия серверных приложений, выполняющихся на многопроцессорных компьютерах. В частности, редакция, носящая название Enterprise Edition или сходное с ним и поддерживающая использование многопроцессорных серверов и кластеров, присутствует в линейках серверных операционных систем, серверных СУБД и серверов приложений всех ведущих производителей указанных категорий программного обеспечения. Задачи, связанные с тестированием и эксплуатацией подобных продуктов, нельзя корректно решить с помощью средств создания виртуальных машин для настольных операционных систем — для этого существует особая категория средств виртуализации, о которых речь пойдет ниже.

Производитель Microsoft Virtual Server 2005 выделил четыре основные области применения этого продукта.

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

Хостинг унаследованных приложений. Зачастую наиболее удачные бизнес-приложения эксплуатируются десятилетиями, поэтому вполне может случиться так, что платформа, для которой они написаны, в компании уже практически не применяется из-за отсутствия нормальной технической поддержки со стороны производителей оборудования, а также, возможно, из-за отсутствия в компании персонала, специализирующегося на сопровождении устаревших платформ, и разработчиков, способных обновить данное приложение. В этом случае применение серверного ПО для создания виртуальных машин с операционными системами, выпущенными несколько лет назад (например, Windows NT 4.0), может оказаться наиболее простым и выгодным решением, позволяющим продлить жизнь бизнес-приложениям, эксплуатирующимся достаточно давно, и не тратить средства ни на переписывание приложений, ни на переобучение пользователей.

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

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

Во всех перечисленных случаях Virtual Server 2005 позволяет снизить затраты либо на аппаратное обеспечение, либо на сопровождение и поддержку инфраструктуры и приложений.

Как и другие средства создания виртуальных машин, Virtual Server 2005 выполняется под управлением операционной системы хоста (в данном случае Windows Server 2003) за счет части оперативной памяти, доступной этой операционной системе; при этом аппаратное обеспечение может быть виртуальным, то есть смоделированным Virtual Server 2005.

Virtual Server 2005 доступен в двух редакциях — Standard и Enterprise, отличающихся только числом поддерживаемых процессоров. Первая из редакций поддерживает четыре физических процессора, вторая — до 32. Хотя в обеих редакциях продукта каждой виртуальной машине доступен только один процессор, зато этот процессор можно использовать на все сто процентов (чего средства создания виртуальных машин для настольных операционных систем, естественно, не позволяют).

Virtual Server 2005 — это многопоточная служба операционной системы. Каждая виртуальная машина выполняется в своем потоке.

Сам Virtual Server 2005 может использовать до 64 Гбайт оперативной памяти, а каждая виртуальная машина — до 3,6 Гбайт.

Virtual Server 2005 может эмулировать до четырех жестких IDE-дисков объемом до 128 Гбайт или дисководов CD/DVD-ROM (в качестве дисководов можно использовать и образы дисков в формате ISO), а также до четырех виртуальных шин SCSI общим объемом до 56,5 Тбайт; при этом данным продуктом поддерживается двухузловой кластер из виртуальных машин с общим хранилищем данных на виртуальных SCSI-дисках. Это позволяет смоделировать работу серверного программного обеспечения в таком кластере без реального приобретения соответствующего оборудования.

Что касается поддержки графики, то Virtual Server 2005 эмулирует видеоадаптер S3 Trio64 с 4 Мбайт видеопамяти, 2D-ускорителем и поддержкой Microsoft DirectX.

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

Virtual Server 2005 поддерживаются следующие гостевые операционные системы:

— Windows Server 2003, Standard Edition;

— Windows Server 2003, Enterprise Edition;

— Windows Server 2003, Web Edition;

— Windows Small Business Server 2003;

— Windows 2000 Server;

— Windows 2000 Advanced Server;

— Windows NT Server 4.0 with Service Pack 6a.

Кроме того, Virtual Server 2005 позволяет обеспечивать баланс загрузки различных виртуальных машин, эмулируя кластерную конфигурацию, и содержит средства управления распределением ресурсов (памяти, процессорного времени, приоритетов выполнения) для подобных виртуальных машин.

Средства администрирования Virtual Server 2005 представляют собой приложение с Web-интерфейсом. Для создания решений на базе Virtual Server 2005 существует документированный COM API, позволяющий программно решать задачи администрирования, развертывания виртуальных машин и их конфигурирования, автоматизируя эти процессы с помощью административных скриптов или приложений, созданных с помощью широкого спектра средств разработки для платформ Windows и .NET.

Отметим, что Virtual Server 2005 обладает средствами интеграции с Active Directory. Кроме того, для данного продукта доступно и средство Microsoft Operations Manager 2005 Management Pack for Virtual Server, позволяющее с помощью Microsoft Operations Manager управлять событиями и производительностью виртуальных машин.

1.4.7 Серверные продукты компании EMC/Vmware

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

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

Средства создания виртуальных машин масштаба предприятия

VMware GSX Server 3.1

VMware GSX Server 3.1 представляет собой средство создания виртуальных машин и, подобно настольным средствам аналогичного назначения, выполняется под управлением операционной системы хоста (в данном случае — 32- или 64-разрядных серверных версий Windows и Linux, выполняющихся на компьютерах с одним или несколькими x86-совместимыми процессорами), используя часть оперативной памяти, доступной этой операционной системе. Основные области применения данного продукта: тестирование прикладного и системного программного обеспечения и средств разработки, в том числе конфигураций ПО, моделирование распределенных серверных приложений на одном физическом сервере, хостинг различных серверных приложений, включая унаследованные, обеспечение равномерности загрузки серверов за счет размещения одного и того же набора этих виртуальных машин на нескольких физических серверах. Иными словами, спектр задач, решаемых с помощью GSX Server, сходен с теми, что решаются с помощью Microsoft Virtual Server 2005, однако набор поддерживаемых данным продуктом операционных систем более широк и не ограничивается различными версиями Windows — среди ОС, поддерживаемых в качестве гостевых, широкий спектр версий Linux, а при необходимости с помощью этого продукта можно также выполнять последние версии Novell Netware (рис. 5). Данный продукт содержит в своем составе средства для организации удаленного администрирования, основанные на Web-интерфейсе и выполняющиеся под управлением Windows или Linux.

Рисунок 1.5. Windows-версия VMware GSX Server 3.1

VMware ESX Server 2.5 представляет собой средство создания виртуальных машин, не требующее наличия операционной системы-хоста (по существу, оно само играет роль операционной системы) и выполняющееся на компьютерах с двумя и более 32-разрядными процессорами Intel и AMD, двумя и более сетевыми адаптерами. В качестве хранилища файлов должны выступать SCSI-диски, накопители, доступные с помощью Fibre Channel, либо встроенный RAID-контроллер — в таком хранилище данный продукт создает собственную файловую систему VMware File System (VMFS). Продукт может быть установлен на Blade-серверы или на сети хранения данных SAN.

VMware ESX Server 2.5 поддерживает эмуляцию до 80 виртуальных процессоров и одновременное выполнение до 32 виртуальных машин с гостевыми ОС, включающими серверные версии Windows, Linux, FreeBSD, Novell NetWare. Для некоторых их версий Windows и Linux поддерживаются виртуальные симметричные многопроцессорные конфигурации.

Данный продукт также содержит в своем составе средства для организации удаленного администрирования, основанные на Web-интерфейсе и выполняющиеся под управлением Windows или Linux (рис. 1.6). В отличие от VMware GSX Server 3.1, он рассчитан на удаленное администрирование и не включает инструментов, выполняющихся локально на самом сервере (за исключением, естественно, процедуры установки и первоначальной конфигурации самого ESX Server).

Рисунок 1.6. Средства удаленного администрирования VMware ESX Server 2.5

Для VMware ESX Server существует дополнение под названием VMware Virtual SMP, которое позволяет одной виртуальной машине выполняться на нескольких физических процессорах. Указанное дополнение дает возможность осуществлять дополнительное масштабирование наиболее ресурсоемких приложений, выполняющихся на виртуальных машинах, а также тестировать работу подобных приложений на нескольких процессорах.

Отметим, что ряд производителей аппаратного обеспечения, в частности IBM, поставляет на рынок аппаратно-программные решения, включающие предустановленный VMware ESX Server.

Средства управления виртуальными машинами и другие инструменты

VMware VirtualCenter 1.2 и VMotion

VMware VirtualCenter 1.2 — это средство управления виртуальными машинами под управлением ESX Server и GSX Server и содержащими их серверами. Данный продукт позволяет осуществлять конфигурацию операционных систем, служб и приложений, выполняющихся на виртуальных машинах, переносить их с одной машины на другую, производить быстрое развертывание серверов с предустановленной операционной системой и приложениями (рисунок 1.7.).

Рисунок 1.7. VMware VirtualCenter

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

VMware P2V Assistant

VMware P2V Assistant — средство создания виртуальных машин на основе реально существующих физических машин, выполняющихся под управлением различных версий Windows, начиная с Windows NT 4.0. Этот продукт создает «моментальный снимок» исходной операционной системы и превращает его в виртуальную машину, избавляя администраторов от необходимости установки и конфигурации последней. Созданные с его помощью виртуальные машины могут выполняться под управлением VMware ESX Server, VMware GSX Server и VMware Workstation.

VMware ACE

VMware ACE — это инструмент, рассчитанный на администраторов сетей и предназначенный для создания стандартных виртуальных машин и конфигураций для рабочих станций. Его основное назначение — упрощение администрирования рабочих станций за счет создания однотипных конфигураций и переноса их на рабочие станции.

Особенностью данного продукта является широкий набор возможностей, связанных с обеспечением безопасности сети, таких как поддержка рабочих станций-«гостей» (например, ноутбуков посетителей), установка срока действия той или иной конфигурации.

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

В качестве гостевых ОС VMware ACE поддерживает различные версии DOS, Windows, Linux, FreeBSD, Novell Netware, Sun Solaris, а в качестве операционных систем хоста и средств управления VMware ACE Manager (рис. 4) — все версии Windows, начиная с Windows 2000.

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

2. Постановка задачи и ее реализация

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

Для вычисления аппаратных требований к ПК нашего учебного класса необходимо взять минимальные требования к аппаратному обеспечению каждой из гостевых операционных систем, которые планируется запускать и добавить к ним аппаратные требования для хостовой операционной системы, в данном случае Microsoft Windows XP Professional Service Pack 2.

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

Минимальные аппаратные требования, необходимые для нормального функционирования этой системы приведены в таблице 2.1

Таблица 2.1 Минимальные аппаратные требования операционной системы Microsoft Windows XP Professional Service Pack 2

Аппаратные требования для каждой из гостевых операционных систем приведены в таблицах 3, 4, 5 и 6. Аппаратные требования приведенные ниже являются не минимальными фактическими конфигурациями, но требованиями, необходимыми для комфортной работы в той или иной среде, так как учащийся должен иметь возможность «нормально» работать с каждой из гостевых операционных систем т. е. без долгосрочного ожидания окончания той или иной операции. Так как запуск нескольких гостевых операционных систем не планируется, то для расчета аппаратных требований к одной реальной машине проектируемого учебного класса необходимо воспользоваться следующим алгоритмом: Для расчета тактовой частоты процессора: выбрать максимальную тактовую частоту из таблиц, приведенных выше и удвоить ее. Для расчета объема оперативной памяти: выбрать максимальный объем оперативной памяти из таблиц, приведенных выше и удвоить его.

Таблица 2.2 Аппаратные требования гостевой операционной системы Microsoft Windows XP Professional Service Pack 2

Таблица 2.3 Аппаратные требования гостевой операционной системы Debian GNU/Linux (Sarge) 3.1 Ядро 2.4.27 (Текстовый режим)

Таблица 2.4 Аппаратные требования гостевой операционной системы Debian GNU/Linux (Sarge) 3.1 Ядро 2.4.27 (Графический режим оконного менеджера KDE)

Таблица 2.5 Аппаратные требования гостевой операционной системы Microsoft DOS 3.30

Для расчета пространства на жестком диске хостовой машины: суммировать все значения объема пространства на жестком диске из таблиц 2−6.Получившиеся значения приводятся в таблице 2.6.

Таблица 2.6 Минимальные аппаратные требования к машине-хосту исходя из характеристик каждой из гостевых операционных систем.

Следовательно, каждая из машин в учебном классе должна быть оснащена в соответствии с таблицей 7.

Среди дополнительных аппаратных требований к машинам-хостам следует отметить наличие сетевого адаптера для сетевого взаимодействия на скорости не менее 100 Мбит/с, видеоадаптеров и мониторов поддерживающих разрешение не менее 1280×1024.

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

— Microsoft Windows XP Professional Service Pack 2

— Debian GNU/Linux 3.1 (Sarge) ядро 2.4.27 (в режиме KDE)

— MS-DOS 3.30

Для упрощения следует разбить задачу на несколько основных этапов:

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

— планирование виртуального учебного класса;

— подготовка к развертыванию системы виртуальных машин (включает в себя конфигурирование отдельно взятой виртуальной машины под каждую из гостевых операционных систем);

— перенос образов дисков и настроек на все реальные машины учебного класса и настройка виртуальной учебной сети;

— тестирование учебного класса.

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

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

— Vmware Workstation;

— Microsoft Virtual PC;

— Bochs.

Перечислим ниже их преимущества и недостатки:

Vmware Workstation:

Преимущества:

— поддержка множества операционных систем;

— поддержка сетевого взаимодействия и сетевой интеграции;

— возможность создания «моментальных снимков» состояния виртуальных машин;

— поддержка обмена данными с операционной системой хоста посредством буфера обмена.

Недостатки:

— высокая цена продукта;

— относительно высокие системные требования;

— недостаточно тщательная эмуляция, в результате чего происходят сбои в работе.

Microsoft Virtual PC:

Преимущества:

— поддержка сетевого взаимодействия и сетевой интеграции;

— гибкость настройки;

— возможность загрузить неактивную установленную операционную систему в качестве гостевой;

— возможность создания «моментальных снимков» состояния виртуальных машин;

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

Недостатки:

— ограниченная поддержка операционных систем;

— отсутствие возможности отмены всех изменений, сделанных пользователем в данном сеансе работы.

Bochs:

Преимущества:

— бесплатный программный продукт с открытым кодом;

— очень тщательная эмуляция инструкций процессора;

— кроссплатформенность;

— возможность использовать различные прошивки BIOS.

Недостатки:

— отсутствие поддержки динамических дисков;

— отсутствие поддержки создания «моментальных снимков» состояния;

— отсутствие поддержки сетевой интеграции и трансляции сетевых адресов.

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

2.3 Краткое описание операционных систем

2.3.1 Debian GNU/Linux

GNU/Linux (произносится «гну слэш лимнукс») — свободная UNIX-подобная операционная система. Она основана на системных программах, разработанных в рамках проекта GNU, и на ядре Linux. Обычно по историческим причинам (и для краткости) эта система называется просто «Linux».

К операционной системе GNU/Linux также часто относят программы, дополняющие эту операционную систему, и прикладные программы, делающие её полноценной многофункциональной операционной средой.

В отличие от большинства других операционных систем, GNU/Linux не имеет единой «официальной» комплектации. Вместо этого GNU/Linux поставляется в большом количестве так называемых дистрибутивов, в которых программы GNU соединяются с ядром Linux и другими программами. Наиболее известными дистрибутивами GNU/Linux являются Slackware, Red Hat, Fedora Core, Mandriva, SuSE, Debian, Gentoo, Ubuntu. Из дистрибутивов российских разработчиков наиболее известны ALT Linux и ASPLinux.

В отличие от Microsoft Windows, Mac OS (Mac OS X) и коммерческих UNIX-подобных систем, GNU/Linux не имеет географического центра разработки. Нет и организации, которая владела бы этой системой; нет даже единого координационного центра. Программы для GNU/Linux — результат работы тысяч проектов. Некоторые из этих проектов централизованы, некоторые сосредоточены в фирмах, но большинство объединяют программистов со всего света, которые знакомы только по переписке. Создать свой проект или присоединиться к уже существующему может любой и, в случае успеха, результаты работы станут известны миллионам пользователей. Пользователи принимают участие в тестировании свободных программ, общаются с разработчиками напрямую, что позволяет быстро находить и исправлять ошибки и реализовывать новые возможности.

Именно такая гибкая и динамичная система разработки, невозможная для проектов с закрытым кодом, определяет исключительную экономическую эффективность GNU/Linux. Низкая стоимость свободных разработок, отлаженные механизмы тестирования и распространения, привлечение людей из разных стран, обладающих разным видением проблем, защита кода лицензией GPL — всё это стало причиной успеха свободных программ.

Конечно, такая высокая эффективность разработки не могла не заинтересовать крупные фирмы, которые стали открывать свои проекты. Так появились Mozilla (Netscape, AOL), OpenOffice.org (Sun), свободный клон Interbase (Borland), SAP DB (SAP). IBM способствовала переносу GNU/Linux на свои мейнфреймы.

С другой стороны, открытый код значительно снижает себестоимость разработки закрытых систем для Linux и позволяет снизить цену решения для пользователя. Вот почему Linux стала платформой, часто рекомендуемой для таких продуктов, как Oracle, DB2, Informix, SyBase, SAP R3, Domino.

Большинство пользователей для установки GNU/Linux используют дистрибутивы. Дистрибутив — это не просто набор программ, а ряд решений для разных задач пользователей, объединённых едиными системами установки, управления и обновления пакетов, настройки и поддержки. Самые распространённые в мире дистрибутивы:

— американский Red Hat и его наследник Fedora Core;

— немецкий SuSE;

— французский Mandriva (бывший Mandrake);

— не имеющий национальной принадлежности международный дистрибутив Debian GNU/Linux;

— один из самых старых дистрибутивов Slackware;

— сравнительно молодой и активно развивающийся дистрибутив Gentoo;

— очень молодой, но перспективный дистрибутив Ubuntu Linux.

Помимо перечисленных, существует множество других дистрибутивов, как базирующихся на перечисленных, так и созданных с нуля и зачастую предназначенных для выполнения ограниченного количества задач. Каждый из них имеет свою концепцию, свой набор пакетов, свои достоинства и недостатки. Ни один не может удовлетворить всех пользователей, а потому рядом с лидерами благополучно существуют другие фирмы и объединения программистов, предлагающие свои решения, свои дистрибутивы, свои услуги. Существует множество LiveCD, построенных на основе GNU/Linux, например, Knoppix. LiveCD позволяет запускать GNU/Linux непосредственно с компакт-диска, без установки на жёсткий диск.

Для желающих досконально разобраться с GNU/Linux подойдёт любой из дистрибутивов, однако довольно часто для этой цели используются так называемые source-based дистрибутивы, то есть предполагающие самостоятельную сборку всех (или части) компонентов из исходных кодов, такие как LFS, Gentoo или CRUX. Однако для начинающих изучать основы UNIX-систем, наилучшим вариантом будет уже «собранный» и готовый к использованию дистрибутив. Для нашего учебного курса мы выбрали Debian.

Debian — проект по созданию дистрибутивов свободных операционных систем. Наиболее законченный и наиболее используемый дистрибутив — Debian GNU/Linux. Также существуют проекты по использованию других ядер: Debian GNU/Hurd, Debian GNU/NetBSD и Debian GNU/kFreeBSD.

Debian — наиболее строгий из всех дистрибутивов в отношении лицензий программ. Имеет наибольшее хранилище пакетов — готовых к использованию программ, — и если даже не по их числу, то по числу поддерживаемых архитектур: начиная с ARM, используемой во встраиваемых устройствах, наиболее популярных x86 и PowerPC, новых 64-разрадных AMD и заканчивая IBM S/390, используемой в мейнфреймах. Хранилище разделено на три ветки:

стабильную (stable), содержащую пакеты, вошедшие в последний официальный дистрибутив (обновление пакетов в нём происходит только для устранения уязвимостей);

тестируемую (testing), из которой будет формироваться следующий стабильный дистрибутив;

нестабильную (unstable), в которой пакеты готовятся к помещению в тестируемую ветку.

Существует также ветка, называемая экспериментальной (experimental); в неё помещаются пакеты, претерпевающие особо большие изменения. В Debian серьёзно относятся к любым изменениям, благодаря чему проблемы с обновлением бывают очень редко (ценой этому является не совсем быстрая реакция на выход новых версий программ). Для работы с хранилищем разработаны разные средства, самое популярное из которых — APT.

Debian стал основой целого ряда дистрибутивов (более 100). Самые известные из них — Adamantix, Bioknoppix, Clusterix, Gnoppix, Knoppix, Kubuntu, Libranet, Linspire, MEPIS, Ubuntu Linux и Xandros Desktop OS.

Стабильные версии операционной системы Debian называются именами персонажей мультфильма «Toy Story». Само название «Debian» составлено из имён основателя проекта Яна Мёрдока (Ian Murdock) и его подруги (теперь — жены) Дебры (Debra).

Создание Debian начал в августе 1993 года Ян Мёрдок. Он намеревался создать новый дистрибутив, который будет создаваться открыто, в духе Linux и GNU. Debian был задуман как дистрибутив, который будет собран тщательно и добросовестно, и так же качественно будет сопровождаться и поддерживаться. Проект начался как небольшая, тесно сплочённая группа хакеров мира свободного ПО, а затем постепенно рос, став большим, организованным сообществом разработчиков и пользователей. Подробности истории можно прочесть на сайте www.debian.org.

История релизов Debian:

Версия/Кодовое имя Дата выхода

0.93R6 26 октября 1995

1.1 Базз (Buzz) 17 июня 1996

1.2 Рекс (Rex) 12 декабря 1996

1.3 Бо (Bo) 5 июня 1997

2.0 Хэмм (Hamm) 24 июля 1998

2.1 Слинк (Slink) 9 марта 1999

2.2 Потэйто (Potato) 15 августа 2000

3.0 Вуди (Woody) 19 июля 2002

3.1 Сарж (Sarge) 6 июня 2005

Следующая стабильная версия будет иметь название «Этч» (Etch).

2.3.2 DOS (MS-DOS 3.30)

Дисковая операционная система фирмы Майкрософт — MS-DOS — в своё время была довольно широко распространена на PC-совместимых компьютерах. Со временем она была заменена различными вариантами операционной системы Windows.

MS-DOS была выпущена в 1981 году и вышла в восьми версиях, пока Майкрософт не прекратила её разработку в 2000 г. Это был ключевой продукт фирмы, дававший ей существенный доход и маркетинговый ресурс, в ходе развития Майкрософт от разработчика языка программирования до крупной компании, производящей самое разнообразное ПО.

В 1980 Тимом Патерсоном (Tim Paterson) из Seattle Computer Products (SCP) была создана QDOS (Quick and Dirty Operating System). QDOS, по большей части, была 16-разрядным клоном CP/M, но с новой файловой системой — FAT. QDOS была переименована в 86-DOS, поскольку разрабатывалась для работы на процессоре Intel 8086. Майкрософт приобрела QDOS за $ 50 000 и продала её IBM уже как PC-DOS (MS-DOS).

MS-DOS является одной из версий DOS.

DOS является однозадачной операционной системой: управление передаётся прикладной программе, которая по мере необходимости вызывает прерывание int 21h. Это очень удобно как для прикладных программистов, предпочитающих языки низкого уровня, так и для авторов вирусов — что может быть проще подмены системного прерывания в реальном режиме?

DOS возник из QDOS, бывшего клоном операционной системы CP/M, и поэтому очень похож на неё. Начиная с версии 2.0, DOS унаследовал понятие хендла (file handle) у UNIX-подобных систем.

DOS имеет консольную систему ввода/вывода и поддерживает три стандартных потока: stdin, stdout и stderr.

DOS — 16-битная операционная система, работающая в реальном режиме, поэтому для расширения возможностей и преодоления ограничений реального режима создали так называемые расширители DOS. Они запускают программы в защищённом 32-битном режиме и эмулируют привычные программисту сервисы int 21h. Обычно они поддерживают стандарт DPMI — DOS Protected Mode Interface. Самый известный и широко используемый (в игрушках) расширитель — DOS4GW.

Существует несколько ветвей ДОС для PC. Все они схожи по наборам команд и базовой функциональности, но отличаются производительностью, стабильностью работы и дополнительными функциями.

DR-DOS (Novell DOS, Caldera DR-DOS) — выпущен Digital Research в 1991 г., перекуплен компанией Novell в 1993 г., перекуплен компанией Caldera и распространяется с открытым исходным кодом.

MS-DOS — выпущен компанией Microsoft в 1982 г.

PC-DOS — выпущен компанией IBM в 1981 г.

PTS-DOS — выпущен компанией ФизТехСофт в 1993 г.

Paragon Dos Pro (первоначальное название — PT$-DOS). Ветка PTS-DOS, выпущенная компанией Paragon Software после того, как её основатели, включая ведущего разработчика PTS-DOS ушли из ФизТехсофта, основав собственную компанию. Последние версии этой ветки включают поддержку FAT32.

FreeDOS — выпущен в 1994 г. Это свободный ДОС, изначально назывался PD-DOS.

FreeDOS32 — свободный и полностью 32-битный ДОС. Не требует расширителей для запуска 32-битных приложений. Планируется избавиться и от других ограничений ДОС (поддержка других файловых систем, многозадачности и т. п.).

Появление FreeDOS, а так же развитие свободного программного обеспечения и особенно DJGPP привело к появлению полностью свободного дистрибутива ДОС GNU/DOS. В его состав входят популярные GNU-приложения, такие как vim (текстовый редактор), Arachne (web-браузер, почтовый клиент и файловый менеджер), OpenGEM (графический пользовательский интерфейс), различные средства разработки программного обеспечения для ДОС. Его объём составляет более 70 Мб двоичных программ, а также более 200 Мб двоичных программ и их исходников. GNU/DOS очень полезен для пользователей старых компьютеров, желающих пользоваться самыми современными версиями программ, а также для разработчиков, желающих держать под полным контролем всё железо компьютера. Выбор именно этой ветви операционных систем для курса «Системного Программирования» вполне понятен и обоснован исторически.

2.3.3 Microsoft Windows XP Professional Service Pack 2

Вот краткая справка по данной операционной системе с сайта производителя, компании Microsoft:

Microsoft Windows XP Professional Edition — это выбор организаций, которые хотят в полном объеме использовать возможности вычислительной техники. Предоставляя передовые возможности, например поддержку беспроводных сетей и услуги удаленного помощника, Windows XP Professional устанавливает новый уровень эффективности и надежности в обработке данных.

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

Более высокая производительность и совершенная многозадачность. Одновременное выполнение нескольких программ — даже наиболее требовательных к вычислительным ресурсам — и по-прежнему быстрый отклик системы на команды. С установленной Windows XP переносной компьютер быстрее, чем когда бы то ни было раньше, переходит в ждущий или спящий режим и возвращается обратно в рабочее состояние, при этом поддерживается высокая эффективность и стабильность работы.

Windows Messenger

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

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

Удаленная поддержка Теперь ИТ-специалист (ИТ — информационные технологии) может помочь вам справиться с проблемами, связанными с компьютером, или обучить вас новым технологиям, независимо от того, где они находятся — в одной с вами комнате или в другом городе.

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

Надежность профессионального уровня Организовав работу на базе Windows XP, вы будете всегда уверены в надежности и работоспособности системы. Созданная на основе проверенной операционной системы Windows 2000, Windows XP отличается повышенной надежностью и обладает возможностями, которые облегчают восстановление системы при возникновении проблем.

Усовершенствованные функции:

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

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

Расширенная поддержка портативных компьютеров Расширенная поддержка портативных компьютеров позволяет работать в пути так же эффективно, как и в офисе. Предоставляется простой доступ ко всем данным и программам, находящимся на офисном компьютере. Кроме того, Windows XP Professional расширяет возможности энергосбережения и позволяет продлить срок службы аккумуляторной батареи переносного компьютера.

2.4 Описание процесса реализации

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

Компьютеры vpc1-vpc8 работают под управлением Microsoft Virtual PC, тогда как vsrv1 работает под управлением Microsoft Virtual Server. Такая структура была призвана обеспечить нормальное взаимодействие как машин внутри сети между собой и сервером, так и доступ к сети университета. После того, как план был одобрен мы приступили к его реализации.

Рисунок 2.1. Топология сети и план учебного класса на основе виртуальных машин

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

2.4.3 Тестирование учебного класса В результате использования учебного класса на основе виртуальных машин в преподавании курса системного программирования (на языке ассемблера), курса администрирования Microsoft Windows XP Professional, а также начального курса введения в UNIX системы, в течении трех с половиной месяцев, недостатков в работе класса выявлено не было.

Преподавание вышеупомянутых курсов, в частности курса администрирования Microsoft Windows XP Professional осуществлялось следующим образом: Курс был расчитан на пятнадцать часов, пять дней, по три часа в день. В течение первых двух часов студентам читались лекции, после чего, в течении последнего часа они должны были выполнять практические задания с использованием виртуальных машин, такие как:

— автоматизированная установка Microsoft Windows XP Professional;

— подключение компьютера к домену сети (с использованием виртуального сервера);

— выполнение операций над учетными записями пользователей;

— сетевое конфигурирование рабочих станций.

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

3. Специальная часть

3.1 Моделирование предметной области Предметной областью называется часть реального мира, представляющая интерес для данного исследования (использования). Моделирование предметной области является основой статической части модели. Построение модели предметной области начинается с выявления абстракций, существующих в реальном мире, т. е. концептуальных объектов, встречающихся в системе. При проектировании объектно-ориентированного программного обеспечения требуется структурировать программу так, чтобы в центре оказались именно эти объекты из пространства задачи. Это происходит потому, что требования к программе меняются намного быстрее, чем реальный мир. Основой объектного моделирования вообще и статического моделирования в частности и является создание модели этих абстракций из предметной области. Модель предметной области представляет словарь терминов, которым пользуются для выявления и описания прецедентов системы в дальнейшем. В ходе выявления объектов из предметной области необходимо установить, какие связи существуют между ними. Очень важными связями являются отношение агрегации (отношение между целым и частью) и обобщение (отношение между подклассом и суперклассом). В основу статической модели мы положим диаграмму классов, отображающую модели предметной области. В данном дипломном проекте рассматривается протокол прикладного уровня, ориентированный на конкретные прикладные задачи. Он определяет как процедуры по организации взаимодействия определенного типа между прикладными процессами, так и форму представления информации при таком взаимодействии.

3.2 Моделирование прецедентов Разработка программного обеспечения подчиняется определенному жизненному циклу (ЖЦ). Жизненный цикл — это упорядоченный набор видов деятельности, осуществляемый и управляемый в рамках каждого проекта по разработке ПО. Жизненный цикл определяет этапы, так что программный продукт переходит с одного этапа на другой, начиная с зарождения концепции продукта и заканчивая этапом его сопровождения.

На укрупненном уровне ЖЦ включает три этапа:

— анализ;

— проектирование;

— реализация.

На детализированном уровне ЖЦ можно разбить на семь этапов:

— установление требований;

— спецификация требований;

— проектирование архитектуры;

— детализированное проектирование;

— реализация;

— интеграция;

— сопровождение.

Наша задача рассмотреть подробно первый этап — установление требований. Задачей этапа определения требований является определение, анализ и обсуждение требований с заказчиками. На этом этапе применяются различные методы сбора информации от заказчиков, и занимается этим аналитик бизнес-процессов (системный аналитик). К методам можно отнести исследование концепции с помощью структурированных и неструктурированных интервью пользователей, анкеты, изучение документов и форм, видеозаписи и т. д.

Рассмотрим требования предъявляемые пользователями данной системы. У будущих пользователей возникают следующие требования к разрабатываемой системе:

— возможность пользователю при наличии минимальных знаний компьютера использовать программный продукт;

— система обеспечить быстрое соединение и просмотр информации;

— система должна проводить обмен данных с учетом различных ограничений, установленных администратором для пользователей;

Следующим этапом разработки программного продукта является построение диаграммы прецедентов.

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

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

Диаграмма прецедентов — это документированная модель предполагаемого поведения системы.

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

— краткое описание;

— предусловия;

— детализированное описание потока событий: основной поток и альтернативные потоки;

— постусловия.

Для дальнейшего более подробного рассмотрения и документирования выделяется прецедент «Организации удаленного обмена данными».

Приведем описательную спецификацию данного прецедента:

— прецедент дает возможность пользователю пройти идентификацию для получения доступа на сервер;

— основной поток: после запуска FTP протокола пользователь подключается под своим логином и паролем к серверному приложению для обмена файлами. Альтернативный поток: клиент может передавать и принимать информацию в том случае, если администратор не ограничил его правами доступа;

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

Диаграмма прецедентов показана на рисунке 3.1.

Рисунок 3.1. Диаграмма прецедентов

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

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

— текста последовательности действий в прецеденте, который записывается сверху вниз по левой стороне;

— объектов, перенесенных прямо с диаграммы пригодности и представленных в виде прямоугольников, в которых в формате «объект: класс» записывается имя или номер экземпляра объекта и имя класса объекта;

— сообщений, изображаемых стрелками, которые направлены от одного объекта к другому;

— методов (операций), представляемых в виде прямоугольников. Они расположены на пунктирных линиях, соответствующих тем объектам, которым методы принадлежат. Длину прямоугольника можно использовать для того, чтобы показать фокус управления в последовательности: метод владеет управлением вплоть до точки, в которой прямоугольник кончается.

Диаграмма последовательности показана на рисунке 3.2.

Рисунок 3.2. Диаграмма последовательности Рисунок 3.2. Диаграмма кооперации

3.4 Диаграмма классов Систему образует системное состояние. Состояние является функцией содержимого системной информации в заданный момент времени. Определение состояния системы описывается в модели классов. Различают классы-сущности, которые определяют информацию системы; пограничные классы, которые определяют GUI-объекты; для управления программной логикой существуют управляющие классы.

Моделирование классов — итеративный пошаговый процесс.

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

Моделирование классов приводит к функциональному подходу, сторонники объектно-ориентированного подхода предпочитают называть его проблемно-ориентированным.

Диаграмма классов показана на рисунке 3.3.

Рисунок 3.4 Диаграмма классов

Заключение

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

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

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

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

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

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

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

Особенно широко данный подход применяется на ПК архитектуры Intel x86 в ОС Windows NT/XP, системах реального времени (QNX, RTL), а также ряде систем UNIX. Одновременно с этим инженеры, разрабатывавшие пути повышения надежности функционирования и повышения коэффициента использования вычислительной мощности высокопроизводительных ЭВМ, например мэйнфреймов, реализовали возможность логического объединения групп процессоров, устройств хранения и передачи данных, изначально скомпонованных в единый вычислительный ресурс, как независимых ЭВМ. В конце 90-х годов прошлого века вычислительная мощность доминирующей архитектуры ПК (x86) стала достаточной для реализации сходных с логическими разделами мэйнфреймов идей.

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

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

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

1 Volker Ruppert A brief history of virtual machines. Artech House 1993.

2 Бек А.

Введение

в системное программирование. — М.: «Мир», 1988.

3 Вишняков В. А., Петровский А. А. Системное обеспечение микроЭВМ. — Минск: «Вышэйшая школа», 1990.

4 Дейкстра Э. Структура мультипрограммной системы THE

5 Дейкстра Э. Взаимодействие последовательных процессов

6 Мейс Т. Обзор архитектуры Windows 3. x, Windows 95, OS/2 Warp, Windows NT

7 Керниган Брайан. Практика программирования. — СПб.: Невский Диалект, 2001. — 381 с.

8 Зубков С. В. Assembler для DOS, Windows и UNIX. — ДМК, 2000

9 Intel Architecture Software Developer’s Manual

10 Bochs User’s Manual

11 Microsoft Virtual PC User’s Guide

12 Vmware Workstation User’s Manual

13 Информационный бюллетень Microsoft http://microsoft.com/ru/products

14 Хоар К. Мониторы — структурная концепция операционных систем

15 Соломон Д. Архитектура ядра Windows NT 5.0

16 Н. А. Олифер, В. Г. Олифер Сетевые операционные системы

17 Таненбаум Э. Современные операционные системы. — СПб.: Питер, 2002. — 1040 с.

18 Столлингс Вильям. Операционные системы, 4-е издание. — М.: Вильямс, 2002. — 848 с.

19 Мурашко И. В., Авалян В. Э. Библия MS-DOS версии 5.0 в 2-х книгах. Кн. 1. — М.: НПО «Гермес», 1992

20 Мурашко И. В., Авалян В. Э. Библия MS-DOS версии 5.0 в 2-х книгах. Кн. 2. — М.: НПО «Гермес», 1992

21 Скэнлон Л. Персональные ЭВМ IBM PC и XT. Пер. с англ. — 2 -е изд. М.: Радио и Связь, 1991

22 Фролов А. В., Фролов Г. В. Аппаратное обеспечение IBM PC. М.: «ДИАЛОГ-МИФИ». 1992

23 Борзенко А. Путешествие по памяти. «Компьютер Пресс», 1992

24 Microsoft 2285B Course, Teacher’s reference

25 Москаленко М. Виртуальные машины как программное обеспечение серверов, Компьютер-Пресс 2001

26 ГОСТ 12.1 003−83, ГОСТ 12.1.0280, ГОСТ 12.4.051−87

Приложение Текст программы Состав файла Samba. conf

# This is the main Samba configuration file. You should read the

# smb. conf (5) manual page in order to understand the options listed

# here. Samba has a huge number of configurable options (perhaps too

# many!) most of which are not shown in this example

#

# Any line which starts with a; (semi-colon) or a # (hash)

# is a comment and is ignored. In this example we will use a #

# for commentry and a; for parts of the config file that you

# may wish to enable

#

# NOTE: Whenever you modify this file you should run the command «testparm»

# to check that you have not made any basic syntactic errors.

#

#================= Global Settings ==================

[global]

# 1. Server Naming Options:

# workgroup = NT-Domain-Name or Workgroup-Name

workgroup = MDKGROUP

# netbios name is the name you will see in «Network Neighbourhood» ,

# but defaults to your hostname

; netbios name =

# server string is the equivalent of the NT Description field

server string = Samba Server %v

# Message command is run by samba when a «popup» message is sent to it.

# The example below is for use with LinPopUp:

; message command = /usr/bin/linpopup «%f» «%m» %s; rm %s

# 2. Printing Options:

# CHANGES TO ENABLE PRINTING ON ALL CUPS PRINTERS IN THE NETWORK

# (as cups is now used in linux-mandrake 7.2 by default)

# if you want to automatically load your printer list rather

# than setting them up individually then you’ll need this

printcap name = cups

Продолжение приложения А

load printers = yes

# It should not be necessary to spell out the print system type unless

# yours is non-standard. Currently supported print systems include:

# bsd, sysv, plp, lprng, aix, hpux, qnx, cups

printing = cups

# Samba 2.2 supports the Windows NT-style point-and-print feature. To

# use this, you need to be able to upload print drivers to the samba

# server. The printer admins (or root) may install drivers onto samba.

# Note that this feature uses the print$ share, so you will need to

# enable it below.

# printer admin = @

; printer admin = @adm

# This should work well for winbind:

printer admin = @" Domain Admins"

# 3. Logging Options:

# this tells Samba to use a separate log file for each machine

# that connects

log file = /var/log/samba/log.%m

# Put a capping on the size of the log files (in Kb).

max log size = 50

# Set the log (verbosity) level (0 <= log level <= 10)

; log level = 3

# 4. Security and Domain Membership Options:

# This option is important for security. It allows you to restrict

# connections to machines which are on your local network. The

# following example restricts access to two C class networks and

# the «loopback» interface. For more examples of the syntax see

# the smb. conf man page. Do not enable this if (tcp/ip) name resolution does

# not work for all the hosts in your network.

; hosts allow = 192.168.1. 192.168.2. 127.

# Uncomment this if you want a guest account, you must add this to /etc/passwd

# otherwise the user «nobody» is used

; guest account = pcguest

# Allow users to map to guest:

map to guest = bad user

# Security mode. Most people will want user level security. See

# security_level.txt for details.

security = domain

# Use password server option only with security = server or security = domain

# When using security = domain, you should use password server = *

; password server =

password server = *

# Password Level allows matching of _n_ characters of the password for

# all combinations of upper and lower case.

; password level = 8

; username level = 8

# You may wish to use password encryption. Please read

# ENCRYPTION. txt, Win95. txt and WinNT. txt in the Samba documentation.

# Do not enable this option unless you have read those documents

# Encrypted passwords are required for any use of samba in a Windows NT domain

# The smbpasswd file is only required by a server doing authentication, thus

# members of a domain do not need one.

encrypt passwords = yes

smb passwd file = /etc/samba/smbpasswd

# The following are needed to allow password changing from Windows to

# also update the Linux system password.

# NOTE: Use these with 'encrypt passwords' and 'smb passwd file' above.

# NOTE2: You do NOT need these to allow workstations to change only

# the encrypted SMB passwords. They allow the Unix password

# to be kept in sync with the SMB password.

; unix password sync = Yes

# You either need to setup a passwd program and passwd chat, or

# enable pam password change

; pam password change = yes

; passwd program = /usr/bin/passwd %u

; passwd chat = *New*UNIX*password* %nn *Re*ype*new*UNIX*password* %nn

;*passwd:*all*authentication*tokens*updated*successfully*

# Unix users can map to different SMB User names

; username map = /etc/samba/smbusers

# Using the following line enables you to customise your configuration

# on a per machine basis. The %m gets replaced with the netbios name

# of the machine that is connecting

; include = /etc/samba/smb.conf.%m

# Options for using winbind. Winbind allows you to do all account and

# authentication from a Windows or samba domain controller, creating

# accounts on the fly, and maintaining a mapping of Windows RIDs to unix uid’s

# and gid’s. winbind uid and winbind gid are the only required parameters.

#

# winbind uid is the range of uid’s winbind can use when mapping RIDs to uid’s

winbind uid = 10 000−20 000

#

# winbind gid is the range of uid’s winbind can use when mapping RIDs to gid’s

winbind gid = 10 000−20 000

#

# winbind separator is the character a user must use between their domain

# name and username, defaults to «»

winbind separator = +

#

# winbind use default domain allows you to have winbind return usernames

# in the form user instead of DOMAIN+user for the domain listed in the

# workgroup parameter.

winbind use default domain = yes

#

# template homedir determines the home directory for winbind users, with

# %D expanding to their domain name and %U expanding to their username:

template homedir = /home/%D/%U

# When using winbind, you may want to have samba create home directories

# on the fly for authenticated users. Ensure that /etc/pam.d/samba is

# using 'service=system-auth-winbind' in pam_stack modules, and then

# enable obedience of pam restrictions below:

obey pam restrictions = yes

#

# template shell determines the shell users authenticated by winbind get

template shell = /bin/bash

# 5. Browser Control and Networking Options:

# Most people will find that this option gives better performance.

# See speed. txt and the manual pages for details

socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192

# Configure Samba to use multiple interfaces

# If you have multiple network interfaces then you must list them

# here. See the man page for details.

; interfaces = 192.168.12.2/24 192.168.13.2/24

# Configure remote browse list synchronisation here

# request announcement to, or browse list sync from:

# a specific host or from / to a whole subnet (see below)

; remote browse sync = 192.168.3.25 192.168.5.255

# Cause this host to announce itself to local subnets here

; remote announce = 192.168.1.255 192.168.2.44

# set local master to no if you don’t want Samba to become a master

# browser on your network. Otherwise the normal election rules apply

; local master = no

# OS Level determines the precedence of this server in master browser

# elections. The default value should be reasonable

; os level = 33

# Domain Master specifies Samba to be the Domain Master Browser. This

# allows Samba to collate browse lists between subnets. Don’t use this

# if you already have a Windows NT domain controller doing this job

; domain master = yes

# Preferred Master causes Samba to force a local browser election on startup

# and gives it a slightly higher chance of winning the election

; preferred master = yes

# 6. Domain Control Options:

# Enable this if you want Samba to be a domain logon server for

# Windows95 workstations or Primary Domain Controller for WinNT and Win2k

; domain logons = yes

# if you enable domain logons then you may want a per-machine or

# per user logon script

# run a specific logon batch file per workstation (machine)

; logon script = %m.bat

# run a specific logon batch file per username

; logon script = %U.bat

# Where to store roaming profiles for WinNT and Win2k

# %L substitutes for this servers netbios name, %U is username

# You must uncomment the [Profiles] share below

; logon path = \%LProfiles%U

# Where to store roaming profiles for Win9x. Be careful with this as it also

# impacts where Win2k finds it’s /HOME share

; logon home = \%L%U.profile

# The add user script is used by a domain member to add local user accounts

# that have been authenticated by the domain controller, or when adding

# users via the Windows NT Tools (ie User Manager for Domains).

# Scripts for file (passwd, smbpasswd) backend:

; add user script = /usr/sbin/useradds /bin/false '%u'

; delete user script = /usr/sbin/userdel '%s'

; add user to group script = /usr/bin/gpasswda '%u' '%g'

; delete user from group script = /usr/bin/gpasswdd '%u' '%g'

; set primary group script = /usr/sbin/usermodg '%g' '%u'

; add group script = /usr/sbin/groupadd %g && getent group '%g'|awkF: '{print $ 3}'

; delete group script = /usr/sbin/groupdel '%g'

# Scripts for LDAP backend (assumes nss_ldap is in use on the domain controller,

# and needs configuration in smbldap_conf.pm

; add user script = /usr/share/samba/scripts/smbldap-useradd.pl '%u'

; delete user script = /usr/share/samba/scripts/smbldap-userdel.pl '%u'

; add user to group script = /usr/share/samba/scripts/smbldap-groupmod.plm '%u' '%g'

; delete user from group script = /usr/share/samba/scripts/smbldap-groupmod.plx '%u' '%g'

; set primary group script = /usr/share/samba/scripts/smbldap-usermod.plg '%g' '%u'

; add group script = /usr/share/samba/scripts/smbldap-groupadd.pl '%g' && /usr/share/samba/scripts/smbldap-groupshow.pl %g|awk '/^gidNumber:/ {print $ 2}'

; delete group script = /usr/share/samba/scripts/smbldap-userdel.pl '%g'

# The add machine script is use by a samba server configured as a domain

# controller to add local machine accounts when adding machines to the domain.

# The script must work from the command line when replacing the macros,

# or the operation will fail. Check that groups exist if forcing a group.

# Script for domain controller for adding machines:

; add machine script = /usr/sbin/useraddd /dev/nullg machinesc 'Machine Account' -s /bin/falseM %u

# Script for domain controller with LDAP backend for adding machines (please

# configure in /etc/samba/smbldap_conf.pm first):

; add machine script = /usr/share/samba/scripts/smbldap-useradd.plw -d /dev/nullg machinesc 'Machine Account' -s /bin/false %u

# Domain groups:

# Domain groups are now configured by using the 'net groupmap' tool

# Samba Password Database configuration:

# Samba now has runtime-configurable password database backends. Multiple

# passdb backends may be used, but users will only be added to the first one

# Default:

; passdb backend = smbpasswd guest

# TDB backen with fallback to smbpasswd and guest

; passdb backend = tdbsam smbpasswd guest

# LDAP with fallback to smbpasswd guest

# Enable SSL by using an ldaps url, or enable tls with 'ldap ssl' below.

; passdb backend = ldapsam: ldaps://ldap.mydomain.com smbpasswd guest

# Use the samba2 LDAP schema:

; passdb backend = ldapsam_compat:ldaps://ldap.mydomain.com smbpasswd guest

# Idmap settings:

# Idmap backend to use:

; idmap backend = ldap: ldap://ldap.mydomain.com

# This is a range of unix user-id's that samba will map non-unix RIDs to,

# such as when using Winbind

; idmap uid = 10 000−20 000

; idmap gid = 10 000−20 000

# LDAP configuration for Domain Controlling:

# The account (dn) that samba uses to access the LDAP server

# This account needs to have write access to the LDAP tree

# You will need to give samba the password for this dn, by

# running 'smbpasswdw mypassword'

; ldap admin dn = cn=root, dc=mydomain, dc=com

; ldap ssl = start_tls

# start_tls should run on 389, but samba defaults incorrectly to 636

; ldap port = 389

; ldap suffix = dc=mydomain, dc=com

# Seperate suffixes are available for machines, users, groups, and idmap, if

# ldap suffix appears first, it is appended to the specific suffix.

# Example for a unix-ish directory layout:

; ldap machine suffix = ou=Hosts

; ldap user suffix = ou=People

; ldap group suffix = ou=Group

; ldap idmap suffix = ou=Idmap

# Example for AD-ish layout:

; ldap machine suffix = cn=Computers

; ldap user suffix = cn=Users

; ldap group suffix = cn=Groups

; ldap idmap suffix = cn=Idmap

# 7. Name Resolution Options:

# All NetBIOS names must be resolved to IP Addresses

# 'Name Resolve Order' allows the named resolution mechanism to be specified

# the default order is «host lmhosts wins bcast». «host» means use the unix

# system gethostbyname () function call that will use either /etc/hosts OR

# DNS or NIS depending on the settings of /etc/host.config, /etc/nsswitch.conf

# and the /etc/resolv.conf file. «host» therefore is system configuration

# dependant. This parameter is most often of use to prevent DNS lookups

# in order to resolve NetBIOS names to IP Addresses. Use with care!

# The example below excludes use of name resolution for machines that are NOT

# on the local network segment

# - OR — are not deliberately to be known via lmhosts or via WINS.

; name resolve order = wins lmhosts bcast

# Windows Internet Name Serving Support Section:

# WINS Support — Tells the NMBD component of Samba to enable it’s WINS Server

; wins support = yes

# WINS Server — Tells the NMBD components of Samba to be a WINS Client

# Note: Samba can be either a WINS Server, or a WINS Client, but NOT both

; wins server = w.x.y.z

# WINS Proxy — Tells Samba to answer name resolution queries on

# behalf of a non WINS capable client, for this to work there must be

# at least one WINS Server on the network. The default is NO.

; wins proxy = yes

# DNS Proxy — tells Samba whether or not to try to resolve NetBIOS names

# via DNS nslookups. The built-in default for versions 1.9.17 is yes,

# this has been changed in version 1.9.18 to no.

dns proxy = no

# 8. File Naming Options:

# Case Preservation can be handy — system default is _no_

# NOTE: These can be set on a per share basis

; preserve case = no

; short preserve case = no

# Default case is normally upper case for all DOS files

; default case = lower

# Be very careful with case sensitivity — it can break things!

; case sensitive = no

# Enabling internationalization:

# you can match a Windows code page with a UNIX character set.

# Windows: 437 (US), 737 (GREEK), 850 (Latin1 — Western European),

# 852 (Eastern Eu.), 861 (Icelandic), 932 (Cyrillic — Russian),

# 936 (Japanese — Shift-JIS), 936 (Simpl. Chinese), 949 (Korean Hangul),

# 950 (Trad. Chin.).

# UNIX: ISO8859−1 (Western European), ISO8859−2 (Eastern Eu.),

# ISO8859−5 (Russian Cyrillic), KOI8-R (Alt-Russ. Cyril.)

# This is an example for french users:

; dos charset = 850

; unix charset = ISO8859−1

#================ Share Definitions ===================

[homes]

comment = Home Directories

browseable = no

writable = yes

# You can enable VFS recycle bin on a per share basis:

# Uncomment the next 2 lines (make sure you create a

# .recycle folder in the base of the share and ensure

# all users will have write access to it. See

# examples/VFS/recycle/REAME in samba-doc for details

; vfs object = /usr/lib/samba/vfs/recycle.so

# Un-comment the following and create the netlogon directory for Domain Logons

; [netlogon]

; comment = Network Logon Service

; path = /var/lib/samba/netlogon

; guest ok = yes

; writable = no

#Uncomment the following 2 lines if you would like your login scripts to

#be created dynamically by ntlogon (check that you have it in the correct

#location (the default of the ntlogon rpm available in contribs)

;root preexec = /usr/bin/ntlogonu %Ug %Go %ad /var/lib/samba/netlogon

;root postexec = rmf /var/lib/samba/netlogon/%U.bat

# Un-comment the following to provide a specific roving profile share

# the default is to use the user’s home directory

;[Profiles]

; path = /var/lib/samba/profiles

; browseable = no

; guest ok = yes

# This script can be enabled to create profile directories on the fly

# You may want to turn off guest acces if you enable this, as it

# hasn’t been thoroughly tested.;root preexec = PROFILE=/var/lib/samba/profiles/%u; if [ ! -e $PROFILE ];

; then mkdirpm700 $PROFILE; chown %u.%g $PROFILE;fi

# NOTE: If you have a CUPS print system there is no need to

# specifically define each individual printer.

# You must configure the samba printers with the appropriate Windows

# drivers on your Windows clients or upload the printer driver to the

# server from Windows (NT/2000/XP). On the Samba server no filtering is

# done. If you wish that the server provides the driver and the clients

# send PostScript («Generic PostScript Printer» under Windows), you have

# to use 'printcap name = cups' or swap the 'print command' line below

# with the commented one. Note that print commands only work if not using

# 'printing=cups'

[printers]

comment = All Printers

path = /var/spool/samba

browseable = no

# to allow user 'guest account' to print.

guest ok = yes

writable = no

printable = yes

create mode = 0700

# =====================================

# print command: see above for details.

# =====================================

print command = lpr-cupsP %po raw %sr # using client side printer drivers.

; print command = lpr-cupsP %p %s # using cups own drivers (use generic PostScript on clients).

# This share is used for Windows NT-style point-and-print support.

# To be able to install drivers, you need to be either root, or listed

# in the printer admin parameter above. Note that you also need write access

# to the directory and share definition to be able to upload the drivers.

# For more information on this, please see the Printing Support Section of

# /usr/share/doc/samba-/docs/Samba-HOWTO-Collection.pdf

#

# A special case is using the CUPS Windows Postscript driver, which allows

# all features available via CUPS on the client, by publishing the ppd file

# and the cups driver by using the 'cupsaddsmb' tool. This requires the

# installation of the CUPS driver (http://www.cups.org/windows.php)

# on the server, but doesn’t require you to use Windows at all :-).

[print$]

path = /var/lib/samba/printers

browseable = yes

write list = @adm root

guest ok = yes

inherit permissions = yes

# Settings suitable for Winbind:

; write list = @" Domain Admins" root

; force group = +@" Domain Admins"

# A useful application of samba is to make a PDF-generation service

# To streamline this, install windows postscript drivers (preferably colour)

# on the samba server, so that clients can automatically install them.

# Note that this only works if 'printing' is *not* set to 'cups'

[pdf-generator]

path = /var/tmp

guest ok = No

printable = Yes

comment = PDF Generator (only valid users)

#print command = /usr/share/samba/scripts/print-pdf file path win_path recipient IP &

print command = /usr/share/samba/scripts/print-pdf %s ~%u //%L/%u %m %I «%J» &

# This one is useful for people to share files

;[tmp]

; comment = Temporary file space

; path = /tmp

; read only = no

; public = yes

# A publicly accessible directory, but read only, except for people in

# the «staff» group

;[public]

; comment = Public Stuff

; path = /home/samba/public

; public = yes

; writable = no

; write list = @staff

# Audited directory through experimental VFS audit. so module:

# Uncomment next line.

; vfs object = /usr/lib/samba/vfs/audit.so

# Other examples.

#

# A private printer, usable only by Fred. Spool data will be placed in Fred’s

# home directory. Note that fred must have write access to the spool directory,

# wherever it is.

;[fredsprn]

; comment = Fred’s Printer

; valid users = fred

; path = /homes/fred

; printer = freds_printer

; public = no

; writable = no

; printable = yes

# A private directory, usable only by Fred. Note that Fred requires write

# access to the directory.

;[fredsdir]

; comment = Fred’s Service

; path = /usr/somewhere/private

; valid users = fred

; public = no

; writable = yes

; printable = no

# a service which has a different directory for each machine that connects

# this allows you to tailor configurations to incoming machines. You could

# also use the %u option to tailor it by user name.

# The %m gets replaced with the machine name that is connecting.

;[pchome]

; comment = PC Directories

; path = /usr/pc/%m

; public = no

; writable = yes

# A publicly accessible directory, read/write to all users. Note that all files

# created in the directory by users will be owned by the default user, so

# any user with access can delete any other user’s files. Obviously this

# directory must be writable by the default user. Another user could of course

# be specified, in which case all files would be owned by that user instead.

;[public]

; path = /usr/somewhere/else/public

; public = yes

; only guest = yes

; writable = yes

; printable = no

# The following two entries demonstrate how to share a directory so that two

# users can place files there that will be owned by the specific users. In this

# setup, the directory should be writable by both users and should have the

# sticky bit set on it to prevent abuse. Obviously this could be extended to

# as many users as required.

;[myshare]

; comment = Mary’s and Fred’s stuff

; path = /usr/somewhere/shared

; valid users = mary fred

; public = no

; writable = yes

; printable = no

; create mask = 0765

Процесс настройки Microsoft Virtual PC

Установите VirtualPC и запустите программу. При первом запуске должен появиться мастер настройки. Если он не появился, то в главном окне Нажмите кнопку New. Нажмите Next в первом окне, и следующее окно будет выглядеть так:

Выберите «Create a Virtual Machine» и нажмите Next. На следующем шаге вы должны выбрать название виртуальной машины.

Следущее окно позволяет вам выбрать тип операционной системы. Рекомендуется Windows 2000, т.к. это поможет избежать напоминания об активации Windows.

Вы можете выбрать количество оперативной памяти, с которым будет работать виртуальная машина. Можно оставить настройки по умолчанию.

Далее укажите, что вы хотите создать новый виртуальный жесткий диск.

Следующий этап указывает расположение виртуального жесткого диска. Можно оставить по умолчанию.

Настройка окончена. Вы видите последнее окно мастера. Нажмите Finish.

Теперь вы вновь должны оказаться в главном окне программы. Выберите виртуальную машину, которую вы только что создали, и нажмите Start.

Когда появится новое окно, выберите CD из ниспадающего меню наверху далее выберите «Capture ISO Image…». Выберите ISO образ, который вы создали.

Если программа выдает ошибку, то вероятно ваш образ более 2 Гб, и VirtualPC не поддерживает такие образы. Придется использовать обходной путь. Смонтируйте ISO образ при помощи сторонних програм, таких как Daemon Tools (freeware) или Alcohol. После того, как образ смонтирован, в меню CD выберите букву соответствующую образу букву диска вместо «Capture ISO image…» .