иерархическая виртуализация посредством многоуровневого механизма виртуализации

Формула изобретения

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

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

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

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

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

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

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

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

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

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

6. Компьютерная система по п.5, в которой упомянутый ресурс включает в себя по меньшей мере одну страницу памяти.

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

8. Компьютерная система по п.7, в которой ядро гипервизора удостоверяется в том, что материнский раздел удовлетворил запрос, сделанный дочерним разделом, и обеспечивает выполнение этого запроса.

9. Компьютерная система по п.7, в которой запрос, сделанный дочерним разделом, делается ядром операционной системы в дочернем разделе.

10. Компьютерная система по п.7, в которой запрос, сделанный дочерним разделом, делается драйвером в дочернем разделе.

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

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

ядра гипервизора, функционирующего непосредственно поверх аппаратного обеспечения компьютера; и

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

13. Машиночитаемый носитель по п.12, в котором стек виртуализации дополнительно создает еще один дочерний раздел.

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

15. Машиночитаемый носитель по п.12, в котором дочерний раздел имеет свой собственный стек виртуализации.

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

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

Описание изобретения к патенту

Область техники, к которой относится изобретение

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

Предшествующий уровень техники

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

Большинство систем виртуализации содержит одну единственную программу монитора виртуальных машин (МВМ, VMM). В некоторых устройствах МВМ называется "гипервизором". Гипервизор выполнен с возможностью запуска непосредственно на аппаратном обеспечении. Таким образом, он является окончательным арбитром, принимающим решение относительно того, как используется программное обеспечение. По этой причине в общем случае может быть только один гипервизор в машине (в одном комплекте аппаратного обеспечения). Гипервизор обеспечивает одновременный запуск множества "гостевых" операционных систем (ОС) или просто "гостей" в системе.

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

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

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

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

Сущность изобретения

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

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

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

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

Перечень чертежей

Вышеприведенное краткое описание сущности изобретения, как и нижеследующее подробное описание, лучше понимаются в сочетании с прилагаемыми чертежами. Для иллюстрации настоящего изобретения на чертежах приведены различные аспекты изобретения. Однако изобретение не ограничивается конкретными рассматриваемыми аспектами. Имеются следующие чертежи:

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

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

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

фиг.3 иллюстрирует один тип виртуализации с вложенными гипервизорами и разделами;

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

фиг.4B дает общее представление о том, как снабженный микроядром гипервизор и стек виртуализации вписываются в пример реализации;

фиг.4C иллюстрирует сценарий, в котором дочерний раздел запрашивает у материнского раздела исключительный контроль над собственными ресурсами;

фиг.5 иллюстрирует концепцию, в соответствии с которой множество стеков виртуализации могут находиться в одном разделе;

фиг.6 иллюстрирует иерархическую компоновку стеков виртуализации и их соответствующих разделов;

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

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

Подробное описание

Общий обзор

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

Виртуальные машины

На фиг.1 приведена схема, представляющая логическую многоуровневую архитектуру аппаратного и программного обеспечения для виртуализированной среды в компьютерной системе. Как показано на чертеже, на физической архитектуре 112 аппаратного обеспечения непосредственным или косвенным образом запускается программа 110 виртуализации. Программа 110 виртуализации может быть (a) монитором виртуальных машин, который выполняется вместе с ведущей операционной системой или с ведущей операционной системой с гипервизорным компонентом, причем гипервизорный компонент выполняет виртуализацию. Программа 110 виртуализации виртуализирует архитектуру 108 гостевого аппаратного обеспечения (изображенную пунктирными линиями для отображения того, что этот компонент является разделом или "виртуальной машиной"), то есть на самом деле аппаратное обеспечение не существует, а виртуализируется программой 110 виртуализации. Гостевая операционная система 106 выполняется на архитектуре 108 гостевого аппаратного обеспечения, и в гостевой операционной системе 106 запускается программное приложение 104. В виртуализированной операционной среде, приведенной на фиг.1, программное приложение 104 может быть запущено в компьютерной системе 102, даже если программное приложение 104 предназначено для запуска в операционной системе, которая в целом несовместима с ведущей операционной системой и архитектурой 112 аппаратного обеспечения.

На фиг.2A приведена виртуализированная компьютерная система, содержащая программный уровень 204 ведущей операционной системы (ведущей ОС), функционирующей непосредственно над физическим аппаратным обеспечением 202 компьютера, причем ведущая ОС 204 обеспечивает доступ к ресурсам физического аппаратного обеспечения 202 компьютера посредством предоставления интерфейсов к разделам A 208 и B 210 для использования соответственно операционными системами 212 и 214. Это позволяет ведущей ОС 204 оставаться незамеченной для уровней 212 и 214 операционных систем, функционирующих над ней. Повторим, что для выполнения виртуализации ведущая ОС 204 может быть специально разработанной операционной системой с присущими ей возможностями виртуализации, или в альтернативном варианте она может быть стандартной операционной системой со встроенным гипервизорным компонентом для выполнения виртуализации (не показан).

Если вновь обратиться к фиг.2A, то над ведущей ОС 204 имеется два раздела, раздел A 208, который может быть, например, виртуализированным процессором Intel 386, и раздел B 210, который может быть, например, виртуализированной версией одного из процессоров семейства Motorola 680X0. В каждом разделе 208 и 210 имеются гостевые операционные системы (гостевые ОС) соответственно A 212 и B 214. Поверх гостевой ОС A 212 запущены два приложения, приложение A1 216 и приложение A2 218, а поверх гостевой ОС B 214 запущено приложение B1 220.

В отношении фиг.2A важно отметить, что раздел A 208 и раздел B 210 (которые показаны пунктирными линиями) являются виртуализированными представлениями компьютерного программного обеспечения, которые существуют только в виде программных конструкций. Их осуществление возможно благодаря выполнению специализированных(ой) программ(ы) виртуализации, которые не только представляют раздел 208 и раздел B 210 соответственно гостевой ОС A 212 и гостевой ОС B 214, но которые также выполняют все программные этапы, необходимые для обеспечения косвенного взаимодействия гостевой ОС A 212 и гостевой ОС B 214 с реальным физическим компьютерным аппаратным обеспечением 202.

На фиг.2B приведена альтернативная виртуализированная вычислительная система, в которой виртуализация выполняется монитором 204' виртуальных машин (МВМ), запущенным вместе с ведущей операционной системой 204". В некоторых случаях МВМ 204' может быть приложением, запущенным над ведущей операционной системой 204" и взаимодействующим с компьютерным аппаратным обеспечением 202 только через ведущую операционную систему 204". В других случаях, как показано на фиг.2B, МВМ 204' может вместо этого содержать частично независимую программную систему, которая на некоторых уровнях взаимодействует косвенным образом с компьютерным аппаратным обеспечением 202 через ведущую операционную систему 204", но на других уровнях МВМ 204' взаимодействует с компьютерным программным обеспечением 202 непосредственно (аналогично тому, как ведущая операционная система непосредственно взаимодействует с компьютерным аппаратным обеспечением). В третьих случаях МВМ 204' может содержать полностью независимую программную систему, которая на всех уровнях непосредственно взаимодействует с компьютерным аппаратным обеспечением 202 (аналогично тому, как ведущая операционная система непосредственно взаимодействует с компьютерным аппаратным обеспечением), не используя ведущую операционную систему 204" (хотя и взаимодействуя с ведущей операционной системой 204" для координации использования компьютерного аппаратного обеспечения 202 и недопущения конфликтов и т.п.).

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

Иерархическая виртуализация посредством многоуровневого монитора виртуальных машин

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

На фиг.3 приведена рекурсивная виртуализация, чтобы можно было сравнить ее с иерархической виртуализацией посредством многоуровневого механизма виртуализации. При рекурсивной виртуализации гипервизоры "вложены" один в другой. В основании расположен единственный "настоящий" гипервизор, и над ним функционирует один или несколько гипервизоров второго уровня. Например, на фиг.3 "настоящий" гипервизор A 301 расположен поверх аппаратного обеспечения 300 машины. Гипервизоры B 302 и C 308 вложены в гостевые разделы B 314 и C 316, причем гостевые разделы B 314 и C 316 поддерживаются "настоящим" гипервизором A 301.

Вложенные гипервизоры B 302 и C 308 могут каждый поддерживать свои собственные гостевые разделы. Например, гипервизор B 302 поддерживает гостевой раздел B.1 304 и гостевой раздел B.2 306. Аналогично гипервизор C 308 поддерживает гостевой раздел C.1 310 и гостевой раздел C.2 312. Специалистам в данной области техники должно быть ясно, хотя это и не показано на фиг.3, что гостевые разделы B.1 304, B.2 306, C.1 310 и C.2 312 в пределах гостевых разделов B 314 и B 316 могут содержать дальнейшие вложенные гипервизоры. И эти дальнейшие вложенные гипервизоры могут поддерживать следующие вложенные разделы и т.д.

Однако недостатком такой рекурсивной компоновки является низкая эффективность. Поскольку гипервизоры второго уровня (и все более высокого уровня) написаны в предположении, что они имеют непосредственный доступ к аппаратному обеспечению, эффективность их работы низка. Кроме того, многие процессоры обеспечивают аппаратную поддержку одного уровня виртуализации, но они редко обеспечивают поддержку более чем одного уровня. Наконец, при такой вложенной схеме никакой гипервизор не знает обо всех разделах и не может связываться непосредственно (например, посредством гипервизоров) со всеми разделами. Например, если гипервизор A 301 хочет связаться с гостем B.1 304, он должен сделать это через гипервизор B 302, что является очень неэффективным.

В отличие от фиг.3 на фиг.4A и 4B приведена иерархическая виртуализация посредством многоуровневого механизма виртуализации, которая устраняет необходимость использования вложенных гипервизоров. Так, на фиг.4A изображен гипервизор с разделенными функциональными возможностями (действующими на множестве уровней) в сравнении с традиционным гипервизором. Слева на фиг.4A приведена схема традиционного гипервизора 401, а справа приведена схема, раскрытая в настоящем документе, причем гипервизор разделен на стек 402 виртуализации и микроядро 400 гипервизора.

Микроядро 400 является очень маленьким и простым, и оно взаимодействует с аппаратным обеспечением 403. Оно обеспечивает только элементарные услуги, требуемые для разделения ресурсов машины. Более сложные разделы гипервизора 401 "выталкиваются" в любой избранный гостевой раздел 405 в виде стека 402 виртуализации. Стек 402 виртуализации имеет дело с таким поведением, как виртуализация устройства, вызовы, создание раздела, конфигурация и т.д.

Фиг.4B дает общее представление о том, каким образом гипервизор, содержащий микроядро, и стек виртуализации вписываются в типичную среду виртуализации. Так, в одном аспекте настоящего изобретения микроядро 400 гипервизора расположено непосредственно поверх физического аппаратного обеспечения 403 машин, а соответствующий стек 1 402 виртуализации микроядра 400 гипервизора выталкивается в материнский раздел 404. В свою очередь стек 402 виртуализации способен поддерживать свои собственные разделы. На фиг.4B стек 402 виртуализации поддерживает дочерний раздел A 406 и дочерний раздел B 408.

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

Так, на фиг.4C приведен сценарий, в котором дочерний раздел A 406 запрашивает 410 материнский раздел 404 об освобождении. Соответствующий компонент в стеке виртуализации обрабатывает этот запрос. Как правило, это может быть реализовано таким образом, что запрос выполняется операционной системой (то есть ядром ОС) в дочернем разделе A 406 или неким драйвером в дочернем разделе A 406, и этот запрос может быть направлен загрузчику в материнском разделе 404. Загрузчик может быть информированным загрузчиком (то есть загрузчиком, осведомленным о виртуализации). Таким образом, материнский раздел 404 может закрыть дверь в отношении любого вмешательства в дочерний раздел A 406, поскольку в освобожденный дочерний раздел A 406 нельзя проникнуть через материнский раздел 404.

Гипервизор 400 фактически обеспечивает выполнение 412 этого запроса, поскольку он является высшим арбитром в любой виртуализированной системе. На фиг.4C в качестве примера материнский раздел 404 не имеет доступа к участку памяти дочернего раздела A 406. Таким образом, материнский раздел 404 не может получить доступ к ресурсам дочернего раздела A 406. При этом материнский раздел 404 может иметь доступ 416 к другим участкам дочернего раздела A 406.

Аналогично весь дочерний раздел B 408 не доступен 414 для материнского раздела 404, и поэтому к материнскому разделу 404 полностью отсутствует доверие, что делает дочерний раздел B 408 очень безопасным. Это означает, что материнский раздел 404 не может ничего знать о дочернем разделе B 408. Интересно заметить, что в некоторых аспектах настоящего изобретения материнский раздел 404 несмотря на ограниченный (или отсутствующий) контроль над полностью освобожденным разделом, таким как раздел B 408, сохраняет способность в качестве материнского раздела 404 закрывать дочерний раздел B 408, если дочерний раздел ведет себя несоответствующим или неожиданным образом.

Фиг.5 иллюстрирует идею еще одного аспекта настоящего изобретения, согласно которой в одном разделе может находиться множество стеков виртуализации. Например, первый стек 1 502 виртуализации может находиться в материнском разделе 508 вместе со вторым стеком 2 503 виртуализации. Первый стек 1 502 виртуализации способен поддерживать множество дочерних разделов (по отношению к материнскому разделу, в котором он находится). Таким образом, стек 1 502 виртуализации поддерживает дочерний раздел 1A 504 и дочерний раздел 1B 506. Аналогично, стек 2 503 виртуализации поддерживает дочерний раздел 2A 505 и дочерний раздел 2B 507. Хотя на чертеже приведены только два стека виртуализации, в данном разделе может находиться любое число стеков виртуализации, и каждый из этих стеков виртуализации может поддерживать любое заданное число дочерних разделов.

Одна причина, для чего нужно иметь множество стеков виртуализации рядом друг с другом в одном разделе, состоит в том, чтобы, например, один стек 502 виртуализации мог специализироваться на поддержке безопасных разделов с ограниченной функциональностью, тогда как другой стек 503 виртуализации мог бы специализироваться на предоставлении полномасштабной поддержки всевозможных ресурсов. Естественно, что первый стек 502 виртуализации будет гораздо более безопасным (а следовательно, и его разделы), поскольку он будет пропорционально менее сложным, чем последний стек 502 виртуализации. В этом контексте безопасность и сложность можно повысить за счет друг друга. Так, например, последний стек 503 виртуализации может обеспечивать поддержку интерфейсов IDE (интегрированная электроника управления устройствами) и SCSI (интерфейс малых вычислительных систем), тогда как первая версия 502 с ограниченными функциональными возможностями не может.

В еще одном аспекте изобретения, приведенном на фиг.6, вышеупомянутые стеки виртуализации и их соответствующие разделы можно расположить в иерархическом порядке. Так, микроядро 600 гипервизора поддерживает материнский раздел 608, и соответствующий стек 1 602 виртуализации для микроядра 600 гипервизора расположен в материнском разделе 608. Этот стек 1 602 виртуализации поддерживает первый дочерний раздел 1A 604 и второй дочерний раздел 1B 606. Во втором дочернем разделе 1B 606 находится второй стек 2 610 виртуализации, и этот стек 2 610 виртуализации поддерживает два других дочерних раздела (или внучатых раздела по отношению к первоначальному разделу 608): дочерний раздел 2A 605 и дочерний раздел 2B 607.

Хотя на фиг.6 это не показано, понятно, что каждый дочерний раздел 605 и 607, поддерживаемый вторым стеком 2 610 виртуализации, может в свою очередь поддерживать один или несколько третичных стеков виртуализации, и эти стеки могут в свою очередь поддерживать дальнейшие дочерние разделы. Короче говоря, на фиг.6 приведена попытка проиллюстрировать идею, что архитектура гипервизора, состоящая из микроядра и стека виртуализации, делает возможной иерархическую виртуализацию. Разделы могут содержать множество стеков виртуализации, и такие стеки виртуализации могут поддерживать множество разделов, и каждый из множества разделов может поддерживать дальнейшие стеки виртуализации и т.д.

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

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

Снабженный микроядром гипервизор и службы виртуализации

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

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

Наверху этого уровня находится уровень 710 управления памятью. Этот уровень имеет диспетчер памяти, который обеспечивает простейшее управление внутренней памятью для гипервизора 700, и модуль диспетчера ресурсов, который хранит правила распределения ресурсов для заданного ЦПУ и использования памяти. Компоненты более высокого уровня отвечают за реализацию этих правил.

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

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

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

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

Наконец, службы 704 виртуализации содержат четыре модуля: во-первых, диспетчер распределения обрабатывает входящие события и распределяет их соответствующим образом; во-вторых, модуль диспетчера гипервызовов распределяет вызовы гипервизора, поступившие от гостя; в-третьих, модуль диспетчера перехвата занимается распределением и направлением перехватов (например, доступом к определяемым моделью регистрам, выполнением определенных команд и т.д.) и, в-четвертых, модуль выполнения команд управляет выполнением определенных команд в процессе виртуализации.

Компоненты стека виртуализации

На фиг.8 в соответствии с другим аспектом изобретения приведены различные компоненты, составляющие стек виртуализации, и их взаимоотношения друг с другом. С любыми имеющими отношение компонентами, не раскрытыми в настоящем документе, можно ознакомиться в родственной заявке, озаглавленной "SYSTEMS AND METHODS FOR MULTI-LEVEL INTERCEPT PROCESSING IN A VIRTUAL MACHINE ENVIRONMENT," порядковый № 11/078,141, поданной 11 марта 2005 г. "Внешний монитор", раскрытый в этой заявке, является подкомпонентом стека виртуализации, рассмотренного в настоящей заявке.

Данный стек 800 виртуализации может быть реализован в пользовательском режиме 802 и в режиме 804 ядра. Кроме того, режим 804 ядра может иметь такие компоненты, как библиотека 806 обработчика сообщений гипервизора и API гипервизора и драйвер 810 инфраструктуры виртуализации. Пользовательский режим 802 может иметь такие компоненты, как служба 812 виртуальной машины и рабочий процесс 814 виртуальной машины.

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

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

Кроме того, VID 810 также содержит Выполнение сложных команд. Этот подкомпонент способен осуществлять интерпретацию сложных команд, которые затрагивают память и которые не обрабатываются непосредственно гипервизором. Эта поддержка требуется для некоторых сценариев эмуляции устройств (например, для обращения к плоской памяти VGA, записи в ПЗУ или обращения к отображенным на память регистрам эмулируемого устройства).

VID 810 также содержит Перехваты процессора. Этот подкомпонент позволяет компонентам пользовательского режима задавать перехваты виртуального процессора. Например, модуль эмулируемого устройства может захотеть принять уведомление о перехвате, когда осуществляется обращение к определенному диапазону портов ввода-вывода при помощи команды IN или OUT. Другие примеры перехватов процессора включают в себя: обращение к регистру MSR, CPUID, исключительные ситуации и HLT. Этот компонент отслеживает установленные перехваты и направляет сообщения о перехватах надлежащим образом.

Наконец, VID 810 может содержать подкомпонент Создания и управления разделами. Этот подкомпонент позволяет компонентам пользовательского уровня создавать, удалять и управлять разделами и задавать распространяющиеся на весь раздел ресурсы и квоты, определяя правила планирования заданий и управления доступом. Например, создание нового раздела может быть реализовано сначала посредством гипервызова модуля в гипервизоре (например, HvCreatePartition). Затем посредством гипервызова HvCreateVp создаются один или несколько виртуальных процессоров. Посредством другого гипервызова, например HvMapGpaPages, гостевому пространству физических адресов вновь созданного раздела выделяется память. Посредством гипервызова HvInstallIntercept запрашиваются перехваты для определенных действий процессора. Посредством гипервызова HvSetPartitionProperty устанавливаются правила планирования заданий и безопасности. В память вновь созданной виртуальной машины копируется код инициализации (например, загрузчик ОС или системная BIOS). Посредством гипервызова HvResumePartition начинается выполнение в рамках виртуальной машины. Эти гипервызовы приведены исключительно в качестве примера, и специалистам в данной области техники должно быть понятно, что создание раздела может быть реализовано также другими и эквивалентными способами. Аналогично способы удаления разделов (удаление виртуальных процессоров, гостевых физических адресов и т.д.) должны быть понятны специалистам в данной области техники, равно как и способы управления ресурсами раздела.

Как указывалось выше, VID 810 и API 806 гипервизора существуют в режиме 804 ядра. Однако другие компоненты стека 800 виртуализации существуют в пользовательском режиме 802. Например, Служба 812 управления виртуальными машинами управляет набором конфигураций виртуальной машины и делает открытым набор интерфейсов API на основе WMI для управления виртуальными машинами. Эта служба отвечает за порождение нового рабочего процесса виртуальной машины при запуске виртуальной машины. Эта служба может быть перезапущена без влияния на какие-либо рабочие процессы виртуальной машины (что делает машину более отказоустойчивой в случае аварийного отказа службы).

Другой компонент пользовательского режима 802 - это Рабочий процесс 814 виртуальной машины. Каждая виртуальная машина имеет связанный с ней рабочий процесс. В случае аварийного отказа какого-либо компонента в рабочем процессе вред может быть ограничен одной виртуальной машиной. В рабочем процессе 814 имеется структура виртуализированных машин. Виртуальная машина состоит из набора виртуальных устройств. Каждое устройство имеет свои настойки и параметры, многие из которых могут настраиваться пользователем. Структура устройства отвечает за создание экземпляров модулей виртуального устройства и "соединение" этих устройств для получения функциональной виртуальной машины. Устройства, которые входят в состав виртуальной машины, указываются в ведомости устройств, которая является частью конфигурационного файла виртуальных машин.

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

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

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