1. 02 7月, 2016 3 次提交
  2. 01 7月, 2016 1 次提交
  3. 30 6月, 2016 1 次提交
  4. 27 6月, 2016 8 次提交
    • J
      Revert "conf: allow setting peer address in <ip> element of <interface>" · f6acf039
      Ján Tomko 提交于
      This reverts commit 93135abf.
      
      This feature was accidentally pushed in the feature freeze.
      f6acf039
    • J
      Revert "conf: support host-side IP/route information in <interface>" · d6584565
      Ján Tomko 提交于
      This reverts commit fe6a7789.
      
      This feature was accidentally pushed in the feature freeze.
      d6584565
    • L
      conf: support host-side IP/route information in <interface> · fe6a7789
      Laine Stump 提交于
      This is place as a sub-element of <source>, where other aspects of the
      host-side connection to the network device are located (network or
      bridge name, udp listen port, etc). It's a bit odd that the interface
      we're configuring with this info is itself named in <target dev='x'/>,
      but that ship sailed long ago:
      
          <interface type='ethernet'>
            <mac address='00:16:3e:0f:ef:8a'/>
            <source>
              <ip address='192.168.122.12' family='ipv4'
                  prefix='24' peer='192.168.122.1'/>
              <ip address='192.168.122.13' family='ipv4' prefix='24'/>
              <route family='ipv4' address='0.0.0.0'
                     gateway='192.168.122.1'/>
              <route family='ipv4' address='192.168.124.0' prefix='24'
                     gateway='192.168.124.1'/>
            </source>
          </interface>
      
      In practice, this will likely only be useful for type='ethernet', so
      its presence in any other type of interface is currently forbidden in
      the generic device Validate function (but it's been put into the
      general population of virDomainNetDef rather than the
      ethernet-specific union member so that 1) we can more easily add the
      capability to other types, and 2) we can retain the info when set to
      an invalid interface type all the way through to validation and report
      a proper error, rather than just ignoring it (which is currently what
      happens for many other type-specific settings).
      
      (NB: The already-existing configuration of IP info for the guest-side
      of interfaces is in subelements directly under <interface>, and the
      name of the guest-side interface (when configurable) is in <guest
      dev='x'/>).
      fe6a7789
    • V
      conf: allow setting peer address in <ip> element of <interface> · 93135abf
      Vasiliy Tolstov 提交于
      The peer attribute is used to set the property of the same name in the
      interface IP info:
      
        <interface type='ethernet'>
          ...
          <ip family='ipv4' address='192.168.122.5'
              prefix='32' peer='192.168.122.6'/>
          ...
        </interface>
      
      Note that this element is used to set the IP information on the
      *guest* side interface, not the host side interface - that will be
      supported in an upcoming patch.
      
      (This is an updated *re*-commit of commit 690969af, which was
      subsequently reverted in commit 1d14b13f).
      Signed-off-by: NVasiliy Tolstov <v.tolstov@selfip.ru>
      Signed-off-by: NLaine Stump <laine@laine.org>
      93135abf
    • L
      conf: use virNetDevIPInfo for guest-side <interface> config · fbc1843d
      Laine Stump 提交于
      All the same information was already there, just in slightly different
      places in the virDomainNetDef.
      fbc1843d
    • L
      conf: use virNetDevIPInfo in virDomainHostdevCaps · 69e04044
      Laine Stump 提交于
      a.k.a. <hostdev mode='capabilities' type='net'>.
      
      This replaces the existing nips, ips, nroutes, and routes with a
      single virNetDevIPInfo, and simplifies the code by calling that
      object's parse/format/clear functions instead of open coding.
      69e04044
    • L
      conf: single object containing list of IP addresses, list of routes · 9911562a
      Laine Stump 提交于
      There are currently two places in the domain where this combination is
      used, and there is about to be another. This patch puts them together
      for brevity and uniformity.
      
      As with the newly-renamed virNetDevIPAddr and virNetDevIPRoute
      objects, the new virNetDevIPInfo object will need to be accessed by a
      utility function that calls low level Netlink functions (so we don't
      want it to be in the conf directory) and will be called from multiple
      hypervisor drivers (so it can't be in any hypervisor directory); the
      most appropriate place is thus once again the util directory.
      
      The parse and format functions are in conf/domain_conf.c because only
      the domain XML (i.e. *not* the network XML) has this exact combination
      of IP addresses plus routes. Note that virDomainNetIPInfoFormat() will
      end up being the only caller to virDomainNetRoutesFormat() and
      virDomainNetIPsFormat(), so it will just subsume those functions in a
      later patch, but we can't do that until they are no longer called.
      
      (It would have been nice to include the interface name within the
      virNetDevIPInfo object (with a slight name change), but that can't
      be done cleanly, because in each case the interface name is provided
      in a different place in the XML relative to the routes and IP
      addresses, so putting it in this object would actually make the code
      more confused rather than simpler).
      9911562a
    • L
      conf/openvz: eliminate incorrect/undocumented use of <source dev='blah'/> · 9658e70f
      Laine Stump 提交于
      When support for <interface type='ethernet'> was added in commit
      9a4b705f back in 2010, it erroneously looked at <source dev='blah'/>
      for a user-specified guest-side interface name. This was never
      documented though. (that attribute already existed at the time in the
      data.ethernet union member of virDomainNetDef, but apparently had no
      practical use - it was only used as a storage place for a NetDef's
      bridge name during qemuDomainXMLToNative(), but even then that was
      never used for anything).
      
      When support for similar guest-side device naming was added to the lxc
      driver several years later, it was put in a new subelement <guest
      dev='blah'/>.
      
      In the intervening years, since there was no validation that
      ethernet.dev was NULL in the other drivers that didn't actually use
      it, innocent souls who were adding other features assuming they needed
      to account for non-NULL ethernet.dev when really they didn't, so
      little bits of the usual pointless cargo-cult code showed up.
      
      This patch not only switches the openvz driver to use the documented
      <guest dev='blah'/> notation for naming the guest-side device (just in
      case anyone is still using the openvz driver), and logs an error if
      anyone tries to set <source dev='blah'/> for a type='ethernet'
      interface, it also removes the cargo-cult uses of ethernet.dev and
      <source dev='blah'/>, and eliminates if from the RNG and from
      virDomainNetDef.
      
      NB: I decided on this course of action after mentioning the
      inconsistency here:
      
        https://www.redhat.com/archives/libvir-list/2016-May/msg02038.html
      
      and getting encouragement do eliminate it in a later IRC discussion
      with danpb.
      9658e70f
  5. 26 6月, 2016 1 次提交
  6. 24 6月, 2016 2 次提交
  7. 21 6月, 2016 1 次提交
    • L
      conf: limit chassisNr, and busNr to a minimum value of 1, not 0 · df2fb9bf
      Laine Stump 提交于
      In the case of chassisNr (used to set chassis_nr of a pci-bridge
      controller), 0 is reserved for / used by the pci[e]-root bus. In the
      base of busNr, a value of 0 would mean that the root bus had no places
      available to plug in new buses, including the pxb itself (the
      documentation I wrote for pxb even noted the limit of busNr as 1.254).
      
      NB: oddly, the "chassis" attribute, which is used for pcie-root-port
      and pcie-switch-downstream-port *can* be set to 0, since it's the
      combination of {chassis, slot} that needs to be unique, not chassis by
      itself (and slot 0 of pcie-root is reserved, while pcie-*-port can use
      *only* slot 0).
      
      This resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1342962
      df2fb9bf
  8. 17 6月, 2016 1 次提交
  9. 16 6月, 2016 1 次提交
  10. 15 6月, 2016 2 次提交
  11. 14 6月, 2016 6 次提交
  12. 09 6月, 2016 5 次提交
  13. 08 6月, 2016 1 次提交
  14. 06 6月, 2016 1 次提交
  15. 04 6月, 2016 1 次提交
  16. 30 5月, 2016 1 次提交
  17. 28 5月, 2016 1 次提交
    • M
      docs: Teach apibuild to deal with (1U << 31) too · 38df47c9
      Michal Privoznik 提交于
      The apibuild script is a terrifying beast that parses some source
      files of ours and produces an XML representation of them. When it
      comes to parsing enums we have in some header files, it tries to
      be clever and detect a value that an enum member has (or if it is
      an alias for a different member). Whilst doing that it has to
      deal with values we give to the members in many formats. At some
      places we just pass the value in decimal:
      
          VIR_DOMAIN_BLOCK_JOB_TYPE_PULL = 1,
      
      in other places, we use the aliasing:
      
          VIR_CONNECT_GET_ALL_DOMAINS_STATS_ACTIVE = VIR_CONNECT_LIST_DOMAINS_ACTIVE,
      
      and in other places bitwise shifts are used:
      
          VIR_CONNECT_GET_ALL_DOMAINS_STATS_ENFORCE_STATS = 1 << 31, /* enforce requested stats */
      
      The script tries to parse all of these resulting in the following
      tokens: "1", "VIR_CONNECT_LIST_DOMAINS_ACTIVE", "1<<31"; Then, the
      script tries to turn these into integers using python's eval()
      function. This function succeeds on the first and the last
      tokens. But, if we were to modify the last example so that it's
      of the following form:
      
          VIR_CONNECT_GET_ALL_DOMAINS_STATS_ENFORCE_STATS = 1U << 31, /* enforce requested stats */
      
      the token representing enum's member value will then be "1U<<31".
      So our parsing is good. Unfortunately, python is not aware of the
      difference between signed and unsigned C types, therefore eval()
      fails over this token and the parser falls back thinking it's an
      alias to another enum member. Well it's not.
      
      The solution is to transform [0-9]U into [0-9] as for our
      purposes here it's the same thing.
      Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
      38df47c9
  18. 26 5月, 2016 1 次提交
    • L
      conf: permit auto-assignment of controller indexes · 4d100c7a
      Laine Stump 提交于
      Hand-entering indexes for 20 PCI controllers is not as tedious as
      manually determining and entering their PCI addresses, but it's still
      annoying, and the algorithm for determining the proper index is
      incredibly simple (in all cases except one) - just pick the lowest
      unused index.
      
      The one exception is USB2 controllers because multiple controllers in
      the same group have the same index. For these we look to see if 1) the
      most recently added USB controller is also a USB2 controller, and 2)
      the group *that* controller belongs to doesn't yet have a controller
      of the exact model we're just now adding - if both are true, the new
      controller gets the same index, but in all other cases we just assign
      the lowest unused index.
      
      With this patch in place and combined with the automatic PCI address
      assignment, we can define a PCIe switch with several ports like this:
      
        <controller type='pci' model='pcie-root-port'/>
        <controller type='pci' model='pcie-switch-upstream-port'/>
        <controller type='pci' model='pcie-switch-downstream-port'/>
        <controller type='pci' model='pcie-switch-downstream-port'/>
        <controller type='pci' model='pcie-switch-downstream-port'/>
        <controller type='pci' model='pcie-switch-downstream-port'/>
        <controller type='pci' model='pcie-switch-downstream-port'/>
        ...
      
      These will each get a unique index, and PCI addresses that connect
      them together appropriately with no pesky numbers required.
      4d100c7a
  19. 25 5月, 2016 1 次提交
  20. 21 5月, 2016 1 次提交
    • L
      conf: allow type='pci' addresses with no address attributes specified · 8f578716
      Laine Stump 提交于
      Prior to this, <address type='pci'/> wasn't allowed when parsing
      (domain+bus+slot+function needed to be a "valid" PCI address, meaning
      that at least one of domain/bus/slot had to be non-0), the RNG
      required bus to be specified, and if type was set to PCI when
      formatting, domain+bus+slot+function would always be output.
      
      This makes all the address attributes optional during parse and RNG
      validation, and suppresses domain+bus+slot+function if domain+bus+slot
      are all 0 (NB: if d+b+s are all 0, any value for function is
      nonsensical as that will never happen in the real world, and after
      the next patch we will always assign a real working address to any
      empty PCI address before it is ever output to anywhere).
      
      Note that explicitly setting all attributes to 0 is equivalent to
      setting none of them, which is okay, since 0000:00:00 is reserved in
      any PCI bus setup, and can't be used anyway.
      8f578716