Перенос виртуальной машины hyper v на физический сервер: как перенести виртуальные машины Hyper-V, да побыстрее / Блог компании DataLine / Хабр

Содержание

как перенести виртуальные машины Hyper-V, да побыстрее / Блог компании DataLine / Хабр

     «Любишь Hyper-V – люби и PowerShell»
     Первое правило Сообщества Hyper-V в Телеграм 

     «А если любишь VMware ESXi, то люби PowerShell на пару с ESXi CLI и REST API»
     Дополнено мной

Живая миграция (live migration) – популярная функция в Hyper-V. Она позволяет переносить работающие виртуальные машины без видимого простоя. В сети много инструкций по переносу ВМ, но многие из них устарели. Вдобавок не все заглядывают в расширенные настройки и правильно используют возможности Live Migration. 

Я собрал нюансы и неочевидные параметры для быстрого переноса ВМ внутри кластера и между кластерами. Заодно поделюсь маленькими секретами в настройке и проектировании. Надеюсь, статья будет полезна начинающим админам.  

Дисклеймер: Все описанные шаги желательно сделать ДО ввода сервера Hyper-V в прод. Hyper-V никогда не прощает ошибок проектирования и подведет вас при первом удобном случае. То есть уже на следующий день.

Вспоминаем матчасть


Как обычно происходит миграция ВМ с одного узла на другой внутри кластера Hyper-V:
  1. Конфигурация ВМ копируется с одного узла кластера на другой. 
  2. Страницы памяти виртуальной машины помечаются для копирования на целевой хост, и начинается процесс их перемещения в режиме онлайн.
  3. Поскольку виртуальная машина все еще работает, страницы памяти постоянно меняются. Во время миграции Hyper-V отслеживает измененные страницы памяти и переносит их на другой хост. Процесс повторяется до тех пор, пока на первом узле кластера не останется только несколько измененных страниц.


    Копирование страниц памяти с одного узла на другой и их синхронизация.

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

Это и называется живой миграцией. Схема справедлива
для любого
гипервизора.

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

По такой схеме работает классическая живая миграция внутри Failover Cluster. Для нее нужен общий том CSV, поданный всем хостам кластера.
 
Помимо этого есть второй вид Live Migration, живая миграция в режиме «ничего общего» (Shared-Nothing Live Migration). Этот сценарий обычно используется для миграции ВМ без простоя между кластерами. Помимо страниц памяти с одного хоста Hyper-V на другой копируется диск VHD(X) с переносом и синхронизацией дельты данных, записанных на него. 

Разберем основные нюансы по настройке интерфейсов.

Задаем настройки протоколов


  1. Для начала зайдем в Hyper-V manager и откроем правым кликом настройки Hyper-V. В настройках Live Migration укажем адреса сетевых интерфейсов, к которым будет обращаться гипервизор: 


  2. Заглянем в Advanced features. Нас интересуют оба пункта: протокол аутентификации и транспорт, который используют наши ВМ.
    • Authentication protocol: по умолчанию установлен протокол CredSSP – Credential Security Support Provider Protocol. Он прост в использовании, но, если в инфраструктуре несколько кластеров, мы не сможем перенести ВМ между кластерами. 

      Мы выберем Kerberos как более безопасный и подходящий для переноса ВМ между различными кластерами.

    • Performance options: здесь выбираем сетевой протокол. Живая миграция у нас будет работать поверх Switch Embedded Team по протоколу SMB (Server Message Block). 

      Возможность использовать этот протокол появилась в Windows Server 2016. SMB по умолчанию отдает трафик в несколько портов (SMB Multi-channel). Также он прекрасно работает с RDMA – адаптером удаленного прямого доступа к памяти. Это полезно для ускорения переноса кластеров. 



  3. Kerberos позволяет переносить ВМ между кластерами, но требует настройки ограниченного делегирования (Kerberos Constrained Delegation) на объектах Computer в Active Directory. 

    Начиная с Windows Server 2016, службы работают в контексте NETWORK SERVICE, который не может имперсонироваться в AD. Так что в этом случае выбираем неограниченное делегирование (Unconstrained Delegation), но учитываем, что это довольно небезопасно:

    Если живая миграция инициируется через System Center Virtual Machine Manager (SC VMM), то дополнительной настройки не нужно. SC VMM является доверенным сервисом для переноса машин по Shared-Nothing Live Migration.

  4. Протокол SMB не требует особой настройки. Если мы находимся в доверенной среде, можно немного ускорить процесс Live Migration и отключить сквозное шифрование данных SMB:
    Set-SmbServerConfiguration -EncryptData $false -RejectUnencryptedAccess $false

    Так мы совершим меньше действий при передаче трафика и не потратим лишнее время на шифрование. В случае с кластерами оно может нам понадобиться. 

    Эти же настройки в более модном Windows Admin Center:



Разбираемся с конфигурацией сети

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

Как было раньше. Старые мануалы по переносу ВМ Hyper-V описывают сценарии с использованием технологии тиминга Load Balancing/Fail Over (LBFO). LBFO позволяла группировать физические сетевые адаптеры и создавать поверх них интерфейсы. Но были и минусы, например: не было поддержки RDMA, нельзя было выяснить, через какой порт тима будет идти трафик. А поскольку трафик живой миграции требует довольно жирного канала, это превращалось в проблему, когда все сетевые ворклоады ломились в один физический порт. 

Как сейчас. В Windows Server 2019 даже нельзя создать виртуальный свитч поверх LBFO Team. Единственным поддерживаемым решением для объединения портов сетевой карты в Hyper-V остался Switch Embedded Team (SET).  

SET агрегирует адаптеры, как и vSwitch у ESXi. Физические сетевые порты становятся патч-кордом для разных типов трафика (в том числе для ВМ), а поверх них нарезаются виртуальные интерфейсы. 

Тут нужно добавить, что в типах гипервизоров есть небольшой рассинхрон. Англоязычные авторы считают, что есть только 2 типа, но на самом деле их 3 (подробно мы с коллегами описывали их в этом посте). Когда-то гипервизоры ESX были гибридного типа (1+). Это был такой модернизированный Red Hat c ролью гипервизора. VMware ушла от этого в vSphere 4.1 и стала честным гипервизором типа 1 (bare-metal). 

Microsoft взяла опыт VMware на вооружение и реализовала Switch Embedded Team в Windows Server 2016. Эта схема показывает большую производительность и гибкость в управлении трафиком в рамках тиминга.


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

Как это влияет на процесс настройки. В Hyper-V, помимо менеджмент-интерфейса, мы обычно создаем интерфейсы для живой миграции и интерфейсы для CSV-трафика кластера. Для этого нам нужно знать количество сетевых портов, входящих в SET, – именно столько виртуальных интерфейсов нужно будет создать. Также учитываем  расположение сетевых портов на PCI-шине, количество сокетов для последующего маппинга интерфейсов по NUMA-нодам и количество физических ядер на каждом процессоре.

Посмотрим на процесс пошагово

  1. Для начала опишем сети, которые будем использовать. Предположим, у нас стандартная двухпортовая on-board сетевая карта и двухсокетная материнская плата.
  2. Создать SET через стандартный интерфейс можно с помощью Virtual Switch в VMM (Virtual Machine Manager). Если VMM нет, выполняем следующий скрипт  PowerShell на каждом хосте Hyper-V: 
    New-VMSwitch -Name "SET" –NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $True -AllowManagementOS $true -MinimumBandwidthMode Weight

    В результате мы создадим свитч с менеджмент-интерфейсом. MinimumBandwidthMode обязательно сразу задаем как weight, иначе после создания SET мы не сможем изменить этот параметр. Так пропускная способность сети будет указана в относительных числах. Это понадобится для настройки Network QoS Policies (а иначе они не будут работать). 

    Если мы настраиваем SET поверх RDMA-адаптеров, то MinimumBandwidthMode работать не будет ни в каком режиме. Следовательно, Network QoS Policies при включенном RDMA тоже работать не будут.

  3. Алгоритм балансировки выставляем в Dynamic вместо дефолтного Hyper-V Port (в Windows Server 2019). Dynamic использует лучшие аспекты режимов Address Hash и Hyper-V Port и хорошо обрабатывает и входящий, и исходящий трафик: 
    Set-VMSwitchTeam "SET" -LoadBalancingAlgorithm Dynamic

    Здесь нужно быть очень внимательным, особенно если мы создаем SET через SC VMМ и оставляем балансировку Host Default. В Windows Server 2016 алгоритмом по умолчанию был Dynamic. В Windows Server 2019 дефолтный алгоритм по непонятным причинам изменили на Hyper-V Port, так что можно и ошибиться.
  4. Когда мы создали свитч, IP-адрес первого физического интерфейса мигрирует на виртуальный интерфейс свитча. 

    После этого мы создаем сетевые интерфейсы по количеству физических портов на сетевой карте и «прибиваем» CSV-трафик и трафик живой миграции к каждому порту: 

    # Создаем виртуальные сетевые адаптеры Live Migration
    Add-VMNetworkAdapter –ManagementOS –Name "LiveMigration01" –SwitchName MGMT-Switch -NumaAwarePlacement $true
    Add-VMNetworkAdapter –ManagementOS –Name "LiveMigration02" –SwitchName MGMT-Switch -NumaAwarePlacement $true
    
    # Задаем VLAN
    Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "LiveMigration*" -VlanId 2 -Access
    
    #Задаем IP-адреса для адаптеров
    New-NetIPAddress –InterfaceAlias "vEthernet (LiveMigration01)" -IPAddress 192.168.2.2 -PrefixLength 24 -Confirm:$false
    New-NetIPAddress –InterfaceAlias "vEthernet (LiveMigration02)" -IPAddress 192.168.2.3 -PrefixLength 24 -Confirm:$false
    
    # Создаем виртуальные сетевые адаптеры CSV-трафика
    Add-VMNetworkAdapter –ManagementOS –Name "CSV01" –SwitchName MGMT-Switch -NumaAwarePlacement $true
    Add-VMNetworkAdapter –ManagementOS –Name "CSV02" –SwitchName MGMT-Switch -NumaAwarePlacement $true
    
    # Задаем VLAN
    Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "CSV*" -VlanId 3 -Access
    
    # Задаем IP-адреса для адаптеров
    New-NetIPAddress –InterfaceAlias "vEthernet (CSV01)" -IPAddress 192.168.3.2 -PrefixLength 24 -Confirm:$false
    New-NetIPAddress –InterfaceAlias "vEthernet (CSV02)" -IPAddress 192.168.3.3 -PrefixLength 24 -Confirm:$false
  5. Теперь мы должны утилизировать все доступные нам оффлоады. Например, я выкручиваю Jumbo Frames до 9K для всех типов трафика, кроме Management. 

    Тут без помощи сетевых инженеров не обойтись: потребуется настройка портов на сетевом оборудовании.  

    Set-NetAdapterAdvancedProperty -Name "NIC1" -DisplayName "Jumbo Packet" -DisplayValue 9014
    Set-NetAdapterAdvancedProperty -Name "NIC2" -DisplayName "Jumbo Packet" -DisplayValue 9014
    Set-NetAdapterAdvancedProperty -Name "vEthernet (CSV01)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes"
    Set-NetAdapterAdvancedProperty -Name "vEthernet (CSV02)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes"
    Set-NetAdapterAdvancedProperty -Name "vEthernet (LiveMigration01)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes"
    Set-NetAdapterAdvancedProperty -Name "vEthernet (LiveMigration02)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes"

    Названия свойств сильно зависят от модели сетевой карты, так как это не статические фичи Windows Server, а фичи конкретной модели сетевой карты. Чтобы использовать эти фичи, нужно ОБЯЗАТЕЛЬНО ставить драйверы от производителя сетевой карты и ни в коем случае не использовать стандартный драйвер Windows. Иначе сразу после создания SET может отвалиться сеть по Management’у. Список всех свойств сетевой карты можно получить через командлет Get-NetAdapterAdvancedProperties.
  6. Проверим, что метрики сетевых интерфейсов равны:

    Синхронизируем метрики интерфейсов и снизим приоритет интерфейсов CSV-трафика. В моем случае задавал так:

    Set-NetIPInterface -InterfaceIndex 16 -InterfaceMetric 10000
    Set-NetIPInterface -InterfaceIndex 3 -InterfaceMetric 10000
    Set-NetIPInterface -InterfaceIndex 9 -InterfaceMetric 10500
    Set-NetIPInterface -InterfaceIndex 6 -InterfaceMetric 10500
    

    Это нужно, чтобы трафик равномерно распределялся между физическими портами на равных.
  7. Если карта поддерживает RDMA, то трафик живой миграции уместно перенести на нее. RDMA позволяет двум хостам обмениваться данными в их памяти без обращения к ОС хостов и без нагрузки на CPU. Поддержку RDMA на карте проверяем с помощью командлета Get-NetAdapterRdma.


    Пример: что можно получить с помощью командлета. Скрин со statemigration.com.

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

  8. На сетевую производительность влияет расстояние до сокета процессора от конкретного порта и PCI-шины. Поэтому перейдем к маппингу виртуальных адаптеров и настройке Virtual Machine Queues (VMQ). 

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

    Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC1" -VMNetworkAdapterName "LiveMigration01"
    Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC2" -VMNetworkAdapterName "LiveMigration02"
    Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC1" -VMNetworkAdapterName "CSV01"
    Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC2" -VMNetworkAdapterName "CSV02"
  9. Настройка VMQ помогает учесть расположение на PCI-шине. По умолчанию, очереди обрабатываются нулевым ядром нулевого процессора. Это не очень хорошо: во-первых, мы его ОЧЕНЬ сильно греем, во-вторых, так мы просто не сможем выжать из сетевого порта больше 3 Гб. Это относится к трафику ВМ. Но у нас же другой трафик (SMB)! Значит, имеет смысл настроить RSS. 

    До Windows Server 2019 настройка VMQ была обязательна, пока не появился dVMMQ. Он автоматически балансирует трафик и перекидывает его с ядра на ядро, как только нагрузка доходит 90%. Так что на Windows Server 2019 сидеть и высчитывать ядра для VMQ не нужно. 

    Настраиваем так:

    Set-NetAdapterRss -Name "NIC1" -BaseProcessorGroup 0 -BaseProcessorNumber 2 -MaxProcessors 8 -MaxProcessorNumber 16
    Set-NetAdapterRss -Name "NIC2" -BaseProcessorGroup 0 -BaseProcessorNumber 16 -MaxProcessors 8 -MaxProcessorNumber 30

    Посмотрим наглядно, как это работает. Предположим, у нас есть 2 процессора с 16 физическими ядрами. Это 32 логических ядра с учетом многопоточности. Открываем Excel и выписываем по порядку ядра от 0 до 31:

    Для первого порта сетевого адаптера назначаем Base Processor Number 2. Для количества ядер берем степень двойки. В четвертой степени получим 16 – это значение задаем для MaxProcessorNumber.

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

    Через эти же командлеты можно задать и количество RSS-очередей (RSS Queues). Их количество зависит от конкретной модели сетевой карты, поэтому перед настройкой RSS Queues нужно изучить документацию к сетевой карте.


Настраиваем миграцию для кластеризованного сценария 


Со стороны Failover Cluster дополнительно выкрутим настройки таймаутов кластера:
(Get-Cluster).SameSubnetDelay = 2000
(Get-Cluster).SameSubnetThreshold = 30

  • SameSubnetDelay указывает, сколько раз в какое время мы посылаем хартбиты. По умолчанию он выставлен в 1 секунду. 

    Если узлы кластера находятся в одной сети, этого достаточно. Если они в разных сетях, то нужно настроить CrossSubnetDelay с теми же значениями.

  • SameSubnetThreshold показывает, сколько хартбитов мы можем максимально пропустить. По дефолту это 5 хартбитов, максимум – 120. Мы поставим оптимальное значение – 30 хартбитов.

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

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

Собственно, это и есть минимальный джентльменский набор настроек для корректной работы Live Migration в Hyper-V. 

Перенос виртуальной машины на физическую – Сайт ARNY.RU

Итак, нужно было перенести виртуальную, предварительно настроенную и оттестированную Ubuntu 16.04 из Hyper-V на физический машину. Опасался «подводных камней», с которыми столкнулся при обратном переносе, отличие — ОС была Windows. Оказалось, всё прозрачно.

Последовательность переноса

Первое что нужно — выключить виртуальную машину и скопировать vhd-шник.

Второе — открутить диск от физической машины и подцепить к машине, на которой будет выполняться перенос. Для подобных операций очень рекомендую купить USB док-станцию. У меня вот такая и очень ей доволен, удобно:

Далее, для переноса воспользовался программой Vhd2Disk

Программа абсолютно проста и настолько же эффективна. Посмотреть соответствие дисков можно в Управление дисками:

Перенос 5Gb прошел  менее чем за 10 минут без всяких проблем. После загрузки оказалось только, что сетевой интерфейс стал вместо eth0 — eno1. Почему так происходит почитать можно здесь. Поэтому данный интерфейс не был автоматически включен. Команда ifconfig выводит только активные интерфейсы. Посмотреть все интерфейсы, включая отключенные:

ifconfig -a

Стартовать интерфейс:

ifconfig eno1 up

Настроить новый сетевой интерфейс на автостарт:

vi /etc/network/interfaces

Настройка на DHCP:

iface eno1 inet dhcp
auto eno1

Настройка на статику:

iface eno1 inet static
address 192.168.0.1
netmask 255.255.255.0
gateway 192.168.0.254
dns-nameservers 192.168.0.254 8.8.8.8
auto eno1

Тут же, если что, можно прикрутить статический маршрут:

up route add -net 192.168.21.0 netmask 255.255.255.0 gw 192.168.0.254
или
up route add -net 192.168.21.0 netmask 255.255.255.0 eno1
или
up route add -net 192.168.21.0 netmask 255.255.255.0 gw 192.168.0.254 eno1

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

  • Маршрут следующего перехода — указывается только IP адрес следующего перехода;
  • Напрямую подключённый статический маршрут — указывается только выходной интерфейс;
  • Полностью заданный статический маршрут — указываются IP адрес следующего перехода и выходной интерфейс.
Для интерфейсов типа точка-точка можно использовать статические маршруты, указывающие на выходной интерфейс или адрес следующего перехода. Для многоточечных или широковещательных интерфейсов рекомендуется использовать статические маршруты, указывающие на адрес следующего перехода.

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

Ну и до кучи — посмотреть список маршрутов:

netstat -n -r

Посмотреть список оборудования:

lspci

Посмотреть информацию о процессоре:

lscpu

Раньше использовал VirtualBox для полигона и экспериментов, теперь всё проще — Hyper-V встроен в Windows 10 Pro и есть простой инструмент для переноса.

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

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

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

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


%WINDIR%\system32\sysprep\sysprep.exe /generalize /shutdown /oobe

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


C:\Windows\System32\Sysprep

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

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

 

Экспорт 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, что бы узнать какую машину экспортировать:


Get-VM

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


Export-VM -Name 'CentOS' -Path 'C:\VMimported\'

Где:

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

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

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

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


Export-VM -Name 'CentOS' -Path 'C:\VMimported\' -CaptureLiveState CaptureCrashConsistentState

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

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


Import-VM -Path "C:\wii\CentOS\Virtual Machines\8EA3B8C0-611B-48EF-8344-392FA71D89B6.vmcx"

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.

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


Import-VM -Path 'C:\VMimported\CentOS\Virtual Machines\8EA3B8C0-611B-48EF-8344-392FA71D89B6.vmcx' -VhdDestinationPath 'C:\NewPath\' -VirtualMachinePath 'C:\NewPath\' -Copy

Где:

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

Дополнительные ключи:

  • SnapshotFilePath — куда будут скопированы чекпоинты
  • SmartPagingFilePath — куда будет скопирован файл подкачки

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

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


Import-VM -Path "C:\wii\CentOS\Virtual Machines\8EA3B8C0-611B-48EF-8344-392FA71D89B6.vmcx" -Copy -GenerateNewId

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

Теги: #powershell

Экспорт и импорт виртуальной машины Hyper-V – WindowsTips.Ru. Новости и советы

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

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

Ниже рассмотрим процесс экспорта-импорта виртуальной машины на примере Hyper-V, входящего в состав Windows 10, детальнее.

Рассматриваемые вопросы:
  1. Экспорт виртуальной машины
  2. Экспорт снимка виртуальной машины
  3. Надежность формата экспорта Hyper-V
  4. Импорт виртуальной машины

1. Экспорт виртуальной машины

Одним из преимуществ новой версии Hyper-V, вошедшей в состав Windows Server 2012 R2, клиентских систем Windows 8.1 и 10, является способность осуществлять некоторые ресурсоемкие задачи, в частности, экспорт на лету, в процессе работы виртуальной машины, без ее остановки, даже без приостановки. Экспорт осуществляется в фоновом режиме, он проходит не быстро, поскольку задействует небольшое количество системных ресурсов, оставляя пользователю возможность работать с виртуальной машиной дальше.

Как осуществляется экспорт виртуальной машины? Выбираем в диспетчере Hyper-V нужную виртуальную машину, вызываем контекстное меню. Нам нужна команда «Экспорт».

Далее используем кнопку обзора и указываем путь хранения файлов экспорта. Жмем «Экспорт».

2. Экспорт снимка виртуальной машины

Еще одна относительно новая функция Hyper-V, которой не было в старых серверных версиях Windows – возможность экспорта отдельной контрольной точки, то есть, виртуальной машины в состоянии на момент создания этой контрольной точки. Ранее гипервизор Microsoft предусматривал только экспорт-импорт всей виртуальной машины. И в случае, если нужно было состояние какой-то отдельной контрольной точки, приходилось экспортировать виртуальную машину со всеми ее контрольными точками, а после импорта делать откат к нужной. Сейчас Hyper-V позволяет экспортировать каждую отдельную контрольную точку. Экспортировав отдельный снапшот, его можно затем импортировать как новую виртуальную машину, в частности, со своим уникальным идентификатором на том же сервере или компьютере.

Чтобы осуществить экспорт виртуальной машины из контрольной точки, выбираем в диспетчере Hyper-V и машину, и контрольную точку. На последней вызываем контекстное меню и выбираем «Экспорт».

3. Надежность формата экспорта Hyper-V

Экспорт виртуальной машины Hyper-V осуществляется не в какой-нибудь отдельный сжатый формат файла, куда помещаются и виртуальный жесткий диск, и файлы конфигурации, и сохраненное состояние гостевой ОС, как, например, это предлагается механизмом экспорта-импорта в программе VirtualBox. В случае с виртуальными машинами VirtualBox экспорт-импорт возможен при участии посредника – файла формата OVA. При повреждении этого файла импорт виртуальной машины VirtualBox может не состояться. А вот в случае с Hyper-V экспорт виртуальной машины означает полное копирование виртуального жесткого диска в исходном его формате – VHDX (или VHD).

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

4. Импорт виртуальной машины

Экспортированную виртуальную машину в дальнейшем можно импортировать в совместимой версии Hyper-V в составе серверных редакций Windows и клиентских Windows 8.1 и 10.

Для импорта виртуальной машины выбираем соответствующую функцию в диспетчере Hyper-V.

Жмем «Далее» в окне приветствия мастера.

В следующем окне используем кнопку обзора и указываем путь к папке с экспортированной виртуальной машиной. Жмем «Далее».

Выбираем нужную виртуальную машину, если в указанной папке их несколько. Жмем «Далее».

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

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

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

В нашем случае имеет место быть копирование виртуальной машины, это третий тип импорта. Жмем «Далее».

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

В нашем случае просто допишем в пути (через слеш) создание отдельной папки «Копия». Жмем «Далее».

Этот же путь укажем и для файла VHDX, чтобы все находилось в одном месте. Жмем «Далее».

Завершающий этап мастера – сводка данных импорта. Жмем «Готово».

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

Все – процесс импорта осуществлен. Импортированную виртуальную машину можно запускать и тестировать.

Перенос сервера в среду виртуализации Hyper-V – Сайт ARNY.RU

Хочу поделиться своим опытом переноса. Нужно было перенести Windows 2008 Enterprise в среду Hyper-V. Сначала предполагал использовать утилиту Disk2vhd, но потом был установлен Acronis Backup Advanced и я воспользовался его встроенной возможностью при создании бекапа конвертировать бекап в виртуальную машину. Для этого достаточно при настройке свойств задания резервного копирования для пункта «Преобразование в виртуальную машину» выбрать Преобразовать, затем выбрать тип машины и месторасположение, где будут созданы файлы.

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

Не всегда импорт возможен. Так при импорте между хостами Hyper-V 2008/2008 R2 проблем нет, но если переносить с хоста Hyper-V 2008/2008 R2 на хост Hyper-V 20012 R2 и выше — непосредственно при самом импорте не будет найдено доступных машин для импорта. Решение такое:

  • Выключить виртуальные машины (VM) на хосте Hyper-V 2008/2008 R2;
  • Остановить службу Hyper-V Virtual Machine Management Service (VMMS) на хосте 2008/2008 R2;
  • Скопировать папки VM на хост Hyper-V Windows Server 2012 R2;
  • Импортировать.

Между Hyper-V 2012 R2/2016 и обратно ещё пока импортировать VM не пробовал.

Проблемы

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

но это ничего не дало. Далее при просмотре Диспетчера устройств обнаружилось, что устройство шина VMBus с восклицательным знаком, а состояние устройства — «Не найдены свободные ресурсы, которые устройство может использовать». Помогла эта статья MS. После выполнения указанных в статье действий и перезагрузки, сразу заработала мышь, появилась виртуальная сетевая карта и виртуальный видеоадаптер.

Дальше — нет доступа к сети, искал, искал, нашёл — криво создался виртуальный коммутатор (в Hyper-V 2008 R2, куда осуществлялся перенос, он называется Виртуальная сеть ), оказывается и такое бывает 🙂

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

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal server\WinStations

Отсюда понятно, что перед конвертацией сервера в виртуальную машину эту настройку нужно снять с конкретного сетевого адаптера и выставить настройку — «Все сетевые адаптеры настроены для этого протокола»:

Ну и последний пункт переноса — удаление лишних теперь программ и драйверов.

Выводы

Перед переносом:

  1. Для Windows 2008 в msconfig отметить чекбокс «Определить HAL»;
  2. Если это сервер RDP, то в Конфигурации служб терминалов выставить «Все сетевые адаптеры настроены для этого протокола».

При соблюдении этих условий перенос пройдем максимально гладко.

Следующим этапом планирую опробовать для архивирования виртуальных машин прекрасный по отзывам Veem Backup Free Edition.

Добавление от 19.11.2016

Переносил ещё одну машину — уже под управлением Windows XP на хост Hyper-V. Теперь уже воспользовался программой Disk2vhd. Программа использует теневое копирование и очень легко и просто создаёт образ прям с работающей машины. Можно выбрать конвертацию как в vhd, так и в более новый vhdx. После переноса та же проблема — неправильный драйвер уровня аппаратных абстракций HAL,  поэтому нет виртуальных устройств и не работает мышь. Опция Disk2vhd «Подготовить машину к переносу в виртуальную среду» не помогла, опции «Определить HAL», которая есть в Windows 2008, в Windows XP нет. Решилось установкой служб интеграции, ещё можно попробовать напрямую указать HAL в Boot.ini, это же делает и опция «Подготовить машину к переносу в виртуальную среду», но драйвер она подписывает неправильный. Должно быть, как я понял:

multi(0)disk(0)rdisk(0)partition(1)\WINNT="Microsoft Windows XP" /HAL=hal.dll

Как переместить виртуальную машину Hyper-V 3.0

Добрый день уважаемые читатели блога, я продолжаю знакомить вас с виртуализацией на базе Microsoft Hyper-V 3.0 и сегодня мы рассмотрим, как переместить виртуальную машину, с одного хоста на другой, в идеале без простоев и без наличия централизованных утилит управления, по типу SCVMM 2012 R2 и без общего хранилища. Думаю для начинающих системных администраторов, это будет полезно.

live migration в Hyper-V

Перемещение виртуальной машины или как его еще называют live migration, появилась в рабочем виде только в Hyper-V 3.0 в операционной системе Windows Server 2012 R2. В данной версии его существенно улучшили и теперь он работает без общего хранилища и без кластера, от вас лишь в идеале потребуется гигабитное сетевое подключение, между участниками перемещения.

Хочу отметить, что основной фишкой live migration, является то, что виртуальная машина продолжает работать, нет простоя

Что переносится при live migration

  • Виртуальные машины
  • Виртуальные диски
  • Содержимое оперативной памяти
  • Состояние процессора

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

Требования live migration

Давайте определимся, что необходимо для успешного перемещения виртуальной машины на Hyper-V 3.0:

  • Логично, что нам нужно минимально два хоста виртуализации, первый это источник перемещения, а второй, хост назначения.
  • У хоста назначения, должно хватать ресурсов, чтобы принять виртуальную машину
  • Обязательное требование, это процессоры должны быть одного семейства, если у вас процессор intel, то перевезти на AMD у вас не получиться, такие же ограничения были и у vMotion Vmware
  • Сетевое подключение между хостами Hyper-V 3.0, желательно должно быть 1 гб/сек, можно даже под это дело выделить отдельную сетевую карту с другим VLAN ID.
  • В некоторых случаях виртуальные коммутаторы на обоих хостах должны называться одинаково, чтобы избежать ошибок перемещения.

И так на первом хосте, у меня есть виртуальная машина с именем dc7, ее я хочу переместить на другой хост Hyper-V. Для этого щелкаем по ней правым кликом и выбираем переместить.

первое окно мастера можно сразу пропускать, оно не несет ни какой полезности.

Далее у вас два варианта перемещения:

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

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

Далее вас спросят:

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

Далее задаем папку сохранения.

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

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

В диспетчере задач, можно про мониторить загрузку сети при перемещении.

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

Еще раз про живую миграцию: как перенести виртуальные машины Hyper-V, да побыстрее

Как настроить перенос работающих ВМ без простоя внутри кластера и между кластерами.

29 июля  •  Евгений Парфенов

“Любишь Hyper-V – люби и PowerShell”

© Первое правило Сообщества Hyper-V в Телеграм

 

“А если любишь VMware ESXi, то люби PowerShell на пару с ESXi CLI и REST API”

© Дополнено мной

 

Живая миграция (live migration) – популярная функция в Hyper-V. Она позволяет переносить работающие виртуальные машины без видимого простоя. В сети много инструкций по переносу ВМ, но технология развивается, а туториалы устаревают. Вдобавок не все заглядывают в расширенные настройки и правильно используют возможности Live Migration.

Поводом для статьи стала инструкция для Hyper-V 3.0. В своем материале покажу, как изменилась настройка с тех пор.

Я собрал нюансы и неочевидные параметры для быстрого переноса ВМ внутри кластера и между кластерами. Заодно поделюсь маленькими секретами в настройке и проектировании. Надеюсь, статья будет полезна начинающим админам.

Дисклеймер: Все описанные шаги желательно сделать ДО ввода сервера Hyper-V в прод. Hyper-V никогда не прощает ошибок проектирования и подведет вас при первом удобном случае. То есть уже на следующий день.

Вспоминаем матчасть

Как обычно происходит миграция ВМ с одного узла на другой внутри кластера Hyper-V:

  1. Конфигурация ВМ копируется с одного узла кластера на другой.
  2. Страницы памяти виртуальной машины помечаются для копирования на целевой хост, и начинается процесс их перемещения в режиме онлайн.
  3. Поскольку виртуальная машина все еще работает, страницы памяти постоянно меняются. Во время миграции Hyper-V отслеживает измененные страницы памяти и переносит их на другой хост. Процесс повторяется до тех пор, пока на первом узле кластера не останется только несколько измененных страниц.
Копирование страниц памяти с одного узла на другой и их синхронизация
  1. ВМ на исходном хосте выключается, оставшиеся страницы памяти копируются на целевой хост, и виртуальная машина на нем включается. Переключение происходит за доли секунды. Процесс достаточно быстрый, чтобы ни один клиент не заметил простоя.

Это и называется живой миграцией. Схема справедлива для любого гипервизора.

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

По такой схеме работает классическая живая миграция внутри Failover Cluster. Для нее нужен общий том CSV, поданный всем хостам кластера.

Помимо этого есть второй вид Live Migration, живая миграция в режиме “ничего общего”, или Shared-Nothing Live Migration. Этот сценарий обычно используется для миграции ВМ без простоя между кластерами. Помимо страниц памяти с одного хоста Hyper-V на другой копируется диск VHD(X) с переносом и синхронизацией дельты данных, записанных на него.

Разберем основные нюансы по настройке интерфейсов.

Задаем настройки протоколов

  1. Для начала зайдем в Hyper-V manager и откроем правым кликом настройки Hyper-V. В настройках Live Migration укажем адреса сетевых интерфейсов, к которым будет обращаться гипервизор:
  1. Заглянем в Advanced features. Нас интересуют оба пункта: протокол аутентификации и транспорт, который используют наши ВМ.
    • Authentication protocol: по умолчанию установлен протокол CredSSP – Credential Security Support Provider Protocol. Он прост в использовании, но, если в инфраструктуре несколько кластеров, мы не сможем перенести ВМ между кластерами.

      Мы выберем Kerberos как более безопасный и подходящий для переноса ВМ между различными кластерами.

    • Performance options: здесь выбираем сетевой протокол. Живая миграция у нас будет работать поверх Switch Embedded Team по протоколу SMB (Server Message Block).

      Возможность использовать этот протокол появилась в Windows Server 2016. SMB по умолчанию отдает трафик в несколько портов (SMB Multi-channel). Также он прекрасно работает с RDMA – адаптером удаленного прямого доступа к памяти. Это полезно для ускорения переноса кластеров.

  1. Kerberos позволяет переносить ВМ между кластерами, но требует настройки ограниченного делегирования (Kerberos Constrained Delegation) на объектах Computer в Active Directory.

    Начиная с Windows Server 2016, службы работают в контексте NETWORK SERVICE, который не может имперсонироваться в AD. Так что в этом случае выбираем неограниченное делегирование (Unconstrained Delegation), но учитываем, что это довольно небезопасно.

    Если живая миграция инициируется через System Center Virtual Machine Manager (SC VMM), то дополнительной настройки не нужно. SC VMM является доверенным сервисом для переноса машин по Shared-Nothing Live Migration.

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

    Set-SmbServerConfiguration -EncryptData $false -RejectUnencryptedAccess $false

    Так мы совершим меньше действий при передаче трафика и не потратим лишнее время на шифрование. В случае с кластерами оно может нам понадобиться.

    Эти же настройки в более модном Windows Admin Center:

Разбираемся с конфигурацией сети

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

Как было раньше. Старые мануалы по переносу ВМ Hyper-V описывают сценарии с использованием технологии тиминга Load Balancing/Fail Over (LBFO). LBFO позволяла группировать физические сетевые адаптеры и создавать поверх них интерфейсы. Но были и минусы, например: не было поддержки RDMA, нельзя было выяснить, через какой порт тима будет идти трафик. А поскольку трафик живой миграции требует довольно жирного канала, это превращалось в проблему, когда все сетевые ворклоады ломились в один физический порт.

Как сейчас. В Windows Server 2019 даже нельзя создать виртуальный свитч поверх LBFO Team. Единственным поддерживаемым решением для объединения портов сетевой карты в Hyper-V остался Switch Embedded Team (SET).

SET агрегирует адаптеры, как и vSwitch у ESXi. Физические сетевые порты становятся патч-кордом для разных типов трафика (в том числе для ВМ), а поверх них нарезаются виртуальные интерфейсы.

Тут нужно добавить, что в типах гипервизоров есть небольшой рассинхрон. Англоязычные авторы считают, что есть только 2 типа, но на самом деле их 3 (подробно мы с коллегами описывали их в этом посте). Когда-то гипервизоры ESX были гибридного типа (1+). Это был такой модернизированный Red Hat c ролью гипервизора. VMware ушла от этого в vSphere 4.1 и стала честным гипервизором типа 1 (bare-metal).

Microsoft взяла опыт VMware на вооружение и реализовала Switch Embedded Team в Windows Server 2016. Эта схема показывает большую производительность и гибкость в управлении трафиком в рамках тиминга.

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

Как это влияет на процесс настройки. В Hyper-V, помимо менеджмент-интерфейса, мы обычно создаем интерфейсы для живой миграции и интерфейсы для CSV-трафика кластера. Для этого нам нужно знать количество сетевых портов, входящих в SET, – именно столько виртуальных интерфейсов нужно будет создать. Также учитываем  расположение сетевых портов на PCI-шине, количество сокетов для последующего маппинга интерфейсов по NUMA-нодам и количество физических ядер на каждом процессоре.

Посмотрим на процесс пошагово
  1. Для начала опишем сети, которые будем использовать. Предположим, у нас стандартная двухпортовая on-board сетевая карта и двухсокетная материнская плата.
Имя сети Назначение Сеть Шлюз VLAN ID Количество виртуальных адаптеров
Management Управляющий интерфейс 192.168.1.0/24 192.168.1.1 0 (Native) 1
LiveMigration Живая миграция 192.168.2.0/24   2 2
CSV CSV-трафик 192.168.3.0/24   3 2
  1. Создать SET через стандартный интерфейс можно с помощью Virtual Switch в VMM (Virtual Machine Manager). Если VMM нет, выполняем следующий скрипт  PowerShell на каждом хосте Hyper-V:

    New-VMSwitch -Name "SET" –NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $True -AllowManagementOS $true -MinimumBandwidthMode Weight

    В результате мы создадим свитч с менеджмент-интерфейсом. MinimumBandwidthMode обязательно сразу задаем как weight, иначе после создания SET мы не сможем изменить этот параметр. Так пропускная способность сети будет указана в относительных числах. Это понадобится для настройки Network QoS Policies (а иначе они не будут работать).

    Если мы настраиваем SET поверх RDMA-адаптеров, то MinimumBandwidthMode работать не будет ни в каком режиме. Следовательно, Network QoS Policies при включенном RDMA тоже работать не будут.

  2. Алгоритм балансировки выставляем в Dynamic вместо дефолтного Hyper-V Port (в Windows Server 2019). Dynamic использует лучшие аспекты режимов Address Hash и Hyper-V Port и хорошо обрабатывает и входящий, и исходящий трафик:

    Set-VMSwitchTeam "SET" -LoadBalancingAlgorithm Dynamic

    Здесь нужно быть очень внимательным, особенно если мы создаем SET через SC VMМ и оставляем балансировку Host Default. В Windows Server 2016 алгоритмом по умолчанию был Dynamic. В Windows Server 2019 дефолтный алгоритм по непонятным причинам изменили на Hyper-V Port, так что можно и ошибиться.

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

    После этого мы создаем сетевые интерфейсы по количеству физических портов на сетевой карте и “прибиваем” CSV-трафик и трафик живой миграции к каждому порту:

    # Создаем виртуальные сетевые адаптеры Live Migration
    Add-VMNetworkAdapter –ManagementOS –Name "LiveMigration01" –SwitchName MGMT-Switch -NumaAwarePlacement $true
    Add-VMNetworkAdapter –ManagementOS –Name "LiveMigration02" –SwitchName MGMT-Switch -NumaAwarePlacement $true
    
    # Задаем VLAN
    Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "LiveMigration*" -VlanId 2 -Access
    
    #Задаем IP-адреса для адаптеров
    New-NetIPAddress –InterfaceAlias "vEthernet (LiveMigration01)" -IPAddress 192.168.2.2 -PrefixLength 24 -Confirm:$false
    New-NetIPAddress –InterfaceAlias "vEthernet (LiveMigration02)" -IPAddress 192.168.2.3 -PrefixLength 24 -Confirm:$false
    
    # Создаем виртуальные сетевые адаптеры CSV-трафика
    Add-VMNetworkAdapter –ManagementOS –Name "CSV01" –SwitchName MGMT-Switch -NumaAwarePlacement $true
    Add-VMNetworkAdapter –ManagementOS –Name "CSV02" –SwitchName MGMT-Switch -NumaAwarePlacement $true
    
    # Задаем VLAN
    Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName "CSV*" -VlanId 3 -Access
    
    # Задаем IP-адреса для адаптеров
    New-NetIPAddress –InterfaceAlias "vEthernet (CSV01)" -IPAddress 192.168.3.2 -PrefixLength 24 -Confirm:$false
    New-NetIPAddress –InterfaceAlias "vEthernet (CSV02)" -IPAddress 192.168.3.3 -PrefixLength 24 -Confirm:$false
  4. Теперь мы должны утилизировать все доступные нам оффлоады.

    Например, я выкручиваю Jumbo Frames до 9K для всех типов трафика, кроме Management.

    Тут без помощи сетевых инженеров не обойтись: потребуется настройка портов на сетевом оборудовании.

    Set-NetAdapterAdvancedProperty -Name "NIC1" -DisplayName "Jumbo Packet" -DisplayValue 9014
    Set-NetAdapterAdvancedProperty -Name "NIC2" -DisplayName "Jumbo Packet" -DisplayValue 9014
    Set-NetAdapterAdvancedProperty -Name "vEthernet (CSV01)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes"
    Set-NetAdapterAdvancedProperty -Name "vEthernet (CSV02)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes"
    Set-NetAdapterAdvancedProperty -Name "vEthernet (LiveMigration01)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes"
    Set-NetAdapterAdvancedProperty -Name "vEthernet (LiveMigration02)" -DisplayName "Jumbo Packet" -DisplayValue "9014 Bytes"

    Названия свойств сильно зависят от модели сетевой карты, так как это не статические фичи Windows Server, а фичи конкретной модели сетевой карты. Чтобы использовать эти фичи, нужно ОБЯЗАТЕЛЬНО ставить драйверы от производителя сетевой карты и ни в коем случае не использовать стандартный драйвер Windows. Иначе сразу после создания SET может отвалиться сеть по Management’у. Список всех свойств сетевой карты можно получить через командлет Get-NetAdapterAdvancedProperties.

  5. Проверим, что метрики сетевых интерфейсов равны:

    Синхронизируем метрики интерфейсов и снизим приоритет интерфейсов CSV-трафика. В моем случае задавал так:

    Set-NetIPInterface -InterfaceIndex 16 -InterfaceMetric 10000
    Set-NetIPInterface -InterfaceIndex 3 -InterfaceMetric 10000
    Set-NetIPInterface -InterfaceIndex 9 -InterfaceMetric 10500
    Set-NetIPInterface -InterfaceIndex 6 -InterfaceMetric 10500

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

  6. Если карта поддерживает RDMA, то трафик живой миграции уместно перенести на нее. RDMA позволяет двум хостам обмениваться данными в их памяти без обращения к ОС хостов и без нагрузки на CPU. Поддержку RDMA на карте проверяем с помощью командлета Get-NetAdapterRdma.

    Пример: что можно получить с помощью командлета. Скрин со statemigration.com

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

  7. На сетевую производительность влияет расстояние до сокета процессора от конкретного порта и PCI-шины. Поэтому перейдем к маппингу виртуальных адаптеров и настройке Virtual Machine Queues (VMQ).

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

    Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC1" -VMNetworkAdapterName "LiveMigration01"
    Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC2" -VMNetworkAdapterName "LiveMigration02"
    Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC1" -VMNetworkAdapterName "CSV01"
    Set-VMNetworkAdapterTeamMapping -ManagementOS -PhysicalNetAdapterName "NIC2" -VMNetworkAdapterName "CSV02"
  8. Настройка VMQ помогает учесть расположение на PCI-шине. По умолчанию, очереди обрабатываются нулевым ядром нулевого процессора. Это не очень хорошо: во-первых, мы его ОЧЕНЬ сильно греем, во-вторых, так мы просто не сможем выжать из сетевого порта больше 3 Гб. Это относится к трафику ВМ. Но у нас же другой трафик (SMB)! Значит, имеет смысл настроить RSS.

    До Windows Server 2019 настройка VMQ была обязательна, пока не появился dVMMQ. Он автоматически балансирует трафик и перекидывает его с ядра на ядро, как только нагрузка доходит 90%. Так что на Windows Server 2019 сидеть и высчитывать ядра для VMQ не нужно.

    Настраиваем так:

    Set-NetAdapterRss -Name "NIC1" -BaseProcessorGroup 0 -BaseProcessorNumber 2 -MaxProcessors 8 -MaxProcessorNumber 16
    Set-NetAdapterRss -Name "NIC2" -BaseProcessorGroup 0 -BaseProcessorNumber 16 -MaxProcessors 8 -MaxProcessorNumber 30

    Посмотрим наглядно, как это работает. Предположим, у нас есть 2 процессора с 16 физическими ядрами. Это 32 логических ядра с учетом многопоточности. Открываем Excel и выписываем по порядку ядра от 0 до 31:

    Для первого порта сетевого адаптера назначаем Base Processor Number 2. Для количества ядер берем степень двойки. Получаем 16 – это значение задаем для MaxProcessorNumber.

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

    Через эти же командлеты можно задать и количество RSS-очередей (RSS Queues). Их количество зависит от конкретной модели сетевой карты, поэтому перед настройкой RSS Queues нужно изучить документацию к сетевой карте.

Настраиваем миграцию для кластеризованного сценария

Со стороны Failover Cluster дополнительно выкрутим настройки таймаутов кластера:

(Get-Cluster).SameSubnetDelay = 2000
(Get-Cluster).SameSubnetThreshold = 30
  • SameSubnetDelay указывает, сколько раз в какое время мы посылаем хартбиты. По умолчанию он выставлен в 1 секунду.

    Если узлы кластера находятся в одной сети, этого достаточно. Если они в разных сетях, то нужно настроить CrossSubnetDelay с теми же значениями.

  • SameSubnetThreshold показывает, сколько хартбитов мы можем максимально пропустить. По дефолту это 5 хартбитов, максимум – 120. Мы поставим оптимальное значение – 30 хартбитов.

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

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

Собственно, это и есть минимальный джентльменский набор настроек для корректной работы Live Migration в Hyper-V.

Преобразование физической машины в виртуальную машину Hyper-V

Блог NAKIVO> Администрирование и резервное копирование Hyper-V> Как преобразовать физическую машину в виртуальную машину Hyper-V

14 января 2019

по Майкл Бозе

Виртуализация

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

Общие характеристики и рекомендации по преобразованию P2V

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

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

Контроллер домена, работающий на физическом сервере . Лучше создать новую виртуальную машину, установить ОС Windows Server (операционную систему), развернуть роль контроллера домена (DC), синхронизировать новый DC с вашим основным DC, понизить статус вашего старого основного DC, удалить старый DC из Active Directory. (AD) Site & Services и, наконец, удалите старый контроллер домена.Повторите миграцию контроллера домена еще раз, если вам нужно использовать имя хоста и IP-адрес, которые также использовались физическим сервером с контроллером домена (поскольку два сервера не могут использовать одно и то же имя и IP-адрес одновременно). Преобразование физического сервера, на котором в настоящее время работает контроллер домена, в виртуальную машину может вызвать проблемы.

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

Системы на специальном оборудовании . Примерами таких систем могут быть машины Solaris с архитектурой SPARC, серверы macOS с архитектурой PowerPC и т. Д.

Возможные проблемы

Преобразование

P2V может вызвать некоторые проблемы. Давайте рассмотрим некоторые распространенные проблемы и причины их возникновения.

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

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

Рекомендации по устранению проблем

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

Удалите ненужные драйверы . Удалите драйверы для устройств, которые не будут использоваться виртуальной машиной. Такой подход позволяет снизить вероятность критических ошибок, которые приводят к BSOD. Будьте осторожны с драйверами контроллера диска — их удаление может сделать вашу систему незагружаемой.

Предварительная установка служб интеграции Hyper-V .Службы интеграции Hyper-V — это набор драйверов и приложений, используемых для правильной работы виртуальных машин. Перед выполнением миграции P2V установите службы Integration Services в ОС. Если невозможно установить интегрированные службы на физическом компьютере, преобразуйте физический компьютер в виртуальный. Если ваша виртуальная машина не загружается, выключите ее, подключите виртуальный диск VHD (VHDX) к системе Windows и используйте PowerShell для установки служб Integration Services на подключенный VHD (VHDX).

Наконец, имейте в виду несколько советов:

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

Инструменты для преобразования физической машины в виртуальную машину Hyper-V

Двумя наиболее популярными бесплатными инструментами для преобразования физической машины в виртуальную машину Hyper-V являются Microsoft Virtual Machine Converter (MVMC) и Disk2VHD.

Конвертер виртуальных машин Microsoft

MVMC (Microsoft Virtual Machine Converter) разработан Microsoft и используется для преобразования всей физической машины или виртуальной машины VMware, включая все диски, в виртуальную машину Hyper-V. Имейте в виду, что MVMC преобразует каждый раздел в один виртуальный диск. Если на жестком диске физического сервера есть 4 раздела, то MVMC создаст 4 отдельных файла виртуальных дисков в формате VHD (преобразование в файлы VHDX не поддерживается).Следовательно, скрытые разделы размером 100 или 350 МБ, которые автоматически создаются во время установки новых версий Windows (Windows 7 или новее), будут преобразованы в отдельные виртуальные диски.

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

Microsoft предоставляет графический интерфейс пользователя (GUI) и интерфейс командной строки (CLI) через PowerShell для Microsoft Virtual Machine Converter. Использование графического интерфейса пользователя удобно, а использование модуля PowerShell позволяет создавать сценарии для массового преобразования машин.

Преобразовать можно только машины с операционной системой Windows.Официально поддерживаемые версии — Windows Server 2008 и Windows Server 2012. Конечно, вы можете попробовать конвертировать Windows Server 2016 и другие версии Windows. Linux и другие операционные системы, такие как FreeBSD, Solaris и т. Д., Не поддерживаются. .NET Framework и BITS (Background Intelligent Transfer Service) Compact Server необходимы на машине, на которой вы устанавливаете MVMC.

Диск 2VHD

Disk2VHD — это бесплатный инструмент преобразования, разработанный Sysinternals, который был приобретен Microsoft.Этот инструмент может преобразовывать физические диски в виртуальные, но не может преобразовывать всю виртуальную машину. Обратите внимание, что ОС, работающая на физическом сервере, может быть не подготовлена ​​для работы Disk2VHD в виртуальной среде перед преобразованием дисков. Если физический диск состоит из нескольких разделов, эти разделы будут созданы на одном динамическом VHD или виртуальном диске VHDX (в отличие от разделов, преобразованных с помощью MVMC). Вы можете выбрать отдельные разделы диска для преобразования. Файл целевого виртуального диска не должен находиться на преобразованном томе.Дисковые тома, зашифрованные Bitlocker, не могут быть преобразованы.

Disk2VHD — это автономное легкое портативное приложение — его не нужно устанавливать, просто запустите EXE-файл на компьютере с Windows. Disk2VHD должен выполняться на физическом сервере, диски которого вы хотите преобразовать для импорта в виртуальную машину. Концепция заключается в следующем: вы должны преобразовать диски, затем создать новую виртуальную машину и присоединить виртуальные диски (файлы VHD или VHDX) к этой новой виртуальной машине. Поскольку Disk2VHD выполняется на работающем сервере, остановите все возможные службы, особенно службы, связанные с базой данных, чтобы обеспечить согласованность данных и согласованность приложения образа диска, который у вас будет в результате.Параметр «Использовать службу теневого копирования тома» доступен в Disk2VHD, но его использование может не повлиять на некоторые работающие приложения.

Disk2VHD может быть запущен в Windows Vista, Windows Server 2008 и более новых системах Windows (32-битных и 64-битных). Редакций для Linux и других операционных систем нет. Этот инструмент преобразования можно запустить в режиме графического интерфейса пользователя и в режиме командной строки. Параметры командной строки, включенные в приложение, позволяют создавать сценарии для преобразования физических дисков в виртуальные.

Преобразование P2V с помощью MVMC

Загрузите конвертер виртуальных машин с сайта Microsoft и установите приложение. Установка проста и объяснялась ранее в сообщении блога, посвященном преобразованию виртуальных машин VMware в виртуальные машины Hyper-V. Убедитесь, что BITS Compact Server установлен на хосте Hyper-V, который является целевым сервером.

На целевом хосте (хосте, на котором установлен MVMC) перейдите в Панель управления > Программы и компоненты> Включение или отключение компонентов Windows> Добавить компоненты и убедитесь, что функция сервера BITS Compact Server включена.

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

В этом примере есть две машины — физический сервер, который необходимо преобразовать, и сервер Hyper-V, который является конечным сервером, на котором может быть запущена виртуальная машина, которая у вас будет в результате. Запустите конвертер виртуальных машин Microsoft на конечном сервере и выберите Преобразование физической машины .Нажмите Далее .

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

Примечание: На этом этапе может возникнуть ошибка «Сервер RPC недоступен». Проверьте настройки брандмауэра — подключения инструментария управления Windows (WMI) должны быть разрешены, как показано выше.

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

Выберите тома для включения в преобразование. В этом примере на одном диске два тома. Первый том размером 100 МБ (зарезервирован системой) был создан по умолчанию во время установки Windows и используется для загрузки операционной системы. Не забудьте выбрать эту громкость. Вы также можете выбрать тип подготовки виртуального диска VHD — динамический или фиксированный.Для каждого выбранного тома создается отдельный файл VHD. Нажмите Далее , чтобы продолжить.

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

Выберите хост Hyper-V в качестве места назначения для виртуальной машины. Обратите внимание, что вы не можете выбрать хост в качестве целевого сервера, если на этом сервере не включена роль Hyper-V. Вы можете ввести localhost в качестве адреса конечного сервера, если вы выберете хост Hyper-V в качестве конечного сервера.Если вы используете брокера, введите имя или IP-адрес конечного сервера Hyper-V вместо localhost. Введите учетные данные административной учетной записи, чтобы получить доступ к серверу Hyper-V, или установите флажок Использовать мою учетную запись пользователя Windows , если ваша учетная запись имеет соответствующие права и MVMC работает на целевом хосте Hyper-V. Нажмите Далее , чтобы продолжить.

Примечание: На этом этапе вы можете столкнуться с ошибкой «Сервер RPC недоступен», если вы используете брокера, на котором запущен MVMC, и машина с Microsoft Virtual Machine Converter не может получить доступ к целевому хосту Hyper-V через удаленную процедуру Вызов.Попробуйте следующее:

  • Убедитесь, что службы RPC работают правильно. Запустите services.msc и проверьте службы со следующими именами: средство запуска процессов сервера DCOM, удаленный вызов процедур (RPC), сопоставитель конечных точек RPC.
  • Включите удаленный помощник в брандмауэре Windows, чтобы приложение могло обмениваться данными по сети.
  • Проверьте, включен ли общий доступ к файлам и принтерам в настройках сети.

Укажите сетевой путь для хранения преобразованных виртуальных дисков.Давайте сохраним виртуальные диски на E: \ virtual . Как и в этом примере, сервер MVMC и Hyper-V работают на одном компьютере, путь — \\ localhost \ e $ \ virtual . Нажмите Далее .

Выберите временное расположение на машине, на которой работает конвертер виртуальных машин, например E: \ virtual . Если вы запускаете MVMC на целевом хосте Hyper-V, вы можете использовать тот же каталог, который вы указали на предыдущем шаге, для хранения файлов виртуальных дисков.После завершения преобразования эти временные файлы будут удалены.

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

Просмотрите указанные вами сведения и нажмите Завершить , чтобы начать преобразование.

Дождитесь завершения преобразования.

Примечание: Если вы получаете сообщение об ошибке « Пространство имен \\ comp_name \ root \ microsoft \ bits не существует на сервере comp_name », проверьте, установлен ли BITS Compact Server на конечном сервере.

На этапе Преобразование диска (ов) тома на физических дисках преобразуются в виртуальные диски. Эти преобразованные виртуальные диски хранятся во временном каталоге, который вы указали.В этом каталоге создается подкаталог / MVMC / 0 (1,2,3 и т. Д.). На этапе Copy disk созданные файлы копируются из временного каталога (в этом примере E: \ virtual \ MVMC \ 0 ) в целевой каталог (в данном случае E: \ virtual \ Server2012-convert ) который вы указали в качестве сетевого пути. Этот подход полезен, когда вы используете брокера. Если вы не используете брокера, как в этом примере, а целевой сервер Hyper-V и MVMC работают на одном компьютере, то этот подход непрактичен, так как он заставляет вас тратить время на ожидание при копировании файлов с временный каталог в целевой каталог.На скриншоте ниже вы можете видеть, что файлы VHD в обоих каталогах совпадают.

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

Преобразование P2V с помощью Disk2VHD

Загрузите Disk2VHD с сайта Microsoft по этой ссылке.Извлеките файл disk2vhd.exe из загруженного вами zip-архива. Скопируйте файл disk2vhd.exe на физический компьютер, диски которого вы хотите преобразовать, а затем запустите Disk2VHD. Вы также можете найти файл Disk2vhd.chm с компактным руководством пользователя.

Интерфейс приложения простой и удобный. Установите флажки рядом с дисковыми томами, которые нужно преобразовать. Введите путь назначения для хранения файлов виртуального диска. В этом примере используется общий сетевой SMB (CIFS), отображаемый как диск S :.Вы также можете использовать внешний жесткий диск USB. Не используйте раздел, который нужно преобразовать, в качестве места назначения для файлов VHD (VHDX). В отличие от MVMC, Disk2VHD поддерживает более прогрессивный формат VHDX виртуальных дисков Hyper-V. Установите флажок Use Vhdx . Установите флажок Использовать теневое копирование тома , чтобы предотвратить несогласованность данных и транзакций из-за работы исходного компьютера во время преобразования. Вручную остановите все службы, которые можно остановить, а затем нажмите кнопку Create , чтобы начать процесс преобразования.

Дождитесь завершения преобразования. Disk2VHD может преобразовывать все тома одного физического диска в один файл VHD или VHDX. В текущем примере конвертируется тот же физический компьютер (с двумя томами на физическом диске), который был преобразован с помощью MVMC в предыдущем примере.

Импорт преобразованных дисков в ВМ

Теперь вы должны вручную создать новую виртуальную машину на сервере Hyper-V и импортировать виртуальные диски, созданные утилитой Disk2VHD, в виртуальную машину.Создание новой виртуальной машины объясняется в сообщении блога о создании новых виртуальных машин Hyper-V и в сообщении блога о кроссплатформенном восстановлении. Выберите поколение 1 для вашей виртуальной машины, если исходная физическая машина работала в режиме BIOS. Если исходная машина работала в режиме UEFI, вы можете выбрать «Поколение 2». Объем виртуальной памяти не должен быть меньше, чем на физическом сервере, но вы можете использовать динамическую память. В разделе Network вы можете выбрать виртуальный коммутатор для сетевого подключения.Вы можете использовать виртуальный коммутатор в мостовом режиме, если не хотите перенастраивать параметры сети виртуальной машины, а также параметры сети и конфигурацию приложений связанных машин.

Решающим моментом является подключение виртуальных дисков. В разделе Connect Virtual Hard Disk выберите опцию Use an existing virtual hard disk . Если у вас есть несколько файлов виртуальных дисков, вы можете добавить их позже в настройках виртуальной машины после создания новой виртуальной машины (щелкните правой кнопкой мыши виртуальную машину, выберите Settings , выберите контроллер диска, выберите жесткий диск, нажмите кнопку Добавить , и выберите файл виртуального диска).

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

Заключение

Существует два метода преобразования физических машин в виртуальные машины Hyper-V — с помощью Microsoft Virtual Machine Converter и Disk2VHD. Обе утилиты можно использовать только в системах Windows.

Использование Microsoft Virtual Machine Converter для преобразования физических машин является хорошей идеей, если выполняются требования и ОС на исходной машине находится в списке поддерживаемых операционных систем. Настроить MVMC несложно, но возможны ошибки. Поддерживается только формат виртуальных дисков VHD. Для каждого тома исходного физического диска создается один файл виртуального диска; для преобразования требуется временный каталог с объемом свободного пространства, равным используемому пространству на исходных дисках.Несмотря на ограничения, у вас есть виртуальная машина, которая в результате готова к работе.

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

Когда вы преобразовали физический компьютер в виртуальную машину, вы можете обнаружить преимущества виртуализации.Не забывайте создавать резервные копии своих виртуальных машин с помощью NAKIVO Backup & Replication!

Как преобразовать физическую машину в виртуальную машину Hyper-V

5 (100%) 7 голосов .Руководство по устранению неполадок виртуального Fibre Channel

Hyper-V — статьи TechNet — США (английский)

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

Применимо к: Windows Server 2012, Windows Server 2012R2

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

  • Понимание и опыт настройки технологий Fibre Channel.
  • Понять и опыт настройки Hyper-V.
  • Знакомство с чтением журналов событий Windows Server.

Virtual Fibre Channel позволяет пользователям Hyper-V запускать кластеризованную рабочую нагрузку на виртуальной машине, используя при этом существующие инвестиции в сеть хранения данных (SAN) Fibre Channel (FC).

Виртуализация идентификатора порта

N (NPIV) упрощает управление, а использование множественного пути через MPIO обеспечивает лучшую отказоустойчивость и более высокую производительность.

Требования для виртуального Fibre Channel

  • Одна или несколько установок Windows Server 2012 с установленной ролью Hyper-V.
  • Компьютер с одним или несколькими адаптерами хост-шины (HBA) Fibre Channel, у которых есть обновленный диск HBA, поддерживающий виртуальный Fibre Channel.
  • HBA должен поддерживать виртуализацию идентификатора N_Port ID (NPIV).
  • Виртуальный машины, настроенные для использования виртуального адаптера Fibre Channel, должны работать под управлением одной из следующих гостевых операционных систем:
    • Windows Server 2008
    • Windows Server 2008 R2
    • Windows Server 2012
    • Предварительная версия Windows Server 2012 R2
  • Хранилище, доступ к которому осуществляется через виртуальный адаптер Fibre Channel, поддерживает устройства, повторно отправляющие логические блоки.

Ограничения

  • Virtual Fibre Channel не работает с клиентскими SKU Windows.
  • На каждой виртуальной машине может быть не более 4 виртуальных HBA.
  • Оборудование может ограничивать количество виртуальных портов на физический HBA. Это ограничит количество виртуальных машин, которые могут быть связаны с каждым физическим HBA, установленным на хост.
  • Аппаратное обеспечение может ограничивать количество логических устройств на физический порт.

Ниже приводится список функций Hyper-V, совместимых с виртуальным Fibre Channel.

  • Живая миграция
  • Быстрая миграция
  • Виртуальная машина Сохранить и восстановить
  • Виртуальная машина Пауза и возобновление
  • Экспорт и импорт виртуальной машины
    • Примечание: Хранилище, связанное с виртуальной машиной в сети SAN Fibre Channel, не является частью операций экспорта / импорта.Операции будут неглубокими и будут ограничиваться виртуальной машиной и ее конфигурацией. государство.
  • Резервное копирование инициировано хостом
    • Когда параметр VSSD отслеживания изменений инкрементного резервного копирования отключен (по умолчанию), резервное копирование будет выполнено успешно с сообщением о повышении температуры в журнале событий.
    • Если включен параметр VSSD отслеживания изменений инкрементного резервного копирования, операция резервного копирования завершится ошибкой.

Ниже приводится список функций Hyper-V, несовместимых с виртуальным Fibre Channel

  • Контрольные точки (ранее известные как моментальные снимки)
  • Реплика Hyper-V

Да, FCoE поддерживается сертифицированным адаптером конвергентной сети (CNA).

Следующие шаги выполняются Hyper-V при создании виртуального порта после того, как виртуальный адаптер Fibre Channel настроил виртуальную сеть SAN:

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

Виртуальные ленточные библиотеки, настроенные с помощью виртуального адаптера Fibre Channel, поддерживаются только при использовании System Center Data Protection Manager 2012 R2 U3 или более поздней версии с сертифицированным оборудованием.Дополнительные сведения см. В разделе Совместимые ленточные библиотеки для System Center 2012 DPM. Чтобы определить, поддерживается ли ленточная библиотека виртуальным адаптером Fibre Channel, обратитесь к поставщику оборудования для ленточной библиотеки или запустите инструмент DPM Tape Library Compatibility Test. Дополнительные сведения о тесте совместимости ленточной библиотеки DPM см. В разделе Проверка. совместимость с ленточными библиотеками.

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

Запуск виртуальной машины

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

Для виртуальной машины с включенным виртуальным Fibre Channel процесс создания порта запускается, когда виртуальная машина входит в , начиная с состояния. Каждая обнаруженная логическая единица генерирует событие, которое записывается в журнал событий. Повторное сканирование шины выполняется, если в течение установленного окна тайм-аута не обнаруживаются логические блоки.Окна тайм-аута по умолчанию — 60 секунд.

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

Имя журнала: Microsoft-Windows-Hyper-V-SynthFC-Admin

Источник: Microsoft-Windows-Hyper-V-SynthFcVdev

Дата: 15.07.2013 12:20:35

Идентификатор события: 32213

Категория задачи: Нет

Уровень: Предупреждение

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestBox

Описание:

‘TempVm1’: не появились LUN для синтетического адаптера Fibre Channel HBA Fibre Channel (F5F8DD0B-5EF9-4958-9AF3-48FBF3A6C505).ВМ была запущена после тайм-аута период (90 секунд). Просмотрите сопоставления LUN для виртуального порта. (Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

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

Имя журнала: Microsoft-Windows-Hyper-V-SynthFC-Admin

Источник: Microsoft-Windows-Hyper-V-SynthFcVdev

Код события: 32200

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestComputer

Описание:

‘TempVm1’: синтетический адаптер Fibre Channel HBA Fibre Channel (F5F8DD0B-5EF9-4958-9AF3-48FBF3A6C505) запущен успешно.(Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

Виртуальная машина работает

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

Примеры журналов событий, показывающих добавление LUN ​​для работающей виртуальной машины

Имя журнала: Microsoft-Windows-Hyper-V-VMMS-Admin

Источник: Microsoft-Windows-Hyper-V-VMMS

Дата: 18.07.2013 16:50:08

Идентификатор события: 32186

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: СИСТЕМА

Компьютер: TestComputer

Описание:

Synthetic FC PNP Lun добавляет событие для имени экземпляра \\? \ SCSI # VMLUN & Ven_HP & Prod_HSV300 # 7 & 330739ef & 0 & 070300 # {6f416619-9f29-42a5-b20b-37e219ca02b0} для идентификатора виртуальной машины (E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F) и идентификатор экземпляра VDEV (F5F8DD0B-5EF9-4958-9AF3-48FBF3A6C505).

Имя журнала: Microsoft-Windows-Hyper-V-SynthFC-Admin

Источник: Microsoft-Windows-Hyper-V-SynthFcVdev

Дата: 18.07.2013 16:50:08

Идентификатор события: 32210

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestComputer

Описание:

‘TempVm1’: новый LUN ‘\\? \ SCSI # VMLUN & Ven_HP & Prod_HSV300 # 7 & 330739ef & 0 & 070300 # {6f416619-9f29-42a5-b20b-37e219ca02b0}’ был добавлен для HBA синтетического Fibre Channel. Адаптер Fibre Channel (F5F8DD0B-5EF9-4958-9AF3-48FBF3A6C505).(Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

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

Имя журнала: Microsoft-Windows-Hyper-V-VMMS-Admin

Источник: Microsoft-Windows-Hyper-V-VMMS

Дата: 18.07.2013 17:11:18

Идентификатор события: 32185

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: СИСТЕМА

Компьютер: TestComputer

Описание:

Событие удаления Synthetic FC PNP Lun для имени экземпляра \\? \ SCSI # VMLUN & Ven_HP & Prod_HSV300 # 7 & 330739ef & 0 & 070300 # {6f416619-9f29-42a5-b20b-37e219ca02b0} для виртуальной машины Идентификатор (E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F) и идентификатор экземпляра VDEV (F5F8DD0B-5EF9-4958-9AF3-48FBF3A6C505).

Имя журнала: Microsoft-Windows-Hyper-V-SynthFC-Admin

Источник: Microsoft-Windows-Hyper-V-SynthFcVdev

Дата: 18.07.2013 17:11:18

Код события: 32211

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestComputer

Описание:

‘TempVm1’: LUN ‘\\? \ SCSI # VMLUN & Ven_HP & Prod_HSV300 # 7 & 330739ef & 0 & 070300 # {6f416619-9f29-42a5-b20b-37e219ca02b0}’ удален из HBA синтетического Fibre Channel. Адаптер Fibre Channel (F5F8DD0B-5EF9-4958-9AF3-48FBF3A6C505).(Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

Виртуальная машина отключена

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

Пример журнала событий, показывающий виртуальную машину PowerOff

Имя журнала: Microsoft-Windows-Hyper-V-Worker-Admin

Источник: Microsoft-Windows-Hyper-V-Worker

Дата: 15.07.2013 12:22:47

Код события: 18502

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestComputer

Описание:

«TempVm1» был выключен.(Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

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

При сохранении виртуальной машины все операции ввода-вывода на логических модулях, подключенных к виртуальному адаптеру Fibre Channel, ставятся в очередь и могут завершиться до виртуального машина переведена в сохраненное состояние. Список LUN, доступных для HBA Virtual FC, хранится в файле сохраненного состояния. Виртуальные порты, связанные с виртуальной машиной, удаляются.

Пример журнала событий, показывающий успешное завершение операции сохранения

Имя журнала: Microsoft-Windows-Hyper-V-Worker-Admin

Источник: Microsoft-Windows-Hyper-V-Worker

Дата: 18.07.2013 17:15:24

Код события: 18510

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestComputer

Описание:

‘TempVm1’ успешно сохранен.(Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

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

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

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

Сброс виртуальной машины

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

Восстановление виртуальной машины

Когда виртуальная машина восстанавливается из сохраненного состояния, Hyper-V возобновляет работу виртуальной машины, даже если LUN недоступны.

После создания виртуального порта на физическом HBA немаскированные LUN ​​могут появиться на хосте недетерминированное количество времени. Успешное открытие каждого Доступный LUN связан с событием, которое регистрируется в журнале событий.Если LUN не отображаются как доступные в течение установленного окна тайм-аута, происходит тайм-аут, и список недоступных LUN заносится в журнал событий (пример ниже).

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

Имя журнала: Microsoft-Windows-Hyper-V-SynthFC-Admin

Источник: Microsoft-Windows-Hyper-V-SynthFcVdev

Дата: 18.07.2013 17:15:53 ​​

Идентификатор события: 32212

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestComputer

Описание:

‘TempVm1’: LUN ‘\\? \ SCSI # VMLUN & Ven_HP & Prod_HSV300 # 7 & 330739ef & 0 & 070000 # {6f416619-9f29-42a5-b20b-37e219ca02b0}’ успешно восстановлен для синтетического волокна Канальный адаптер HBA Fibre Channel (F5F8DD0B-5EF9-4958-9AF3-48FBF3A6C505).(Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

Имя журнала: Microsoft-Windows-Hyper-V-VMMS-Admin

Источник: Microsoft-Windows-Hyper-V-VMMS

Дата: 18.07.2013 17:15:53 ​​

Идентификатор события: 32186

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: СИСТЕМА

Компьютер: TestComputer

Описание:

Synthetic FC PNP Lun добавляет событие для имени экземпляра \\? \ SCSI # VMLUN & Ven_HP & Prod_HSV300 # 7 & 330739ef & 0 & 070000 # {6f416619-9f29-42a5-b20b-37e219ca02b0} для идентификатора виртуальной машины (E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F) и VDEV

Имя журнала: Microsoft-Windows-Hyper-V-SynthFC-Admin

Источник: Microsoft-Windows-Hyper-V-SynthFcVdev

Дата: 18.07.2013 17:15:53 ​​

Код события: 32200

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestComputer

Описание:

‘TempVm1’: синтетический адаптер Fibre Channel HBA Fibre Channel (F5F8DD0B-5EF9-4958-9AF3-48FBF3A6C505) запущен успешно.(Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

Имя журнала: Microsoft-Windows-Hyper-V-Worker-Admin

Источник: Microsoft-Windows-Hyper-V-Worker

Дата: 18.07.2013 17:15:54

Код события: 18500

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestComputer

Описание:

«TempVm1» запущен успешно.(Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

Примеры журналов событий, показывающих сбой при обнаружении сопоставлений LU при восстановлении виртуальной машины

Имя журнала: Microsoft-Windows-Hyper-V-SynthFC-Admin

Источник: Microsoft-Windows-Hyper-V-SynthFcVdev

Дата: 19.07.2013 11:02:33

Идентификатор события: 32206

Категория задачи: Нет

Уровень: Ошибка

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestComputer

Описание:

Ошибка при восстановлении виртуальной машины TempVm1: отсутствуют 4 LUN для синтетического Fibre Channel HBA Fibre Channel адаптера (F5F8DD0B-5EF9-4958-9AF3-48FBF3A6C505) поскольку виртуальная машина была сохранена.(Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

Имя журнала: Microsoft-Windows-Hyper-V-SynthFC-Admin

Источник: Microsoft-Windows-Hyper-V-SynthFcVdev

Дата: 19.07.2013 11:02:33

Код события: 32200

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestComputer

Описание:

‘TempVm1’: синтетический адаптер Fibre Channel HBA Fibre Channel (F5F8DD0B-5EF9-4958-9AF3-48FBF3A6C505) запущен успешно.(Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

Имя журнала: Microsoft-Windows-Hyper-V-Worker-Admin

Источник: Microsoft-Windows-Hyper-V-Worker

Дата: 19.07.2013 11:02:33

Код события: 18500

Категория задачи: Нет

Уровень: Информация

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F

Компьютер: TestComputer

Описание:

«TempVm1» запущен успешно.(Идентификатор виртуальной машины E53F0DB7-42F3-4ED2-A017-ADA49EB5CA5F)

Прежде чем виртуальную машину с настроенным виртуальным адаптером Fibre Channel можно будет переместить (перенести) на другой хост, Hyper-V проверяет, что все ресурсы SAN, используемые виртуальной машиной, доступны с целевого хоста. Такое поведение также гарантирует, что состояния резервирования SCSI не будут затронуты после выполнения динамической миграции, чтобы избежать переключения кластера при отказе.

Чтобы обойти временную чувствительность времени отключения при динамической миграции, каждый виртуальный порт Fibre Channel должен быть настроен с двумя наборами Всемирные имена (2 WWPN и WWNN).На исходной машине активен только один из них, а другой используется при миграции виртуальной машины на целевую. Hyper-V автоматически переключает две пары адресов во время динамической миграции.

В рамках предварительной проверки миграции в реальном времени виртуальная сеть SAN на целевом хосте сравнивается с тем же именем, что и у исходного хоста. В операция, которая включает в себя проверку подключения LUN с использованием второй настроенной пары WWN для виртуальной машины, выполняется после того, как виртуальная машина будет перенесена на целевой хост и будет предпринята попытка включения питания на конечном хосте.Если эта проверка не удалась, операция Live Migration завершится неудачно.

Быстрая миграция — это, по сути, сохранение виртуальной машины на исходном узле с последующей операцией восстановления виртуальной машины на целевом узле.

На исходном хосте все операции ввода-вывода на логических модулях, подключенных к адаптеру виртуального Fibre Channel, ставятся в очередь, а все невыполненные операции ввода-вывода на всех LUN. доступны для виртуального адаптера Fibre Channel. Список LUN, доступных для виртуального адаптера Fibre Channel, сохраняется в сохраненном файле состояния.Впоследствии виртуальные порты, связанные с виртуальной машиной, отключаются.

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

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

Признак

Возможная причина

Шаги по устранению неисправностей

Ошибка несовместимого / неподдерживаемого адаптера главной шины

Драйвер, комбинация прошивок не реализует NPIV

неподдерживаемых HBA подтверждается одним из следующих:

· Пользовательский интерфейс: «Это устройство или драйвер не поддерживает виртуальный Fibre Channel.”

· Журнал событий: предупреждение 32170 регистрируется VMMS при запуске

· WMI: свойство Msvm_ExternalFcPort IsHyperVCapable = False при выполнении следующего запроса:

· gwmi -n root \ virtualization \ v2 Msvm_ExternalFcPort -Property InstanceId, WWPN, IsHyperVCapable

Восстановление

· Если при запросе MSFC_FibrePortNPIVMethodsEx или MSFC_FibrePortNPIVAttributes возвращается недопустимый класс, то перестройте часть хранилища WMI Mofcomp / я c: \ windows \ system32 \ wbem \ npivwmi.МОФ

· Если HBA от Emulex, используйте OneCommand, чтобы установить для параметра драйвера хоста « EnableNPIV » значение «Включено», затем перезагрузите

.

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

.

ВМ не запускается Попытки создать виртуальный порт не удались для всех физических портов, назначенных Virtual SAN

Исправление

— Проверьте состояние каждого HBA, назначенного виртуальной сети SAN, и при необходимости исправьте

Свидетельство: состояние событий журнала событий «Нет доступного физического порта для удовлетворения запроса».

Имя журнала: Microsoft-Windows-Hyper-V-SynthFc-Admin

Источник: Microsoft-Windows-Hyper-V-SynthFcVdev

Дата: 23.07.2013 12:03:37

Идентификатор события: 32161

Категория задачи: Нет

Уровень: Ошибка

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ F0F713F5-BFD6-4EB5-B3CC-44F734E170EF

Компьютер: TestComputer

Описание:

«VM1»: операция для виртуального порта (C003FFC780230002) завершилась ошибкой:

Нет доступного физического порта для удовлетворения запроса (идентификатор виртуальной машины F0F713F5-BFD6-4EB5-B3CC-44F734E170EF).

Имя журнала: Microsoft-Windows-Hyper-V-Worker-Admin

Источник: Microsoft-Windows-Hyper-V-Worker

Дата: 23.07.2013 12:03:37

Идентификатор события: 12004

Категория задачи: Нет

Уровень: Ошибка

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ F0F713F5-BFD6-4EB5-B3CC-44F734E170EF

Компьютер: TestComputer

Описание:

‘VM1’ Синтетический Порт FibreChannel: не удалось начать резервирование ресурсов с ошибкой «Недостаточно» Системные ресурсы существуют для выполнения запрошенной услуги .'(0x800705AA). (Идентификатор виртуальной машины F0F713F5-BFD6-4EB5-B3CC-44F734E170EF)

Имя журнала: Microsoft-Windows-Hyper-V-Worker-Admin

Источник: Microsoft-Windows-Hyper-V-Worker

Дата: 23.07.2013 12:03:37

Идентификатор события: 12030

Категория задачи: Нет

Уровень: Ошибка

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ F0F713F5-BFD6-4EB5-B3CC-44F734E170EF

Компьютер: TestComputer

Описание:

«ВМ1» не удалось запустить .(Идентификатор виртуальной машины F0F713F5-BFD6-4EB5-B3CC-44F734E170EF)

ВМ не запускается

Ошибка создания виртуального порта, поскольку WWPN все еще используется из-за:

· HBA не может удалить виртуальный порт

· Невозможность ответа хоста

Доказательства: события журнала событий (см. Ниже в примерах журналов), имя WWPN указано на сервере имен фабрики

· Невозможность HBA удалить виртуальный порт может быть подтверждена по:

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

о Проверка ошибок удаления виртуального порта в журнале событий (см. Ниже в примерах журналов событий)

· Смягчение: удалите порт с помощью инструментов управления HBA, с помощью вызова WMI или перезагрузки хоста.Сообщите о проблеме поставщикам HBA и фабрики

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

фабрики, вызывающий нарушение.

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

Имя журнала: Microsoft-Windows-Hyper-V-VMMS-Admin

Источник: Microsoft-Windows-Hyper-V-VMMS

Дата: 23.07.2013 9:26:23

Идентификатор события: 32110

Категория задачи: Нет

Уровень: Ошибка

Ключевые слова:

Пользователь: СИСТЕМА

Компьютер: TestComputer

Описание:

‘TestVM’: операция виртуального порта NPIV на виртуальном порте (C003FF4CC9C5003E) завершилась ошибкой: всемирное имя порта уже существует в структуре. (идентификатор виртуальной машины 12BE2D01-D693-4488-AA5F-3715CBDA4F10)

Имя журнала: Microsoft-Windows-Hyper-V-SynthFC-Admin

Источник: Microsoft-Windows-Hyper-V-SynthFcVdev

Дата: 23.07.2013 9:26:23

Идентификатор события: 32110

Категория задачи: Нет

Уровень: Ошибка

Ключевые слова:

Пользователь: NT VIRTUAL MACHINE \ 12BE2D01-D693-4488-AA5F-3715CBDA4F10

Компьютер: TestComputer

Описание:

‘TestVM’: операция виртуального порта NPIV на виртуальном порте (C003FF4CC9C5003D) завершилась ошибкой: всемирное имя порта уже существует в структуре. (идентификатор виртуальной машины 12BE2D01-D693-4488-AA5F-3715CBDA4F10)

Имя журнала: Microsoft-Windows-Hyper-V-SynthFC-Admin

Источник: Microsoft-Windows-Hyper-V-SynthFcVdev

Дата: 23.07.2013 9:26:23

Идентификатор события: 32165

Категория задачи: Нет

Уровень: Ошибка

Ключевые слова: & nbs

.

Hyper-V 2008 R2: Руководство по выживанию в виртуальной сети — статьи TechNet — США (английский)

Эта статья находится в стадии разработки на основе сообщения в блоге Адама по адресу: http://blogs.msdn.com/adamfazio/archive/2008/11/14/understanding-hyper-v-vlans.aspx и технический документ «Общие сведения о сети с Hyper-V. « Добавьте свой практический совет .

Примечание. Эта статья основана на Hyper-V 2.0 и может не применяться к Hyper-V 3.0 (Server 2012)

Информационных материалов:

Лучшие практики сети

Hyper-V

  • Вы можете наилучшим образом управлять использованием полосы пропускания сетевых адаптеров виртуальной машины относительно сетевого адаптера хоста (также называемого родительским разделом), оставив для параметров сетевого адаптера виртуальной машины значение «autosense».»
  • Настроить не менее два физических сетевых адаптера. Если требуются дополнительные услуги, добавьте дополнительные физические сетевые адаптеры по мере необходимости.
  • Если только связь между виртуальными машинами нужно, а не с физическая машина или внешней сети, создайте частный виртуальный сеть.
  • Если только связь между виртуальными машинами и физический машина необходим, создать внутреннюю виртуальную сеть.
  • Если виртуальные машины нужно общаться со всей сетью или интернет, создать внешнюю сеть.
  • Если отдельная связь между виртуальными машинами и физический сервер машины при сохранении связи с внешней сетью, использовать внешняя сеть без виртуального сетевого адаптера в управление ОПЕРАЦИОННЫЕ СИСТЕМЫ.
  • Если два внутренний или частный виртуальные сети созданы в Hyper-V и две виртуальные машины созданы на отдельный IP подсеть, они не могут общаться друг с другом.В виртуальный коммутатор работает на слое 2 сетевой модели ISO / OSI. Для достижения маршрутизации на более высокие уровни, маршрутизатор нужно использовать, так же, как было бы сделано в физической среде. ISA 2006 или может использоваться RRAS для достижения этой функциональности.
  • При использовании внутренняя виртуальная сеть, создать исключение, чтобы включить виртуальные машины для общаться с физическим сервером.
  • При использовании виртуальных машин для связи с управление ОПЕРАЦИОННЫЕ СИСТЕМЫ, убедиться, что они находятся в одной IP-подсети.
  • Каждая виртуальная машина может иметь до 12 виртуальных сетевых адаптеров. Восемь сеть адаптеры можно назначить высокоскоростной адаптер и четыре сетевых адаптера могут быть закреплен за наследством адаптер.
  • Если опыт виртуальной машины высокая посещаемость объем, рекомендуется специально физический сетевой адаптер быть назначенным коммутатору внешней сети виртуальной машины.
  • По возможности, использовать высокоскоростной устройства в виртуальные машины, включив интеграция Сервисы.

Hyper-V в DMZ

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

Общие сведения о виртуальных локальных сетях Hyper-V

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

Идентификатор VLAN — это целое число, которое однозначно идентифицирует узел как принадлежащий к определенной VLAN. В соответствии со спецификацией 802.1Q сам идентификатор VLAN инкапсулируется в кадр Ethernet, что позволяет нескольким виртуальным машинам, использующим один и тот же физический сетевой адаптер, взаимодействовать одновременно в разных VLAN.

Во-первых, убедитесь, что ваши физические сетевые адаптеры поддерживают тегирование VLAN и что эта функция включена. ПРИМЕЧАНИЕ. Вы должны установить идентификатор VLAN либо на виртуальном коммутаторе, либо в конфигурации отдельной виртуальной машины, а не на физической сетевой карте.Идентификатор VLAN на виртуальном коммутаторе — это идентификатор, используемый операционной системой управления (также иногда называемый Хост или родительский раздел). Параметр VLAN ID в настройках отдельной виртуальной машины — это то, что будет использовать каждая виртуальная машина. ПРИМЕЧАНИЕ. На виртуальном коммутаторе можно назначить только один идентификатор VLAN. V-Switch (родительский раздел) может работать в одной VLAN, а виртуальные машины (дочерние разделы) могут работать в разных VLAN.

Настройка идентификатора VLAN на виртуальном коммутаторе хоста Настройка идентификатора VLAN на виртуальной машине

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

Помимо описанных выше сценариев, Hyper-V также поддерживает использование виртуальных локальных сетей и идентификаторов виртуальных локальных сетей с виртуальным сетевым коммутатором и виртуальными сетевыми адаптерами. Hyper-V использует 802.1q VLAN trunking для достижения этой цели.Для транкинга требуется создание виртуального сетевого коммутатора на хост, который привязан к физическому сетевому адаптеру, который поддерживает теги 802.1q VLAN.

На этой схеме показан пример использования одной физической сетевой карты в хосте, который подключен к магистрали 802.1q в физической сети, несущей три VLAN (идентификационные номера 5, 10 и 20). Цель дизайна в этом примере включает:

· Магистраль 802.1q, несущая 3 VLAN (5, 10, 20), подключена к физическому адаптеру на хосте.

· Создается один виртуальный коммутатор, который привязывается к физическому адаптеру

.

· Идентификатор VLAN виртуального коммутатора настроен на 5, что позволит виртуальному сетевому адаптеру в родительском устройстве взаимодействовать с VLAN 5

.

· Идентификатор VLAN виртуального сетевого адаптера в дочернем разделе №1 установлен на 10, что позволяет ему обмениваться данными с VLAN 10

.

· Идентификатор VLAN виртуальной сетевой карты в дочернем разделе №2 установлен на 20, что позволяет ему обмениваться данными по VLAN 20.

Ожидается, что существует один виртуальный коммутатор, родительская и две виртуальные машины (дочерний раздел 1 и дочерний раздел 2) могут общаются только через свои соответствующие VLAN, и они не могут общаться друг с другом.

Устранение неисправностей

Убедитесь, что вы используете последние версии драйверов сетевой карты, что они поддерживают тегирование VLAN и что они включены.

  1. Проверьте следующий раздел реестра, чтобы подтвердить номер VLAN-ID: HKLM: \ System \ CurrentControlSet \ services \ VMSMP \ Parameters \ SwitchList

Если вам нужна дополнительная помощь, попробуйте форумы Hyper-V TechNet http: //social.technet.microsoft.com/forums/en/winserverhyperv/threads/

Ресурсы сообщества


См. Также

.

Hyper-V: как найти хост виртуальной машины — статьи TechNet — США (английский)

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

Если в качестве ОС хоста используется Windows Server 2008 R2, а виртуальные машины на нем используют службы интеграции R2, вы можете запросить следующее:

$ [HKLM \ SOFTWARE \ Microsoft \ Virtual Machine \ Guest \ Parameters]
«HostName» =
«PhysicalHostName» = «
«PhysicalHostNameFullyQualified» =
«VirtualMachineName» =

Использование SCVMM:

Кластер Get-VMMServer.domain.com | Get-VM Server1 | Select-Object vmhost

Замените cluster.domain.com на полное доменное имя вашего кластера VMM, а Server1 на сервер, который вы ищете.

Использование PowerShell:

Этот сценарий извлекает имя хоста из реестра виртуальной машины.

Функция Get-VMHost

{

(get-item «HKLM: \ SOFTWARE \ Microsoft \ Virtual Machine \ Guest \ Parameters»). GetValue («HostName»)

}

Использование WMI и PowerShell

функция Get-VMOSDetail

{

Param (

[Параметр ()]

$ ComputerName = $ Env: ComputerName,

[Параметр ()]

$ VMName

)

# Создание HASH-таблицы для создания объекта

$ MyObj = @ {}

# Получение объекта ВМ

$ Vm = Get-WmiObject -Namespace root \ virtualization -Query "Выберите * из Msvm_ComputerSystem, где ElementName = '$ VMName'" -ComputerName $ ComputerName

# Получение сведений о виртуальной машине

$ Kvp = Get-WmiObject -Namespace root \ virtualization -Query "Ассоциаторы {$ Vm}, где AssocClass = Msvm_SystemDevice ResultClass = Msvm_KvpExchangeComponent" -ComputerName $ ComputerName

# Преобразование XML в объект

для каждого ($ CimXml дюйм $ Kvp.GuestIntrinsicExchangeItems)

{

$ XML = [XML] $ CimXml

если ($ XML)

{

каждый ($ CimProperty в ) $ XML.SelectNodes ( "/ INSTANCE / PROPERTY" ))

{

переключатель -точный ($ CimProperty.Имя)

{

«Данные» {$ Value = $ CimProperty.VALUE}

«Имя» {$ Name = $ CimProperty.VALUE}

}

}

$ MyObj.add ($ имя, $ значение)

}

}

# Вывод объекта

Новый объект -TypeName PSCustomObject -Property $ MyObj

}

Использование System Center Configuration Manager:

Этот запрос T-SQL можно использовать для создания отчета с указанием количества хостов на гостя:

ВЫБЕРИТЕ [PhysicalHostNameFullyQualifi0] AS [Полное доменное имя хоста], COUNT (PhysicalHostNameFullyQualifi0) AS [Количество гостей]
С [v_GS_VIRTUAL_MACHINE]
ГРУППА ПО [PhysicalHostNameFullyQualifi0]

Этот запрос T-SQL можно использовать для создания отчета, сопоставляющего хосты с гостями

ВЫБЕРИТЕ sys.Netbios_Name0, vm.PhysicalHostName0, vm.ResourceID
ИЗ dbo.v_GS_VIRTUAL_MACHINE AS vm
ПРИСОЕДИНЯЙТЕСЬ к v_R_System AS sys ON vm.ResourceID = sys.ResourceID

Использование MMC:

Ресурсы:


См. Также

.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *