1. 15 10月, 2019 1 次提交
  2. 14 10月, 2019 1 次提交
  3. 30 9月, 2019 1 次提交
  4. 17 9月, 2019 1 次提交
  5. 10 9月, 2019 1 次提交
    • D
      util: activate directory override when used from library · b1b878c5
      Daniel P. Berrangé 提交于
      The Perl bindings for libvirt use the test driver for unit tests. This
      tries to load the cpu_map/index.xml file, and when run from an
      uninstalled build will fail.
      
      The problem is that virFileActivateDirOverride is called by our various
      binaries like libvirtd, virsh, but is not called when a 3rd party app
      uses libvirt.so
      
      To deal with this we allow the LIBVIRT_DIR_OVERRIDE=1 env variable to be
      set and make virInitialize look for this. The 'run' script will set it,
      so now build using this script to run against an uninstalled tree we
      will correctly resolve files to the source tree.
      Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      b1b878c5
  6. 09 9月, 2019 1 次提交
    • E
      remote: fix UNIX socket path being incorrectly built for libvirtd · ec78c9a0
      eater 提交于
      As a result of changes in
      
            commit d5f0c1b6
            Author: Daniel P. Berrangé <berrange@redhat.com>
            Date:   Thu Jul 18 12:30:22 2019 +0100
      
              remote: stop trying to print help as giant blocks of text
      
      The socket path built would be libvirt//var/run/libvirt-sock
      instead of /var/run/libvirt/libvirt-sock. Fortunately this only
      affects users who have set the 'unix_sock_dir' config parameter
      in /etc/libvirt/libvirtd.conf, which is pretty rare/unusual.
      Signed-off-by: Neater <=@eater.me>
      
      Exception made for the psuedonym above since patch is considered
      trivial & thus non-copyrightable material.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      ec78c9a0
  7. 27 8月, 2019 2 次提交
  8. 09 8月, 2019 6 次提交
    • D
      remote: introduce virtproxyd daemon to handle IP connectivity · b7ed8ce9
      Daniel P. Berrangé 提交于
      The libvirtd daemon provides the traditional libvirt experience where
      all the drivers are in a single daemon, and is accessible over both
      local UNIX sockets and remote IP sockets.
      
      In the new world we're having a set of per-driver daemons which will
      primarily be accessed locally via their own UNIX sockets.
      
      We still, however, need to allow for case of applications which will
      connect to libvirt remotely. These remote connections can be done as
      TCP/TLS sockets, or by SSH tunnelling to the UNIX socket.
      
      In the later case, the old libvirt.so clients will only know about
      the path to the old libvirtd socket /var/run/libvirt/libvirt-sock,
      and not the new driver sockets /var/run/libvirt/virtqemud-sock.
      
      It is also not desirable to expose the main driver specific daemons
      over IP directly to minimize their attack service.
      
      Thus the virtproxyd daemon steps into place, to provide TCP/TLS sockets,
      and back compat for the old libvirtd UNIX socket path(s). It will then
      forward all RPC calls made to the appropriate driver specific daemon.
      
      Essentially it is equivalent to the old libvirtd with absolutely no
      drivers registered except for the remote driver (and other stateless
      drivers in libvirt.so).
      
      We could have modified libvirtd so none of the drivers are registed
      to get the same end result. We could even add a libvirtd.conf parameter
      to control whether the drivers are loaded to enable users to switch back
      to the old world if we discover bugs in the split-daemon model. Using a
      new daemon though has some advantages
      
       - We can make virtproxyd and the virtXXXd per-driver daemons all
         have "Conflicts: libvirtd.service" in their systemd unit files.
         This will guarantee that libvirtd is never started at the same
         time, as this would result in two daemons running the same driver.
         Fortunately drivers use locking to protect themselves, but it is
         better to avoid starting a daemon we know will conflict.
      
       - It allows us to break CLI compat to remove the --listen parameter.
         Both listen_tcp and listen_tls parameters in /etc/libvirtd/virtd.conf
         will default to zero. Either TLS or TCP can be enabled exclusively
         though virtd.conf without requiring the extra step of adding --listen.
      
       - It allows us to set a strict SELinux policy over virtproxyd. For
         back compat the libvirtd policy must continue to allow all drivers
         to run. We can't easily give a second policy to libvirtd which
         locks it down. By introducing a new virtproxyd we can set a strict
         policy for that daemon only.
      
       - It gets rid of the weird naming of having a daemon with "lib" in
         its name. Now all normal daemons libvirt ships will have "virt"
         as their prefix not "libvirt".
      
       - Distros can more easily choose their upgrade path. They can
         ship both sets of daemons in their packages, and choose to
         either enable libvirtd, or enable the per-driver daemons and
         virtproxyd out of the box. Users can easily override this if
         desired by just tweaking which systemd units are active.
      
      After some time we can deprecate use of libvirtd and after some more
      time delete it entirely, leaving us in a pretty world filled with
      prancing unicorns.
      
      The main downside with introducing a new daemon, and with the
      per-driver daemons in general, is figuring out the correct upgrade
      path.
      
      The conservative option is to leave libvirtd running if it was
      an existing installation. Only use the new daemons & virtproxyd
      on completely new installs.
      
      The aggressive option is to disable libvirtd if already running
      and activate all the new daemons.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      b7ed8ce9
    • D
      remote: in per-driver daemons ensure that state initialize succeeds · 4ce29411
      Daniel P. Berrangé 提交于
      When running in libvirtd, we are happy for any of the drivers to simply
      skip their initialization in virStateInitialize, as other drivers are
      still potentially useful.
      
      When running in per-driver daemons though, we want the daemon to abort
      startup if the driver cannot initialize itself, as the daemon will be
      useless without it.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      4ce29411
    • D
      remote: conditionalize IP socket usage in libvirtd daemon · 22045851
      Daniel P. Berrangé 提交于
      Prepare for reusing libvirtd source to create other daemons by making
      the use of IP sockets conditionally defined by the make rules.
      
      The main libvirtd daemon will retain IP listen ability, but all the
      driver specific daemons will be local UNIX sockets only. Apps needing
      IP connectivity will connect via the libvirtd daemon which will proxy
      to the driver specfic daemon.
      Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      22045851
    • D
      remote: conditionalize driver loading in libvirtd daemon · 5d3475c8
      Daniel P. Berrangé 提交于
      Prepare for reusing libvirtd source to create other daemons by making
      the driver(s) to load conditionally defined by the make rules.
      
      If nothing is set, all drivers will be loaded, ignoring any missing ones
      as historically done.
      
      If MODULE_NAME is set only one driver will be loaded and that one must
      succeed.
      Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      5d3475c8
    • D
      remote: conditionalize daemon name in libvirtd daemon · 74d76d64
      Daniel P. Berrangé 提交于
      Prepare for reusing libvirtd source to create other daemons by making
      the daemon name conditionally defined by the make rules.
      Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      74d76d64
    • D
      remote: stop trying to print help as giant blocks of text · d5f0c1b6
      Daniel P. Berrangé 提交于
      The remote daemon tries to print out its help text in a couple of giant
      blocks of text. This has already lead to duplication of the text for the
      privileged vs unprivileged execution mode. With the introduction of more
      daemons, this text is going to be duplicated many more times with small
      variations. This is very unfriendly to translators as they have to
      translate approximately the same text many times with small tweaks.
      
      Splitting the text up into individual strings to print means that each
      piece will only need translating once. It also gets rid of all the
      layout information from the translated strings, so avoids the problem of
      translators breaking formatting by mistake.
      Reviewed-by: NChristophe de Dinechin <dinechin@redhat.com>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      d5f0c1b6
  9. 19 7月, 2019 1 次提交
  10. 12 7月, 2019 2 次提交
  11. 21 6月, 2019 2 次提交
    • D
      remote: delete the avahi mDNS support · 5a148ce8
      Daniel P. Berrangé 提交于
      Libvirtd has long had integration with avahi for advertising libvirtd
      using mDNS when TCP/TLS listening is enabled. For a long time the
      virt-manager application had support for auto-detecting libvirtds
      on the local network using mDNS, but this was removed last year
      
        commit fc8f8d5d7e3ba80a0771df19cf20e84a05ed2422
        Author: Cole Robinson <crobinso@redhat.com>
        Date:   Sat Oct 6 20:55:31 2018 -0400
      
          connect: Drop avahi support
      
          Libvirtd can advertise itself over avahi. The feature is disabled by
          default though and in practice I hear of no one actually using it
          and frankly I don't think it's all that useful
      
          The 'Open Connection' wizard has a disproportionate amount of code
          devoted to this feature, but I don't think it's useful or worth
          maintaining, so let's drop it
      
      I've never heard of any other applications having support for using
      mDNS to detect libvirtd instances. Though it is theoretically possible
      something exists out there, it is clearly going to be a niche use case
      in the virt ecosystem as a whole.
      
      By removing avahi integration we can cut down the dependency chain for
      the basic libvirtd install and reduce our code maint burden.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      5a148ce8
    • D
      remote: drop code for migrating config files from pre-XDG dir layout · e10310d6
      Daniel P. Berrangé 提交于
      The unprivileged libvirtd daemon switched to use the XDG dir layout in
      the 0.9.13 release, and included code for moving config files from the
      old location. The chances of someone upgrading libvirt from <= 0.9.12
      directly to libvirt >= 5.5.0 is close enough to zero that we can
      reasonably drop the back compat code.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      e10310d6
  12. 12 4月, 2019 1 次提交
  13. 06 3月, 2019 1 次提交
  14. 04 2月, 2019 2 次提交
  15. 18 12月, 2018 1 次提交
  16. 14 12月, 2018 1 次提交
    • D
      Remove all Author(s): lines from source file headers · 60046283
      Daniel P. Berrangé 提交于
      In many files there are header comments that contain an Author:
      statement, supposedly reflecting who originally wrote the code.
      In a large collaborative project like libvirt, any non-trivial
      file will have been modified by a large number of different
      contributors. IOW, the Author: comments are quickly out of date,
      omitting people who have made significant contribitions.
      
      In some places Author: lines have been added despite the person
      merely being responsible for creating the file by moving existing
      code out of another file. IOW, the Author: lines give an incorrect
      record of authorship.
      
      With this all in mind, the comments are useless as a means to identify
      who to talk to about code in a particular file. Contributors will always
      be better off using 'git log' and 'git blame' if they need to  find the
      author of a particular bit of code.
      
      This commit thus deletes all Author: comments from the source and adds
      a rule to prevent them reappearing.
      
      The Copyright headers are similarly misleading and inaccurate, however,
      we cannot delete these as they have legal meaning, despite being largely
      inaccurate. In addition only the copyright holder is permitted to change
      their respective copyright statement.
      Reviewed-by: NErik Skultety <eskultet@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      60046283
  17. 20 9月, 2018 1 次提交
  18. 13 8月, 2018 1 次提交
  19. 01 8月, 2018 1 次提交
  20. 27 6月, 2018 1 次提交
  21. 05 6月, 2018 1 次提交
  22. 25 4月, 2018 2 次提交
  23. 24 4月, 2018 1 次提交
  24. 23 3月, 2018 1 次提交
    • D
      remote: remove some __sun conditionals · da1ade7a
      Daniel P. Berrangé 提交于
      The libvirtd daemon has some arbitrary logic to drop privileges, but
      only on Solaris platforms. This was added during Xen days, when Xen was
      the only driver running in libvirtd. There's no expectation or testing
      that this works with the new libxl stack, nor whether dropping
      privileges breaks any of the secondary drivers. Finally, we'll be
      splitting drivers out into their own independant daemons, so this won't
      be applicable to libvirtd in future anyway.
      
      The remote driver client meanwhile arbitrarily disables daemon
      auto-spawn when connecting as non-root, breaking a key feature of
      libvirt unprivileged connections.
      
      Since we've not had any contributions for Solaris since circa 2012
      and we don't do any CI testing we should consider this platform
      unmaintained and thus reasonable to remove this cruft. If someone steps
      forward to maintain Solaris again, this code would need re-evaluating to
      come up with something more targetted.
      
      There's various __sun conditionals in the Xen driver code, but those are
      not touched. This is all for the legacy Xen driver, which will be
      entirely removed at some point in future, so not benefit to hacking out
      just the Solaris parts.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      da1ade7a
  25. 16 3月, 2018 1 次提交
  26. 13 3月, 2018 1 次提交
    • J
      libvirtd: fix potential deadlock when reloading · 33c6eb96
      Jim Fehlig 提交于
      It is possible to deadlock libvirtd when concurrently starting a domain
      and restarting the daemon. Threads involved in the deadlock are
      
      Thread 4 (Thread 0x7fc13b53e700 (LWP 64084)):
      /lib64/libpthread.so.0
          at util/virthread.c:154
          at qemu/qemu_monitor.c:1083
          cmd=0x7fc110017700, scm_fd=-1, reply=0x7fc13b53d318) at
      qemu/qemu_monitor_json.c:305
      cmd=0x7fc110017700,
          reply=0x7fc13b53d318) at qemu/qemu_monitor_json.c:335
          at qemu/qemu_monitor_json.c:1298
          at qemu/qemu_monitor.c:1697
          vm=0x7fc110003d00, asyncJob=QEMU_ASYNC_JOB_START) at qemu/qemu_process.c:1763
      vm=0x7fc110003d00,
          asyncJob=6, logCtxt=0x7fc1100089c0) at qemu/qemu_process.c:1835
          vm=0x7fc110003d00, asyncJob=6, logCtxt=0x7fc1100089c0) at
      qemu/qemu_process.c:2180
      driver=0x7fc12004e1e0,
          vm=0x7fc110003d00, asyncJob=QEMU_ASYNC_JOB_START, incoming=0x0, snapshot=0x0,
          vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE, flags=17) at qemu/qemu_process.c:6111
      driver=0x7fc12004e1e0,
          vm=0x7fc110003d00, updatedCPU=0x0, asyncJob=QEMU_ASYNC_JOB_START,
      migrateFrom=0x0,
          migrateFd=-1, migratePath=0x0, snapshot=0x0,
      vmop=VIR_NETDEV_VPORT_PROFILE_OP_CREATE,
          flags=17) at qemu/qemu_process.c:6334
          xml=0x7fc110000ed0 "<!--\nWARNING: THIS IS AN AUTO-GENERATED FILE.
      CHANGES TO IT ARE LIKELY TO BE\nOVERWRITTEN AND LOST. Changes to this xml
      configuration should be made using:\n  virsh edit testvv\nor other
      applicati"..., flags=0) at qemu/qemu_driver.c:1776
      ...
      
      Thread 1 (Thread 0x7fc143c66880 (LWP 64081)):
      /lib64/libpthread.so.0
          at util/virthread.c:122
      conf/nwfilter_conf.c:159
      sig=0x7ffe0a831e30,
          opaque=0x0) at remote/remote_daemon.c:724
          opaque=0x558c5328b230) at rpc/virnetdaemon.c:654
          at util/vireventpoll.c:508
      rpc/virnetdaemon.c:858
      remote/remote_daemon.c:1496
      (gdb) thr 1
      [Switching to thread 1 (Thread 0x7fc143c66880 (LWP 64081))]
      /lib64/libpthread.so.0
      (gdb) f 1
          at util/virthread.c:122
      122	    pthread_rwlock_wrlock(&m->lock);
      (gdb) p updateLock
      $1 = {lock = {__data = {__lock = 0, __nr_readers = 1, __readers_wakeup = 0,
            __writer_wakeup = 0, __nr_readers_queued = 0, __nr_writers_queued = 1,
      __writer = 0,
            __shared = 0, __rwelision = 0 '\000', __pad1 = "\000\000\000\000\000\000",
            __pad2 = 0, __flags = 0},
          __size = "\000\000\000\000\001", '\000' <repeats 15 times>, "\001",
      '\000' <repeats 34 times>, __align = 4294967296}}
      
      Reloading of the nwfilter driver is stuck waiting for a write lock, which
      already has a reader (from qemuDomainCreateXML) in the critical section.
      Since the reload occurs in the context of the main event loop thread,
      libvirtd becomes deadlocked. The deadlock can be avoided by offloading
      the reload work to a thread.
      Signed-off-by: NJim Fehlig <jfehlig@suse.com>
      Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
      33c6eb96
  27. 22 2月, 2018 1 次提交
  28. 31 1月, 2018 2 次提交
  29. 13 12月, 2017 1 次提交