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.
At any rate, I'm okay with this patch as-is.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org