docs/release/userguide/live_migration.userguide.rst

   1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
   2
   3 .. http://creativecommons.org/licenses/by/4.0
   4
   5 Fast Live Migration
   6 ===================
   7
   8 The NFV project requires fast live migration. The specific requirement is
   9 total live migration time < 2Sec, while keeping the VM down time < 10ms when
  10 running DPDK L2 forwarding workload.
  11
  12 We measured the baseline data of migrating an idle 8GiB guest running a DPDK L2
  13 forwarding work load and observed that the total live migration time was 2271ms
  14 while the VM downtime was 26ms. Both of these two indicators failed to satisfy
  15 the requirements.
  16
  17 Current Challenges
  18 ------------------
  19
  20 The following 4 features have been developed over the years to make the live
  21 migration process faster.
  22
  23 + XBZRLE:
  24         Helps to reduce the network traffic by just sending the
  25         compressed data.
  26 + RDMA:
  27         Uses a specific NIC to increase the efficiency of data
  28         transmission.
  29 + Multi thread compression:
  30         Compresses the data before transmission.
  31 + Auto convergence:
  32         Reduces the data rate of dirty pages.
  33
  34 Tests show none of the above features can satisfy the requirement of NFV.
  35 XBZRLE and Multi thread compression do the compression entirely in software and
  36 they are not fast enough in a 10Gbps network environment. RDMA is not flexible
  37 because it has to transport all the guest memory to the destination without zero
  38 page optimization. Auto convergence is not appropriate for NFV because it will
  39 impact guest’s performance.
  40
  41 So we need to find other ways for optimization.
  42
  43 Optimizations
  44 -------------------------
  45 a. Delay non-emergency operations
  46    By profiling, it was discovered that some of the cleanup operations during
  47    the stop and copy stage are the main reason for the long VM down time. The
  48    cleanup operation includes stopping the dirty page logging, which is a time
  49    consuming operation. By deferring these operations until the data transmission
  50    is completed the VM down time is reduced to about 5-7ms.
  51 b. Optimize zero page checking
  52    Currently QEMU uses the SSE2 instruction to optimize the zero pages
  53    checking.  The SSE2 instruction can process 16 bytes per instruction.
  54    By using the AVX2 instruction, we can process 32 bytes per instruction.
  55    Testing shows that using AVX2 can speed up the zero pages checking process
  56    by about 25%.
  57 c. Remove unnecessary context synchronization.
  58    The CPU context was being synchronized twice during live migration. Removing
  59    this unnecessary synchronization shortened the VM downtime by about 100us.
  60
  61 Test Environment
  62 ----------------
  63
  64 The source and destination host have the same hardware and OS:
  65 ::
  66 Host: HSW-EP
  67 CPU: Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
  68 RAM: 64G
  69 OS: RHEL 7.1
  70 Kernel: 4.2
  71 QEMU v2.4.0
  72
  73 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit
  74 X540-AT2 (rev 01)
  75 QEMU parameters:
  76 ::
  77 ${qemu} -smp ${guest_cpus} -monitor unix:${qmp_sock},server,nowait -daemonize \
  78 -cpu host,migratable=off,+invtsc,+tsc-deadline,pmu=off \
  79 -realtime mlock=on -mem-prealloc -enable-kvm -m 1G \
  80 -mem-path /mnt/hugetlbfs-1g \
  81 -drive file=/root/minimal-centos1.qcow2,cache=none,aio=threads \
  82 -netdev user,id=guest0,hostfwd=tcp:5555-:22 \
  83 -device virtio-net-pci,netdev=guest0 \
  84 -nographic -serial /dev/null -parallel /dev/null
  85
  86 Network connection
  87
  88 .. figure:: lmnetwork.jpg
  89    :align: center
  90    :alt: live migration network connection
  91    :figwidth: 80%
  92
  93
  94 Test Result
  95 -----------
  96 The down time is set to 10ms when doing the test. We use pktgen to send the
  97 packages to guest, the package size is 64 bytes, and the line rate is 2013
  98 Mbps.
  99
 100 a. Total live migration time
 101
 102    The total live migration time before and after optimization is shown in the
 103    chart below. For an idle guest, we can reduce the total live migration time
 104    from 2070ms to 401ms. For a guest running the DPDK L2 forwarding workload,
 105    the total live migration time is reduced from 2271ms to 654ms.
 106
 107 .. figure:: lmtotaltime.jpg
 108    :align: center
 109    :alt: total live migration time
 110
 111 b. VM downtime
 112
 113    The VM down time before and after optimization is shown in the chart below.
 114    For an idle guest, we can reduce the VM down time from 29ms to 9ms. For a guest
 115    running the DPDK L2 forwarding workload, the VM down time is reduced from 26ms to
 116    5ms.
 117
 118 .. figure:: lmdowntime.jpg
 119    :align: center
 120    :alt: vm downtime
 121    :figwidth: 80%