1. 10 9月, 2019 1 次提交
    • L
      util: new function virNetDevMacVLanIsMacvtap() · 1b46566e
      Laine Stump 提交于
      This function returns T if the given name is a macvtap device. This is
      determined by 1) getting the ifindex of the device with that name (if
      there is one), and 2) checking for existence of /dev/tapXX, where "XX"
      is the ifindex learned in (1).
      
      It's also possible to learn this by getting a netlink dump of the
      interface and parsing through it to look for some attributes, but that
      is complicated to figure out, takes longer to execute, and I'm lazy.
      Signed-off-by: NLaine Stump <laine@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      1b46566e
  2. 06 9月, 2019 1 次提交
  3. 23 8月, 2019 2 次提交
    • M
      virpci: Remove unused virPCIDeviceWaitForCleanup · d5b07eae
      Michal Privoznik 提交于
      This function is no longer used after previous commit.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
      d5b07eae
    • M
      storage_driver: Protect pool def during startup and build · 13284a6b
      Michal Privoznik 提交于
      In near future the storage pool object lock will be released
      during startPool and buildPool callback (in some backends). But
      this means that another thread may acquire the pool object lock
      and change its definition rendering the former thread access not
      only stale definition but also access freed memory
      (virStoragePoolObjAssignDef() will free old def when setting a
      new one).
      
      One way out of this would be to have the pool appear as active
      because our code deals with obj->def and obj->newdef just fine.
      But we can't declare a pool as active if it's not started or
      still building up. Therefore, have a boolean flag that is very
      similar and forces virStoragePoolObjAssignDef() to store new
      definition in obj->newdef even for an inactive pool. In turn, we
      have to move the definition to correct place when unsetting the
      flag. But that's as easy as calling
      virStoragePoolUpdateInactive().
      
      Technically speaking, change made to
      storageDriverAutostartCallback() is not needed because until
      storage driver is initialized no storage API can run therefore
      there can't be anyone wanting to change the pool's definition.
      But I'm doing the change there for consistency anyways.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      13284a6b
  4. 22 8月, 2019 2 次提交
  5. 16 8月, 2019 1 次提交
  6. 15 8月, 2019 1 次提交
  7. 14 8月, 2019 2 次提交
  8. 09 8月, 2019 1 次提交
  9. 07 8月, 2019 4 次提交
  10. 06 8月, 2019 5 次提交
  11. 27 7月, 2019 3 次提交
    • E
      backup: Add list of checkpoints to domain · b736619f
      Eric Blake 提交于
      Wire up the use of a checkpoint list into each domain, similar to the
      existing snapshot list.  This includes adding a function for checking
      that a redefine operation fits in with the existing list, as well as
      various filtering capabilities over the list contents.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      b736619f
    • E
      backup: Allow for lists of checkpoint objects · 2795d856
      Eric Blake 提交于
      Create a new file for managing a list of checkpoint objects, borrowing
      heavily from existing virDomainSnapshotObjList paradigms.
      
      Note that while snapshots definitely have a use case for multiple
      children to a single parent (create a base snapshot, create a child
      snapshot, revert to the base, then create another child snapshot),
      it's harder to predict how checkpoints will play out with reverting to
      prior points in time. Thus, in initial use, given a list of
      checkpoints, you never have more than one child, and we can treat the
      most-recent leaf node as the parent of the next node creation, without
      having to expose a notion of a current node in XML or public API.
      However, as the snapshot machinery is already generic, it is easier to
      reuse the generic machinery that tracks relations between domain
      moments than it is to open-code a new list-management scheme just for
      checkpoints (hence, we still have internal functions related to a
      current checkpoint, even though that has no observable effect
      externally, as well as the addition of a function to easily find the
      lone leaf in the list to use as the current checkpoint).
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      2795d856
    • E
      backup: Parse and output checkpoint XML · 1a4df34a
      Eric Blake 提交于
      Add a new file checkpoint_conf.c that performs the translation to and
      from new XML describing a checkpoint. The code shares a common base
      class with snapshots, since a checkpoint similarly represents the
      domain state at a moment in time. Add some basic testing of round trip
      XML handling through the new code.
      
      Of note - this code intentionally differs from snapshots in that XML
      schema validation is unconditional, rather than based on a public API
      flag.  We have many existing interfaces that still need to add a flag
      for opt-in schema validation, but those interfaces have existing
      clients that may not have been producing strictly-compliant XML, or we
      may still uncover bugs where our RNG grammar is inconsistent with our
      code (where omitting the opt-in flag allows existing apps to keep
      working while waiting for an RNG patch).  But since checkpoints are
      brand-new, it's easier to ensure the code matches the schema by always
      using the schema.  If needed, a later patch could extend the API and
      add a flag to turn on to request schema validation, rather than having
      it forced (possibly just the validation of the <domain> sub-element
      during REDEFINE) - but if a user encounters XML that looks like it
      should be good but fails to validate with our RNG schema, they would
      either have to upgrade to a new libvirt that adds the new flag, or
      upgrade to a new libvirt that fixes the RNG schema, which implies
      adding such a flag won't help much.
      
      Also, the redefine flag requires the <domain> sub-element to be
      present, rather than catering to historical back-compat to older
      versions.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      1a4df34a
  12. 26 7月, 2019 5 次提交
  13. 25 7月, 2019 1 次提交
    • E
      snapshot: Don't leak moment obj list metaroot to callers · ceb10192
      Eric Blake 提交于
      virDomainSnapshotFindByName(list, NULL) should return NULL, rather
      than the internal-use-only metaroot.  Most existing callers pass in a
      non-NULL name; the few external callers that don't are immediately
      calling virDomainMomentSetParent (which indeed needs the metaroot
      rather than NULL if the parent name is NULL); but as the leaky
      abstraction is ugly, it is worth instead making
      virDomainMomentSetParent static and adding a new function for
      resolving the parent link of a brand new moment within its list.  The
      existing external uses of virDomainMomentSetParent always succeed
      (either the new moment has parent_name of NULL to become a new root,
      or has parent_name set to a strdup of the previous current moment);
      hence, our new function does not need a return value (but it still has
      a VIR_WARN in case future uses break our assumptions about failure
      being impossible).
      
      Missed when commit 02c4e24d refactored things to attempt to remove
      direct metaroot manipulations out of the qemu and test drivers into
      internal-only details, and made more obvious when commit dc8d3dc6
      factored it out into a separate file.
      Signed-off-by: NEric Blake <eblake@redhat.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      ceb10192
  14. 18 7月, 2019 5 次提交
  15. 16 7月, 2019 1 次提交
  16. 12 7月, 2019 4 次提交
  17. 11 7月, 2019 1 次提交