1. 14 3月, 2020 1 次提交
  2. 05 3月, 2020 1 次提交
  3. 25 2月, 2020 1 次提交
  4. 27 1月, 2020 1 次提交
    • D
      libvirt: pass a directory path into drivers for embedded usage · 207709a0
      Daniel P. Berrangé 提交于
      The intent here is to allow the virt drivers to be run directly embedded
      in an arbitrary process without interfering with libvirtd. To achieve
      this they need to store all their configuration & state in a separate
      directory tree from the main system or session libvirtd instances.
      
      This can be useful for doing testing of the virt drivers in "make check"
      without interfering with the user's own libvirtd instances.
      
      It can also be used for applications using KVM/QEMU as a piece of
      infrastructure to build an service, rather than for general purpose
      OS hosting. A long standing example is libguestfs, which would prefer
      if its temporary VMs did show up in the main libvirtd VM list, because
      this confuses apps such as OpenStack Nova. A more recent example would
      be Kata which is using KVM as a technology to build containers.
      Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      207709a0
  5. 07 1月, 2020 1 次提交
  6. 03 1月, 2020 1 次提交
  7. 23 12月, 2019 1 次提交
    • Y
      storage: Fix daemon crash on lookup storagepool by targetpath · dfff16a7
      Yi Li 提交于
      Causing a crash when storagePoolLookupByTargetPath beacuse of
      Some types of storage pool have no target elements.
      Use STREQ_NULLABLE instead of STREQ
      Avoids segfaults when using NULL arguments.
      
      Core was generated by `/usr/sbin/libvirtd'.
      Program terminated with signal 11, Segmentation fault.
      (gdb) bt
      0  0x0000ffff9e951388 in strcmp () from /lib64/libc.so.6
      1  0x0000ffff92103e9c in storagePoolLookupByTargetPathCallback (
          obj=0xffff7009aab0, opaque=0xffff801058b0) at storage/storage_driver.c:1649
      2  0x0000ffff9f2c52a4 in virStoragePoolObjListSearchCb (
          payload=0xffff801058b0, name=<optimized out>, opaque=<optimized out>)
          at conf/virstorageobj.c:476
      3  0x0000ffff9f1f2f7c in virHashSearch (ctable=0xffff800f4f60,
          iter=iter@entry=0xffff9f2c5278 <virStoragePoolObjListSearchCb>,
          data=data@entry=0xffff95af7488, name=name@entry=0x0) at util/virhash.c:696
      4  0x0000ffff9f2c64f0 in virStoragePoolObjListSearch (pools=0xffff800f2ce0,
          searcher=searcher@entry=0xffff92103e68 <storagePoolLookupByTargetPathCallback>,
           opaque=<optimized out>) at conf/virstorageobj.c:505
      5  0x0000ffff92101f54 in storagePoolLookupByTargetPath (conn=0xffff5c0009f0,
      path=0xffff7009a850 "/vms/images") at storage/storage_driver.c:1672
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      Signed-off-by: NYi Li <yili@winhong.com>
      dfff16a7
  8. 20 12月, 2019 2 次提交
  9. 26 11月, 2019 1 次提交
  10. 15 11月, 2019 1 次提交
  11. 13 11月, 2019 1 次提交
  12. 12 11月, 2019 1 次提交
  13. 21 10月, 2019 2 次提交
  14. 17 10月, 2019 1 次提交
  15. 16 10月, 2019 3 次提交
  16. 15 10月, 2019 1 次提交
  17. 08 10月, 2019 1 次提交
  18. 27 9月, 2019 1 次提交
  19. 27 8月, 2019 1 次提交
  20. 23 8月, 2019 2 次提交
    • M
      storage_driver: Don't crash in storagePoolCreateXML · 9935b435
      Michal Privoznik 提交于
      In my recent patches I've introduced
      virStoragePoolObjIsStarting() which is then used to protect
      storage pool definition when the pool object is locked and
      unlocked during long running jobs. Well, my patches did not
      anticipate that @obj can be NULL under 'cleanup' label in
      storagePoolCreateXML() (for instance when parsing XML fails).
      This imperfection is causing libvirtd to crash then.
      
      Fixes: 13284a6b storage_driver: Protect pool def during startup and build
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>
      9935b435
    • 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
  21. 22 8月, 2019 6 次提交
  22. 09 8月, 2019 1 次提交
  23. 11 7月, 2019 1 次提交
    • D
      storage: acquire a pidfile in the driver root directory · 44a5ba2a
      Daniel P. Berrangé 提交于
      When we allow multiple instances of the driver for the same user
      account, using a separate root directory, we need to ensure mutual
      exclusion. Use a pidfile to guarantee this.
      
      In privileged libvirtd this ends up locking
      
         /var/run/libvirt/storage/driver.pid
      
      In unprivileged libvirtd this ends up locking
      
        /run/user/$UID/libvirt/storage/run/driver.pid
      
      NB, the latter can vary depending on $XDG_RUNTIME_DIR
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      44a5ba2a
  24. 18 3月, 2019 1 次提交
  25. 16 3月, 2019 2 次提交
  26. 07 3月, 2019 2 次提交
  27. 06 3月, 2019 1 次提交
  28. 12 2月, 2019 1 次提交