1. 03 1月, 2020 1 次提交
  2. 21 12月, 2019 1 次提交
  3. 13 11月, 2019 1 次提交
  4. 21 10月, 2019 1 次提交
  5. 16 10月, 2019 1 次提交
  6. 15 10月, 2019 1 次提交
  7. 19 9月, 2019 1 次提交
  8. 10 9月, 2019 2 次提交
  9. 04 9月, 2019 1 次提交
  10. 09 8月, 2019 2 次提交
    • 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: 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
  11. 07 8月, 2019 3 次提交
  12. 30 7月, 2019 1 次提交
  13. 06 3月, 2019 1 次提交
    • M
      Revert "Separate out StateAutoStart from StateInitialize" · 07a9c8ba
      Michal Privoznik 提交于
      https://bugzilla.redhat.com/show_bug.cgi?id=1685151
      
      This reverts commit e4a96909.
      
      Now that drivers may call virConnectOpen() on secondary drivers, it
      doesn't make much sense to have autostart separated from driver
      initialization callback. In fact, it creates a problem because one
      driver during its initialization might try to fetch an object from
      another driver but since the object is yet to be autostarted the fetch
      fails. This has been observed in reality: qemu driver performs
      qemuProcessReconnect() during qemu's stateInitialize phase which may
      call virDomainDiskTranslateSourcePool() which connects to the storage
      driver to look up the volume. But the storage driver did not autostart
      its pools yet therefore volume lookup fails and the domain is killed.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      07a9c8ba
  14. 14 2月, 2019 1 次提交
  15. 03 1月, 2019 1 次提交
  16. 06 11月, 2018 1 次提交
  17. 20 9月, 2018 2 次提交
  18. 11 7月, 2018 1 次提交
  19. 13 6月, 2018 1 次提交
  20. 16 5月, 2018 1 次提交
  21. 19 4月, 2018 1 次提交
  22. 12 4月, 2018 7 次提交
  23. 14 3月, 2018 1 次提交
  24. 16 10月, 2017 1 次提交
  25. 25 9月, 2017 1 次提交
  26. 27 7月, 2016 1 次提交
    • E
      virconf: Fix config file path construction · c5d0a2a3
      Erik Skultety 提交于
      Since commit c4bdff19, the path to the configuration file has been constructed
      in the following manner:
       - if no config filename was passed to virConfLoadConfigPath, libvirt.conf was
       used as default
       - otherwise the filename was concatenated with
       "<config_dir>/libvirt/libvirt%s%s.conf" which in admin case resulted in
       "libvirt-libvirt-admin.conf.conf". Obviously, this non-existent config led to
       ignoring  all user settings in libvirt-admin.conf. This patch requires the
       config filename to be always provided as an argument with the concatenation
       being simplified.
      
       Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1357364Signed-off-by: NErik Skultety <eskultet@redhat.com>
      c5d0a2a3
  27. 12 7月, 2016 1 次提交
  28. 08 6月, 2016 1 次提交
  29. 26 5月, 2016 1 次提交