Общие положения теории эмуляторов, технические характеристики наиболее популярных продуктов. Организация учебного класса на основе выбранной версии продукта. Характеристики платформ для реализации задачи и нормального функционирования виртуальных машин.
При низкой оригинальности работы "Проектирование и построение учебного класса на основе виртуальных машин", Вы можете повысить уникальность этой работы до 80-100%
Виртуальной машиной (англ. virtual machine) называют программную или аппаратную среду, исполняющую некоторый код (например, байт-код, шитый код, p-code или машинный код реального процессора), или спецификацию такой системы. На виртуальную машину, так же как и на реальный компьютер можно инсталлировать операционную систему, у виртуальной машины так же есть BIOS, оперативная память, жесткий диск (выделенное место на жестком диске реального компьютера), могут эмулироваться периферийные устройства. С помощью средства управления виртуальными машинами можно загрузить в выделенное адресное пространство образ операционной системы виртуальной машины (такая операционная система носит название Guest Operating System - гостевая операционная система, в отличие от исходной операционной системы, носящей название Host Operating System - операционная система хоста). Сам продукт выполняется под управлением 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 (рис. Операционные системы для виртуальных машин, полностью поддерживаемые данным продуктом, включают бета-версии 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.Однако ввиду несовершенности аппаратных средств того времени, они получили применение намного позднее. Несмотря на это, в последнее время наблюдается обратный процесс, когда многие концепции “золотого века” кибернетики пересматриваются и находят применение в современных информационных технологиях. Также как и цель данной работы - т.е. ограничение физической системы от повреждений, в результате чего, учащиеся, при изучении упомянутых в этой работе дисциплин, получают возможность проводить с виртуальными системами различные эксперименты, не ограничиваясь одной лишь теорией, без опасения повредить работающую систему. Еще на заре информатизации, когда большая часть работ и исследований в этой области носили теоретический характер, была доказана принципиальная эквивалентность определения понятия вычислимости функции или алгоритма, реализуемого для абстрактных вычислительных машин (например, машин Тьюринга, Маркова, Поста и т.д.). Таким образом, после доказательства соответствующих теорем было открыто широкое поле для реализации программных эмуляторов, которые, взяв за основу систему команд и архитектуру одной вычислительной машины, позволяли "поверх" нее имитировать работу другого вычислителя.
Введение
Новые информационные технологии представляют собой инструмент, позволяющий качественно изменить методы и организационные формы деятельности преподавателя. Благодаря современным технологиям стало возможным использовать операционные системы, созданные для крупных серверных машин, других платформ в учебных классах оснащенных обычными персональными компьютерами. Сейчас, благодаря технологии виртуализации, при изучении компьютерных дисциплин, таких как, низкоуровневое программирование, изучение “экзотических” операционных систем, студенты имеют возможность применить полученные знания на практике и поработать с изучаемой операционной системой не выходя за пределы учебного класса. Нет нужды закупать дорогостоящее оборудование для лабораторий. Виртуальная машина, эмулирующая любую аппаратную платформу и любую операционную систему может быть установлена на персональный компьютер.
Разработчики виртуальных машин, говоря о сферах применения своих продуктов и называя такие из них как тестирование приложений и разработка системного программного обеспечения, обходят вопрос о применении виртуальных машин и эмуляторов в сфере компьютерного обучения.
В связи с этим актуальным является проведение анализа различных версий программных эмуляторов (виртуальных машин) для ПК и выбор наиболее подходящего варианта для построения учебного класса на основе виртуальных машин.
Целью настоящей работы является проектирование и создание учебного класса на основе виртуальных машин для изучения следующих дисциплин: - установка и конфигурирование 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, VM/ХА, VN/ESA) и стала самой распространенной в компьютерной индустрии.
В операционной системе VM/370 пользователь получал в свое распоряжение полноразмерный и полнофункциональный виртуальный компьютер, на который он мог поставить собственную версию операционной системы и установить собственное прикладное программное обеспечение. Этот компьютер включал оперативную память, ресурсы процессора, собственные виртуальные периферийные устройства - практически все то, чем обладает обычный компьютер, только в виртуальном виде. Количество обслуживаемых виртуальных компьютеров определялось лицензией, доступными ресурсами памяти, диска, центрального процессора и т.д.
Операционная система VM/370 стала прототипом для отечественной разработки системы СВМ (система виртуальных машин). Первая версия системы СВМ 1.1 была выпущена в1982 году комбинатом "Роботрон". В 1983 г. операционную систему СВМ 2.2, базирующуюся на шестом релизе VM/370, выпустил Минский НИИЭВМ. С этого момента система СВМ, не подменяя систем ДОС и ОС, заняла прочное место в базовом программном обеспечении для ЕС ЭВМ. В качестве операционной системы, управляющей работой виртуальной машины, могли использоваться любые операционные системы, разработанные для ЕС ЭВМ (например, ОС ЕС, ДОС ЕС и МОС ЕС).
Совершенствование СВМ в НИИЭВМ в начале 90-х годов привело к разработке операционной системы VM/СВМ. Минская компания ІВА, основанная компанией IBM на базе МПО ВТ и НИИЭВМ, до сих пор ведет разработку новых изданий VM/СВМ для мэйнфреймов ІВМ.
Инженеры корпорации 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, предоставляемым операционной системой. Если две операционные системы совместимы по своим АРІ (например, Windows 98 и Windows 2000), то приложения, разработанные для одной из них, будут работать и на другой. Если две операционные системы несовместимы по своим API (например, Windows 2000 и Linux), то существует способ перехватить обрашения приложений к АРІ и сымитировать поведение одной операционной сисгемы средствами другой операционной системы.
При таком подходе можно поставить одну операционную систему и работать одновременно как с ее приложениями, так и с приложениями друтой операционной системы. Поскольку весь код приложения исполняется без эмуляции и лишь вызовы API эмулируются, потеря в производительности незначительная. Но изза того, что многие приложения используют недокументированные функции API или обращаются к операционной системе в обход API, даже очень хорошие эмуляторы API имеют проблемы совместимости и позволяют запустить не более 70% от общего числа приложений. Кроме того, поддерживать эмуляцию API бурно развиваюищейся операционной системы (например, такой как Windows) очень нелегко, и большинство эмуляторов АРІ так и остаются эмуляторами какой-то конкретной версии операционной системы. Так, в 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 (UML), позволяющий запускать несколько копий операционной системы Linux на одном компьютере(в настоящее время встроен в ядро Linux версий 2.6);
- технология Virtuozzo, разработанная российской компанией SWSOFT и позволяющая запускать несколько копий операционной системы Linux на одном компьютере;
- технология, используемая во FREEBSD для запуска приложений Linux.
Проект SOFTPEAR, в перспективе позволяющий запускать приложения Mac OS X на Linux и FREEBSD
1.3.2 Полная эмуляция
Проекты, выполненные по технологии полной эмуляции работают как интерпретаторы. Они последовательно выбирают код гостевой операционной системы и эмулируют поведение каждой отдельно взятой инструкции. Поскольку при этом полностью эмулируется поведение как процессора, так и всех внешних устройств виртуального Intel х86 компьютера, то существует возможность запускать эмулятор на компьютерах с совершенно другой архитектурой, например, на рабочих станциях Мас или на 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/XP, 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
Средство управления виртуальными машинами 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 Минимальные требования различных операционных систем для их выполнения под управлением виртуальных машин
Операционная система виртуальной машины Оперативная Память (Мб) Пространство на жестком диске (Мб)
MS-DOS 6.22 32 50
Windows 95 32 500
Windows 98 Se 64 500
Windows Me 96 2048
Windows NT Workstation SP6 32 500
Windows 2000 Professional 96 2048
Windows XP Home Edition 128 2048
Windows XP Professional 128 2048
OS/2 Warp Version 4 Fix Pack 15 64 500
Из иных особенностей работы с дисками следует обратить внимание на средства коллективной работы с одним и тем же образом жесткого диска с сохранением изменений отдельно для каждого пользователя, а также на возможность отмены всех изменений, сделанных пользователем в данном сеансе работы (последняя функция особенно полезна при тестировании инсталляционных приложений). Отметим также, что предусмотрено сохранение состояния виртуальной машины - в этом случае при ее повторном старте операционная система окажется уже загруженной, а приложения - запущенными.
Из параметров, доступных для конфигурации, следует назвать долю процессорного времени, потребляемую виртуальной машиной, средства сетевого доступа, конфигурацию дисководов, цветовое разрешение, правила захвата мыши при щелчке в окне виртуальной машины, а также правила безопасности, позволяющие заблокировать те или иные возможности манипуляции виртуальными машинами для пользователей, не имеющих административных прав (рис. 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 PC, а в сумме память, занимаемая всеми одновременно запущенными виртуальными машинами, не должна превышать 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, виртуал
Вывод
Следует заметить, что применяемые в данной работе технологии, в частности технология виртуализации, были разработаны сравнительно давно. Теоретические основы были подготовлены ведущими математиками еще в начале прошлого века. Однако ввиду несовершенности аппаратных средств того времени, они получили применение намного позднее.
На каком-то этапе эволюции архитектуры вычислительных машин отказ от многих блестящих идей прошлого стал исторической необходимостью. Несмотря на это, в последнее время наблюдается обратный процесс, когда многие концепции “золотого века” кибернетики пересматриваются и находят применение в современных информационных технологиях.
Одной из главных функций виртуализации является защита физической системы от случайных сбоев, ошибочных действий пользователя, а также намеренных попыток вывести ее из строя. Среда, в которой, работает пользователь, а также приложения пользовательского уровня, в данном случае, являются максимально абстрагированными от физической среды системы. В течении всего времени с момента возникновения виртуальные машины использовались на практике для этой цели. Все остальные сферы применения проистекают отсюда. Также как и цель данной работы - т.е. ограничение физической системы от повреждений, в результате чего, учащиеся, при изучении упомянутых в этой работе дисциплин, получают возможность проводить с виртуальными системами различные эксперименты, не ограничиваясь одной лишь теорией, без опасения повредить работающую систему.
Применение виртуальных машин дает различным категориям пользователей - от начинающих до 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.
