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

> > 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.

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