[libvirt] [PATCH 00/21] Support NBD for tunnelled migration

Pavel Boldin pboldin at mirantis.com
Wed Dec 2 14:16:03 UTC 2015


Ping.

May I have your attention guys?

Pavel

On Wed, Nov 18, 2015 at 8:12 PM, Pavel Boldin <pboldin at mirantis.com> wrote:

> The provided patchset implements NBD disk migration over a tunnelled
> connection provided by libvirt.
>
> The migration source instructs QEMU to NBD mirror drives into the provided
> UNIX socket. These connections and all the data are then tunnelled to the
> destination using newly introduced RPC call. The migration destination
> implements a driver method that connects the tunnelled stream to the QEMU's
> NBD destination.
>
> The detailed scheme is the following:
>
> PREPARE
>  1. Migration destination starts QEMU's NBD server listening on a UNIX
> socket
>     using the `nbd-server-add` monitor command and tells NBD to accept
> listed
>     disks via code added to qemuMigrationStartNBDServer that calls
> introduced
>     qemuMonitorNBDServerStartUnix monitor function.
>
> PERFORM
>  2. Migration source creates a UNIX socket that is later used as NBDs
>     destination in `drive-mirror` monitor command.
>
>     This is implemented as a call to virNetSocketNewListenUnix from
>     doTunnelMigrate.
>
>  3. Source starts IOThread that polls on the UNIX socket, accepting every
>     incoming QEMU connection.
>
>     This is done by adding a new pollfd in the poll(2) call in
>     qemuMigrationIOFunc that calls introduced qemuNBDTunnelAcceptAndPipe
>     function.
>
>  4. The qemuNBDTunnelAcceptAndPipe function accepts the connection and
> creates
>     two virStream's. One is `local` that is later associated with just
> accepted
>     connection using virFDStreamOpen. Second is `remote` that is later
>     tunnelled to the remote destination stream.
>
>     The `local` stream is converted to a virFDStreamDrv stream using the
>     virFDStreamOpen call on the fd returned by accept(2).
>
>     The `remote` stream is associated with a stream on the destination in
>     the way similar to used by PrepareTunnel3* function. That is, the
>     virDomainMigrateOpenTunnel function called on the destination
>     connection object. The virDomainMigrateOpenTunnel calls remote driver's
>     handler remoteDomainMigrateOpenTunnel that makes
> DOMAIN_MIGRATE_OPEN_TUNNEL
>     call to the destination host. The code in remoteDomainMigrateOpenTunnel
>     ties passed virStream object to a virStream on the destination host via
>     remoteStreamDrv driver. The remote driver handles stream's IO by
> tunnelling
>     data through the RPC connection.
>
>     The qemuNBDTunnelAcceptAndPipe at last assigns both streams the same
> event
>     callback qemuMigrationPipeEvent. Its job is to track statuses of the
>     streams doing IO whenever it is necessary.
>
>  5. Source starts the drive mirroring using the qemuMigrationDriveMirror
> func.
>     The function instructs QEMU to mirror drives to the UNIX socket that
> thread
>     listens on.
>
>     Since it is necessary for the mirror driving to get into the
> 'synchronized'
>     state, where writes go to both destinations simultaneously, before
>     continuing VM migration, the thread serving the connections must be
>     started earlier.
>
>  6. When the connection to a UNIX socket on the migration source is made
>     the DOMAIN_MIGRATE_OPEN_TUNNEL proc is called on the migration
> destination.
>
>     The handler of this code calls virDomainMigrateOpenTunnel which calls
>     qemuMigrationOpenNBDTunnel by the means of qemuDomainMigrateOpenTunnel.
>
>     The qemuMigrationOpenNBDTunnel connects the stream linked to a source's
>     stream to the NBD's UNIX socket on the migration destination side.
>
>  7. The rest of the disk migration occurs semimagically: virStream* APIs
> tunnel
>     data in both directions. This is done by qemuMigrationPipeEvent event
>     callback set for both streams.
>
>
> The order of the patches is roughly the following:
>
>  *  First, the RPC machinery and remote driver's
> virDrvDomainMigrateOpenTunnel
>     implementation are added.
>
>  *  Then, the source-side of the protocol is implemented: code listening
>     on a UNIX socket is added, DriveMirror is enhanced to instruct QEMU to
>     `drive-mirror` here and starting IOThread driving the tunneling sooner.
>
>  *  After that, the destination-side of the protocol is implemented:
>     the qemuMonitorNBDServerStartUnix added and qemuMigrationStartNBDServer
>     enhanced to call it. The qemuDomainMigrateOpenTunnel is implemented
>     along with qemuMigrationOpenNBDTunnel that does the real job.
>
>  *  Finally, the code blocking NBD migration for tunnelled migration is
>     removed.
>
> Pavel Boldin (21):
>   rpc: add DOMAIN_MIGRATE_OPEN_TUNNEL proc
>   driver: add virDrvDomainMigrateOpenTunnel
>   remote_driver: introduce virRemoteClientNew
>   remote_driver: add remoteDomainMigrateOpenTunnel
>   domain: add virDomainMigrateOpenTunnel
>   domain: add virDomainMigrateTunnelFlags
>   remote: impl remoteDispatchDomainMigrateOpenTunnel
>   qemu: migration: src: add nbd tunnel socket data
>   qemu: migration: src: nbdtunnel unix socket
>   qemu: migration: src: qemu `drive-mirror` to UNIX
>   qemu: migration: src: qemuSock for running thread
>   qemu: migration: src: add NBD unixSock to iothread
>   qemu: migration: src: qemuNBDTunnelAcceptAndPipe
>   qemu: migration: src: stream piping
>   qemu: monitor: add qemuMonitorNBDServerStartUnix
>   qemu: migration: dest: nbd-server to UNIX sock
>   qemu: migration: dest: qemuMigrationOpenTunnel
>   qemu: driver: add qemuDomainMigrateOpenTunnel
>   qemu: migration: dest: qemuMigrationOpenNBDTunnel
>   qemu: migration: allow NBD tunneling migration
>   apparmor: fix tunnelmigrate permissions
>
>  daemon/remote.c                  |  50 ++++
>  docs/apibuild.py                 |   1 +
>  docs/hvsupport.pl                |   1 +
>  include/libvirt/libvirt-domain.h |   3 +
>  src/driver-hypervisor.h          |   8 +
>  src/libvirt-domain.c             |  43 ++++
>  src/libvirt_internal.h           |   6 +
>  src/libvirt_private.syms         |   1 +
>  src/qemu/qemu_driver.c           |  24 ++
>  src/qemu/qemu_migration.c        | 495
> +++++++++++++++++++++++++++++++++------
>  src/qemu/qemu_migration.h        |   6 +
>  src/qemu/qemu_monitor.c          |  12 +
>  src/qemu/qemu_monitor.h          |   2 +
>  src/qemu/qemu_monitor_json.c     |  35 +++
>  src/qemu/qemu_monitor_json.h     |   2 +
>  src/remote/remote_driver.c       |  91 +++++--
>  src/remote/remote_protocol.x     |  19 +-
>  src/remote_protocol-structs      |   8 +
>  src/security/virt-aa-helper.c    |   4 +-
>  19 files changed, 719 insertions(+), 92 deletions(-)
>
> --
> 1.9.1
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20151202/48808060/attachment-0001.htm>


More information about the libvir-list mailing list