1. 16 4月, 2018 7 次提交
  2. 13 4月, 2018 1 次提交
  3. 12 4月, 2018 23 次提交
  4. 11 4月, 2018 9 次提交
    • J
      openvz: Use virDomainObjListFindBy{UUID|ID}Ref · 9b4fe4c1
      John Ferlan 提交于
      For openvzDomObjFromDomainLocked and openvzDomainLookupByID
      let's return a locked and referenced @vm object so that callers
      can then use the common and more consistent virDomainObjEndAPI
      in order to handle cleanup rather than needing to know that the
      returned object is locked and calling virObjectUnlock.
      
      The LookupByName already returns the ref counted and locked object,
      so this will make things more consistent.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NJim Fehlig <jfehlig@suse.com>
      9b4fe4c1
    • J
      openvz: Add more descriptive error message on Find failure · b7eb4b93
      John Ferlan 提交于
      If openvzDomainLookupByID or openvzDomainLookupByName fails
      to find a vm, let's be a bit more descriptive by providing
      the failing id or name in the error message.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NJim Fehlig <jfehlig@suse.com>
      b7eb4b93
    • J
      openvz: Create accessors to virDomainObjListFindByUUID · e5d682c0
      John Ferlan 提交于
      Rather than repeat code throughout, create and use a couple of
      accessors in order to lookup by UUID.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      Reviewed-by: NJim Fehlig <jfehlig@suse.com>
      e5d682c0
    • J
      lxc: Fix object locking after virDomainObjListRemove · 5290ca53
      John Ferlan 提交于
      The virDomainObjListRemove will return an unlocked
      @vm after calling with a reffed object, thus prior
      to calling virDomainObjEndAPI we should relock.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      5290ca53
    • J
      lxc: Fix possible leaked @vm in lxcDomainCreateXMLWithFiles · abd1e54f
      John Ferlan 提交于
      In error paths, if we call virDomainObjListRemove we will leak
      the @vm because we have called with a reffed and locked @vm.
      So rather than set it to NULL, relock the @vm and allow the
      virDomainObjEndAPI to perform the magic of Unlock/Unref.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      abd1e54f
    • J
      bhyve: Use virDomainObjListFindBy{UUID|ID}Ref · f52d0d42
      John Ferlan 提交于
      For bhyveDomObjFromDomain, bhyveDomainLookupByUUID, and
      bhyveDomainLookupByID let's return a locked and referenced
      @vm object so that callers can then use the common and more
      consistent virDomainObjEndAPI in order to handle cleanup rather
      than needing to know that the returned object is locked and
      calling virObjectUnlock.
      
      The LookupByName already returns the ref counted and locked object,
      so this will make things more consistent.
      
      For bhyveDomainUndefine and bhyveDomainDestroy since the
      virDomainObjListRemove will return an unlocked object, we need to
      relock before making the EndAPI call.
      Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
      f52d0d42
    • A
      qemu: Format gic-version=2 on the command line · 550950e5
      Andrea Bolognani 提交于
      Up until now we have only formatted non-default GIC versions on
      the command line, in order to maintain compatibility with older
      QEMU versions that didn't implement the gic-version option to
      begin with; however, doing so is entirely unnecessary for newer
      QEMU versions, where the option is available. Moreover, having
      the GIC version formatted on the command line at all times
      ensures that QEMU changing its own defaults doesn't affect the
      ABI of libvirt guests.
      
      A few test cases are removed to avoid extra churn. It doesn't
      matter for coverage, as those scenarios are already covered by
      other parts of the test suite.
      
      This patch is better viewed with 'git show -w'.
      Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      550950e5
    • V
      util: don't check for parallel iteration in hash-related functions · 4d7384eb
      Vincent Bernat 提交于
      This is the responsability of the caller to apply the correct lock
      before using these functions. Moreover, the use of a simple boolean
      was still racy: two threads may check the boolean and "lock" it
      simultaneously.
      
      Users of functions from src/util/virhash.c have to be checked for
      correctness. Lookups and iteration should hold a RO
      lock. Modifications should hold a RW lock.
      
      Most important uses seem to be covered. Callers have now a greater
      responsability, notably the ability to execute some operations while
      iterating were reliably forbidden before are now accepted.
      Signed-off-by: NVincent Bernat <vincent@bernat.im>
      4d7384eb
    • D
      travis: skip builds on -maint branches · a3b1ee05
      Daniel P. Berrangé 提交于
      For patches pushed upstream we want builds run on master branch, but
      don't want them run on the -maint branches, as we are not keeping the
      .travis.yml file on stable branches updated wrt latest needs of travis
      CI platforms.
      
      We can't just whitelist 'master' though, because that will prevent
      developers triggering their own private travis builds. So we just
      blacklist *-maint, since developers will typically use named feature
      branches for any work.
      Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      a3b1ee05