1. 14 3月, 2020 1 次提交
  2. 05 3月, 2020 1 次提交
  3. 04 2月, 2020 2 次提交
  4. 30 1月, 2020 1 次提交
  5. 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
  6. 16 1月, 2020 1 次提交
  7. 08 1月, 2020 1 次提交
    • M
      remote_daemon: Initialize host boot time global variable · 35d603d5
      Michal Privoznik 提交于
      This is not strictly needed, but it makes sure we initialize the
      @bootTime global variable. Thing is, in order to validate XATTRs
      and prune those set in some previous runs of the host, a
      timestamp is recorded in XATTRs. The host boot time was unique
      enough so it was chosen as the timestamp value. And to avoid
      querying and parsing /proc/uptime every time, the query function
      does that only once and stores the boot time in a global
      variable. However, the only time the query function is called is
      in a child process that does lock files and changes seclabels. So
      effectively, we are doing exactly what we wanted to prevent from
      happening.
      
      The fix is simple, call the virHostBootTimeInit() function which
      sets the global variable.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NCole Robinson <crobinso@redhat.com>
      35d603d5
  8. 20 12月, 2019 1 次提交
  9. 13 11月, 2019 1 次提交
  10. 12 11月, 2019 1 次提交
  11. 21 10月, 2019 1 次提交
  12. 16 10月, 2019 1 次提交
  13. 15 10月, 2019 2 次提交
  14. 14 10月, 2019 1 次提交
  15. 30 9月, 2019 1 次提交
  16. 17 9月, 2019 1 次提交
  17. 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
  18. 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
  19. 27 8月, 2019 2 次提交
  20. 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
  21. 19 7月, 2019 1 次提交
  22. 12 7月, 2019 2 次提交
  23. 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
  24. 12 4月, 2019 1 次提交
  25. 06 3月, 2019 1 次提交
  26. 04 2月, 2019 2 次提交
  27. 18 12月, 2018 1 次提交
  28. 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
  29. 20 9月, 2018 1 次提交