> > > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list