Migration BoF (meeting minutes):

/me brought up a few topics during the migration BoF, and here's my
running notes (a bit unpolished).

  - Post-copy network conectivity issues -- PeterX is working on it
     - Dave reminds: On the OpenStack side of post copy --
       https://bugzilla.redhat.com/show_bug.cgi?id=1367750
     - [Jiri] In post-copy, the VM state exists on two machines (source
       & dest).
     - [Juan] Documenting sane defaults for different scenarios in
       migration, for higher layers -- TODO
 
  - 'paused-before-switchover' QEMU feature
      - [Jiri] Shouldn't need to do anything outside libvirt
      - It gives a chance to clean up block device jobs
 
  - Native TLS encryption on NBD client/server transports
     - WIP: [libvirt]
       https://bugzilla.redhat.com/show_bug.cgi?id=1300772
     - QEMU-related stuff is merged upstream [DanPB]
       https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg03440.html
       -- [PATCH v3 00/13] Implement TLS support to QEMU NBD server &
       client
     - This is dependent on: [-blockdev / blockdev-add] 
        - Peter Krempa is wiring it up in libvirt
     - Specifying encryption keys for the part of a block chain
     - Kashyap had a hallway chat with Peter Krempa: it's currently
       possible to wire up TLS for NBD, but the parsing of the TLS
       related parameters from '/etc/libvirt/qemu.conf' is a bit of a
       pain.
        - Also better to wait for the '-blockdev' / 'blockdev-add'
          infrastructure to be fully wired in
 
  - CPU modelling infra changes in libvirt / QEMU
    ('query-cpu-model-expansion'):
     - [Kashyap] Any action items for OpenStack Nova?
     - [Jiri] If you're using 'host-model', then Nova need not to do
       anything.  But if you need persistent host model across reboots
       -- then Nova need to do something
     - [Kashyap] 
        - With this rework in libvirt / QEMU, libvirt obtains the CPUID
          info from QEMU; for named-CPU models, libvirt still refers the
          cpu_map.xml
     - [Dave] Each (libvirt) release something or the other breaks with
       CPU modelling.
        - [Jiri] When we break, we try to fix them

  - [BIOS-related] Juan: after migrating a guest from host-A to host-B,
    and reboot the guest on host-B, you'll see a different BIOS.
      - [FIXME] Fill in notes - from Juan, Jiri, and Dave
 
  - Migration with SR-IOV / other PCI devices -- "it can't work" (Juan)
     - [Michal Privoznik] There was talk at one of the past KVM Forums
     - [Dave] There's at least 4 different efforts I know of, trying to
       fix it in different ways
     - Currently: It doesn't work anyway. 
        - The dirty trick is to: Detach the guest; migrate the VM, and
          on the destination re-attach the device
        - There's no support from hardware vendors: e.g. network card
          passthrough from guest -- need a lot of state / registers, etc
          details.  With live migration, you can't just dump the
          registers and use it on the destination -- as the hardware
          simply doesn't support it.

  - [Dave] Something about mediated devices and third party vendors
    (nVIDIA, or Mellanox)
 
  - Multifd work: 
     - Currently there is a single stream for migration, this is
       problematic for various reasons
     - [Juan] A problem with existing approach: In a migration env
       (consisting host-A and host-B), the CPU on host-B -- it can't
       process enough packets, because of the single channel.  So the
       'multi-fd' approach to use several channels to resolve this
       issue.
     - Until now QEMU sends page-by-page (64 pages)
     - [Laurent] What about devices?
     - Sparse documentation.  Juan to write some more details in cover
       letters, and to update the Wiki --
       https://wiki.qemu.org/Features/Migration-Multiple-fds