1. 27 10月, 2016 1 次提交
  2. 16 6月, 2016 1 次提交
    • D
      migration: rename functions to starting migrations · 22724f49
      Daniel P. Berrange 提交于
      Apply the following renames for starting incoming migration:
      
       process_incoming_migration -> migration_fd_process_incoming
       migration_set_incoming_channel -> migration_channel_process_incoming
       migration_tls_set_incoming_channel -> migration_tls_channel_process_incoming
      
      and for starting outgoing migration:
      
       migration_set_outgoing_channel -> migration_channel_connect
       migration_tls_set_outgoing_channel -> migration_tls_channel_connect
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Message-id: 1464776234-9910-3-git-send-email-berrange@redhat.com
      Message-Id: <1464776234-9910-3-git-send-email-berrange@redhat.com>
      Signed-off-by: NAmit Shah <amit.shah@redhat.com>
      22724f49
  3. 26 5月, 2016 1 次提交
    • D
      migration: add support for encrypting data with TLS · e1226365
      Daniel P. Berrange 提交于
      This extends the migration_set_incoming_channel and
      migration_set_outgoing_channel methods so that they
      will automatically wrap the QIOChannel in a
      QIOChannelTLS instance if TLS credentials are configured
      in the migration parameters.
      
      This allows TLS to work for tcp, unix, fd and exec
      migration protocols. It does not (currently) work for
      RDMA since it does not use these APIs, but it is
      unlikely that TLS would be desired with RDMA anyway
      since it would degrade the performance to that seen
      with TCP defeating the purpose of using RDMA.
      
      On the target host, QEMU would be launched with a set
      of TLS credentials for a server endpoint
      
       $ qemu-system-x86_64 -monitor stdio -incoming defer \
          -object tls-creds-x509,dir=/home/berrange/security/qemutls,endpoint=server,id=tls0 \
          ...other args...
      
      To enable incoming TLS migration 2 monitor commands are
      then used
      
        (qemu) migrate_set_str_parameter tls-creds tls0
        (qemu) migrate_incoming tcp:myhostname:9000
      
      On the source host, QEMU is launched in a similar
      manner but using client endpoint credentials
      
       $ qemu-system-x86_64 -monitor stdio \
          -object tls-creds-x509,dir=/home/berrange/security/qemutls,endpoint=client,id=tls0 \
          ...other args...
      
      To enable outgoing TLS migration 2 monitor commands are
      then used
      
        (qemu) migrate_set_str_parameter tls-creds tls0
        (qemu) migrate tcp:otherhostname:9000
      
      Thanks to earlier improvements to error reporting,
      TLS errors can be seen 'info migrate' when doing a
      detached migration. For example:
      
        (qemu) info migrate
        capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off x-postcopy-ram: off
        Migration status: failed
        total time: 0 milliseconds
        error description: TLS handshake failed: The TLS connection was non-properly terminated.
      
      Or
      
        (qemu) info migrate
        capabilities: xbzrle: off rdma-pin-all: off auto-converge: off zero-blocks: off compress: off events: off x-postcopy-ram: off
        Migration status: failed
        total time: 0 milliseconds
        error description: Certificate does not match the hostname localhost
      Reviewed-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      Message-Id: <1461751518-12128-27-git-send-email-berrange@redhat.com>
      Signed-off-by: NAmit Shah <amit.shah@redhat.com>
      e1226365