[libvirt] [PATCH 01/14] Introduce VIR_MIGRATE_COMPRESSED flag

Peter Krempa pkrempa at redhat.com
Fri Feb 22 06:41:08 UTC 2013


On 02/22/13 01:45, Eric Blake wrote:
> On 02/21/2013 02:04 PM, Peter Krempa wrote:
>> On 02/19/13 13:35, Jiri Denemark wrote:
>>> This flag may be used with migration APIs to request compression of
>>> migration data.
>>> ---
>>>    include/libvirt/libvirt.h.in | 1 +
>>>    tools/virsh-domain.c         | 8 ++++++++
>>>    tools/virsh.pod              | 6 ++++--
>>>    3 files changed, 13 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/include/libvirt/libvirt.h.in b/include/libvirt/libvirt.h.in
>>> index ad30cd0..eda9e12 100644
>>> --- a/include/libvirt/libvirt.h.in
>>> +++ b/include/libvirt/libvirt.h.in
>>> @@ -1187,6 +1187,7 @@ typedef enum {
>>>                                                   * when supported */
>>>        VIR_MIGRATE_UNSAFE            = (1 << 9), /* force migration
>>> even if it is considered unsafe */
>>>        VIR_MIGRATE_OFFLINE           = (1 << 10), /* offline migrate */
>>> +    VIR_MIGRATE_COMPRESSED        = (1 << 11), /* compress data
>>> during migration */
>>
>> I'm just wondering if this is enough future proof if somebody invents
>> other migration compression methods. Well but that's something our
>> future selves will need to worry about.
>>
>> ACK (unless somebody else speaks until I'm finished)
>
> I guess there are use cases where compression helps, and use cases where
> it costs more memory and actually slows things down to turn on, so
> requiring the user to pass the new option in order to use compression
> makes sense.  However, I'm wondering if we need further control, such as
> the ability to control the side of the source's xbzrle cache.  I haven't
> checked if later in the series you add a counterpart to migrate-setspeed
> that allows modifying compression cache size.

Patch 10/14 adds APIs that allow to control the xbzrle cache. If the 
cache is small enough, the xbzrle compression is effectively disabled.

As the compression is applied only on pages that became dirty during 
live migration and it doesn't use any CPU heavy algorithm, this 
shouldn't slow things down.

Peter




More information about the libvir-list mailing list