1. 11 7月, 2019 1 次提交
    • D
      network: acquire a pidfile in the driver root directory · c03aef7c
      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/network/driver.pid
      
      In unprivileged libvirtd this ends up locking
      
        /run/user/$UID/libvirt/network/run/driver.pid
      
      NB, the latter can vary depending on $XDG_RUNTIME_DIR
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      c03aef7c
  2. 26 6月, 2019 1 次提交
    • D
      network: avoid including sys/sysctl.h on Linux · 3338c40b
      Daniel P. Berrangé 提交于
      The sys/sysctl.h header is only needed on BSD platforms to get
      the sysctlbyname() function declaration. On Linux we talk to
      procfs instead to change sysctls.
      
      Unfortunately a legacy sys/sysctl.h header does exist on Linux
      and including it has recently started triggering a deprecation
      warning from glibc.
      
      Protect its inclusion with a HAVE_SYSCTLBYNAME check instead
      so that it only gets used on platforms where we need that
      function declaration.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      3338c40b
  3. 17 6月, 2019 12 次提交
  4. 23 5月, 2019 1 次提交
  5. 21 5月, 2019 6 次提交
  6. 30 4月, 2019 1 次提交
  7. 24 4月, 2019 1 次提交
  8. 23 4月, 2019 1 次提交
  9. 18 4月, 2019 4 次提交
  10. 17 4月, 2019 2 次提交
  11. 16 4月, 2019 7 次提交
  12. 19 3月, 2019 2 次提交
    • D
      network: avoid trying to create global firewall rules if unprivileged · 5d010c3d
      Daniel P. Berrangé 提交于
      The unprivileged libvirtd does not have permission to create firewall
      rules, or bridge devices, or do anything to the host network in
      general. Historically we still activate the network driver though and
      let the network start API call fail.
      
      The startup code path which reloads firewall rules on active networks
      would thus effectively be a no-op when unprivileged as it is impossible
      for there to be any active networks
      
      With the change to use a global set of firewall chains, however, we now
      have code that is run unconditionally.
      
      Ideally we would not register the network driver at all when
      unprivileged, but the entanglement with the virt drivers currently makes
      that impractical. As a temporary hack, we just make the firewall reload
      into a no-op.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      5d010c3d
    • D
      network: improve error report when firewall chain creation fails · 9f4e35dc
      Daniel P. Berrangé 提交于
      During startup we create some top level chains in which all
      virtual network firewall rules will be placed. The upfront
      creation is done to avoid slowing down creation of individual
      virtual networks by checking for chain existance every time.
      
      There are some factors which can cause this upfront creation
      to fail and while a message will get into the libvirtd log
      this won't be seen by users who later try to start a virtual
      network. Instead they'll just get a message saying that the
      libvirt top level chain does not exist. This message is
      accurate, but unhelpful for solving the root cause.
      
      This patch thus saves any error during daemon startup and
      reports it when trying to create a virtual network later.
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      9f4e35dc
  13. 14 3月, 2019 1 次提交