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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list