Live migration zero downtime

Discussion in 'Proxmox VE: Installation and configuration' started by johnnyb911, May 25, 2017.

  1. johnnyb911

    johnnyb911 New Member

    Apr 29, 2016
    Likes Received:

    I'm wondering about live migration with zero downtime.

    Is it possible with proxmox/kvm with shared storage (glusterfs or ceph) ?

    Is it a real live migration zero downtime ?

    Thank you for your feedback or xp

  2. eric_f

    eric_f New Member

    Oct 14, 2011
    Likes Received:
    I use ceph for my shared storage and do live migration fairly regularly with zero downtime. This only woks with kvm though, using containers does incur a restart during a migration.
  3. LnxBil

    LnxBil Well-Known Member

    Feb 21, 2015
    Likes Received:
    For the record: Currently, the live migration only works "inside" a cluster, so all nodes have to be part of one cluster.
  4. guletz

    guletz Active Member

    Apr 19, 2017
    Likes Received:
    It not exist zero downtime. The downtime is aboul ms(econs). Under 1 second, it is ok for most of the case. But depends how many clients do you have, or what kind of applicantion do they use.
    Another ideea is to use haproxy for this VM, so in case of a big downtime, haproxy can route the clients to another VM.
    Also I can say that ospf can help if you can use it, in combination with some ospf capable switches ...
  5. fireon

    fireon Well-Known Member
    Proxmox Subscriber

    Oct 25, 2010
    Likes Received:
    Yes this works really great here with Ceph.
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. fortechitsolutions

    Jun 4, 2008
    Likes Received:
    Footnote on the thread, for what it might be worth.

    - Zero Downtime live migration here in proxmox, is not any less or more downtime than you might see with Xen, VMware, etc. There is always ~some millisecond level 'cut' in operation when <old is paused> and <new is lit up>. Generally the delay is such that you may, or may not, notice it if you are constantly pinging the target host being live migrated.

    As always, live-migration is contingent on the simple reality that
    -- activity inside the VM being migrated, generates RAM deltas on the source host. And possibly deltas on attached disk(s) as well (depends if you are using shared-san-style disk; or not).
    -- those changes need to be pushed from Source>>Target before the live-migrate-cut-over can happen
    -- if the rate of change inside the VM being migrated - exceeds the bandwidth you have between the 2 physical servers who are the source, target -- then your live-migration will 'stretch out' -- source machine will stay online; deltas will be copied; incrementally / iteratively ; until the target 'catches up' with the source.

    So: If your source machine "Is too damn busy" when compared to "available bandwidth for pushing the deltas" - then the live migration will in fact never happen. The cut-over time just keeps getting pushed ahead into the future. I've seen this happen on various environments (OpenStack KVM, Proxmox, etc) - it is a matter of not trying to do the impossible. Since - it is impossible. :)

    Note that proxmox, as most KVM implementations now have this feature - allows 'live migration' with non-shared storage. The catch is that - you must wait patiently for disk blocks to be copied first from source to target. Some people dislike waiting so only use shared-storage when they do live migrations. But .. it is doable .. just requires patience, depending on speed of link between proxmox nodes; and the size of the VM images being pushed through the pipe.

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice