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

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.