[libvirt] [PATCH] qemu: make 'xz' image compression viable by using -3

[Michal Privoznik]

On 11/28/19 1:27 PM, Daniel P. Berrangé wrote:
> For managed save we can choose between various compression
> methods. I randomly tested the 'xz' program on a 8 GB guest
> and was surprised to have to wait > 50 minutes for it to
> finish compressing, with 'xz' burning 100% cpu for the
> entire time. Despite the impressive compression, this is
> completely useless in the real world as it is far too long
> to wait to save the VM.
> 
> The 'xz' binary defaults to '-6' optimization level which
> aims for high compression, with moderate memory usage,
> at the expense of speed.
> 
> This change switches it to use the '-3' optimization level
> which is documented as being the one that optimizes speed
> at expense of compression. Even with this, it will still
> outperform all the other options in terms of compression
> level. It is a little less than x4 faster than '-6' which
> means it starts to be a viable choice to use 'xz' for
> people who really want best compression.
> 
> The test results on a 1 GB, fairly freshly booted VM are
> as follows
> 
>    format | save  | restore  size
>    =======+=======+=============
>    raw    |   05s |    1s  | 428 MB
>    lzop   |   05s |    3s  | 160 MB
>    gzip   |   29s |    5s  | 118 MB
>    bz2    |   54s |   22s  | 114 MB
>    xz     | 4m37s |   13s  |  86 MB
>    xz -3  | 1m20s |   12s  |  95 MB

I've got similar numbers.

> 
> Based on this we can say
> 
>   * For moderate compression with no noticable loss in speed
> 
>         => use lzop
> 
>   * For high compression with moderate loss in speed
> 
>         => use gzip
> 
>   * For best compression with significant loss in speed
> 
>         => use xz
> 
> Signed-off-by: Daniel P. Berrangé <berrange at redhat.com>
> ---
>   src/qemu/qemu_driver.c    | 46 ++++++++++++++++++++++-----------------
>   src/qemu/qemu_migration.c | 28 ++++++++----------------
>   src/qemu/qemu_migration.h |  2 +-
>   3 files changed, 36 insertions(+), 40 deletions(-)

Reviewed-by: Michal Privoznik <mprivozn at redhat.com>

Michal