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

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

Иллюстрации

Показать все

Реферат

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

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

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

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

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

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

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

Другой способ преобразования физической машины связан с использованием довольно сложных компонентов инфраструктуры, таких как Автоматизированные Услуги Развертывания ("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, согласованы в каждом соответствующем аспекте (например, согласованы с приложением, согласованы с файловой системой и/или с аварийным отказом и т.д.). В результате, предшествую