Преобразование машин в виртуальные машины - RU2446450C2

Чертежи

Описание

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

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

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

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

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

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

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

Другой способ преобразования физической машины связан с использованием довольно сложных компонентов инфраструктуры, таких как Автоматизированные Услуги Развертывания ("ADS"), и/или Исполняемая Среда Предустановки ("PXE"), чтобы создать переносимую копию содержимого физической машины. Вообще, механизмы, использующие этот тип инфраструктуры, включают в себя выключение физической машины и перезагрузку физической машины посредством, например, PXE. Это позволяет администратору запустить физическую машину без загрузки присущей ей операционной системы и поэтому запретить записи в файлы во время процессов копирования.

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

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

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

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

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

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

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

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

Краткое описание чертежей

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

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

Фиг. 1В - обобщенная схематичная диаграмма фиг. 1А, в которой данные одного или более снимков тома(ов) физического диска перенесены в созданный файл виртуального жесткого диска, используя эффективные механизмы переноса;

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

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

Детальное описание

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

Соответственно, реализации настоящего изобретения могут обеспечить такие преимущества как относительно быстрое, «посредством нажатия одной кнопки» преобразование физической машины в виртуальную машину способом, который может избежать времени простоя физической машины. Кроме того, реализации настоящего изобретения обеспечивают надежное «посредством нажатия одной кнопки» преобразование физической машины в виртуальную машину, так как преобразованная машина будет согласованной в хосте виртуальной машины. Как можно понять из следующего описания и формулы изобретения, такие преобразования могут быть выполнены с любым числом подходящих компонентов и модулей. Например, реализации настоящего изобретения могут включать в себя использование компонентов и механизмов в Услуге Точного Копирования Тома ("VSS"), чтобы создать согласованные с приложением (и/или с файловой системой) снимки. Такие компоненты могут создать один или более согласованных снимков (или изображений в указанное время) одного или более томов физической машины, которые исполняются во время процессов снимка.

Кроме того, реализации настоящего изобретения могут включать в себя использование Услуги Дискового Тома ("VDS") и/или связанных компонентов. Вообще, VDS (или связанный(е) компонент(ы)) включает в себя платформы для создания и конфигурирования томов на физических дисках. Кроме того, реализации настоящего изобретения включают в себя использование "дискового формирователя изображения" и, в некоторых случаях, использование "сборщика изображения". Вообще, дисковый формирователь изображения включает в себя компоненты и/или модули, конфигурированные для создания основанной на блоке (или блоке байтов) копии физического диска или тома, при задании стартового местоположения и числа байтов (или блоков байтов) для копирования. В отличие от этого, инструмент сборщика изображения содержит один или более компонентов и/или модулей, конфигурированных так, чтобы взять, например, файл виртуального жесткого диска в качестве входа и встроить файл виртуального жесткого диска в файловую систему, чтобы предоставить файл как физический диск. Этот предоставленный физический диск может быть сделан доступным точно так же, как любой другой физический диск мог бы быть доступным для операционной системы, которая включает в себя средства для записи данных в его том(а).

Реализации настоящего изобретения дополнительно включают в себя использование файла виртуального жесткого диска (файла "VHD") на хосте виртуальной машины, где файл VHD включает в себя один физический диск и один или более томов физических дисков, управляемых (и доступных внутри) одной или более Виртуальными Машинами ("VM"). Хотя термины "виртуальная машина", "хост виртуальной машины" и "файл VHD" используются в некоторых средах MICROSOFT, понятно, что приведенная здесь ссылка на компоненты MICROSOFT (и/или компоненты WINDOWS SERVER) является только примером. В частности, на основе изучения данного описания и формулы изобретения становится ясным, что компоненты, модули, и/или механизмы, описанные здесь, могут быть найдены и осуществлены в широком диапазоне операционных сред, которые реализуют виртуальные машины или связанные такие объекты.

На фиг. 1А показана обобщенная схематичная диаграмма примерной компьютеризированной среды 100, в которой физическая машина 105 (например, персональный компьютер, физический сервер, и т.д.) может быть преобразована в виртуальную машину, размещенную на хосте 110 виртуальной машины. На одном элементном уровне, преобразование физической машины (например, 105) в виртуальную машину (например, 175, фиг. 1C) может предусматривать получение снимка одного или более томов физической машины (например, 115), создание файла(ов) жесткого диска виртуальной машины (например, 140) на хосте виртуальной машины, перенос снимка(ков) в файл VHD и затем обеспечение того, что один или более перенесенных томов снимка в файле VHD становятся самозагружаемыми как виртуальная машина (например, 175). Таким образом, понятно, что имеется ряд различных процессов подготовки и постоперационных процессов, которые могут быть реализованы, чтобы обеспечить эффективное выполнение преобразования.

По меньшей мере, в одной реализации, например, процесс преобразования может быть инициирован посредством использования модуля 130 преобразования (то есть, модуля, который может включать в себя один или более модулей на машине 105 и/или хосте 110), который инициирует операции снимка одного или более томов на физическом диске(ах) физической машины 105 (например, том 115). Вообще, модуль 130 преобразования может содержать любые соответствующие редакторы и запросчики, конфигурированные для создания согласованной точной копии тома физического диска. Как упомянуто выше, например, такие редакторы и запросчики могут обеспечиваться в услуге точного копирования тома. Таким образом, например, модуль 130 преобразования может начать процесс преобразования, посылая сигнал всем редакторам приложений в каждом одном или более томах физического диска (например, в томе 115), чтобы начать операции снимка его данных. Как показано, например, том 115 включает в себя, по меньшей мере, данные 125 тома, а также загрузочную запись 120.

После приема этого сообщения от модуля 130 преобразования каждый редактор приложения на томе 115 может сбросить свои данные в памяти на физический диск и/или заморозить какую-либо файловую систему или журналы регистрации тома. Для приложений, которые не используют редактор приложения, модуль 130 преобразования может проинструктировать (например, по умолчанию, или по команде от пользователя или администратора) закрыть приложение и таким образом гарантировать, что никакие записи не будут сделаны во время снимка. Соответственно, фиг.1A показывает, что модуль 130 приложения может создать одиночный снимок в указанное время (то есть, копию) всех данных тома по тому 115. Например, фиг. 1A показывает, что модуль 130 преобразования создал снимок 117 тома 115 (то есть "том снимка"), где снимок 117 в этом случае включает данные 127 тома и загрузочную запись 120.

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

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

В любом случае, и в порядке объяснения, данные 127 в снимке 117 будут в принципе отличаться от исходных данных 125 в томе 115, прежде всего, из-за изменений во времени в течение (и/или после) операций снимка. Например, так как физическая машина 105 все еще выполняет программу во время операций снимка, данные 125 тома могут продолжать изменяться, как если бы пользователь продолжал создавать записи в данные определенного приложения. Таким образом, данные 127 тома представляют более раннюю согласованную точку во времени данных 125 в томе 115, которая является, по существу, точкой во времени, в которое модуль 130 преобразования инициировал процессы снимка.

Тем не менее, фиг. 1A также показывает, что загрузочная запись 120 является той же самой на снимке 117, какой она была для исполняемых данных тома 115. Таким образом, понятно, что загрузочные записи (например, 120) вряд ли изменятся во время процессов снимка, так как приложения в типовом случае не имеют доступа к загрузочной записи. В частности, загрузочные записи, в общем случае, изменяются операционной системой и обычно не часто, если вообще изменяются. Фиг. 1А показывает, что загрузочная запись 120 в этом случае та же самая, какая она была перед операциями снимка.

Перед, во время, или вскоре после создания снимка 117 модуль 130 преобразования может также установить один или более файлов 140 виртуальных жестких дисков (VHD) на хост 110 виртуальной машины, который соответствует физическому диску (не показан) физической машины 150. Например, фиг. 1A показывает, что модуль 130 преобразования посылает сообщение 150, чтобы создать записываемый файл 140 виртуального жесткого диска. В одной реализации это может также включать в себя посылку сообщения сначала, чтобы создать файл(ы) VHD (например, 140) конкретного фиксированного размера, и затем посылку отдельного сообщения, чтобы сделать файл VHD записываемым. (Модуль 130 преобразования может также послать сообщение, чтобы создать (записываемый или иначе) файл VHD динамического размера, который увеличивается в размере с добавлением данных).

Вообще, каждый файл VHD может конфигурироваться, чтобы соответствовать единственному физическому диску компьютерной системы, и каждый том в пределах физического диска может быть представлен по типу заново созданного файла VHD. Файл VHD, однако, может в некоторых случаях представить единственный том, а не весь физический диск. Однако, в примере физического диска, где физический диск имеет множество томов (хотя показан только единственный том 115), новый VHD может также содержать данные, соответствующие множеству томов. В этом отношении есть, конечно, некоторая гибкость. Например, если пользователь физической машины 105 имел том, распространенный по множеству разделов (и/или зеркальных томов и т.д.), то пользователь мог бы принять решение выделить только один раздел для данных снимка в адресованном файле виртуального жесткого диска. Точно так же пользователь мог бы принять решение перенести один том физического диска, содержащего множество томов, в файл виртуального жесткого диска.

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

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

В любом случае, после создания файла 140 виртуального жесткого диска, модуль 130 преобразования установит файл 140 как физический диск, чтобы файл 140 мог получить данные снимка 117 через, например, сетевую коммуникацию. (Понятно, что, в некоторых реализациях, описанных здесь, установка может даже не потребоваться.) Таким образом, Фиг.1A также показывает, что модуль 130 преобразования посылает сообщение 155, чтобы установить файл 140 виртуального жесткого диска. В дополнительных или альтернативных реализациях сообщение 155 может включать в себя инструкцию установить файл 140 VHD на хосте виртуальной машины, или на физической машине 105 в преобразованном виде, или в ином месте, где есть возможность сетевого соединения между машиной, где установлен файл 140 VHD, и преобразуемой физической машиной (то есть 105 в этом случае).

Часть устанавливаемого файла 140 может включать в себя ассоциирование файла с одним или более идентификаторами устройства, такими как ID устройства физического диска. Например, хост 110 виртуальной машины может быть проинструктирован установить файл 140 виртуального жесткого диска так, чтобы он был идентифицируемым через путь накопителя как "\\.\device\Harddiskl45\". В частности, фиг. 1B показывает, что VHD 140 является идентифицируемым как "дисковый накопитель 145". Аналогичным образом, модуль 130 преобразования может также идентифицировать идентификатор устройства (и/или, например, точки установки) для каждого снимка (например, 117). В конечном счете, модуль 130 преобразования может использовать идентификаторы идентифицированных устройств для любого снимка и для любых соответствующих файлов VHD для переноса содержимого снимка.

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

Например, несколько гигабайтов данных, которые могли бы обычно потребовать несколько часов на перенос на хост 110 виртуальной машины по обычным протоколам передачи сети, могут быть переданы в некоторых случаях за несколько минут с использованием механизмов пересылки блоков байтов. В любом случае, фиг. 1B показывает, что модуль 130 преобразования передает в этом случае байты (или блоки байтов) "160₁", "160₂" и т.д. и передает эти байты/блоки байтов непосредственно в записываемый файл 140 виртуального жесткого диска через дисковый накопитель 145. Как показано на фиг.1B, файл 140 виртуального жесткого диска может иметь все загрузочные данные 120 и будет включать другие данные 127 тома, зафиксированные в снимке 117, после завершения передачи данных.

Несмотря на перенос данных, файл 140 виртуального жесткого диска может не обязательно быть самозагружаемым на хост 110 виртуальной машины, так как загрузочные данные и драйверы вряд ли будут полезны в контексте хоста 110 виртуальной машины. Одна из причин этого состоит в том, что "виртуальные аппаратные средства", которые существуют в среде виртуальной машины (и/или в пределах хоста 110 виртуальной машины), не могли бы быть тем же самым, чем являются аппаратные средства для физической машины 105. Например, такие компоненты, как ядро и Уровень Абстракции Аппаратных средств ("HAL"), на физической машине 105 могут базироваться, например, на двухпроцессорном комплексе. Кроме того, хост 110 виртуальной машины может эмулировать различные драйверы сетевой карты, архитектуру процессора, физические диски (например, ЗУ, связанное с машиной), идентификаторы физических дисков, драйверы операционной системы и драйверы дисков на виртуальные машины, размещаемые на хосте, которые не могли бы иначе быть найдены, в исходной преобразуемой машине (например, физической машине 105). Такие различия, вероятно, будут, также существовать при преобразовании физического дискового тома от хоста виртуальной машины к виртуальной машине.

В результате, переданные загрузочные данные 120 могли бы быть основаны на характеристиках операционной системы на физической машине 105, которые не обязательно применимы в пределах соответствующей виртуализированной среды на хосте 110 виртуальной машины. Эти и другие причины означают, что администратор, возможно, должен выполнить ряд различных модификаций, в зависимости от конкретной(ых) операционной(ых) среды (сред). Соответственно, модуль 130 преобразования может также изменить файл 140 виртуального жесткого диска, чтобы он был самозагружаемым на хост 110 виртуальной машины. Это может включать в себя, в некоторых случаях, инструкции обновить ядро и HAL - и другие драйверы и настройки реестров - для создаваемой виртуальной машины, основываясь на данных снимка.

Таким образом, например, фиг.1C показывает, что модуль 130 преобразования также посылает запрос 165 и соответствующие аргументы на хост 110 виртуальной машины, чтобы изменить операционную информацию. (В некоторых случаях, эти модификации операционной информации виртуальной машины (например, загрузочный сектор и информация реестров) могут даже быть сделаны на физической машине (перед передачей внутри файла VHD).) В одной реализации это может включать в себя исследование модулем 130 преобразования загрузочной записи снимка 117 тома и замену ранее переданных загрузочных данных 120 новой загрузочной информацией (например, измененной загрузочной информацией или новой загрузочной информацией, созданной с самого начала), основанной на конфигурации нового диска и тома виртуальной машины. На другом этапе модуль 130 преобразования может также исследовать переданную информацию реестров (не показано) снимка 117 тома и обновлять переданную информацию реестров способом, подходящим для виртуальной машины 110, основываясь на новых аппаратных средствах и драйверах, которые существуют на хосте 110 виртуальной машины.

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

Кроме того, модуль 130 преобразования может также создавать эти и/или другие соответствующие значения конфигурации для намеченной виртуальной машины (например, 175), чтобы получаемая виртуальная машина (например, 175) работала с теми же самыми предпочтениями (например, память, центральный процессор и т.д.) как на исходной физической машине 105. Аналогичным образом, администратор хоста 110 виртуальной машины может также (или альтернативно) изменять эти предпочтения для получаемой виртуальной машины. Кроме того, администратор может даже создать такую операционную информацию (то есть значения конфигурации, предпочтения и т.д.), начиная с самого начала. В любом случае, понятно, что ряд объектов может выполнить любое число изменений конфигурации, чтобы гарантировать, что получающаяся виртуальная машина является самозагружаемой и что она будет работать корректным образом в месте размещения виртуальной машины (например, на хосте виртуальной машины).

После изменения/создания соответствующим образом подходящей загрузочной записи (то есть от 120 до 123), информации системных реестров, информации драйверов и/или другой информации конфигурации или предпочтений, модуль 130 преобразования может затем удалить установку (то есть выполнить «демонтаж») файла 140 виртуального жесткого диска, чтобы он больше не был доступен как накопитель. Например, фиг. 1C показывает, что модуль 130 преобразования посылает сообщение 170 на хост 110 виртуальной машины, инструктируя хост 110 виртуальной машины удалить установку файла 140 виртуального жесткого диска. После удаления этой установки файл(ы) 140 виртуального жесткого диска может(гут) использоваться как виртуальная машина 175, данные которой, по существу, идентичны данным тома 115 в момент начала операций снимка.

В частности, данные в пределах тома(ов), которым управляет новая виртуальная машина 175, согласованы в каждом соответствующем аспекте (например, согласованы с приложением, согласованы с файловой системой и/или с аварийным отказом и т.д.). В результате, предшествующий пользователь физической машины 105 теперь будет в состоянии загрузить виртуальную машину 175 на хосте 110 виртуальной машины и использовать виртуальную машину (включая доступ к предшествующим данным), как если бы (или более оптимально, чем, если бы) пользователь использовал физическую машину 105. Кроме того, понятно, что файлы VHD могут быть в общем случае переносимыми. Например, конечный пользователь может перенести виртуальную машину 175 в любое желательное местоположение (то есть, на другой хост виртуальной машины) в, по меньшей мере, одной реализации просто путем переноса файла(ов) виртуальной машины (например, файла(ов) VHD и т.д.), связанного(ых) с виртуальной машиной 175, в желательное местоположение и выполнения любых необходимых обновлений операционной информации.

В другой реализации один или более файлов VHD (например, 140) могут даже быть созданы в физической машине 105 непосредственно, и затем посланы/переданы на соответствующий хост виртуальной машины (например, 110). Например, пользователь на физической машине 105 может создать файл VHD (например, 140) на физической машине и передать содержимое снимка в файл VHD для данных, представляющих интерес, на физической машине. Это, по меньшей мере, один способ, которым пользователь может избежать установки файла VHD (то есть, на хосте 110 виртуальной машины), если желательно. В любом случае пользователь может тогда послать/передать файл VHD и соответствующее содержимое снимка в соответствующее место назначения (например, хост 110 виртуальной машины) и изменить соответствующую операционную информацию в месте назначения. Альтернативно, пользователь может даже изменить операционную информацию для файла VHD и содержимого снимка в источнике (например, на физической машине 105), прежде чем послать файл VHD и содержимое снимка вперед в новое место назначения.

В некоторых случаях, вместо создания "файла" VHD как такового, модуль (например, модуль 130 преобразования) мог бы быть конфигурирован для потоковой передачи из памяти данных снимка и метаданных VHD, созданных на физической машине 105, частями (например, блоками байтов), эффективными для транспортировки. Данные, подлежащие потоковой передаче, могут также быть отформатированы в формате VHD согласно соответствующим спецификациям формата/содержания VHD. Таким образом, после переноса в место назначения (например, на хост 110 виртуальной машины), поток может быть затем сохранен как файл VHD, так как потоковые данные были сгенерированы в формате VHD. Это еще один способ избежать установки файла VHD.

Соответственно, фиг. 1A-1C иллюстрируют ряд обобщенных схем и компонентов, которые могут использоваться в соответствии с реализациями настоящего изобретения для создания снимка данных тома физической машины и создания новой виртуальной машины из этих данных. В дополнение к описанному выше, реализации настоящего изобретения могут также быть описаны в терминах блок-схем способов, содержащих одно или более действий для достижения конкретного результата. Например, фиг. 2 иллюстрирует блок-схемы способов с точки зрения физической машины 105 и хоста 110 виртуальной машины для преобразования машины, такой как физическая машина или другая виртуальная машина, в виртуальную машину. Способы по фиг. 2 описаны ниже относительно компонентов в механизмах, представленных на фиг. 1A-1C.

Например, фиг. 2 показывает, что способ, с точки зрения физической машины 105, для преобразования физической машины в виртуальную машину на хосте виртуальной машины, не испытывая существенного времени отключения на один или более томов физической машины, может содержать действие 200 идентификации конфигураций аппаратных средств физической машины. Действие 200 включает идентификацию одной или более настроек конфигурации аппаратных средств для одного или более томов машины. Например, фиг. 1A показывает модуль 130 преобразования, который может идентифицировать настройки аппаратных средств (и/или программного обеспечения) для тома 115 перед инициированием процессов снимка. Это может включать идентификацию загрузочной записи 120 и данные 125 тома, как они существуют на физической машине 105 для тома 115, и могут дополнительно включать идентификацию, конфигурированы ли данные для мультипроцессорной среды, идентификацию несовместимостей в файлах, поддерживаемых операционной системой, имеются ли ЗУ и сетевые драйверы, которые необходимо учитывать, и т.д.

Кроме того, фиг. 2 показывает, что способ с точки зрения физической машины 105 может содержать действие 210 создания снимка одного или более томов. Действие 210 включает в себя создание одного или более согласованных снимков, соответствующих одному или более томам машины. Например, фиг. 1A показывает, что модуль 130 преобразования создает снимок 117 тома 115, который включает в себя ту же самую загрузочную запись 120, что и ранее, а также данные 127 тома. По меньшей мере, в одной реализации модуль 130 преобразования может вызвать связанные с редактором процессы снимка для тома 115, где доступно, или просто закрыть приложения (или другие процессы записи), где такие редакторы не доступны. В результате может быть обеспечено, что данные в пределах снимка 117 будут согласованными (например, согласованными с приложением) для единственного экземпляра во времени после процессов снимка.

Фиг. 2 также показывает, что способ с точки зрения физической машины 105 может содержать действие 220 посылки снимка(ов) в файл установленного виртуального дискового файла. Действие 220 включает в себя посылку одного или более согласованных снимков в установленный файл виртуального жесткого диска. Например, модуль 130 преобразования извлекает идентификаторы устройства для каждого снимка, полученного на физической машине 105, и далее извлекает любые идентификаторы устройства для каждого файла виртуального жесткого диска, установленного на хосте 110 виртуальной машины. После извлечения соответствующих идентификаторов устройств, фиг. 1B показывает, что модуль 130 преобразования может передать данные 127 тома снимка 117 в файл 140 виртуального жесткого диска, например, с использованием механизмов переноса/копирования байтов (или блоков байтов).

Фиг. 2 далее показывает, что способ с точки зрения физической машины 105 может включать в себя действие 230 посылки загрузочной(ых) записи(ей) в установленный файл виртуального диска. Действие 230 включает в себя посылку загрузочной записи для одного или более согласованных снимков в установленный файл виртуального жесткого диска, так что загрузочная запись одного или более согласованных снимков может быть изменена в хосте виртуальной машины. Например, фиг. 1B показывает, что модуль 130 преобразования также посылает загрузочные данные 120 в файл 140 виртуального жесткого диска. Фиг. 1C также показывает, что модуль 130 преобразования может послать сообщение 165, чтобы модифицировать загрузочную запись 120 в запись 123, так что загрузочная запись 123 становится согласованной для операционной среды хоста 110 виртуальной машины. В одной реализации новая загрузочная запись для новой виртуальной машины может просто быть создана с самого начала, вместо просто посылки и модифицирования.

В дополнение к описанному выше, фиг. 2 показывает, что способ, с точки зрения хоста 110 виртуальной машины, для преобразования машины (то есть физической машины или предшествующей виртуальной машины) в виртуальную машину на хосте виртуальной машины, не подвергаясь существенному времени отключения по одному или более томам машины, может включить в себя действие 240 создания файла виртуального жесткого диска. Действие 240 включает в себя создание файла виртуального жесткого диска, имеющего размер файла. Например, фиг. 1A показывает, что хост 110 виртуальной машины принимает сообщение 150, инструктирующее хост 110 виртуальной машины создать записываемый файл виртуального жесткого диска, а также инструкцию сделать новый файл виртуального жесткого диска записываемым. В ответ хост 110 виртуальной машины создает файл 140 виртуального жесткого диска и делает его записываемым. Как ранее упомянуто, здесь, размер файла виртуального жесткого диска может быть статическим или динамическим. Например, файл 140 виртуального жесткого диска мог бы быть установлен на 100 гигабайтов, чтобы разместить 50 гигабайтов тома 115 данных. Альтернативно, модуль 130 преобразования устанавливает файл 140 виртуального жесткого диска так, чтобы он увеличивался динамически по мере дополнительных передач данных.

Фиг.2 также показывает, что способ с точки зрения хоста 110 виртуальной машины может содержать действие 250 установки файла виртуального жесткого диска. Действие 250 включает в себя установку файла виртуального жесткого диска на хосте виртуальной машины, так что файл виртуального жесткого диска представляется как доступный физический диск. Например, фиг. 1А показывает, что хост 110 виртуальной машины получает запрос 155, чтобы установить файл 140 виртуального жесткого диска. В одном выполнении хост 110 виртуальной машины мог бы инструктироваться для ассоциирования файла 140 с конкретным идентификатором устройства, и затем установить этот идентификатор как физическое устройство. Файл 140 виртуального жесткого диска может тогда представляться, и к нему можно обращаться как к дисковому устройству 145.

Кроме того, способ, с точки зрения хоста 110 виртуальной машины, может содержать действие 260 приема одного или более снимков. Действие 260 включает в себя прием данных одного или более согласованных снимков, соответствующих одному или более томам физической машины. Например, как показано на фиг. 1B, хост 110 виртуальной машины получает данные тома 127 и загрузочные данные 120 с использованием любого соответствующего механизма передачи (то есть побайтной передачи, или передачи блоками байтов и т.д. согласно любому сетевому протоколу).

Кроме того, фиг. 2 показывает, что способ, с точки зрения хоста 110 виртуальной машины, может содержать действие 270 изменения загрузочной записи. Действие 270 включает в себя изменение операционной информации для одного или более согласованных снимков, так что один или более согласованных снимков становятся подходящими для операционной системы на хосте виртуальной машины. Как показано на фиг. 1C, например, хост 110 виртуальной машины получает сообщение 165, чтобы изменить операционную информацию. Например, сообщение 165 может включать в себя один или более запросов для идентификации критериев соответствующего хоста 110 виртуальной машины и изменяет загрузочные данные 120 на загрузочные данные 123 соответствующим способом. Сообщение 165 (или другое сообщение - не показано) может также включать в себя один или более запросов изменить реестры и/или операционную информацию предпочтений.

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

Кроме того, фиг. 2 показывает, что способ, с точки зрения хоста 110 виртуальной машины, может содержать действие 280 удаления установки файла виртуального жесткого диска. Действие 280 включает в себя удаление установки файла жесткого диска, так что файл виртуального жесткого диска становится не доступным как физический диск. Например, хост 110 виртуальной машины принимает сообщение 170, которое запрашивает, чтобы хост 110 виртуальной машины удалил установку файла 140 виртуального жесткого диска. Хост 110 виртуальной машины может затем «демонтировать» файл виртуального жесткого диска, так что файл 140 больше не будет доступным локально или по сети как накопитель диска уровня хоста. В результате файл 140 виртуального диска может быть загружен как виртуальная машина 175, которая содержит данные, которые согласованы для единственного экземпляра во времени, и готовы работать на хосте 110 виртуальной машины. В частности, с точки зрения конечного пользователя, виртуальная машина 175 - фактически для всех намерений и целей - по существу, является идентичной по форме (то есть содержит те же самые данные или подмножество(а) данных) физической машине 105 до операций снимка.

Соответственно, фиг. 1A-1C и 2 обеспечивают ряд компонентов и механизмов для эффективного преобразования машины (например, физической машины или предшествующей виртуальной машины) в виртуальную машину. В частности, чертежи и соответствующий текст описывают, как реализации настоящего изобретения могут быть выполнены, по меньшей мере, в одном аспекте, не требуя обязательной перезагрузки преобразуемой машины и/или, не требуя перезагрузки в среду ADS или PXE. Как таковые, вышеописанные компоненты и механизмы позволяют физическим машинам создаваться относительно быстро, так, как при скоростях передачи для обычного диска и сети.

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

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

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

В качестве примера, но не ограничения, такие машиночитаемые носители могут включать в себя ОЗУ(RAM), ПЗУ (ROM), электронно-стираемые ПЗУ (EEPROM), ПЗУ на компакт-диске (CD-ROM) или другое ЗУ на оптическом диске, ЗУ на магнитном диске или другие магнитные ЗУ, или любой другой носитель, который может использоваться для переноса или хранения желательных средств программного кода в форме исполняемых компьютером инструкций или структур данных и к которому может получить доступ универсальный или специализированный компьютер. Когда информация передается или предоставляется по сети или другому коммуникационному соединению (проводному, беспроводному или комбинации проводного или беспроводного средства) на компьютер, компьютер должным образом рассматривает такое соединение как машиночитаемый носитель. Таким образом, любое такое соединение надлежащим образом определяется как машиночитаемый носитель (среда передачи). Комбинации вышеупомянутых средств также должны быть включены в объем машиночитаемых носителей.

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

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

Реферат

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

Формула