Преобразование виртуальной машины в физическую. Конвертируем Windows в виртуальную машину

Рассказываем о целях, задачах и выгодах от внедрения виртуализации на базе MS Hyper-V

Hyper-V виртуализация физических серверов, рабочих станций, установка и настройка Hyper-V для виртуализации сети, техническая поддержка – с такими задачами часто сталкиваются специалисты “Интегрус” в своей повседневной работе.

Для каких целей платформа виртуализации Microsoft Hyper-V применяется на практике

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

Рассмотрим несколько преимуществ, которые дает технология виртуализации Hyper-V.

Рациональное использование оборудования

Поддержка аппаратной виртуализации Hyper-V дает возможность сосредоточить серверы на меньшем количестве физических машин (как показывает опыт, без виртуализации их ресурсы редко используются на полную мощность). Пример из нашей практики – перенос сервера на виртуальную машину Hyper-V позволил развернуть на единственном физическом сервере одновременно сервер , сервера терминалов и баз данных, соответственно, у заказчика получилось сэкономить средства на покупку “лишнего” оборудования и его эксплуатацию.

Организация частной облачной среды предприятия

Система виртуализации Hyper-V поможет создать общедоступные облачные ресурсы компании и гибко управлять их использованием. Для большей безопасности и защиты виртуальных серверов Hyper-V существует технология экранирования виртуальных машин (Shielded virtual machines).

Безопасность данных компании

В качестве одной из мер безопасности можно рассмотреть использование на клиентских ПК Hyper-V, виртуализацию физической машины. На рабочем месте сотрудника выполняем перенос физической машины в виртуальную среду Hyper-V, разворачиваем две виртуальные машины (ВМ) – рабочую и персональную. На рабочей настраиваем все необходимые ограничения доступа и политики безопасности, принятые в компании, а на персональной пользователь может делать все, что ему угодно, при этом данные компании останутся в полной сохранности, т.к. ВМ изолированы одна от другой. Встроенные средства поддержки виртуализации Hyper-V есть в Windows 7, 10 Pro или Enterprise.

Виртуальные рабочие столы (VDI)

Установка и настройка Hyper-V Server 2012 и хоста виртуализации удаленных рабочих столов предоставит пользователям личные виртуальные рабочие столы – готовое рабочее окружение с доступом к нему из любой точки мира , позволит централизовать администрирование и контролировать все пользовательские потоки данных. А средства динамической миграции ВМ дадут возможность выполнять перенос виртуальных машин Hyper-V практически незаметно для пользователей.

Моделирование любых сред для задач разработки и тестирования приложений

Можно использовать виртуализацию при помощи Hyper-V для имитации физических компьютерных сред , в которых должно функционировать приложение. При этом нет надобности покупать и поддерживать все аппаратные комплектующие, которые понадобились бы, если бы среду воссоздавали физически, достаточно установить Windows Hyper-V и смоделировать все необходимые компоненты.

Непрерывность бизнес-процессов

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

Гипервизор Hyper-V распространяется бесплатно, его можно скачать с сайта Microsoft, устанавливается он на любой Windows или Linux сервер. Им легко управлять и просто использовать.

У вас появились вопросы? Консультация – бесплатно!

Обратитесь к нам за бесплатной консультацией. Позвоните или напишите нам и мы подробно расскажем:

• как мы можем помочь вашему бизнесу расти быстрее, сократить затраты и ускорить операции
• как и в какие сроки будут проводиться работы по проекту
• сколько будет стоить проект (рассчитывается индивидуально)

Специалисты компании “Интегрус” готовы выполнить настройку виртуальных сетей Hyper-V, создание или перенос виртуальной машины VMWare на Hyper-V. Стоимость работ зависит от масштабов проекта.

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

Решения, которые позволят справляться с такими задачами, существуют. На рынке программного обеспечения сегодня представлен целый ряд продуктов, позволяющих создавать виртуальные машины, а точнее, изолированные виртуальные среды, для выполнения приложений и распределения вычислительных ресурсов между ними. Среди них есть и решения от Microsoft, такие как Microsoft Virtual Server 2005 и Microsoft Virtual PC 2007.

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

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

Для решения проблемы импорта существующей системы в виртуальную среду предлагается использовать полную резервную копию целевой системы, которая создается утилитой самой операционной системы, а именно - Backup and Restore.

Результатом полного резервного копирования, выполненного через Backup and Restore, будет файл формата Microsoft Virtual Hard Disk (VHD), который используется и для эмуляции жестких дисков в виртуальной машине Microsoft. Образ формата VHD можно использовать в Microsoft Virtual Server или Microsoft Virtual PC, но из-за особенностей его внутренней архитектуры такой образ VHD нельзя применять в качестве загрузочного. Попытки добиться этого стандартными средствами в среде Virtual PC, а именно с помощью утилит diskpart, bootrec и bootsect, успеха не имели. Хотя монтирование VHD-образа в Virtual Server или Virtual PC в качестве дополнительного диска к имеющейся виртуальной машине позволит без труда восстановить выбранный фрагмент полной резервной копии компьютера, например, путем простого копирования.

Полностью реализовать возможности Windows Backup and Restore для восстановления системы можно только из самого приложения или под управлением Windows Recovery Environment (WinRE), если воспользоваться режимом Complete PC Restore из меню восстановления этой среды. Доступ к WinRE можно получить, имея на руках установочный диск Windows Vista и выбрав вариант Repair My Computer.

Впрочем, в данной статье речь идет не о резервном копировании и восстановлении. Итак, сформулируем еще раз задачу эксперимента. В нашем распоряжении имеется целевой компьютер с установленной Windows Vista и Microsoft Virtual PC 2007. Задача: воссоздать реальную машину в виртуальной среде с минимальными трудозатратами.

В первую очередь создадим полную резервную копию родительской системы. Для этого нужно перейти в Control Panel и воспользоваться приложением Backup and Restore. В открывшемся окне следует выбрать вариант Back up Computer. Далее следуйте инструкциям мастера резервного копирования. Особенность этого шага заключается в том, что резервная копия машины должна быть помещена на раздел жесткого диска, отличный от системного, или на внешний носитель. Вариант размещения архива системы на одном или нескольких DVD-R (W) носителях не подходит, так как нам нужен единственный файл формата VHD.

В результате получаем такую папку, как показано на экране 1.

Из всей совокупности файлов, составляющих полную резервную копию системы, нас интересует файл с расширением *.vhd. Он будет находиться в папке Backup - ### - ###. Копируем его в целевой каталог, например: С:Virtual (см. экран 2).

Теперь запускаем Virtual PC. Создаем новую виртуальную машину и одновременно Hard Disk 1 для нее, через мастер создания виртуальных машин New Virtual Machine Wizard: Create а Virtual Machine - {имя машины} - Operating system - в раскрывающемся списке выбираем Windows Vista - Using recommended RAM - A new virtual hard disk. Далее принимаем параметры мастера по умолчанию. Размер диска при создании можно указать совсем небольшой, например 300 Mбайт. В настройках виртуальной машины можно сразу выставить параметр Undo disk - Enable Undo Disk.

Создаем Hard Disk 2. Выбираем вариант Virtual Hard Disk File - Browse и указываем путь к резервной копии операционной системы - файлу с расширением *.vhd. В результате получаем примерно такую конфигурацию, как на экране 3.

Где Hard Disk 1 - это пустой неформатированный диск, а Hard Disk 2 - файл c резервной копией нашей системы. Нажимаем Ok.

Далее воспользуемся диском с дистрибутивом операционной системы. Вставляем его в накопитель и запускаем виртуальную машину. В меню окна виртуальной машины выбираем CD - Use physical drive #:, где # - имя для используемого устройства DVD. Если нужно, заходим в настройки BIOS виртуальной машины и устанавливаем очередность загрузки, чтобы в первую очередь происходила загрузка именно с устройства DVD. Будет выполнен запуск среды установки операционной системы.

На первом экране c региональными и языковыми параметрами установки нажимаем Next для выбора параметров по умолчанию, на втором экране выбираем пункт Repair Your Computer. Произойдет запуск среды восстановления Windows и обнаружение имеющихся установок операционной системы. В появившемся диалоговом окне System Recovery Options следует нажать Next. Из предложенного меню восстановления выбираем Command Prompt.

X:Sources> Diskpart
DISKPART> Sel disk 0
DISKPART> Create partition primary
DISKPART> Format fs=ntfs quick
DISKPART> sel partition 1
DISKPART> Active
DISKPART> Exit

После исполнения команды Exit выходим из Command Prompt и нажимаем кнопку Restart в меню восстановления для перезагрузки.

Повторно загружаемся с установочного диска. Как и в предыдущих шагах, на первом экране c региональными и языковыми параметрами установки нажимаем Next для выбора параметров по умолчанию; на втором экране выбираем пункт Repair Your Computer. В ответ на приглашение Windows found problems with your computer’s startup options выбираем No и нажимаем Next. Из предложенного меню восстановления опять выбираем Command Prompt. Теперь следует восстановить конфигурацию загрузчика операционной системы.

Прежде всего необходимо скопировать сам загрузчик на загрузочный раздел. Перед копированием снимем атрибуты hidden и system c файла bootmgr.

X:Sources> D:
D:>attrib –h –s bootmgr

Копируем bootmgr на активный раздел:

На следующем шаге нужно восстановить конфигурацию bootmgr. Файл BCD, в котором хранится конфигурация загрузчика, должен находиться в каталогеBoot активного раздела. Существует несколько вариантов решения этой задачи. Самый простой - воспользоваться утилитой bootrec, которая включена в Windows Recovery Environment и имеется на диске с дистрибутивом операционной системы. Данная утилита представляет собой очень полезное средство. Она позволяет восстановить поврежденную запись master boot record (MBR) без перезаписи имеющейся таблицы разделов, boot sector (BR) и собственно сам BCD - файл, в котором хранятся настройки загрузчика операционной системы. Воспользуемся последней возможностью:

D:> bootrec/rebuildbcd

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

Далее следует утвердительно ответить на приглашение, т. е. набрать Y и нажать Enter. Утилита bootrec внесет необходимые изменения. К сожалению, внутренняя архитектура vhd-файла резервной копии системы не позволяет корректно воссоздать Boot Record для активного раздела. Поэтому сделать раздел с имеющейся установленной системой активным не получится, хотя совместное использование утилит diskpart и bootrec подразумевает эти манипуляции и даже вывод положительного результата таких действий на экран.

Проверяем результат выполнения команды bootrec/rebuildbcd (см. экран 5), для чего в командной строке набираем:

КаталогBoot и файл BCD в нем должны присутствовать в корневом каталоге активного раздела. Чтобы не было проблем с запуском локализованных версий операционной системы, копируем необходимые файлы в каталог C:Boot из каталога D:Boot резервной копии системы. Предварительно необходимо переименовать имеющийся там файл BCD.

D:> cd boot
D:> ren bcd bcd_old
D:> xcopy d:oot*.* c:Boot/y/s

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

D:> diskpart
DISKPART> sel disk 0
DISKPART> sel partition 1
DISKPART> set id=27 override

Команда SET ID=27 делает раздел технологическим и скрытым. Этот метод используется поставщиками вычислительных систем для предотвращения доступа к разделу с предустановленной средой WinRE. Впрочем, это не мешает процессу загрузки операционной системы A. Ключ OVERRIDE используется для принудительного назначения атрибута, так как по умолчанию такое действие для загрузочного раздела не разрешено.

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

Произойдет загрузка операционной системы с раздела в файле *.vhd сделанной нами резервной копии системы, причем в режиме восстановления после сбоя. Выбираем Start Windows Normally и получаем виртуальную машину, которая является копией того экземпляра, с которого выполнялось полное резервное копирование.

Некоторые комментарии:

Виртуальную копию операционной системы придется активировать заново, так как Harware ID, вычисляемое при первичной активации, естественно, изменится.

Утилита Backup and Restore позволяет выполнять полное резервное копирование системы только в версиях Windows Vista Business, Enterprise и Ultimate.

Для «преобразования» физических компьютеров в виртуальные машины существует инструмент Virtual Server 2005 Migration Toolkit (VSMT). Однако он требует развертывания дополнительной инфраструктуры Automated Deployment Services (ADS) и в конечном итоге может оказаться дорогим решением (потребуется Windows Server 2003 Enterprise Edition). Кроме того, у меня нет информации об успешной миграции рабочих станций под управлением Windows Vista с использованием этого средства.

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

Валерий Волобуев - MCSA, MCITPro, MCDST, MCT, консультант по информационным технологиям УЦ «Сетевые Технологии», Techexpert inc., Киев

На операционных системах Windows XP, Windows 7 и Windows 8 есть утилита systeminfo.exe, которая показывает основную информацию о системе. Утилита Coreinfo от Марка Руссиновича предоставляет в этом плане гораздо больше возможностей.

Эта утилита командной строки может показать Вам привязки логических процессоров к физическому процессору, узел NUMA и сокет, в котором он находится, а также размеры кэшей, назначенные на каждый логический процессор. Coreinfo также использует функцию Windows GetLogicalProcessorInformation site:msdn.microsoft.com для получения информации и печати её на экране консоли, где привязка логического процессора будет показана звездочкой ‘*’. Coreinfo также полезна для получения подробной информации о процессоре (например, поддерживает ли он виртуализацию Hyper-V) и о топологии кэша Вашей системы.

[Как установить Coreinfo ]

Установка очень проста. Скачайте архив с программой , распакуйте в любое удобное место, запустите. Программа задаст Вам вопрос о принятии условий лицензии и после этого будет готова к работе. Чтобы постоянно иметь утилиту под рукой, скопируйте Coreinfo.exe в папку %SystemRoot%\system32.

[Использование Coreinfo ]

Запускайте Coreinfo из командной строки, запущенной с правами администратора. Для каждого имеющегося ресурса будет показана карта привязки к процессорам, видимым для ОС, где * будет показывать принадлежность к имеющимся процессорам. Например, для системы с 4 ядрами в строке информации о кэше будет карта совместно используемого кэша между ядрами 3 и 4.

-c Выводит информацию о ядрах. -f Выводит информацию о возможностях ядер. -g Выводит информацию о группах. -l Выводит информацию о кэше. -n Выводит информацию об узлах NUMA. -s Выводит информацию о процессорных сокетах. -m Выводит стоимость доступа к NUMA. -v Выводит возможности процессора и системы по поддержке виртуализации (Hyper-V), включая поддержку трансляции адреса второго уровня (на системах Intel требует прав администратора).

По умолчанию (если запустить coreinfo.exe без опций) выводится информация по всем опциям, кроме -v.

Примечание: в выводе тире ‘-‘ означает, что такая функция отключена или не поддерживается, а звездочка ‘*’ означает наличие соответствующей функции (опции, привязки).

1 . Coreinfo site:technet.microsoft.com.

Microsoft Windows (c) Корпорация Майкрософт (Microsoft Corp.), 2009. Все права защищены.
C:\Windows\System32>Coreinfo.exe
Coreinfo v3.31 — Dump information on system CPU and memory topology Copyright (C) 2008-2014 Mark Russinovich Sysinternals — www.sysinternals.com
AMD FX(tm)-6300 Six-Core Processor AMD64 Family 21 Model 2 Stepping 0, AuthenticAMD HTT * Multicore HYPERVISOR — Hypervisor is present VMX — Supports Intel hardware-assisted virtualization SVM * Supports AMD hardware-assisted virtualization X64 * Supports 64-bit mode
SMX — Supports Intel trusted execution SKINIT * Supports AMD SKINIT
NX * Supports no-execute page protection SMEP — Supports Supervisor Mode Execution Prevention SMAP — Supports Supervisor Mode Access Prevention PAGE1GB * Supports 1 GB large pages PAE * Supports > 32-bit physical addresses PAT * Supports Page Attribute Table PSE * Supports 4 MB pages PSE36 * Supports > 32-bit address 4 MB pages PGE * Supports global bit in page tables SS — Supports bus snooping for cache operations VME * Supports Virtual-8086 mode RDWRFSGSBASE — Supports direct GS/FS base access
FPU * Implements i387 floating point instructions MMX * Supports MMX instruction set MMXEXT * Implements AMD MMX extensions 3DNOW — Supports 3DNow! instructions 3DNOWEXT — Supports 3DNow! extension instructions SSE * Supports Streaming SIMD Extensions SSE2 * Supports Streaming SIMD Extensions 2 SSE3 * Supports Streaming SIMD Extensions 3 SSSE3 * Supports Supplemental SIMD Extensions 3 SSE4a * Supports Streaming SIMDR Extensions 4a SSE4.1 * Supports Streaming SIMD Extensions 4.1 SSE4.2 * Supports Streaming SIMD Extensions 4.2
AES * Supports AES extensions AVX * Supports AVX intruction extensions FMA * Supports FMA extensions using YMM state MSR * Implements RDMSR/WRMSR instructions MTRR * Supports Memory Type Range Registers XSAVE * Supports XSAVE/XRSTOR instructions OSXSAVE * Supports XSETBV/XGETBV instructions RDRAND — Supports RDRAND instruction RDSEED — Supports RDSEED instruction
CMOV * Supports CMOVcc instruction CLFSH * Supports CLFLUSH instruction CX8 * Supports compare and exchange 8-byte instructions CX16 * Supports CMPXCHG16B instruction BMI1 * Supports bit manipulation extensions 1 BMI2 — Supports bit manipulation extensions 2 ADX — Supports ADCX/ADOX instructions DCA — Supports prefetch from memory-mapped device F16C * Supports half-precision instruction FXSR * Supports FXSAVE/FXSTOR instructions FFXSR * Supports optimized FXSAVE/FSRSTOR instruction MONITOR * Supports MONITOR and MWAIT instructions MOVBE — Supports MOVBE instruction ERMSB — Supports Enhanced REP MOVSB/STOSB PCLMULDQ * Supports PCLMULDQ instruction POPCNT * Supports POPCNT instruction LZCNT * Supports LZCNT instruction SEP * Supports fast system call instructions LAHF-SAHF * Supports LAHF/SAHF instructions in 64-bit mode HLE — Supports Hardware Lock Elision instructions RTM — Supports Restricted Transactional Memory instructions
DE * Supports I/O breakpoints including CR4.DE DTES64 — Can write history of 64-bit branch addresses DS — Implements memory-resident debug buffer DS-CPL — Supports Debug Store feature with CPL PCID — Supports PCIDs and settable CR4.PCIDE INVPCID — Supports INVPCID instruction PDCM — Supports Performance Capabilities MSR RDTSCP * Supports RDTSCP instruction TSC * Supports RDTSC instruction TSC-DEADLINE — Local APIC supports one-shot deadline timer TSC-INVARIANT * TSC runs at constant rate xTPR — Supports disabling task priority messages
EIST — Supports Enhanced Intel Speedstep ACPI — Implements MSR for power management TM — Implements thermal monitor circuitry TM2 — Implements Thermal Monitor 2 control APIC * Implements software-accessible local APIC x2APIC — Supports x2APIC
CNXT-ID — L1 data cache mode adaptive or BIOS
MCE * Supports Machine Check, INT18 and CR4.MCE MCA * Implements Machine Check Architecture PBE — Supports use of FERR#/PBE# pin
PSN — Implements 96-bit processor serial number
PREFETCHW * Supports PREFETCHW instruction
Maximum implemented CPUID leaves: 0000000D (Basic), 8000001E (Extended).
Logical to Physical Processor Map: *—— Physical Processor 0 -*—- Physical Processor 1 —*— Physical Processor 2 —*— Physical Processor 3 —-*- Physical Processor 4 ——* Physical Processor 5
Logical Processor to Socket Map: ****** Socket 0
Logical Processor to NUMA Node Map: ****** NUMA Node 0
No NUMA nodes.
Logical Processor to Cache Map: *—— Data Cache 0, Level 1, 16 KB, Assoc 4, LineSize 64 *—— Instruction Cache 0, Level 1, 64 KB, Assoc 2, LineSize 64 *—— Unified Cache 0, Level 2, 2 MB, Assoc 16, LineSize 64 -*—- Data Cache 1, Level 1, 16 KB, Assoc 4, LineSize 64 -*—- Instruction Cache 1, Level 1, 64 KB, Assoc 2, LineSize 64 -*—- Unified Cache 1, Level 2, 2 MB, Assoc 16, LineSize 64 —*— Data Cache 2, Level 1, 16 KB, Assoc 4, LineSize 64 —*— Instruction Cache 2, Level 1, 64 KB, Assoc 2, LineSize 64 —*— Unified Cache 2, Level 2, 2 MB, Assoc 16, LineSize 64 —*— Data Cache 3, Level 1, 16 KB, Assoc 4, LineSize 64 —*— Instruction Cache 3, Level 1, 64 KB, Assoc 2, LineSize 64 —*— Unified Cache 3, Level 2, 2 MB, Assoc 16, LineSize 64 —-*- Data Cache 4, Level 1, 16 KB, Assoc 4, LineSize 64 —-*- Instruction Cache 4, Level 1, 64 KB, Assoc 2, LineSize 64 —-*- Unified Cache 4, Level 2, 2 MB, Assoc 16, LineSize 64 ——* Data Cache 5, Level 1, 16 KB, Assoc 4, LineSize 64 ——* Instruction Cache 5, Level 1, 64 KB, Assoc 2, LineSize 64 ——* Unified Cache 5, Level 2, 2 MB, Assoc 16, LineSize 64 ****** Unified Cache 6, Level 3, 8 MB, Assoc 1, LineSize 64
Logical Processor to Group Map: ****** Group 0

By Mark Russinovich

Published: August 18, 2014

Download Coreinfo (192 KB)

Introduction

Coreinfo is a command-line utility that shows you the mapping between logical processors and the physical processor, NUMA node, and socket on which they reside, as well as the cache’s assigned to each logical processor.

Требования к процессору для включения Hyper-V в Windows 8

It uses the Windows’ GetLogicalProcessorInformation function to obtain this information and prints it to the screen, representing a mapping to a logical processor with an asterisk e.g. ‘*’. Coreinfo is useful for gaining insight into the processor and cache topology of your system.

Installation

You run Coreinfo by typing "coreinfo”.

Using CoreInfo

For each resource it shows a map of the OS-visible processors that correspond to the specified resources, with "*" representing the applicable processors. For example, on a 4-core system, a line in the cache output with a map of shared by cores 3 and 4.

Usage: coreinfo [-c][-f][-g][-l][-n][-s][-m][-v]

Parameter	Description
**-c **	Dump information on cores.
-f	Dump core feature information.
-g	Dump information on groups.
**-l **	Dump information on caches.
-n	Dump information on NUMA nodes.
-s	Dump information on sockets.
-m	Dump NUMA access cost.
-v	Dump only virtualization-related features including support for second level address translation.
(requires administrative rights on Intel systems).

All options except -v are selected by default.

Coreinfo Output:

Download Coreinfo (192 KB)

Простая миграция Windows Server в окружение Hyper-V

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

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

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

Первыми кандидатами на консолидацию в виртуальные машины могут являться:

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

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

• Нагруженные службы, особенно требующие интенсивной дисковой активности (например, СУБД)
• Инфраструктурные сервисы, от которых зависит работа самого гипервизора. Например, Active Directory Services в виртуальной машине, включенной в тот же домен AD – не самая лучшая идея
• Использование специфического оборудования

Виртуализация не может быть вложенной. Если на исходном оборудовании есть виртуальные машины в каком-либо виде (Virtual PC, Virtual Box, VmWare и т.п.), их следует переносить отдельно по методике v2v (Virtual-to-Virtual)

Ну и, наконец, не стоит забывать про «все яйца в одной корзине». Что в случае работы множества виртуальных машин на одном сервере становится особенно актуально.

Рассмотрим процесс миграции на реальном примере.

Исходные данные

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

Методика переноса

На рынке существует большое количество коммерческих продуктов, позволяющих выполнить перенос в виртуальное окружение – прежде всего, Microsoft System Center Operations Manager с пакетом Hyper-V Management Pack. Практически все подобные инструменты требуют приобретения лицензии, и их следует рассматривать в случае массовой консолидации десятков серверов и дальнейшего управления.

Для разовой миграции одного сервера хотелось обойтись простыми и подручными средствами.

Первое, что пришло в голову – использовать для переноса встроенную функцию резервного копирования Windows Server Backup, которая, начиная с Windows Server 2008, создает на выходе образ виртуального диска VHD с резервной копией системы.

После некоторых экспериментов с резервным копированием было найдено более простое решение.

На сайте Microsoft имеется набор весьма полезных утилит от Марка Руссиновича (Mark Russinovich) из команды Sysinternals, среди которых есть улилита disk2vhd . Она и делает как раз то, что требуется – позволяет снять с диска образ VHD. Причем, в отличие от Windows Server Backup, который создает по отдельному образу VHD на каждый том, disk2vhd позволяет скопировать физический диск со всеми томами (или выборочно) в один виртуальный диск. Кроме того, disk2vhd работает и в более старых версиях Windows (2000/XP/2003).

Образ можно снимать как в оффлайне, подключив диск к другому серверу или загрузившись с образа WinPE, так и на ходу с VSS-снапшота файловой системы.

Также утилита работает с командной строки, что весьма полезно, например, при миграции серверов в Core-инсталляции.

Созданный образ диска впоследствии можно использовать при создании виртуальной машины.

Создание виртуальной машины

После снятия образа с существующей системы необходимо создать виртуальную машину Hyper-V с необходимыми настройками.

Указать необходимое количество оперативной памяти

Выбрать подключение к сети

И, наконец, выбрать существующий образ диска, созданный ранее при помощи disk2vhd

После создания отредактировать необходимые настройки – количество процессорных ядер, специфические настройки сети

И не забыть доставить утилиты Hyper-V в виртуальную машину.

Таким образом, можно достаточно легко перенести операционную систему с физического сервера на виртуальную машину Hyper-V.

Потенциальные проблемы

В принципе, сам по себе процесс миграции достаточно прост и должен пройти гладко.

Coreinfo v.3.2

Однако небольшие подводные камни все же могут встретиться. Касаются они, прежде всего, гостевой операционной системы версий Windows Server 2000/2003 и Windows 2000/XP.

Во-первых, для корректной работы старых версий ОС Windows под управлением Hyper-V потребуется установка соответствующих утилит и драйверов в гостевой ОС. Которые, в свою очередь, требуют установки последней версии Service Pack. Поэтому перед миграцией в виртуальную среду следует, по возможности, выполнить обновление переносимой ОС до максимума.

Вторая проблема связана с активацией OEM-версий Windows ниже Vista/2008 (в Volume-версиях подобной проблемы нет). Поскольку при переносе с физической системы в виртуальную меняется оборудование (сетевой адаптер и системная плата), активация Windows становится недействительной. В случае с Windows Server 2008/Windows Vista и выше эта проблема не является критичной и не приводит к отказу работы, достаточно будет просто выполнить активацию повторно. А вот старые версии Windows перед запуском потребуют восстановить активацию, но выполнить ее через интернет не удастся до установки драйверов на сетевой адаптер.

Кстати, с точки зрения лицензионной чистоты перенос P2V для OEM-версий является недопустимым и разрешается только для Volume или Retail версий Windows. Поэтому не забудьте посчитать стоимость лицензирования при планировании подобных операций.

sysinternals виртуализация hyper-v

| сохранено

HВложенная виртуализация Hyper-Vв черновикахПеревод

Виртуализация, Серверное администрирование, Системное администрирование

На этой неделе Microsoft выпустила сборку Windows 10 Insider Preview Build 10565. В этой сборке добавлено несколько новых функций в операционную систему. В частности Бен Армстронг (менджер Hyper-V в Microsoft) упоминает в в своем блоге, что добавлена возможность создания вложенной виртуализации Hyper-V в Windows 10. Вложенная виртуализации позволяет запустить Hyper-V внутри виртуальной машины и создать несколько виртуальных машин в рамках этой основной виртуальной машины. Вы cможете запускать несколько гиппервизоров Hyper-V, без необходимости в дополнительном физическом оборудовании.

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

Шаг 1: Создание виртуальной машины

Шаг 2 : Запуск скрипта Enable-NestedVm.ps1, позволяющий упростить процесс проверки требований (например, что динамическая память должна быть выключена). Этот сценарий проверит конфигурацию, изменит, что некорректно (с разрешения) и включит вложенную виртуализацию для виртуальной машины. Обратите внимание, что ВМ должна быть выключена.

Шаг 3: Установка компонентов Hyper-V на в гостевой VM

Шаг 4: Включение сети. После того, как вложенная виртуализация включена в виртуальной машине, включите MAC- spoofing для работы сети. Запустите с правами администратора PowerShell на хост-машине и выполните:

Шаг 5: Создайте вложеную ВМ.

Вложенная виртуализация пока еще на ранней стадии разработки и тестирования, поэтому она имеет несколько известных проблем:
1. Оба гипервизора должны быть последней версии Hyper-V. Другие гипервизоры не будут работать. Windows Server 2012R2, а также сборки до 10565 не будут работать.
2. После того, как вложенная виртуализация включена в виртуальной машине некоторые функции будут больше не совместимы с этой виртуальной машины.

Руководство по требованиям к поддержке PAE/NX/SSE2 для Windows 8

Они будут вызывать ошибки или вообще препядствовать запуску виртуальной машины:
— динамическая память должен быть выключена иначе виртуальная машина не сможет загрузится;
— изменить объем памяти не удастся;
— применить контрольные точки для работающей ВМ не удастся;
— горячая миграция не работает;
— нет возможности сохранить ВМ.
3. После того, как вложенная виртуализация включена в виртуальной машине, для работы сети ее гостевых машин необходимо включить MAC- spoofing.
4. В настоящее время работает только на процессарах Intel, с включенной поддержкой Intel VT-х.
5. Для вложенной виртуализации необходим большой объем памяти. Удалось запустить виртуальную машину в виртуальной машине с 4 Гб оперативной памяти, но все жутко тормозило.

hyper-v, Nested Virtualization, Вложенная виртуализация

наверх

Источник статей: Хабр.

Время указано в том часовом поясе, который установлен на Вашем устройстве.

Версия сайта: 0.8.
Об ошибках, предложениях, пожалуйста, сообщайте через Telegram пользователю @leenr, по e-mail [email protected] или с помощью других способов связаться.

Всегдабр (расширение для Google Chrome)
Статистика посещений
СоХабр в ВК (новости проекта)

Согласно достаточно давно появившейся информации, как например в статье Windows Server 2012 Failover Cluster – Enhanced Integration with Active Directory (AD) , нам предоставляется возможность виртуализации и размещения контроллера домена в кластере Hyper-V , даже не смотря на то, что этот самый кластер будет стартовать раньше, чем виртуальный контроллер домена внутри этого кластера. Если честно, я долго не решался браться за виртуализацию контроллера домена, однако последнее общение с коллегами показало, что из их опыта, виртуальный контроллер домена внутри кластера Hyper-V - это вполне реальный и работоспособный сценарий.

В этой заметке мы рассмотрим пример Physical-to-Virtual (P2V ) конвертации физического сервера в виртуальную среду на базе гипервизора Hyper-V в составе ОС Windows Server 2012 R2 . В рассматриваемом примере физический сервер представляет из себя серверную платформу HP ProLiant DL 360 G5 с ОС Windows Server 2012 R2 и основными серверными ролями AD DS и DNS . И как наверное понятно, с инфраструктурной точки зрения сервер представляет собой действующий контроллер домена.

Для выполнения конвертации действующего физического сервера в виртуальную машину Hyper-V я воспользуюсь утилитой Microsoft Virtual Machine Converter (MVMC ) 3.0 . Ознакомится со всеми возможностями этой утилиты можно в библиотеке TechNet . На мой взгляд, помимо преимуществ, эта утилита имеет и ряд определённых недостатков. К недостаткам я могу отнести например то, что получающаяся в результате P2V конвертации виртуальная машина имеет формат Generation 1 ., а также то, что каждый логический диск создается в виде отдельного VHD -файла. Но в целом это преодолимые вещи и их мы рассмотрим после завершения процедуры конвертации с помощью MVMC. В конечном итоге план наших действий будет следующий:

1 . P2V конвертация физического сервера с помощью MVMC.
2 . Преобразование виртуальных дисков в формат VHDX.
3 . Настройка сети в гостевой ОС виртуальной машины.
4 . Проверка обновления компонент интеграции Hyper-V
5 . Удаление ПО поддержки аппаратных компонент сервера.
6 . Конвертация виртуальной машины в формат Generation 2.
7 . Удаление несуществующих устройств из ОС виртуальной машины.

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

А ) Для операций P2V хост виртуализации должен иметь свободное дисковое пространство объёмом не менее, чем общий размер занятого пространства на дисках виртуализуемого сервера. А с учётом временных операций MVMC желательно вообще ориентироваться на двойной объём данных.

Б ) Для последующих операций конвертации ВМ G1 в G2 на системном диске хоста виртуализации, где предположительно расположены папки профилей пользователей, должно присутствовать свободное дисковое пространство объёмом не менее, чем общий размер занятого пространства на дисках виртуализуемого сервера. В процессе конвертации будет создана временная копия виртуального диска в виде wim-образа в каталоге %LOCALAPPDATA%\Temp или C:\Users\%USERNAME%\AppData\Local\Temp )

P2V конвертация физического сервера с помощью MVMC

Как и условились, устанавливать MVMC будем на тот хост виртуализации, который будет получателем новой виртуальной машины. На выбранном хосте должна быть установлена роль Hyper-V и включена "фича" BITS Compact Server . Роль Hyper-V была установлена ранее, так как это действующий хост виртуализации, а вот BITS нам нужно будет установить дополнительно, так как по умолчанию она выключена. Сделаем это с помощью PowerShell :

Import-Module ServerManager Install-WindowsFeature -Name " BITS-Compact-Server " -IncludeAllSubFeature -IncludeManagementTools

После установки, запускаем MVMC и на первом экране выбираем тип конвертации – Physical machine conversion

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

На следующем шаге нажимаем кнопку Scan System , и ждём когда в информационном окне System Information появится информация о конвертируемом сервере.

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

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

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

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

На шаге Summary просматриваем краткую сводную информацию и запускаем процесс конвертации кнопкой Finish

Дожидаемся успешного окончания процесса конвертации…

Сразу после того, как процесс конвертации завершён, выключаем физический сервер-источник.

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

Также создана виртуальная машина формата Generation 1 , у которой виртуальные диски подключены к виртуальному IDE -контроллеру. Виртуальный диск с длинным названием (по метке тома с физической системы) используется для запуска ОС со второго, основного виртуальном диска.

Теперь нужно выполнить первый проверочный запуск виртуального сервера, чтобы убедиться в том, что виртуализованная система стартует и работает успешно. На всякий случай перед первым запуском можно отключить сетевой адаптер виртуальной машины от виртуального коммутатора Hyper-V.

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

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

Преобразование виртуальных дисков в формат VHDX

Так как виртуальная машина была создана MVMC с дисками в формате VHD мы можем самостоятельно выполнить преобразование дисков в более "продвинутый" формат VHDX . Для этого выключим виртуальную машину и в консоли Hyper-V Manager из меню Actions выберем пункт Edit disk . Выбрав виртуальный диск на шаге мастера Choose Action выберем режим конвертирования – Convert

После того как диски преобразованы изменим путь к дискам в свойствах виртуальной машины

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

Настройка сети в гостевой ОС виртуальной машины.

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

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

Проверка обновления компонент интеграции Hyper-V

Чтобы убедиться в том, что в "новоиспечённой" виртуальной машине используются компоненты интеграции Hyper-V самой актуальной версии, доступной на хосте виртуализации, откроем консольное подключение к виртуальной машине и в меню Action выберем пункт монтирования образа диска с компонентами интеграции – Insert Integration Services Setup Disk

В смонтированном в виртуальной системе диске найдём и запустим файл \support\amd64\setup.exe

Если компоненты интеграции имеют актуальную версию, то мы получим примерно следующее сообщение:

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

Удаление ПО поддержки аппаратных компонент сервера

После того как наш сервер стал виртуальным, нужно позаботиться о том, чтобы всё программное обеспечение, которое ранее было установлено на этот сервер для поддержки аппаратных компонент, было аккуратно удалено. В нашем примере удалению подлежат все приложения из состава HP Insight Software . Также мы можем удалить установленного ранее агента ИБП, так как теперь выключением гостевой ОС виртуальной машины в случае отключения электропитания будет управлять хост виртуализации.

После удаления ПО снова перезагрузим гостевую систему, чтобы убедиться в её успешном запуске.

Конвертация виртуальной машины в формат Generation 2

На данном этапе наш виртуальный сервер полноценно работает в штатном режиме, однако если мы хотим улучшить его путём преобразования в формат Generation 2 , предварительно стоит позаботиться о создании резервной копии рабочей ВМ. Просто и удобно это можно сделать например с помощью System Center 2012 R2 Data Protection Manager (DPM )…

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

Преобразование в виртуальную машину второго поколения будем проводить с помощью небезызвестного PS-скрипта Hyper-V generation 2 VM conversion utility (Convert-VMGeneration ) . Если говорить упрощенно, то принцип работы данного скрипта заключается в том, что он новую виртуальную машину второго поколения с новым виртуальным дисков, на который клонирует копию основного системного раздела с исходного виртуального диска ВМ G1 и создаёт дополнительные разделы необходимые для загрузки ВМ G2. Таким образом, исходная виртуальная машина первого поколения остаётся нетронутой, и если в процессе конвертации G1>G2 возникнут трудности непреодолимого характера, то нам никто не мешает продолжить использование исходной виртуальной машины.

Итак, скачиваем и копируем скрипт Convert-VMGeneration.ps1 на хост виртуализации, где в данный момент работает наша виртуальная машина.

Перед началом конвертации ещё раз убедимся в том, что на диске с профилями пользователей (как правило это диск C:\ ) достаточно места для создания временной копии виртуального диска ВМ (в процессе конвертации будет создан временный wim-образ в каталоге %LOCALAPPDATA%\Temp )

Дополнительно убедимся в том, что внутри виртуальной машины выключена поддержка среды восстановления WinRE (требование автора скрипта конвертации). Сделать это можно консольной командой:

reagentc /disable

Выключим виртуальную машину.

Запустим на хосте виртуализации скрипт конвертации:

" KOM-DC01 " -Path " D:\ "

Как видим, первая попытка запуска скрипта завершается ошибкой.

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

На первом диске (Disk 0 ) содержится информация необходимая для загрузки ОС, но не содержится самой ОС. При этом скрипт пытается использовать для конвертации именно этот диск. Так как в результате работы скрипта загрузочный раздел фактически будет создан заново, мы можем попробовать удалить имеющийся загрузочный диск. Для этого выключим виртуальную машину и удалим из конфигурации ВМ первый виртуальный диск, который имеет метку тома в виртуальной ОС “System Reserved ” (диск объёмом примерно в 350MB).

То есть мы оставим в свойствах ВМ только один диск, тот на котором расположена гостевая ОС Windows Server 2012 R2. После этих изменений не нужно пытаться запустить виртуальную машину (из этого всё равно не выйдет ничего хорошего), а сразу пробуем выполнить скрипт конвертации:

.\Convert-VMGeneration.ps1 -VMName " KOM-DC01 " -Path " D:\ " -IgnoreWinRE

Ключ IgnoreWinRE здесь добавлен для того, чтобы избежать сообщения после которого преобразование прекращалось с ошибкой (несмотря на то, что в гостевой ОС поддержка WinRE выключена):

WinRE is configured. Run reagentc /disable inside guest first, or use IgnoreWinRE parameter
Completed with error. Trace status code 700

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

Прежде, чем нажать Yes , откроем на хосте виртуализации оснастку управления дисками и убедимся в том, что в системе появился новый виртуальный диск, который смонтирован под порядковым номером указанным в сообщении скрипта (в нашем примере это Disk 7 ). Это и есть тот новый виртуальный диск, который создан скриптом конвертации, для клонирования на него исходного виртуального диска (он также смонтирован скриптом в нашем примере как Disk 6 )

Итак, после нажатия Yes в будет произведено клонирование данных с одного виртуального диска на другой с добавлением дополнительных разделов, необходимых для ВМ второго поколения.

По окончании работы скрипта соответствующие разделы будут автоматически отмонтированы

При необходимости переименуем исходную виртуальную машину первого поколения…

Проверим конфигурацию вновь созданной виртуальной машины второго поколения.

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

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

Теперь можно спокойно удалить старую виртуальную машину (в нашем случае это исходная ВМ, ранее переименованная в KOM-DC01-OLD ) поколения G1 и перенести готовую ВМ G2 в кластер, если он используется.

При необходимости можно включить выключенный до конвертации в G2 WinRE

reagentc /enable

Удаление несуществующих устройств из ОС виртуальной машины

На текущий момент наш виртуальный сервер уже является виртуальной машиной Hyper-V второго поколения. Завершающим немаловажным действием является удаление из гостевой ОС всех старых устройств-"фантомов" и относящихся к ним драйверам с помощью оснастки управления устройствами (Device Manager ).

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

Удалять старые устройства будем методом.

Устанавливаем системную переменную для включения отображения устройств-призраков в оснастке управления устройствами и следующей командой (не закрывая окна командной строки) запускаем оснастку:

set devmgr_show_nonpresent_devices =1 start devmgmt.msc

В открытой оснастке в меню View выбираем пункт "Show hidden devices "…

Разворачиваем каждый узел типов устройств и удаляем все устройства отображаемые как неактивные.

В процессе удаления некоторых устройств может быть доступна опция удаления драйвера устройства “Delete the driver software for this device ”. Так как эти драйверы более не нужны в гостевой виртуальной системе, можно включать советующую опцию.

По завершению перезагружаем гостевую ОС виртуальной машины, чтобы убедиться в том, что она успешно стартует и работает.

На этом этапе можно сказать, что работы по конвертации физического контроллера домена на базе Windows Server 2012 R2 в виртуальную машину Hyper-V Generation 2 завершены и теперь, всё что нам остается сделать – убедиться в работоспособности прикладной части виртуального сервера, например проверить состояние роли контроллера домена с помощью таких инструментов как DCDIAG .

OS: MS Windows XP/2003.
Application: VMware vCenter Converter (Windows).

Задача: получить копию "компьютера" (физической вычислительной машины) под управлением операционной системы "MS Windows XP/2003", в комплекте со всеми приложениями и данными в виде, неизменном по отношению к конечному пользователю, готовую к запуску в среде аппаратной виртуализации ("Intel VT", она же "Virtual Machine eXtension", и "AMD-V", она же "Secure Virtual Machines") предоставляемой продуктами Hyper-V, Qemu-KVM, VMware, XEN.

Рассмотрим вариант с использованием продукта "VMware vCenter Converter", по простому - "VMware Converter". Программа свободно не распространяется, предоставляется только после регистрации на сайте производителя, но совершенно бесплатна. Очень удобна, кстати говоря, конвертирует практически что угодно во что угодно, имея при этом весьма приятный и "интуитивно понятный" интерфейс. VMware-вцы молодцы, что ни говори об их непомерных финансовых аппетитах - долгое время шли впереди планеты всей, делая самые удобные и реально работающие системы виртуализации. Эпоха "интернет", как в своё время "книгопечатания", многократно упростившая доступ к информации, перераспределила центры развития и сместила баланс сил игроков в сфере разработки интересного и перспективного программного обеспечения, но многолетние наработки, горы патентов, умеющие умы никуда не делись и выдают продукты обладающие прелестями "корпоративных" - отточенностью и предсказуемостью результата.

И так, подавив набирающий силу поток словоблудия, приступим к делу. Идём на сайт производителя (www.vmware.com), прыгаем по ссылкам, регистрируемся, буде в том имеется необходимость и скачиваем "конвертер " (примерно 124 Мегабайта).

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

На машине подлежащей виртуализации устанавливаем "конвертер", запускаем его, жмём бросающуюся в глаза кнопочку "Convert Machine" запуская тем самым мастер "Conversation". С помощью "выпадающих меню" и "чекбоксов" определяемся с тем, что желаем здесь и сейчас "виртуализировать" именно эту самую машину, на которой и запущено приложение:

Следующим естественным шагом определяемся, во что желаем превратить систему пока ещё работающую на пышущей жаром и гудящей внутренностями железке. Я неоднократно конвертировал в самых разных вариантах виртуальные машины "VMware Server v.2" - потому его формат и выбираю. В качестве месторасположения образа изготавливаемой виртуальной машины лучше выбрать какой-нибудь внешний, по отношению к корневой файловой системе, носитель информации, но не обязательно - можно разместить его где угодно:

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

"Data to copy". Здесь мы можем выбрать, какие диски подлежат переносу в виртуальную машину (системный и загрузочные переносятся без-вариантно). В "basic"-режиме мало что можно изменить, потому сразу переходим в расширенный - "Advanced":

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

Важно определится, каким образом вы планируете переносить и вообще использовать в дальнейшем создаваемую виртуальную машину. Нужно решить, в каком виде и объёме создавать результирующие виртуальные диски. Если виртуализация проводится в инфраструктуре с "гигабитными" или "оптическими" высокоскоростными сетевыми магистралями между серверами с "безразмерными" дисковыми хранилищами, то рекомендую сразу раздвинуть до разумного максимума пространство виртуального диска и задать формат "Pre-allocated" (что даст на выходе "сырой" RAW-файл, сразу готовый к работе на максимальной скорости в любой из перечисленных выше систем виртуализации). Если образ виртуального сервера придётся протягивать через игольное ушко хлипкой сети государственного органа или мелкого предпринимателя, не решающегося стать крупным - следует выбрать формат "Not pre-allocated", для уменьшения размера финального виртуального диска за счёт пропуска "пустого" пространства (получим VMDK-файл формата "VMware Server v.2", требующий последующей переконвертации в желаемый формат уже на несущем сервере):

Если жить совсем кисло и на сервере, где будет работать создаваемая виртуальная машина, свободного места меньше, чем на исходном виртуализируемом, то придётся явно указать размер финального диска:

"Devices". Всё просто - берём по минимуму (один процессор, старая-добрая шина IDE и памяти "лишь-бы хватило"), догнаться всегда успеем:

"Networks". От создания виртуального сетевого интерфейса рекомендую отказаться, так как проще сразу врезать в запускаемую виртуальную машину то, что лучше всего поддерживается системой виртуализации (например "VirtIO" в KVM):

"Services". Немаловажная вкладка. Хотел было выше упомянуть о необходимость остановить все активно использующие ресурсы "сервисы" виртуализируемой "физической" системы, но подумал о том, что не всегда это возможно. Зато возможно и полезно указать не запускаться (будучи переведённым в "ручной" режим) особо прожорливым системным и пользовательским службам. Дело в том, что при первом запуске виртуальной машины с операционной системой "MS Window" на борту таковая не менее десяти минут "утаптывается" на новом месте жительства, выискивая и тестируя на совместимость подходящие обнаруженному оборудованию драйверы. Учитывая то, что "оборудование" обновилось полностью, работы у системы и так хватает, а запускающиеся параллельно парочка сервисов "корпоративного уровня" (чем "корпоративнее", тем жаднее до кручения диска) и антивирус с "завёрнутыми гайками" способны поставить на колени "MS Windows" на пару-тройку часов (и это не преувеличение).

"Advanced". Последним важным этапом завершаем подготовку к виртуализации. Указываем удалить бесполезные в дальнейшей "виртуальной" работе срезы "восстановления системы". И, возможно самая полезная опция "Reconfigure destination virtual machine", укажем подготовить создаваемую виртуальную машину к загрузке в неизвестно каком окружении, сбросив аппаратно-зависимые настройки, вроде привязки HAL (правда, это мои домыслы, но полагаю, что от истины я далёк не более чем на разницу в терминологии):

Убедимся в том, что не забыли чего-нибудь мелкого, но важного и жмём кнопку "Finish", которая на самом деле даёт команду на старт конвертации как таковой:

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

В результате мы получим или RAW-файл, свободный от привязок к какой-либо определённой системе виртуализации и готовый к применению, или VMDK-файл (готовый к применению в среде VMware), требующий переконвертации в формат RAW.