1. 10 12月, 2019 2 次提交
  2. 09 12月, 2019 17 次提交
  3. 05 12月, 2019 2 次提交
  4. 03 12月, 2019 3 次提交
    • P
      qemu: Always reset @info in qemuDomainGetJobInfo · ab163144
      Peter Krempa 提交于
      qemuDomainGetJobInfo didn't always reset the return data in @info.
      Thankfully this wouldn't be a problem as the RPC layer does it but we
      should do it anyways.
      
      Since we reset the struct we don't have to set the type to
      VIR_DOMAIN_JOB_NONE as the value is 0.
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      ab163144
    • P
      2dae916d
    • D
      qemu: make 'xz' image compression viable by using -3 · 8aaed287
      Daniel P. Berrangé 提交于
      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
      
      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
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      8aaed287
  5. 02 12月, 2019 2 次提交
  6. 29 11月, 2019 1 次提交
  7. 27 11月, 2019 2 次提交
  8. 21 11月, 2019 3 次提交
  9. 19 11月, 2019 2 次提交
  10. 15 11月, 2019 3 次提交
    • P
      replace use of gnulib snprintf by g_snprintf · 43b01ef2
      Pavel Hrdina 提交于
      Glib implementation follows the ISO C99 standard so it's safe to replace
      the gnulib implementation.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
      43b01ef2
    • J
      Add API to change qemu agent response timeout · 95f5ac9a
      Jonathon Jongsma 提交于
      Some layered products such as oVirt have requested a way to avoid being
      blocked by guest agent commands when querying a loaded vm. For example,
      many guest agent commands are polled periodically to monitor changes,
      and rather than blocking the calling process, they'd prefer to simply
      time out when an agent query is taking too long.
      
      This patch adds a way for the user to specify a custom agent timeout
      that is applied to all agent commands.
      
      One special case to note here is the 'guest-sync' command. 'guest-sync'
      is issued internally prior to calling any other command. (For example,
      when libvirt wants to call 'guest-get-fsinfo', we first call
      'guest-sync' and then call 'guest-get-fsinfo').
      
      Previously, the 'guest-sync' command used a 5-second timeout
      (VIR_DOMAIN_QEMU_AGENT_COMMAND_DEFAULT), whereas the actual command that
      followed always blocked indefinitely
      (VIR_DOMAIN_QEMU_AGENT_COMMAND_BLOCK). As part of this patch, if a
      custom timeout is specified that is shorter than
      5 seconds,  this new timeout is also used for 'guest-sync'. If there is
      no custom timeout or if the custom timeout is longer than 5 seconds, we
      will continue to use the 5-second timeout.
      Signed-off-by: NJonathon Jongsma <jjongsma@redhat.com>
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      95f5ac9a
    • J
      Use g_mkstemp_full instead of mkostemp(s) · 4ac47730
      Ján Tomko 提交于
      With g_mkstemp_full, there is no need to distinguish between
      mkostemp and mkostemps (no suffix vs. a suffix of a fixed length),
      because the GLib function looks for the XXXXXX pattern everywhere
      in the string.
      
      Use S_IRUSR | S_IWUSR for the permissions and do not pass O_RDWR
      in flags since it's implied.
      Signed-off-by: NJán Tomko <jtomko@redhat.com>
      Reviewed-by: NPeter Krempa <pkrempa@redhat.com>
      4ac47730
  11. 14 11月, 2019 3 次提交