Mastering Windows Server 2016 Hyper-V

location:

http://www.savilltech.com/videos/sharednothinglivemigration/sharednothinglivemigration.wmv
The move can also be initiated using the Move-VM PowerShell cmdlet.

In my experience, the Shared Nothing Live Migration can be one of the most
troublesome migrations to get working, so here are my top troubleshooting tips:

First,  make    sure    that    you have    adhered to  the requirements    I   listed  previously.

Check   the Event   Viewer  for detailed    messages.   The location    to  check   is

Applications    and Services    Logs    ➣   Microsoft   ➣   Windows ➣   Hyper-V-VMMW    ➣

Admin.

Make    sure    that    the IP  configuration   is  correct between the source  and target. The

servers must    be  able    to  communicate.    Try pinging the target  Live    Migration   IP

address from    the source  server.

Run the following   PowerShell  command in  an  elevated    session to  show    the IP

addresses   being   used    for a   server  and the order   in  which   they    will    be  used:

gwmi    -n  root\virtualization\v2  Msvm_VirtualSystemMigrationService  |`

    select  MigrationServiceListenerIPAddressList

Make    sure    that    the Hyper-V (MIG-TCP-In)    firewall    exception   is  enabled on  the

target.

The target  server  must    be  resolvable  by  DNS.    Try an  nslookup    of  the target  server.

On  the target  server, run the command ipconfig    /registerdns,   and then    run

ipconfig    /flushdns   on  the source  server.

On  the source  server, flush   the Address Resolution  Protocol    (ARP)   cache   with    the

command arp -d  *.

To  test    connectivity,   try a   remote  WMI command to  the target  (the    Windows

Management  Instrumentation,    WMI-In, firewall    exception   must    be  enabled on  the

target),    such    as  the following:

gwmi    -computer   <DestinationComputerName>   ‐n  root\virtualization\v2

Msvm_VirtualSystemMigrationService

Try changing    the IP  address used    for Live    Migration;  for example,    if  you’re

currently   using   10.1.2.0/24,    try changing    to  the specific    IP  address (for    example,

10.1.2.1/32).   Also    check   any IPsec   configurations  or  firewalls   between the sources

and target. Check   for multiple    NICs    on  the same    subnet  that    could   be  causing

problems,   and if  you find    any,    try disabling   one of  them.

Try setting authentication  to  CredSSP,    and initiate    locally from    a   Hyper-V server. If

this    works,  the problem is  the Kerberos    delegation.

The most common problems I have seen are a misconfiguration of Kerberos and the
IP configuration, but failing to resolve the target server via DNS will also cause