locked
choose live migration or quick migration in certain conditions RRS feed

  • Question

  • HI,

    i want to ask, what default method live /Quick migration is used by hyper v

     - when one node has failure/or crash by hardware/power lost, and If there is a vm on the host it will be automatically migrate by live migration or quick migration?

    - when one node has ben restart by manually, without shutdown the VM is use live/quick migration?

    because when im read many article quick migration need more downtime than live migration.

    when maintance the host ( installing memory etc), what method can i used? live migration or quick migration?

    Thanks,


    • Edited by vidzpbs Tuesday, June 30, 2020 10:19 AM
    Tuesday, June 30, 2020 10:17 AM

Answers

  • Hi,

    Thanks for posting in our Technet forum!

    Firstly, if you use HA with Failover Cluster, when a node crash, it is unable to c live migration or quick migration for the quick and live migration requires both source and destination nodes to be up and operational.

    Secondly, the High Availability means if a node has a failure, the VM on the node can be failed over to another node automatically. So you don’t have to live migration or quick migration.

    Failover for crashed VM is not always safe. When the VM running on Node1 crashed, it will be failed over to Node2 and restart. It is not a normal VM shutdown and restart. It will cause data lost. For data safety, we suggest you configure a backup or a replica for the VM at regular time.

    Hope my answer can help you. If anything unclear, please feel free to let me know.

    Best Regards,

    Ariana.

    • Proposed as answer by Ariana Zhang Monday, July 6, 2020 3:30 AM
    • Marked as answer by vidzpbs Thursday, July 9, 2020 4:07 AM
    Wednesday, July 1, 2020 9:16 AM

All replies

  • "when one node has failure/or crash by hardware/power lost, and If there is a vm on the host it will be automatically migrate by live migration or quick migration?"

    When there is a node failure, neither quick nor live migration will be used to start the VMs on a surviving node.  Both quick and live migration requires both source and destination nodes to be up and operational as both methods require the host systems to cooperate in the transfer of ownership.  In a failed node situation, a surviving node takes ownership of the VM and boots it to get it started.  This means there may be a loss of data, similar to a power fail restart on a physical machine.

    "when one node has ben restart by manually, without shutdown the VM is use live/quick migration?"

    By default, it will try to live migrate, but you can configure it to quick migrate.  Yes, quick migration requires some downtime as the machine is placed into a saved state while the ownership is moved from one node to another and then booted from the saved state.  Live migration keeps the VM running while the VM's memory is moved from one host to another.

    "when maintance the host ( installing memory etc), what method can i used? live migration or quick migration?"

    Either one.  The only caveat is that if you have dissimilar hosts in a cluster, it may be necessary to use quick migration.  This comes about because the dissimilar hosts may have different instruction sets.  A live migration can't occur because the active memory would contain hardware instructions that may not exist on the destination host.  By using quick migration, which boots from a saved state, the VM is started with the hardware instructions of the destination machine.


    tim

    Tuesday, June 30, 2020 1:45 PM
  • "when one node has failure/or crash by hardware/power lost, and If there is a vm on the host it will be automatically migrate by live migration or quick migration?"

    When there is a node failure, neither quick nor live migration will be used to start the VMs on a surviving node.  Both quick and live migration requires both source and destination nodes to be up and operational as both methods require the host systems to cooperate in the transfer of ownership.  In a failed node situation, a surviving node takes ownership of the VM and boots it to get it started.  This means there may be a loss of data, similar to a power fail restart on a physical machine.

    Hi tim, 

    thanks for your answer

    how about when i use HA with failover cluster , what automatic method when one node crash, is live or quick migration?

    Wednesday, July 1, 2020 1:28 AM
  • Hi,

    Thanks for posting in our Technet forum!

    Firstly, if you use HA with Failover Cluster, when a node crash, it is unable to c live migration or quick migration for the quick and live migration requires both source and destination nodes to be up and operational.

    Secondly, the High Availability means if a node has a failure, the VM on the node can be failed over to another node automatically. So you don’t have to live migration or quick migration.

    Failover for crashed VM is not always safe. When the VM running on Node1 crashed, it will be failed over to Node2 and restart. It is not a normal VM shutdown and restart. It will cause data lost. For data safety, we suggest you configure a backup or a replica for the VM at regular time.

    Hope my answer can help you. If anything unclear, please feel free to let me know.

    Best Regards,

    Ariana.

    • Proposed as answer by Ariana Zhang Monday, July 6, 2020 3:30 AM
    • Marked as answer by vidzpbs Thursday, July 9, 2020 4:07 AM
    Wednesday, July 1, 2020 9:16 AM
  • "how about when i use HA with failover cluster , what automatic method when one node crash, is live or quick migration?"

    Neither quick nor live migration is used in a cluster when a node fails because both of those methods require cooperative operations between two working nodes.  When a hose node fails in an uncontrolled manner, the VMs running on that node fail in a similar uncontrolled manner.  What the cluster does is it transfers ownership of the VM to a surviving node of the cluster and boots the VM to get it running again.  Depending upon what that VM, there may or may not be data loss.  There will definitely be a loss of connectivity for an extended period of time (time to transfer ownership, time to boot VM, time to start applications on VM, time to perform any automated recovery built into the applications (if any)).  Client applications will generally have to reconnect to the rebooted VM applications.

    As noted, you can enhance some aspects of HA by configuring a replica, but there is no guarantee against data loss by use of a replica.  A replica keeps a copy of the VM 'up to date' on another system, but even that is a point in time.  In other words, the replica is updated periodically, not in real-time, so there is still likely to be some amount of data loss if you have to go to a replica.  

    Some applications, such as SQL databases, are fairly robust as they have transaction logs that can be replayed when a VM is rebooted on another node.  SQL also has other methods that work in conjunction with clustering to provide highly levels of ensuring data consistency through failures.  So it is not just the cluster itself, but sometimes the application, too, which helps ensure data consistency.


    tim


    Wednesday, July 1, 2020 12:19 PM
  • Hi,

    Is your problem solved? If you use our solution to solve the problem, please mark it as an answer to help other community members quickly find useful responses. If you use your own solution to solve the problem, please share your experience and solutions here. It is also very helpful for other community members with similar problems. If not, please reply and tell us what's going on to provide further assistance.

     

    Best regards,

    Ariana.

    Friday, July 3, 2020 1:33 AM
  • Hi,

    Is your problem solved? If it is solved, please mark it as an answer to help other community members quickly find useful responses. If not, please reply and tell us what's going on to provide further assistance.

    Best regards,

    Ariana.

    Monday, July 6, 2020 2:00 AM