1. 11 12月, 2019 5 次提交
  2. 10 12月, 2019 2 次提交
    • P
      conf: domaincaps: Add 'backup' feature flag · 528191c7
      Peter Krempa 提交于
      This flag will allow figuring out whether the hypervisor supports the
      incremental backup and checkpoint features.
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      528191c7
    • E
      backup: Document new XML for backups · 252958ee
      Eric Blake 提交于
      Prepare for new backup APIs by describing the XML that will represent
      a backup.  The XML resembles snapshots and checkpoints in being able
      to select actions for a set of disks, but has other differences.  It
      can support both push model (the hypervisor does the backup directly
      into the destination file) and pull model (the hypervisor exposes an
      access port for a third party to grab what is necessary).  Add
      testsuite coverage for some minimal uses of the XML.
      
      The <disk> element within <domainbackup> tries to model the same
      elements as a <disk> under <domain>, but sharing the RNG grammar
      proved to be hairy. That is in part because while <domain> use
      <source> to describe a host resource in use by the guest, a backup job
      is using a host resource that is not visible to the guest: a push
      backup action is instead describing a <target> (which ultimately could
      be a remote network resource, but for simplicity the RNG just
      validates a local file for now), and a pull backup action is instead
      describing a temporary local file <scratch> (which probably should not
      be a remote resource).  A future refactoring may thus introduce some
      way to parameterize RNG to accept <disk type='FOO'>...</disk> so that
      the name of the subelement can be <source> for domain, or <target> or
      <scratch> as needed for backups. Future patches may improve this area
      of code.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      252958ee
  3. 09 12月, 2019 1 次提交
    • D
      conf: pass in default architecture via domain XML options · 6430c005
      Daniel P. Berrangé 提交于
      When parsing the guest XML we must fill in the default guest arch if it
      is not already present because later parts of the parsing process need
      this information.
      
      If no arch is specified we lookup the first guest in the capabilities
      data matching the os type and virt type. In most cases this will result
      in picking the host architecture but there are some exceptions...
      
       - The test driver is hardcoded to always use i686 arch
       - The VMWare/ESX drivers will always place i686 guests ahead
         of x86_64 guests in capabilities, so effectively they always
         use i686
       - The QEMU driver can potentially return any arch at all
         depending on what combination of QEMU binaries are installed.
      
      The domain XML hardware configurations are inherently architecture
      specific in many places. As a result whomever/whatever created the
      domain XML will have had a particular architecture in mind when
      specifying the config. In pretty much any sensible case this arch
      will have been the native host architecture. i686 on x86_64 is
      the only sensible divergance because both these archs are
      compatible from a domaain XML config POV.
      
      IOW, although the QEMU driver can pick an almost arbitrary arch as its
      default, in the real world no application or user is likely to be
      relying on this default arch being anything other than native.
      
      With all this in mind, it is reasonable to change the XML parser to
      allow the default architecture to be passed via the domain XML options
      struct. If no info is explicitly given then it is safe & sane to pick
      the host native architecture as the default for the guest.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      6430c005
  4. 06 12月, 2019 3 次提交
  5. 05 12月, 2019 10 次提交
  6. 04 12月, 2019 13 次提交
  7. 03 12月, 2019 4 次提交
  8. 28 11月, 2019 1 次提交
    • D
      docs: don't run xmllint when generating API HTML files · 8d9ca128
      Daniel P. Berrangé 提交于
      After generating the API HTML files we run xmllint in docs/html/*.html
      to validate the correctness. Since
      
        commit 0aa8536f
        Author: Daniel P. Berrangé <berrange@redhat.com>
        Date:   Wed Nov 20 14:49:26 2019 +0000
      
          docs: generate API reference pages for admin, qemu & lxc libraries
      
      we have many rules generating files into docs/html/. The xmllint
      calls for each rule are picking up files which are part-generated by
      other parallel build rules resulting in transient errors like:
      
        GEN      html/index.html
        GEN      html/index-admin.html
        GEN      html/index-qemu.html
        GEN      html/index-lxc.html
        GEN      hvsupport.html.in
      html/index-lxc.html:1: parser error : Document is empty
      
      ^
      make[4]: *** [Makefile:2407: html/index-qemu.html] Error 1
      
      The easiest solution is to move the xmllint rules to the 'make check'
      phase of the build.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      8d9ca128
  9. 27 11月, 2019 1 次提交