1. 18 10月, 2019 1 次提交
  2. 17 10月, 2019 1 次提交
  3. 16 10月, 2019 3 次提交
  4. 15 10月, 2019 4 次提交
  5. 14 10月, 2019 2 次提交
    • D
    • D
      build: link to glib library · cfbe9f12
      Daniel P. Berrangé 提交于
      Add the main glib.h to internal.h so that all common code can use it.
      
      Historically glib allowed applications to register an alternative
      memory allocator, so mixing g_malloc/g_free with malloc/free was not
      safe.
      
      This was feature was dropped in 2.46.0 with:
      
            commit 3be6ed60aa58095691bd697344765e715a327fc1
            Author: Alexander Larsson <alexl@redhat.com>
            Date:   Sat Jun 27 18:38:42 2015 +0200
      
              Deprecate and drop support for memory vtables
      
      Applications are still encourged to match g_malloc/g_free, but it is no
      longer a mandatory requirement for correctness, just stylistic. This is
      explicitly clarified in
      
          commit 1f24b36607bf708f037396014b2cdbc08d67b275
          Author: Daniel P. Berrangé <berrange@redhat.com>
          Date:   Thu Sep 5 14:37:54 2019 +0100
      
              gmem: clarify that g_malloc always uses the system allocator
      
      Applications can still use custom allocators in general, but they must
      do this by linking to a library that replaces the core malloc/free
      implemenentation entirely, instead of via a glib specific call.
      
      This means that libvirt does not need to be concerned about use of
      g_malloc/g_free causing an ABI change in the public libary, and can
      avoid memory copying when talking to external libraries.
      
      This patch probes for glib, which provides the foundation layer with
      a collection of data structures, helper APIs, and platform portability
      logic.
      
      Later patches will introduce linkage to gobject which provides the
      object type system, built on glib, and gio which providing objects
      for various interesting tasks, most notably including DBus client
      and server support and portable sockets APIs, but much more too.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      cfbe9f12
  6. 30 9月, 2019 1 次提交
  7. 20 9月, 2019 1 次提交
  8. 19 9月, 2019 1 次提交
  9. 17 9月, 2019 1 次提交
  10. 16 9月, 2019 1 次提交
  11. 10 9月, 2019 2 次提交
  12. 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
  13. 28 8月, 2019 4 次提交
  14. 27 8月, 2019 5 次提交
  15. 26 8月, 2019 1 次提交
  16. 16 8月, 2019 1 次提交
  17. 14 8月, 2019 1 次提交
  18. 09 8月, 2019 9 次提交
    • D
      remote: enable connecting to the per-driver daemons · b18c273a
      Daniel P. Berrangé 提交于
      Historically URIs handled by the remote driver will always connect to
      the libvirtd UNIX socket. There will now be one daemon per driver, and
      each of these has its own UNIX sockets to connect to.
      
      It will still be possible to run the traditional monolithic libvirtd
      though, which will have the original UNIX socket path.
      
      In addition there is a virproxyd daemon that doesn't run any drivers,
      but provides proxying for clients accessing libvirt over IP sockets, or
      tunnelling to the legacy libvirtd UNIX socket path.
      
      Finally when running inside a daemon, the remote driver must not reject
      connections unconditionally. For example, the QEMU driver needs to be
      able to connect to the network driver. The remote driver must thus be
      willing to handle connections even when inside the daemon, provided no
      local driver is registered.
      
      This refactoring enables the remote driver to be able to connect to the
      per-driver daemons. The URI parameter "mode" accepts the values "auto",
      "direct" and "legacy" to control which daemons are connected to.
      
      The client side libvirt.conf config file also supports a "remote_mode"
      setting which is used if the URI parameter is not set.
      
      If neither the config file or URI parameter set a mode, then "auto"
      is used, whereby the client looks to see which sockets actually exist
      right now.
      
      The remote driver will only ever spawn the per-driver daemons, or
      the legacy libvirtd. It won't ever try to spawn virtproxyd, as
      that is only there for IP based connectivity, or for access from
      legacy remote clients.
      
      If connecting to a remote host over any kind of ssh tunnel, for now we
      must assume only the legacy socket exists. A future patch will introduce
      a netcat replacement that is tailored for libvirt to make remote
      tunnelling easier.
      
      The configure arg '--with-remote-default-mode=legacy|direct' allows
      packagers to set a default at build time. If not given, it will default
      to legacy mode.
      
      Eventually the default will switch to direct mode. Distros can choose
      to do the switch earlier if desired. The main blocker is testing and
      suitable SELinux/AppArmor policies.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      b18c273a
    • D
      remote: refactor the code for choosing the UNIX socket path · 74695569
      Daniel P. Berrangé 提交于
      The ssh, libssh, libssh2 & unix transports all need to use a UNIX socket
      path, and duplicate some of the same logic for error checking. Pull this
      out into a separate method to increase code sharing.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      74695569
    • D
      remote: use enum helpers for parsing remote driver transport · 8b216749
      Daniel P. Berrangé 提交于
      Instead of open-coding a string -> enum conversion, use the enum helpers
      for the remote driver transport. The old code uses STRCASEEQ, so we must
      force the URI transport to lowercase for sake of back-compatibility.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      8b216749
    • D
      remote: handle autoprobing of driver within virtproxyd · 55c8d1a9
      Daniel P. Berrangé 提交于
      The virtproxyd daemon is merely responsible for forwarding RPC calls to
      one of the other per-driver daemons. As such, it does not have any
      drivers loaded and so regular auto-probing logic will not work. We need
      it to be able to handle NULL URIs though, so must implement some kind of
      alternative probing logic.
      
      When running as root this is quite crude. If a per-driver daemon is
      running, its UNIX socket will exist and we can assume it will accept
      connections. If the per-driver daemon is not running, but socket
      autostart is enabled, we again just assume it will accept connections.
      
      The is not great, however, because a default install may well have
      all sockets available for activation. IOW, the virtxend socket may
      exist, despite the fact that the libxl driver will not actually work.
      
      When running as non-root this is slightly easier as we only have two
      drivers, QEMU and VirtualBox. These daemons will likely not be running
      and socket activation won't be used either, as libvirt spawns the
      daemon on demand. So we just check whether the daemon actually is
      installed.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      55c8d1a9
    • D
      remote: open secondary drivers via remote driver if needed · 46362955
      Daniel P. Berrangé 提交于
      When the client has a connection to one of the hypervisor specific
      daemons (eg virtqemud), the app may still expect to use the secondary
      driver APIs (storage, network, etc). None of these will be registered in
      the hypervisor daemon, so we must explicitly open a connection to each
      of the daemons for the secondary drivers we need.
      
      We don't want to open these secondary driver connections at the same
      time as the primary connection is opened though. That would mean that
      establishing a connection to virtqemud would immediately trigger
      activation of virtnetworkd, virnwfilterd, etc despite that that these
      drivers may never be used by the app.
      
      Thus we only open the secondary driver connections at time of first use
      by an API call.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      46362955
    • D
      remote: change hand written methods to not directly access connection · 76d5208b
      Daniel P. Berrangé 提交于
      The driver dispatch methods access the priv->conn variables directly.
      In future we want to dynamically open the connections for the secondary
      driver. Thus we want the methods to call a method to get the connection
      handle instead of assuming the private variable is non-NULL.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      76d5208b
    • D
      remote: fix lock ordering mistake in event registration · 7ea3f0d7
      Daniel P. Berrangé 提交于
      If the event (un)registration methods are invoked while no connection is
      open, they jump to a cleanup block which unlocks a mutex which is not
      currently locked.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      7ea3f0d7
    • D
      remote: change generated methods to not directly access connection · 9cc8ecc8
      Daniel P. Berrangé 提交于
      The driver dispatch methods access the priv->conn variables directly.
      In future we want to dynamically open the connections for the secondary
      driver. Thus we want the methods to call a method to get the connection
      handle instead of assuming the private variable is non-NULL.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      9cc8ecc8
    • D
      remote: get rid of bogus ATTRIBUTE_UNUSED annotation client param · 690f0275
      Daniel P. Berrangé 提交于
      The client parameter is always used to get access to the private data
      struct.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      690f0275