On Tue, Nov 26, 2013 at 12:31:12 -0800, Chegu Vinod wrote:
On 11/26/2013 4:24 AM, Jiri Denemark wrote:
> On Thu, Nov 21, 2013 at 17:47:24 -0800, Chegu Vinod wrote:
>> Busy enterprise workloads hosted on large sized VM's tend to dirty
>> memory faster than the transfer rate achieved via live guest migration.
>> Despite some good recent improvements (& using dedicated 10Gig NICs
>> between hosts) the live migration may NOT converge.
>>
>> Recently support was added in qemu (version 1.6) to allow a user to
>> choose if they wish to force convergence of their migration via a
>> new migration capability : "auto-converge". This feature allows for
qemu
>> to auto-detect lack of convergence and trigger a throttle-down of the
>> VCPUs.
>>
>> This RFC patch includes the libvirt support needed to trigger this
>> feature. (Testing is still in progress)
...
> So except for the small issues, the patch looks good to me.
However, do
> I remember correctly that this feature can be turned on dynamically for
> an already running migration? If so, I think we want a second patch
> adding a new API for setting this auto-converge feature.
Yes.
Is there a sample reference/example that I could look up ?
You can have a look at virConnectGetCPUModelNames, which is the most
recent simple API added to libvirt (commits
f90857b32aa81f9a5e878e7bceb2df30e2b1b4f8,
fd69544965ddf0e49e40c99d24708da4ba1a7648,
cbcecd7ab14de22467c405023580afcb9e8eca54,
ea45b23cfc2b75053aea96f29a2a91cfc8e26013) but n qemu_driver.c you will
need to use QEMU_JOB_MIGRATION_OP as the job type (the third parameter
to qemuDomainObjBeginJob) to make this API working during migration.
Jirka