[libvirt] [RFC] libvirt support multi-thread compression for live migration

[Li, Liang Z]

> >
> > On 2015年06月04日 20:01, Jiri Denemark wrote:
> >> On Wed, Jun 03, 2015 at 15:13:17 +0000, Feng, Shaohe wrote:
> >>> Eric,
> >>> Thank you for reply.
> >>>
> >>> Is it necessary to expose these two APIs to user application?
> >>> + virdomainMigrateSetCapabilities
> >>> + virdomainMigrateGetCapabilities
> >>>
> >>> For qemu , the migration capabilities are "xbzrle", "rdma-pin-all",
> >>> "auto-converge",
> >>>   "zero-blocks" and "compress".
> >> No, these capabilities are either turned on/off based on flags passed
> >> to
> >> virDomainMigrate3 API.
> > I think we need to call qemuMonitorGetMigrationCapability when
> 
> [It's hard to read replies that aren't visually distinct from the rest of the text;
> you'll notice that most posters on this list leave a blank line before and after
> any text they add, so that a scan of the left-most column can easily spot
> blanks as a key for where new content begins]
> 
> > qemuMigrationSetCompression
> > if the source/dest node doesn't support  'compress' capability, we
> > need to stop migration if flags contain VIR_MIGRATE_COMPRESSED
> > (currently it stands for xbzrle, and Eric's previous mail suggest we
> > share this flag with 'compress')
> 
> No, I was asking whether libvirt's 'compress' flag should imply "all possible
> compression at once", or whether there are cases where xbzrle and multi-
> thread are independently useful and should not both be on at once.  If it is
> safe to always use both, then we don't need a new flag, but I don't know if it
> is safe.

Multiple thread compression is CPU-intensive, while xbzrle is RAM-intensive.
Although they can co-work correctly, there is no evidence show that turning both
on will achieve better performance than using xbzrle or multi-thread independently.

May be it's better to let the users decide which one to use depend on their specific 
use case.
   
> The migration handshake is already set up to negotiate capabilities between
> source and destination, whether it takes one flag (turning on both
> compressions, or gracefully falling back to xbzrle alone) or two (one per
> compression type, and erroring out if a request is made for an unsupported
> compression).
> 
> --
> Eric Blake   eblake redhat com    +1-919-301-3266
> Libvirt virtualization library http://libvirt.org