Системная виртуальная машина
![]() | Эта статья включает список общих ссылок , но в ней отсутствуют достаточные соответствующие встроенные цитаты . ( февраль 2015 г. ) |
В вычислительной технике системная виртуальная машина — это виртуальная машина (ВМ), которая предоставляет полную системную платформу и поддерживает выполнение полной операционной системы (ОС). [1] Они обычно эмулируют существующую архитектуру и создаются с целью либо предоставить платформу для запуска программ, где реальное оборудование недоступно для использования (например, выполнение на устаревших платформах), либо иметь несколько экземпляров виртуальных машин, ведущих к более эффективному использованию вычислительных ресурсов, как с точки зрения энергопотребления, так и с точки зрения экономической эффективности (известная как аппаратная виртуализация , ключ к среде облачных вычислений ), или и то, и другое. Первоначально виртуальная машина была определена Попеком и Голдбергом как «эффективная изолированная копия реальной машины».
Системные виртуальные машины [ править ]
Преимущества системной виртуальной машины:
- Несколько сред ОС могут сосуществовать на одном и том же основном жестком диске с виртуальным разделом, который позволяет совместно использовать файлы, созданные либо в «хостовой» операционной системе, либо в «гостевой» виртуальной среде. Установка дополнительного программного обеспечения, беспроводное подключение и удаленная репликация, например печать и отправка факсов, могут быть созданы в любой гостевой или хостовой операционной системе. Независимо от системы, все файлы хранятся на жестком диске хостовой ОС.
- Предоставление приложений, обслуживание, высокая доступность и аварийное восстановление присущи выбранному программному обеспечению виртуальной машины.
- Может обеспечить эмулируемую хоста аппаратную среду, отличную от архитектуры набора команд (ISA), посредством эмуляции или использования JIT-компиляции .
Основными недостатками виртуальных машин являются:
- Виртуальная машина менее эффективна, чем реальная машина, когда она обращается к жесткому диску хоста косвенно.
- Когда на жестком диске фактического хоста одновременно работают несколько виртуальных машин, дополнительные виртуальные машины могут иметь различную и/или нестабильную производительность (скорость выполнения и защита от вредоносных программ). Это зависит от нагрузки данных, налагаемой на систему другими виртуальными машинами, если только выбранное программное обеспечение виртуальной машины не обеспечивает временную изоляцию между виртуальными машинами .
- Защита от вредоносного ПО для виртуальных машин не обязательно совместима с «хостом» и может потребовать отдельного программного обеспечения.
Несколько виртуальных машин с собственной гостевой операционной системой часто используются для консолидации серверов, чтобы избежать помех со стороны отдельных виртуальных машин на одной и той же платформе.
Желание запускать несколько операционных систем было первоначальной мотивацией для виртуальных машин, чтобы обеспечить разделение времени между несколькими однозадачными операционными системами. В некотором отношении системную виртуальную машину можно считать обобщением концепции виртуальной памяти , исторически предшествовавшей ей. IBM CP/CMS , первые системы, допускающие полную виртуализацию , реализовали разделение времени , предоставив каждому пользователю однопользовательскую операционную систему, CMS . В отличие от виртуальной памяти, системная виртуальная машина дает пользователю право писать привилегированные инструкции в своем коде. Этот подход имел определенные преимущества, например, добавление устройств ввода/вывода, не разрешенных стандартной системой. [2]
Поскольку технология развивает виртуальную память для целей виртуализации, новые системы избыточного выделения памяти могут применяться для управления разделением памяти между несколькими виртуальными машинами в одной реальной компьютерной операционной системе. Возможно совместное использование «страниц памяти» с идентичным содержимым среди нескольких виртуальных машин, работающих на одной физической машине, что может привести к сопоставлению их с одной и той же физической страницей с помощью метода, известного как слияние одинаковых страниц ядра . Это особенно полезно для страниц, доступных только для чтения, например тех, которые содержат сегменты кода; в частности, это будет иметь место для нескольких виртуальных машин, на которых выполняется одно и то же или похожее программное обеспечение, библиотеки программного обеспечения, веб-серверы, компоненты промежуточного программного обеспечения и т. д. Гостевые операционные системы не обязательно должны быть совместимы с аппаратным обеспечением хоста, что позволяет запускать разные операционные системы на одном компьютере (например, Microsoft Windows , Linux или предыдущие версии операционной системы) для поддержки будущего программного обеспечения.
Использование виртуальных машин для поддержки отдельных гостевых операционных систем популярно в отношении встраиваемых систем . Типичным использованием будет запуск операционной системы реального времени одновременно с предпочтительной сложной операционной системой, такой как Linux или Windows. Другое применение — новое и непроверенное программное обеспечение, которое все еще находится на стадии разработки и работает в « песочнице» . Виртуальные машины имеют и другие преимущества для разработки операционных систем, включая улучшенный доступ для отладки и более быструю перезагрузку. [3]
Техники [ править ]
В зависимости от желаемого использования используются различные методы виртуализации. Собственное исполнение основано на прямой виртуализации базового аппаратного обеспечения, таким образом, оно предоставляет несколько «экземпляров» той же архитектуры , на которой основана реальная машина, способных запускать полноценные операционные системы. Некоторые виртуальные машины также могут эмулировать различные архитектуры и позволять выполнять программные приложения и операционные системы, написанные для другого процессора или архитектуры. Виртуализация на уровне операционной системы позволяет разделить ресурсы компьютера посредством ядра поддержки для нескольких изолированных экземпляров пользовательского пространства , которые обычно называются контейнерами и могут выглядеть и ощущаться для конечных пользователей как настоящие машины . Некоторые компьютерные архитектуры поддерживают аппаратную виртуализацию , что обеспечивает эффективную полную виртуализацию за счет использования аппаратных возможностей, специфичных для виртуализации, в первую очередь центральных процессоров.
Виртуализация базового оборудования ( собственное исполнение )
Этот подход описывается как полная виртуализация оборудования и может быть реализован с использованием гипервизора типа 1 или типа 2 : гипервизор типа 1 работает непосредственно на оборудовании, а гипервизор типа 2 работает в другой операционной системе, например Linux или Windows. . На каждой виртуальной машине может работать любая операционная система, поддерживаемая базовым оборудованием. Таким образом, пользователи могут одновременно запускать две или более разных «гостевых» операционных систем на отдельных «частных» виртуальных компьютерах.
Пионерской системой, использующей эту концепцию, была IBM CP-40 , первая (1967 г.) версия IBM CP/CMS (1967–1972 г.) и предшественник семейства IBM VM (с 1972 г. по настоящее время). Благодаря архитектуре VM большинство пользователей запускают относительно простую интерактивных вычислений однопользовательскую операционную систему CMS в качестве «гостя» поверх программы управления VM ( VM-CP ). Такой подход сохранял простоту конструкции CMS, как если бы она работала отдельно; программа управления незаметно предоставляет услуги многозадачности и управления ресурсами «за кулисами». В дополнение к связи CMS и другим системным задачам выполняются многозадачные виртуальные машины (RSCS, GCS, TCP/IP, UNIX), и пользователи могут запускать любую другую операционную систему IBM, например MVS , даже сам новый CP или теперь z /ОС . Даже простую CMS можно запускать в многопоточной среде (LISTSERV, TRICKLE). z/VM — это текущая версия VM, которая используется для поддержки сотен или тысяч виртуальных машин на данном мейнфрейме. используется В некоторых установках Linux на IBM Z для запуска веб-серверов , где Linux работает как операционная система на многих виртуальных машинах.
Полная виртуализация особенно полезна при разработке операционных систем, когда экспериментальный новый код можно запускать одновременно со старыми, более стабильными версиями, причем каждая на отдельной виртуальной машине. Процесс может быть даже рекурсивным : IBM отлаживала новые версии своей операционной системы виртуальной машины VM на виртуальной машине, работающей под управлением более старой версии VM, и даже использовала эту технику для моделирования нового оборудования. [Примечание 1]
Стандартная x86 архитектура набора команд , используемая в современных ПК, фактически не отвечает требованиям виртуализации Попека и Голдберга . Примечательно, что не существует режима выполнения, в котором всегда перехватываются все конфиденциальные машинные инструкции, что позволило бы виртуализировать каждую инструкцию.
Несмотря на эти ограничения, нескольким пакетам программного обеспечения удалось обеспечить виртуализацию на архитектуре x86 , хотя динамическая перекомпиляция привилегированного кода, впервые реализованная VMware , влечет за собой некоторые издержки производительности по сравнению с виртуальной машиной, работающей на изначально виртуализуемой архитектуре, такой как IBM. System/370 или Motorola MC68020 . К настоящему времени нескольким другим пакетам программного обеспечения, таким как Virtual PC , VirtualBox , Parallels Workstation и Virtual Iron, удается реализовать виртуализацию на оборудовании x86.
Intel и AMD добавили в свои процессоры x86 функции , обеспечивающие аппаратную виртуализацию .
Помимо виртуализации ресурсов одной машины, несколько независимых узлов в кластере могут быть объединены и доступны как одна виртуальная NUMA- машина. [4]
Эмуляция неродной системы [ править ]
Виртуальные машины также могут выполнять роль эмулятора , позволяя программные приложения и операционные системы, написанные для другой архитектуры процессора компьютера запускать .
Виртуализация на уровне операционной системы [ править ]
Виртуализация на уровне операционной системы — это технология виртуализации серверов , которая виртуализирует серверы на уровне операционной системы (ядра). Это можно рассматривать как разделение: один физический сервер делится на несколько небольших разделов (также называемых виртуальными средами (VE), виртуальными частными серверами (VPS), гостями, зонами и т. д.); каждый такой раздел выглядит и ощущается как настоящий сервер с точки зрения его пользователей.
Например, Solaris Zones поддерживает несколько гостевых операционных систем, работающих под одной и той же операционной системой, например Solaris 10. [5] Гостевые операционные системы могут использовать один и тот же уровень ядра с одной и той же версией операционной системы или могут представлять собой отдельную копию операционной системы с другой версией ядра с использованием зон ядра Solaris. [6] Собственные зоны Solaris также требуют, чтобы операционная система хоста была версией Solaris; другие операционные системы других производителей не поддерживаются. [ нужна ссылка ] Однако фирменные зоны Solaris необходимо будет использовать для использования других операционных систем в качестве зон. [ нужна ссылка ]
Другим примером являются разделы системной рабочей нагрузки (WPAR), представленные в версии 6.1 операционной системы IBM AIX. Системные разделы WPAR — это программные разделы, работающие в одном экземпляре глобальной среды ОС AIX.
Архитектура уровня операционной системы имеет низкие накладные расходы, что помогает максимально эффективно использовать ресурсы сервера. Виртуализация приводит к незначительным накладным расходам и позволяет запускать сотни виртуальных частных серверов на одном физическом сервере. Напротив, такие подходы, как полная виртуализация (например, VMware ) и паравиртуализация (например, Xen или UML ), не могут достичь такого уровня плотности из-за накладных расходов на выполнение нескольких ядер. С другой стороны, виртуализация на уровне операционной системы не позволяет запускать разные операционные системы (т.е. разные ядра), хотя разные библиотеки, дистрибутивы и т. д. возможны. В зависимости от желаемого использования используются различные методы виртуализации. Собственное исполнение основано на прямой виртуализации базового аппаратного обеспечения, таким образом, оно предоставляет несколько «экземпляров» той же архитектуры, на которой основана реальная машина, способных запускать полноценные операционные системы. Некоторые виртуальные машины также могут эмулировать различные архитектуры и позволять выполнять программные приложения и операционные системы, написанные для другого процессора или архитектуры. Виртуализация на уровне операционной системы позволяет разделить ресурсы компьютера посредством поддержки ядра для нескольких изолированных экземпляров пользовательского пространства, которые обычно называются контейнерами и могут выглядеть и ощущаться для конечных пользователей как настоящие машины. Некоторые компьютерные архитектуры поддерживают аппаратную виртуализацию, что обеспечивает эффективную полную виртуализацию за счет использования аппаратных возможностей, специфичных для виртуализации, в первую очередь центральных процессоров.
Аппаратное обеспечение с поддержкой виртуализации [ править ]
Примеры оборудования с поддержкой виртуализации включают следующее:
- Alcatel-Lucent 3B20D/3B21D эмулируется на коммерческих готовых компьютерах с системой 3B2OE или 3B21E. [ нужны разъяснения ]
- ARM TrustZone
- Boston Circuits gCore (сетка на кристалле) с 16 ядрами ARC 750D и аппаратным модулем виртуализации Time-machine.
- Freescale PowerPC MPC8572 и MPC8641D
- IBM System/360 Model 67 , System/370 , System/390 и zSeries Мэйнфреймы
- IBM Power Systems
- х86 :
- AMD-V (ранее под кодовым названием Pacifica)
- Intel VT-x (ранее под кодовым названием Vanderpool)
- HP vPAR и сотовый nPAR
- Системы GE и Honeywell Multics [ нужны разъяснения ]
- Системы Honeywell 200/2000 Liberator заменяют системы IBM 14xx
- Honeywell Уровень 62/64/66 [ нужна ссылка ]
- Модели IBM System/360 и System/370 с эмуляторами, поддерживающими программы для старых систем IBM
- Миникомпьютеры Honeywell уровня 6 имитировали предшественники 316/516/716 minis [ нужна ссылка ]
- Корпорация Oracle (ранее Sun Microsystems ) SPARC sun4v ( SPARC M6 , T5 , T4 , T3 , UltraSPARC T1 и T2 ) – используется Oracle VM Server для SPARC , также известных как «логические домены».
- Процессоры Xerox Sigma 6 были модифицированы для эмуляции систем GE/Honeywell 600/6000. [ нужна ссылка ]
См. также [ править ]
Примечания [ править ]
- ^ См . «Историю CP/CMS» , где описано использование IBM виртуальных машин для разработки операционных систем и моделирования нового оборудования.
Ссылки [ править ]
- ^ «Виртуальные машины: виртуализация против эмуляции» . Архивировано из оригинала 15 июля 2014 г. Проверено 11 марта 2011 г.
- ^ Смит и Наир, стр. 395–396.
- ^ Сверхбыстрые перезагрузки серверов — еще одна причина, по которой виртуализация хороша. Архивировано 14 июня 2006 г. на Wayback Machine . vmwarez.com (9 мая 2006 г.). Проверено 14 июня 2013 г.
- ^ Мэтью Чепмен и Гернот Хейзер. vNUMA: виртуальный мультипроцессор с общей памятью. Материалы ежегодной технической конференции USENIX 2009 г., Сан-Диего, Калифорния, США, июнь 2009 г. [1]
- ^ «Обзор зон Oracle Solaris» . docs.oracle.com . Проверено 26 июня 2015 г.
- ^ «О зонах ядра Oracle Solaris» . docs.oracle.com . Проверено 26 июня 2015 г.
Дальнейшее чтение [ править ]
- Джеймс Э. Смит, Рави Наир, Виртуальные машины: универсальные платформы для систем и процессов , Морган Кауфманн, май 2005 г., ISBN 1-55860-910-5 , 656 страниц (охватывает как процессные, так и системные виртуальные машины)
- Крейг, Иэн Д. Виртуальные машины . Спрингер , 2006 г., ISBN 1-85233-969-1 , 269 страниц (охватывает только виртуальные машины процессов)