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". Sorry , I use outlook. Will change to thunderbird. -----Original Message----- From: Qiao, Liyong Sent: Wednesday, June 3, 2015 7:49 AM To: Eric Blake; Feng, Shaohe; libvir-list@xxxxxxxxxx Cc: Bhandaru, Malini K; Ding, Jian-feng; Chylinski, Arek; Koniszewski, Pawel; Li, Liang Z; berrange@xxxxxxxxxx; veillard@xxxxxxxxxx Subject: Re: [RFC] libvirt support multi-thread compression for live migration On 2015年06月03日 01:02, Eric Blake wrote: > On 06/02/2015 07:56 AM, Qiao, Liyong wrote: >> Hi Eric >> Thanks for replying the mail, replied in lines. >> >>> +virdomainMigrateGetParameters(virDomainPtr domain, >>> + int *level, >>> + int *threads, >>> + int *dthreads, >>> + int flags) >>> + >> I'd rather we used virTypedParameters, to make it easier to use the same API to pass ALL future possible tuning parameters, rather than just hard-coding to only the parameters of this one feature. >> >> Okay ,that sound good, but if virTypedParameters can be passed to qemu_driver such as qemu_monitor_json.c qemu_monitor_text.c ? > [Your quoting style makes it very hard to distinguish original text > from added text. Please consider changing your outgoing mail process > to ensure that you add another level of quoting to all previous text > so that your added text is the only unquoted text. Also, configure > your mailer to wrap long lines.] hi Eric, sorry about the inconvenient mail client, I switch outlook to thunder bird, hopes it will be better. > Use existing API for a guide - for example, virDomainSetBlockIoTune > takes virTypedParamters, as well as defines a specific set of > parameters that it will understand. The set of parameters can be > enlarged without needing a new API (good for backporting features > without requiring a .so version bump), but for any given libvirt > version, the set of features understood is finite and limited to what > you can translate to the QMP call. So qemu_driver.c would take the > virTypedParameters, reject the ones it does not understand, and > convert the ones it does understand into the 'int level, int threads, > int dthreads' parameters used in qemu_monitor_json.c where you drive > the actual QMP command with fixed parameters and types. ah, that helps, thanks for kindly supporting, we will think a bit more to how implement this API (taken virTypedParamters as parameter) > > >> If we think that it is worth always turning on both compression styles simultaneously, then reuse the bit. Otherwise, we need a different bit, and users can choose which (or both) of the two compression styles as desired. >> >> +1 for reuse compressed, and we can set compress-level, >> +compress-threads, compress-dthreads by >> +virdomainMigrateSetParameters(maybe some new virsh command--- >> +migrate-setparameter) >> But how can we passing these parameter when we using `virsh migrate `, is there any parameter we can use in 'virsh migrate' command ? >> Can you point me out ? > The underlying API already has a form that takes virTypedParameters > (see virDomainMigrate3()), so your first task is to figure out how to > extend the API to expose new typed parameters for your new migration tunings. > Once that is done, then you can worry about how to tweak the 'virsh > migrate' client to pass in those new parameters. > -- BR, Eli(Li Yong)Qiao -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list