Tw-city.info

IT Новости
3 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Перенос контроллера домена на виртуальную машину

Header Menu

Особенности развертывания виртуализированных контроллеров домена

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

Недопустимые действия при развертывании виртуализации

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

  • Не применяйте разностные виртуальные жесткие диски (VHD) на виртуальной машине, настраиваемой в качестве контроллера домена. Это слишком облегчает возврат к предыдущей версии, а также снижает производительность. Дополнительные сведения о типах виртуальных жестких дисков см. в статье «Мастер создания виртуального жесткого диска» (страница может быть на английском языке) http://go.microsoft.com/fwlink/?LinkID=137279.
  • Не клонируйте установку операционной системы без использования программы Sysprep.exe, поскольку идентификатор безопасности (SID) компьютера не будет обновлен. Дополнительные сведения об использовании программы подготовки системы (Sysprep) см. в разделе «Использование виртуальных жестких дисков» статьи «Способы развертывания операционной системы на виртуальную машину» (страница может быть на английском языке) (http://go.microsoft.com/fwlink/?LinkId=137100).
  • Чтобы предотвратить возникновение потенциально возможной ситуации отката номера последовательного обновления (USN), не используйте копии VHD-файла, который представляет уже развернутый контроллер домена, для развертывания дополнительных контроллеров домена. Следующие три пункта этого списка также рекомендуются с целью предотвращения потенциально возможной ситуации отката номера последовательного обновления. Дополнительные сведения об откате номера последовательного обновления см. в Приложение A: виртуализированные контроллеры домена и проблемы репликации.
  • Не используйте функцию экспорта Hyper-V для экспорта виртуальной машины, на которой выполняется контроллер домена.

Миграция из физической в виртуальную среду

System Center Virtual Machine Manager (VMM) 2008 обеспечивает единое управление физическими компьютерами и виртуальными машинами. Кроме того, это решение предоставляет возможность миграции физического компьютера на виртуальную машину. Это процесс известен как преобразование физического компьютера в виртуальную машину (P2V). Во время процесса преобразования P2V физический контроллер домена, миграция которого осуществляется, не должен быть включен одновременно с новой виртуальной машиной, чтобы избежать ситуации отката номера последовательного обновления, как описано в Приложение A: виртуализированные контроллеры домена и проблемы репликации.

Преобразование P2V необходимо выполнить в автономном режиме, чтобы данные каталога были согласованы, когда контроллер домена вновь включится. Вариант автономного режима предлагается и рекомендуется в мастере преобразования физического сервера. Описание различий между автономным и оперативным режимами см. в статье «P2V: преобразование физических компьютеров в виртуальные машины в VMM» (страница может быть на английском языке) (http://go.microsoft.com/fwlink/?LinkId=155072). Во время преобразования P2V виртуальная машина не должна быть подключена к сети. Сетевой адаптер виртуальной машины следует включать только после завершения процесса преобразования P2V и его проверки. На этом этапе исходный физический компьютер будет отключен. Не подключайте исходный физический компьютер обратно к сети, пока жесткий диск не будет переформатирован.

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

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

Выполняется миграция на тестовую виртуальную машину одного рабочего контроллера домена из каждого домена преобразованием P2V согласно рекомендациям, приведенным в подразделе Миграция из физической в виртуальную среду. Физические рабочие компьютеры и тестовые виртуальные машины должны находиться в разных сетях, когда они вновь будут подключаться к сети. Чтобы избежать в тестовой среде откатов номера последовательного обновления, все контроллеры домена, миграция которых выполняется с физических компьютеров на виртуальные машины, должны быть отключены от сети. (Для этого необходимо остановить службу NTDS или перезагрузить компьютер в режиме восстановления служб каталогов (DSRM).) После отключения контроллеров домена от сети в среде не должны производиться обновления. Компьютеры должны оставаться отключенными от сети в процессе миграции P2V; ни один компьютер нельзя вновь подключать к сети, пока полностью не завершена миграция всех компьютеров. Дополнительные сведения об откате номера последовательного обновления см. в Приложение A: виртуализированные контроллеры домена и проблемы репликации.

Последующие тестовые контроллеры домена должны создаваться как реплики в тестовой среде.

Служба времени

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

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

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

Дополнительные сведения об установке и использовании служб интеграции см. в руководстве «Начало работы с Hyper-V» (страница может быть на английском языке) http://go.microsoft.com/fwlink/?LinkId=137146.

Хранение

Чтобы оптимизировать производительность виртуальной машины, настроенной в качестве контроллера домена, следуйте приведенным ниже рекомендациям для хранения файлов операционной системы, Active Directory и VHD-файлов.

  • Хранение на виртуальной машине. Файл базы данных Active Directory (Ntds.dit), файлы журналов и SYSVOL-файлы должны храниться на виртуальном диске, отдельном от файлов операционной системы. Интеграционные компоненты необходимо устанавливать так, чтобы для интерфейса IDE можно было использовать виртуальные драйверы вместо эмуляции. Быстродействие виртуальных SCSI- и IDE-дисков одинаково при использовании ими виртуальных драйверов.
  • Хранение VHD-файлов на узле. Рекомендации. Рекомендации по хранению на узле относятся к хранению VHD-файлов. Чтобы обеспечить максимальную производительность, не храните VHD-файлы на диске, который часто используют другие службы или приложения, например на системном диске с установленной ОС Windows узла. Каждый VHD-файл рекомендуется хранить на отдельном разделе отдельно от операционной системы узла и остальных VHD-файлов. Оптимальная конфигурация достигается при хранении каждого VHD-файла на отдельном физическом диске.
  • Виртуальные жесткие диски фиксированного объема в сравнении с транзитными дисками. Существует много способов конфигурации хранилища для виртуальных машин. Если используются VHD-файлы, то виртуальные жесткие диски фиксированного объема более эффективны, чем динамические виртуальные жесткие диски, поскольку память для виртуальных жестких дисков фиксированного объема выделяется при их создании. Транзитные диски, используемые виртуальными машинами для доступа к физической среде хранения, еще лучше оптимизированы для обеспечения высокой производительности. Транзитные диски, по существу, являются физическими дисками или логическими номерами устройств (LUN), подключенными к виртуальной машине. Транзитные диски не поддерживают функцию создания моментального снимка. Поэтому транзитные диски являются предпочтительной конфигурацией жестких дисков, поскольку не рекомендуется использовать моментальные снимки для контроллеров домена.
Читать еще:  Доверие между доменами

Чтобы уменьшить вероятность повреждения данных Active Directory, используйте SCSI-контроллеры или отключите кэширование записей на ATA/IDE-дисках.

Перенос контроллера домена на виртуальную машину

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

А что делать хостовой машине в домене?
Правильный вопрос
Nitalex
контроллер домена виртуализировать можно, но очень не желательно и это то же верно. Конкретно была проблема -основной DC был на vmware — MDAEMON на реальной машине. LDAP запросы с демона в упор не проходили на DC. Это то, с чем я столкнулся. Но когда бекапный сервер сидел на vmware server проблем не наблюдалось (хостовая машины не включена в домен — по мимо DC на ней крутился wsus).

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

skiper
основной DC был на vmware — MDAEMON на реальной машине. LDAP запросы с демона в упор не проходили на DC.

Виртуалки крутились на том же хосте, что и MDAEMON? Сетевые карты — Broadcom?

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

Nitalex
на их рекомендации: контроллер домена виртуализировать можно, но очень не желательно.

Я не видел таких рекомендаций, спорить не буду.
Вот только VMware не могут вообще давать таких рекомендаций, т.к. их должны давать в MS.
А от MS я видел много примеров ЗА и ни одной рекомендации ПРОТИВ.

Akina
А что делать хостовой машине в домене?

Хост тоже можно ввести в домен. Вопрос действительно в другом: надо ли оно?

OlegP@
Приведите эти примеры, которые ЗА.

1. Любой вебкаст на тему виртуализации средствами MS.
Если интересно, честно рекомендую www.hyper-v.ru, вэб-касты на тему виртуализации серверов.
2. Живые примеры, вот первый, что вспомнилось: Домен из виртуалок. (http://social.technet.microsoft.com/Forums/ru-RU/virtualizationru/thread/205b7184-c8a8-4a67-9803-20c0c35c1d73)

Кстати, ссылка на KB888794 по вашему ЗА или ПРОТИВ?

ЗА, но в этой статье не много нового.
К примеру, то же замечание про снапшоты и DC было еще (и есть) в справочной системе к MS Virtual Server 2005.

Alex Pr
1. Любой вебкаст на тему виртуализации средствами MS
Не серьезно либо нужно конкретнее.

Живые примеры, вот первый, что вспомнилось
Чтобы было убедительно, надо с того форума дать ссылку на ваш поста #10 и дописать ixbt «ЗА».

ЗА, но в этой статье не много нового.
Не согласен. Сможете отстоять свое мнение?

Виртуалки крутились на том же хосте, что и MDAEMON
на разных физических машинах. но как сказал Sola

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

OlegP@
Не согласен. Сможете отстоять свое мнение?

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

Я этим вопросом хотел узнать мнение Alex Pr. Он считаем что ЗА

Да. я считаю что ЗА, т.к. не вижу в этой статье серьезных рекомендаций против:
1. рекомендации по резервному питанию, кешу физических дисков, не использованию «снимков» системы, не использованию разделяемых дисков (differencing disks), не использование ф-ии «паузы» виртуальной машины, правильному резервному копированию. рекомендациями «против» нисколько не считаю.
Почему? Просто это изначально должно быть понятно. И если провести параллель между контроллером домена на физической машине, то видно что часть рекомендаций просто перенесена в виртуальную среду и все.

2. Производительность FSMO и Глобальный каталог.
Да, с этим есть нюансы. Только обращу ваше внимание, что эта статья применима к:
цитата: Windows Server 2008 Virtualization with Hyper-V
Microsoft Virtual PC
Microsoft Virtual Server 2005
EMC VMware family of virtualization products
Novel family of virtualization products
Т.е. общая для всех этих продуктов виртуализации, а не конкретно к к одному.

Если просмотреть старые документы Microsoft, то можно наткнуться даже на такой:
Running Domain Controllers in Virtual Server 2005 (http://www.microsoft.com/downloads/details.aspx?FamilyID=64db845d-f7a3-4209-8ed2-e261a117fc6b&displaylang=en)
Документ датируется аж 2004-ым годом, — в нем можно без проблем увидеть такие рекомендации, цитирую часть:
цитата:
Certain domain controller roles require a higher level of availability and performance than others. Domain controllers installed in virtual machines are not recommended for the following roles:
• Operations master role holders (also called flexible single-master operations, or FSMOs): PDC emulator, RID master, infrastructure master, domain naming master, and schema master.
• Global catalog servers that service Exchange clients. Exchange servers are highly dependent on the responsiveness of global catalog servers.
• Bridgehead servers. These servers send and receive intersite replication. In addition to being required to handle significant network traffic, bridgehead servers that experience performance issues can have widespread impact on other services.
Теперь, объединив информацию из стати, приведенной ранее lap и и документ Running Domain Controllers in Virtual Server 2005 скажу следующее (ИМХО):

Актуальность рекомендаций производительности морально устарела и относится к устаревшим продуктам виртуализации предыдущего поколения, в частности — Virtual Server 2005 в последнем документе.

Если вести разговор о современной виртуализации, а значит средствами Hyper-V, то, пожалуйста:

Обращу ваше внимание на раздел Planning Considerations for Virtualized Domain Controllers (http://technet.microsoft.com/en-us/library/dd348476.aspx)
цитата:
Lightweight Directory Access Protocol (LDAP) tests were run on a physical domain controller with ADTest.exe and then on a virtual machine that was hosted on a server that was identical to the physical domain controller. Only one logical processor was used for the physical computer, and only one virtual processor was used for the virtual machine to easily reach 100-percent CPU utilization. In the following table, the letter and number in parenthesis after each test indicate the specific test in ADTest.exe. As this data shows, virtualized domain controller performance was 88 to 98 percent of the physical domain controller performance.
Далее в этой статье приводятся таблица с тестами производительности, если вы посмотрите документ Running Domain Controllers in Virtual Server 2005 (там такой таблицы, есть лишь общий взгляд на производительность), то увидите, что потери в производительности сильно разнятся и уже LDAP не будет ограничивающим фактором для принятия решения — стоит ли виртуализировать контроллер домена.

Ну и последнее, что не столь изменилось:
цитата:
Operations master roles
Domain controllers that hold most operations master (also known as flexible single master operations or FSMO) roles do not have significantly more load than other domain controllers. Therefore, they do not need special consideration for virtualization. Bridgehead servers do not need special consideration in terms of performance.

The one exception is the primary domain controller (PDC) emulator operations master role, which in general has higher processor load than other operations master roles. As a result, you may decide to use a physical computer to host the PDC emulator role to improve performance.

Global catalog servers and Exchange
Domain controllers that are configured as global catalog servers, which typically provide directory services for servers running Microsoft Exchange Server, may experience performance loads that are greater than the other domain controllers in your network. For example, when Exchange servers expand distribution lists, they can place a significant load on the domain controllers that provide global catalog services. For performance reasons, consider using physical servers instead of virtual machines for those global catalog servers that provide
В данном случае нет утверждений «за» и «против», а конечный выбор стоит уже за нами.

Читать еще:  Доменная учетная запись

Добавление от 03.02.2009 01:59:

Musik
. нет гарантий в отношении производительности или надежности не-МS продуктов.

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

Перенос контроллера домена на виртуальную машину

Расскажу о простом и эффективном способе переноса Windows системы из физической среды в виртуальную, который я сам оттестировал на Microsoft Hyper-V Server R2 и Microsoft Windows Server 2008 R2. Последним, мигрировавшим таким образом, был контроллер домена Windows Server 2003 SP2.

Конечно, если вы поклонник “правильных” решений, у вас много свободного времени и к тому же вы любитель квестов, то я порекомендую воспользоваться возможностями System Center Virtual Machine Manager с его визардом P2V, Microsoft Virtual Server Migration Toolkit (VSMT) и Automated Deployment Service (ADS), или другими решениями аналогичной задачи.

Я же в последнем случае не рискнул воспользоваться даже утилитой Disk2vhd от Sysinternals а решил сделать все офлайн при помощи проверенного Norton Ghost.

1. Делаем образ диска/системного раздела исходной системы. Как уже сказал, я использую для этого Norton Ghost.

2. Создаем виртуальную машину с диском достаточного размера на шине IDE. (Я, к слову, в рабочей среде использую только диски фиксированного размера)

3. Подключаем вновь созданный диск в хостовой системе, назначаем ему букву. В Windows Server 2008 R2 это можно сделать прямо из Диспетчера сервера/Управление дисками.

В Hyper-V Server R2 для этого придется воспользоваться diskpart-ом. Читаем “DISKPART> help select vdisk” и “DISKPART> help attach vdisk”.

4. Создаем нужных размеров разделы.

5. Делаем загрузочный раздел виртуального диска активным.

6. Помещаем загрузочную запись в MBR виртуального диска. Я использую для этого утилиту “mbrfix”. Читаем соответственно “MbrFix /?”. Если этого не сделать, то виртуальная машина не загрузится с этого диска.

7. Разворачиваем созданный образ раздела/диска. Опять же давно знакомый Norton Ghost нам в помощь.

Казалось бы, что уже можно включать виртуальную машину. Но в большинстве случаев система выпадет в синий экран с ошибкой “STOP: 0x0000007B INACCESSIBLE_BOOT_DEVICE ”. Так происходит, когда в переносимой системе используется не стандартный контроллер IDE. Теорию и практику по этому поводу можно глянуть в базе знаний Microsoft. Соответственно, нужно установить стандартный контроллер IDE вручную и мы продолжаем:

8. Подгрузим куст реестра, отвечающий за стандартный контруллер IDE, в нашу пока еще офлайн систему. Я делаю это следующим образом. В regedit.exe в ветку “HKEY_USERS” в новый раздел “123” загружаю реестр из файла “System32configSYSTEM”. В рег файле, созданном под руководством упомянутой статьи делаю массовую замену строки “HKEY_LOCAL_MACHINESYSTEMCurrentControlSet” на “HKEY_USERS123ControlSet001”. Импортирую, измененный таким образом рег файл. И выгружаю временный куст “123”.

9. Проверим наличие и если необходимо добавим в папку “%SystemRoot%System32Drivers” драйвера: Atapi.sys, Intelide.sys, Pciide.sys, Pciidex.sys. Их можно взять из установочного диска соответствующей версии Windows или файла “%SystemRoot%Driver CacheI386Driver.cab”.

10. Отключим виртуальный диск от хостовой системы.

11. Загружаем виртуальную машину.

Дальше на ваше усмотрение, но я рекомендую также проделать:

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

2. Очистить систему от лишних устройств. Обычно диспетчер устройств не показывает отсутствующие девайсы. Но системная переменная “devmgr_show_nonpresent_devices” со значением “1” заставляет его это делать. Соответственно, установив эту переменную, я выставляю в диспетчере устройств “ВидПоказывать скрытые устройства” и вручную удаляю все не активные девайсы.

На этом этапе перенос Windows из физической среду в виртуальную можно считать завершенным.

Импорт и экспорт в Hyperv или перенос виртуальных машин

10 сентября 2019

Импорт и экспорт в Hyper V это возможность копирование и переноса виртуальных машин. Эта возможность используется в тестовой среде, когда у нас есть образ или шаблон машины и для переноса с одного сервера на другой. Я так же слышал, что кто-то использует эту возможность как резервное копирование. Мы рассмотрим на примерах с GUI и в Powershell.

Если вы хотите создать шаблон виртуальной машины, то перед экспортом нужно сделать sysprep. Что бы просто перенести виртуальную машину Hyper V этого делать не надо.

Sysprep — это утилита сброса уникальных идентификаторов. Когда в одной сети находятся машины с одинаковыми идентификаторами могут быть ошибки и конфликты. После сброса идентификаторов нужно будет заново устанавливать те данные, которые требуются при первой установке Windows. Я бы крайне рекомендовал делать эту операцию во избежание проблем. Вы можете запустить эту команду из CMD:

Либо запустить файл sysprep.exe в этой папке:

И подтвердить действия с этими настройками:

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

Экспорт Hyper V

Теперь выполним экспорт виртуальной машины Hyper V, в этот момент ВМ может быть включена. Нажмите на нее правой кнопкой и найдите кнопку экспорта:

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

После этого мы выполнили в Hyper V копирование виртуальной машины.

Импорт Hyper V

Что бы выполнить в Hyper V импорт виртуальной машины нажмите следующую кнопку:

После стартового окна нам нужно будет выбрать папку, куда мы экспортировали ВМ:

Проверяем, что имя ВМ совпадает с той, которую мы хотим импортировать:

На следующем окне у нас появляется три возможных пункта клонирования виртуальной машины Hyper V. Так как ВМ тоже имеет уникальные идентификаторы этот пункт очень важен:

  • Регистрировать виртуальную машину по мету (Register the virtual machine in-place) — если файлы ВМ уже находятся там, где они должны и вы не планируете переносить их в новое место. Это может быть ВМ с подключенной флешки или iSCSI диска. В этом случае уникальный идентификатор не генерируется.
  • Восстановить виртуальную машину (Restore the virtual machine) — в отличие от предыдущего пункта все файлы переносятся в новое место, которые вы укажете в следующем окне. Уникальный идентификатор так же остается прежним.
  • Копировать виртуальную машину (Copy the virtual machine) — копирует ВМ с новым сгенерированным идентификатором. В следующем окне нужно будет указать куда копировать эти файлы. Этот случай используется когда мы используем шаблон ВМ.

Если в этот момент уже работает ВМ с этим идентификатором, то мы получим ошибку:

The operation failed because a virtual machine with the same identifier already exists. Select a new identifier and try the operation again.

Ошибка загрузки конфигурации виртуальной машины hyper v

Я выполню копирование машины, но остальные варианты аналогичны:

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

В этом окне выбирается расположение диска:

В этой ВМ адаптер подключен к другому коммутатору и его не существует на этом хосте гипервизора. Проверка коммутаторов идет по именам и если раньше коммутатор, на этом же хосте, назывался ‘Ext 1’, а затем был удален или переименован на ‘Ext 01’ вы тоже получите ошибку. Можно выбрать новый коммутатор или пропустить этот шаг:

Читать еще:  Новый домен в существующем лесу

На последнем шаге мы проверяем введенные данные и нажимаем кнопку подтверждения:

После этого ВМ импортируется и вам может понадобится подключиться к коммутатору и переименовать ее.

В обоих случаях вам нужно зайти в настройки ВМ:

Для переименовывания машины нужно зайти на вкладку «Имя»:

Если сетевых адаптеров у ВМ нет, то нужно зайти во вкладку добавления устройств и добавить сетевой адаптер:

А затем подключить к коммутатору:

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

Экспорт и импорт виртуальной машины Hyper V в Powershell

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

Получим список ВМ Hyper V, что бы узнать какую машину экспортировать:

Что бы через консоль Powershell в Hyper V скопировать виртуальную машину, в базовом варианте, нужно сделать следующее:

  • Name — имя ВМ, которую экспортируем
  • Path — путь, где будет лежать копия виртуальной машины Hyper V

Так как мы можем выполнить клонирование и включенной машины, то у нас есть несколько способов манипулировании с памятью. Для этого есть ключ CaptuteLiveState, которого нет в версии Windows Server 2012 r2 и ниже, со значениями:

  • CaptureSavedState — включает оперативную память
  • CaptureDataConsistentState — используется Production checkpoint
  • CaptureCrashConsistentState — память не сохраняется

По умолчанию используется CaptureSavedState.

Для импорта есть три варианта сохранения идентификаторов, которые описывались выше.

Если вы решили импортировать ВМ, которая уже находиться в нужной папке и с сохранением идентификаторов сделайте так:

VMCX — это файл, который лежит в папке «Virtual Machines» экспортированной ВМ. Если виртуальная машина с этим идентификатором уже есть в Hyper V вы получите ошибку:

Import-VM : Failed to create virtual machine. The operation failed because a virtual machine with the same identifier already exists. Select a new identifier and try the operation again.

Для импорта ВМ, с сохранением идентификаторов, но в новое место на диске выполните:

  • VhdDestinationPath — куда будет скопирован виртуальный диск Hyper V
  • VirtualMachinePath — куда будут скопированы файлы конфигурации виртуально машины
  • Copy — указывает, что это операция копирования
  • SnapshotFilePath — куда будут скопированы чекпоинты
  • SmartPagingFilePath — куда будет скопирован файл подкачки

Можно не указывать каждый тип файлов, а просто указать файл конфигурации в Path и действие Copy — тогда ВМ будет скопирована в местоположение указанное в настройках Hyper V.

В случае копирования VM с генерированием нового идентификатора можно сделать так:

В этом случае все файлы будут перемещены в папку, которая была указана в настройках Hyper V. Операция клонирования выполнена.

Клонирование виртуального контролера домена в Windows Server 2012

Одной из стратегических целей, которую преследует Microsoft в своих последних продуктах – виртуализация всего, что только возможно, что является естественным требованиям для тотальной миграции в облака. Специально для этого, в новых версиях Hyper-V и Active Directory, которые выходят в составе новой серверной ОС Windows Server 2012, был введен ряд существенных улучшений и дополнений. Например, Microsoft сообщает о том, что теперь в виртуальной машине Hyper-V можно запускать даже высоконагруженные сервера SQL. Кроме того Microsoft наконец-то реализовало возможность создавать полноценные виртуальные контроллеры домена.

Если вы помните, в Windows Server 2008 R2 существовали следующие проблемы с виртуализацией контроллеров домена Active Directory:

  • Нельзя создавать снапшот виртуального контроллера домена (если быть боле точным снапшот создать можно, но смысла это не имеет)
  • Виртуальный DC нельзя клонировать
  • Невозможна онлайн миграция V2V контроллера также
  • Восстановление виртуального DC средствами гипервизора невозможно
  • Для работы кластера Windows Server 2008 R2 требуется физический контроллер домена

Большинство из этих проблем связано с работой механизма USN (update sequence numbers). Вкратце напомним, в чем же была загвоздка. Для отслеживания обновлений между партнерами по репликации в лесу Active Directory используются идентификаторы USN. С помощью USN и ID вызова любой контроллер домена однозначно определяет, когда нужно принять и применить изменения в AD от партнеров по репликации, а когда переслать свои изменения. С помощью этого механизма обеспечивается непротиворечивость и актуальность базы AD.

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

В Windows Server 2012 контролеры домена теперь можно виртуализовать и работать с ними точно также, как с любой другой виртуальной машиной (можно делать снапшоты, клонировать DC и т.д.).

Данный функционал основывается на новой функции в Windows Server 2012 под названием VM-GenerationID. На данный момент эта функция поддерживается только в гипервизоре Hyper-V, но Microsoft рекомендует и другим производителям платформ виртуализации интегрировать данную функцию (в частности VMware уже заявила о поддержке технологии в следующей версии VSphere).

VM-Generation ID является функцией гипервизора и генерируется им при клонировании и или создании снапшота контроллера домена. VM-Generation ID представляет собой уникальный 128 битный идентификатор, который доступен приложениям через драйвер Windows Server 2012. Контроллер домена хранит значение VM-Generation ID в нереплицируемом атрибуте базы Active Directory. И перед применением изменений в базу Active Directory, контроллер домена сравнивает значение VM-Generation ID в своей базе AD со значением, полученным от гипервизора через драйвер Windows Server 2012. Если значения отличаются, осуществляется сброс параметров invocation ID и аннулирование RID. Таким образом контроллер домена определяет, что применен снапшот или контроллер домена клонирован, и актуализирует свою базу в соответствии с другими контроллерами домена AD.

Как клонировать виртуальный контроллер домена

Подготовка к клонированию DC

  • Требуется сервер Windows Server 2012 с ролью Hyper-V (вероятно, в будущем и другие гипервизоры будут поддерживать VM-GenerationID)
  • Установленный контроллер домена на Windows Server 2012 (физический или виртуальный) с ролью PDC. Найти сервер с ролью PDC можно с помощью команды:
  • Виртуальный контроллер домена с ОС Windows Server 2012 (не PDC), развернутый на сервере Windows Server 2012 Hyper-V server. Это тот самый контроллер домена.. который мы будем клонировать (пусть он будет называться VirtualDC1).

Чтобы контроллер домена можно было клонировать, его нужно добавить в группу Cloneable Domain Controllers. Сделать это можно с помощью консоли Active Directory Users and Computers, панели управления Active Directory Administrative Center или же команды PowerShell.

Команда PowerShell будет выглядеть так:

На исходном контролере домена (VirtualDC1) запустим команду New-ADDCCloneConfigFile , с помощью которой настраиваются IP адрес и имя нового виртуального контролера домена (клона). Пусть это будет VirtualDC2.

Примечание: в данном случае новый контроллер домена будет находится в этом же сайте. Более подробно о других параметрах клонирования можно прочитать на TechNet-е ).

После этого из графического GUI Hyper-V Manager запускаем импорт виртуальной машины, выбрав в качестве параметра опцию Copy the virtual machine (create a new unique ID).

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

Ссылка на основную публикацию
Adblock
detector