On 06/04/2015 06:31 PM, Qiao,Liyong wrote:
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