1. 17 6月, 2019 5 次提交
  2. 23 5月, 2019 1 次提交
  3. 21 5月, 2019 6 次提交
  4. 30 4月, 2019 1 次提交
  5. 24 4月, 2019 1 次提交
  6. 23 4月, 2019 1 次提交
  7. 18 4月, 2019 4 次提交
  8. 17 4月, 2019 2 次提交
  9. 16 4月, 2019 7 次提交
  10. 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
  11. 14 3月, 2019 1 次提交
  12. 06 3月, 2019 1 次提交
  13. 22 2月, 2019 1 次提交
    • L
      network: add netmask to dhcp range of dnsmasq conf file for IPv4 · 82fe58ff
      Laine Stump 提交于
      dnsmasq documentation says that the *IPv4* prefix/network
      address/broadcast address sent to dhcp clients will be automatically
      determined by dnsmasq by looking at the interface it's listening on,
      so the original libvirt code did not add a netmask to the dnsmasq
      commandline (or later, the dnsmasq conf file).
      
      For *IPv6* however, dnsmasq apparently cannot automatically determine
      the prefix (functionally the same as a netmask), and it must be
      explicitly provided in the conf file (as a part of the dhcp-range
      option). So many years after IPv4 DHCP support had been added, when
      IPv6 dhcp support was added the prefix was included at the end of the
      dhcp-range setting, but only for IPv6.
      
      A user had reported a bug on a host where one of the interfaces was a
      superset of the libvirt network where dhcp is needed (e.g., the host's
      ethernet is 10.0.0.20/8, and the libvirt network is 10.10.0.1/24). For
      some reason dnsmasq was supplying the netmask for the /8 network to
      clients requesting an address on the /24 interface.
      
      This seems like a bug in dnsmasq, but even if/when it gets fixed
      there, it looks like there is no harm in just always adding the
      netmask to all IPv4 dhcp-range options similar to how prefix is added
      to all IPv6 dhcp-range options.
      Signed-off-by: NLaine Stump <laine@laine.org>
      Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
      82fe58ff
  14. 02 2月, 2019 1 次提交
  15. 01 2月, 2019 1 次提交
  16. 29 1月, 2019 1 次提交
  17. 26 1月, 2019 1 次提交
    • L
      network: remove stale function · 43be65a4
      Laine Stump 提交于
      networkMigrateStateFiles was added nearly 5 years ago when the network
      state directory was moved from /var/lib/libvirt to /var/run/libvirt
      just prior to libvirt-1.2.4). It was only required to maintain proper
      state information for networks that were active during an upgrade that
      didn't involve rebooting the host. At this point the likelyhood of
      anyone upgrading their libvirt from pre-1.2.4 directly to 5.0.0 or
      later *without rebooting the host* is probably so close to 0 that no
      properly informed bookie would take *any* odds on it happening, so it
      seems appropriate to remove this pointless code.
      Signed-off-by: NLaine Stump <laine@laine.org>
      Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
      43be65a4
  18. 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
  19. 20 9月, 2018 2 次提交