1. 18 8月, 2012 1 次提交
  2. 16 8月, 2012 1 次提交
    • L
      conf: add <vlan> element to network and domain interface elements · 3f9274a5
      Laine Stump 提交于
      The following config elements now support a <vlan> subelements:
      
      within a domain: <interface>, and the <actual> subelement of <interface>
      within a network: the toplevel, as well as any <portgroup>
      
      Each vlan element must have one or more <tag id='n'/> subelements.  If
      there is more than one tag, it is assumed that vlan trunking is being
      requested. If trunking is required with only a single tag, the
      attribute "trunk='yes'" should be added to the toplevel <vlan>
      element.
      
      Some examples:
      
        <interface type='hostdev'/>
          <vlan>
            <tag id='42'/>
          </vlan>
          <mac address='52:54:00:12:34:56'/>
          ...
        </interface>
      
        <network>
          <name>vlan-net</name>
          <vlan trunk='yes'>
            <tag id='30'/>
          </vlan>
          <virtualport type='openvswitch'/>
        </network>
      
        <interface type='network'/>
          <source network='vlan-net'/>
          ...
        </interface>
      
        <network>
          <name>trunk-vlan</name>
          <vlan>
            <tag id='42'/>
            <tag id='43'/>
          </vlan>
          ...
        </network>
      
        <network>
          <name>multi</name>
          ...
          <portgroup name='production'/>
            <vlan>
              <tag id='42'/>
            </vlan>
          </portgroup>
          <portgroup name='test'/>
            <vlan>
              <tag id='666'/>
            </vlan>
          </portgroup>
        </network>
      
        <interface type='network'/>
          <source network='multi' portgroup='test'/>
          ...
        </interface>
      
      IMPORTANT NOTE: As of this patch there is no backend support for the
      vlan element for *any* network device type. When support is added in
      later patches, it will only be for those select network types that
      support setting up a vlan on the host side, without the guest's
      involvement. (For example, it will be possible to configure a vlan for
      a guest connected to an openvswitch bridge, but it won't be possible
      to do that for one that is connected to a standard Linux host bridge.)
      3f9274a5
  3. 15 8月, 2012 2 次提交
    • L
      network: add connections counter to networks · 300bcdb6
      Laine Stump 提交于
      Just as each physical device used by a network has a connections
      counter, now each network has a connections counter which is
      incremented once for each guest interface that connects using this
      network.
      
      The count is output in the live network XML, like this:
      
         <network connections='20'>
         ...
         </network>
      
      It is read-only, and for informational purposes only - it isn't used
      internally anywhere by libvirt.
      300bcdb6
    • L
      network: merge relevant virtualports rather than choosing one · 6a3691b7
      Laine Stump 提交于
      One of the original ideas behind allowing a <virtualport> in an
      interface definition as well as in the <network> definition *and*one
      or more <portgroup>s within the network, was that guest-specific
      parameteres (like instanceid and interfaceid) could be given in the
      interface's virtualport, and more general things (portid, managerid,
      etc) could be given in the network and/or portgroup, with all the bits
      brought together at guest startup time and combined into a single
      virtualport to be used by the guest. This was somehow overlooked in
      the implementation, though - it simply picks the "most specific"
      virtualport, and uses the entire thing, with no attempt to merge in
      details from the others.
      
      This patch uses virNetDevVPortProfileMerge3() to combine the three
      possible virtualports into one, then uses
      virNetDevVPortProfileCheck*() to verify that the resulting virtualport
      type is appropriate for the type of network, and that all the required
      attributes for that type are present.
      
      An example of usage is this: assuming a <network> definitions on host
      ABC of:
      
        <network>
          <name>testA</name>
          ...
          <virtualport type='openvswitch'/>
          ...
          <portgroup name='engineering'>
            <virtualport>
              <parameters profileid='eng'/>
            </virtualport>
          </portgroup>
          <portgroup name='sales'>
            <virtualport>
              <parameters profileid='sales'/>
            </virtualport>
          </portgroup>
        </network>
      
      and the same <network> on host DEF of:
      
        <network>
          <name>testA</name>
          ...
          <virtualport type='802.1Qbg'>
            <parameters typeid="1193047" typeidversion="2"/>
          </virtualport>
          ...
          <portgroup name='engineering'>
            <virtualport>
              <parameters managerid="11"/>
            </virtualport>
          </portgroup>
          <portgroup name='sales'>
            <virtualport>
              <parameters managerid="55"/>
            </virtualport>
          </portgroup>
        </network>
      
      and a guest <interface> definition of:
      
        <interface type='network'>
          <source network='testA' portgroup='sales'/>
          <virtualport>
            <parameters instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"
                        interfaceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"\>
          </virtualport>
          ...
        </interface>
      
      If the guest was started on host ABC, the <virtualport> used would be:
      
        <virtualport type='openvswitch'>
          <parameters interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'
                      profileid='sales'/>
        </virtualport>
      
      but if that guest was started on host DEF, the <virtualport> would be:
      
          <virtualport type='802.1Qbg'>
            <parameters instanceid="09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f"
                        typeid="1193047" typeidversion="2"
                        managerid="55"/>
          </virtualport>
      
      Additionally, if none of the involved <virtualport>s had a specified type
      (this includes cases where no virtualport is given at all),
      6a3691b7
  4. 20 3月, 2012 1 次提交
  5. 12 1月, 2012 1 次提交
  6. 02 1月, 2012 1 次提交
    • M
      Implement DNS SRV record into the bridge driver · 973af236
      Michal Novotny 提交于
      Hi,
      this is the fifth version of my SRV record for DNSMasq patch rebased
      for the current codebase to the bridge driver and libvirt XML file to
      include support for the SRV records in the DNS. The syntax is based on
      DNSMasq man page and tests for both xml2xml and xml2argv were added as
      well. There are some things written a better way in comparison with
      version 4, mainly there's no hack in tests/networkxml2argvtest.c and
      also the xPath context is changed to use a simpler query using the
      virXPathInt() function relative to the current node.
      
      Also, the patch is also fixing the networkxml2argv test to pass both
      checks, i.e. both unit tests and also syntax check.
      
      Please review,
      Michal
      Signed-off-by: NMichal Novotny <minovotn@redhat.com>
      973af236
  7. 21 10月, 2011 1 次提交
    • L
      docs: fix incorrect info about routed networks · 52e3b3d1
      Laine Stump 提交于
      In a recent expansion of the documentation on network forward modes, I
      incorrectly stated that incoming sessions to guests on routed networks
      were blocked. This is true for guests on NATed networks, but not
      routed. This patch corrects that error, and adds a pointer to the
      nwfilter page for those who do want to restrict incoming sessions to
      hosts on routed networks.
      52e3b3d1
  8. 15 10月, 2011 1 次提交
    • L
      docs: fix network XML documentation · 4040ff66
      Laine Stump 提交于
      A few people have attempted to use the new forwarding modes with older
      versions of libvirt. The docs where the modes are described have
      always stated the minimum required libvirt version, but the examples
      at the end didn't, which I believe is what has caused the confusion.
      
      Similarly, the section on portgroups now has a version tag added at
      the beginning.
      
      I also noticed that there was no example of defining a <dns> hostname,
      so I added one, as well as making the domain name example more
      recognizable (by adding ".com" to the domain).
      4040ff66
  9. 11 8月, 2011 2 次提交
    • L
      docs: use IPv6 addresses in range reserved for documentation · e6d5d610
      Laine Stump 提交于
      Someone in an IRC channel or an email pointed out a few days ago that
      the examples of IPv6 addresses in the libvirt documentation were not
      in the officially reserved "documentation" range. This addresses their
      concern.
      e6d5d610
    • L
      docs: describe new virtual switch configuration in network XML docs · 073ef15c
      Laine Stump 提交于
      This should have been done with the rest of the patch for virtual
      switch / network device abstraction. If documents the new elements
      (and new usage of existing elements) in the <network> XML to support
      libvirt networks that use existing host bridges and macvtap direct
      connections, as well as the new <portgroup> element.
      073ef15c
  10. 27 7月, 2011 1 次提交
    • M
      bandwidth: Integrate bandwidth into portgroups · fe957f0a
      Michal Privoznik 提交于
      Every DomainNetDef has a bandwidth, as does every portgroup.
      Whenever a DomainNetDef of type NETWORK is about to be used, a call is
      made to networkAllocateActualDevice(). This function chooses the "best"
      bandwidth object and places it in the DomainActualNetDef.
      From that point on, whenever some code needs to use the bandwidth data
      for the interface, it's retrieved with virDomainNetGetActualBandwidth(),
      which will always return the "best" info as determined in the
      previous step.
      fe957f0a
  11. 25 7月, 2011 1 次提交
    • M
      bandwidth: Define schema and create documentation · a8923162
      Michal Privoznik 提交于
      Define new 'bandwidth' element with possible child element 'inbound'
      and 'outbound' addressing incoming and outgoing traffic respectively:
      
      <bandwidth>
        <inbound average='1000' peak='2000' burst='5120'/>
        <outbound average='500'/>
      </bandwidth>
      
      Leaving any element out means not to shape traffic in that
      direction.
      The units for average and peak (rate) are in kilobytes per second,
      for burst (size) are just in kilobytes.
      This element can be inserted into domain's 'interface' and
      'network'.
      a8923162
  12. 25 6月, 2011 3 次提交
    • L
      docs: fix indentation of sub-elements of <ip> in network XML · 303133ee
      Laine Stump 提交于
      The sub-elements of <ip> had been placed at the same level of
      indentation as ip itself, implying that they were really elements of
      <network>. Within that, sub-elements of ip/dhcp were also at that same
      level. These have been double-indented.
      
      At the same time, I realized that the documentation for the new <dns>
      element had been placed right in the middle of the description of the
      sub-elements of <ip>. I moved it up out of the way.
      303133ee
    • M
      Network: Add support for DNS hosts definition to the network XML · 9d4e2845
      Michal Novotny 提交于
      This commit introduces names definition for the DNS hosts file using
      the following syntax:
      
        <dns>
          <host ip="192.168.1.1">
            <name>alias1</name>
            <name>alias2</name>
          </host>
        </dns>
      
      Some of the improvements and fixes were done by Laine Stump so
      I'm putting him into the SOB clause again ;-)
      Signed-off-by: NMichal Novotny <minovotn@redhat.com>
      Signed-off-by: NLaine Stump <laine@laine.org>
      9d4e2845
    • M
      Add TXT record support for virtual DNS service · 5dd986db
      Michal Novotny 提交于
      This commit introduces the <dns> element and <txt> record for the
      virtual DNS network. The DNS TXT record can be defined using following
      syntax in the network XML file:
      
        <dns>
          <txt name="example" value="example value" />
        </dns>
      
      Also, the Relax-NG scheme has been altered to allow the texts without
      spaces only for the name element and some nitpicks about memory
      free'ing have been fixed by Laine so therefore I'm adding Laine to the
      SOB clause ;-)
      Signed-off-by: NMichal Novotny <minovotn@redhat.com>
      Signed-off-by: NLaine Stump <laine@laine.org>
      5dd986db
  13. 08 4月, 2011 1 次提交
    • L
      docs: add an IPv6 address to network XML examples · f25d064e
      Laine Stump 提交于
      It was just pointed out that, although I added documentation for the
      IPv6 additions to the network XML, I neglected to use those additions
      in the examples. This patch adds an IPv6 address to each of the
      examples except for the "default" network, since that is a faithful
      reproduction of the default network config that's automatically
      installed, which doesn't include any IPv6 address (for good reason -
      because there is no such thing as IPv6 NAT, there is no one IPv6
      address that would work for all installations).
      f25d064e
  14. 18 2月, 2011 1 次提交
    • L
      Give each virtual network bridge its own fixed MAC address · 5754dbd5
      Laine Stump 提交于
      This fixes https://bugzilla.redhat.com/show_bug.cgi?id=609463
      
      The problem was that, since a bridge always acquires the MAC address
      of the connected interface with the numerically lowest MAC, as guests
      are started and stopped, it was possible for the MAC address to change
      over time, and this change in the network was being detected by
      Windows 7 (it sees the MAC of the default route change), so on each
      reboot it would bring up a dialog box asking about this "new network".
      
      The solution is to create a dummy tap interface with a MAC guaranteed
      to be lower than any guest interface's MAC, and attach that tap to the
      bridge as soon as it's created. Since all guest MAC addresses start
      with 0xFE, we can just generate a MAC with the standard "0x52, 0x54,
      0" prefix, and it's guaranteed to always win (physical interfaces are
      never connected to these bridges, so we don't need to worry about
      competing numerically with them).
      
      Note that the dummy tap is never set to IFF_UP state - that's not
      necessary in order for the bridge to take its MAC, and not setting it
      to UP eliminates the clutter of having an (eg) "virbr0-nic" displayed
      in the output of the ifconfig command.
      
      I chose to not auto-generate the MAC address in the network XML
      parser, as there are likely to be consumers of that API that don't
      need or want to have a MAC address associated with the
      bridge.
      
      Instead, in bridge_driver.c when the network is being defined, if
      there is no MAC, one is generated. To account for virtual network
      configs that already exist when upgrading from an older version of
      libvirt, I've added a %post script to the specfile that searches for
      all network definitions in both the config directory
      (/etc/libvirt/qemu/networks) and the state directory
      (/var/lib/libvirt/network) that are missing a mac address, generates a
      random address, and adds it to the config (and a matching address to
      the state file, if there is one).
      
      docs/formatnetwork.html.in: document <mac address.../>
      docs/schemas/network.rng: add nac address to schema
      libvirt.spec.in: %post script to update existing networks
      src/conf/network_conf.[ch]: parse and format <mac address.../>
      src/libvirt_private.syms: export a couple private symbols we need
      src/network/bridge_driver.c:
          auto-generate mac address when needed,
          create dummy interface if mac address is present.
      tests/networkxml2xmlin/isolated-network.xml
      tests/networkxml2xmlin/routed-network.xml
      tests/networkxml2xmlout/isolated-network.xml
      tests/networkxml2xmlout/routed-network.xml: add mac address to some tests
      5754dbd5
  15. 24 12月, 2010 1 次提交
  16. 23 2月, 2010 2 次提交
  17. 06 11月, 2009 1 次提交
    • M
      Cleanup whitespace in docs · c6d5ac17
      Matthew Booth 提交于
      This patch is the result of running the following command in the docs
      directory: sed -i 's/\t/        /g; s/\s*$//' *.html.in
      
      * docs/*.html.in:convert tabs into 8 spaces and remove trailing whitespace
      c6d5ac17
  18. 28 10月, 2009 1 次提交
    • P
      Add support for an external TFTP boot server · 936565c7
      Paolo Bonzini 提交于
      This patch adds an optional attribute to the <bootp> tag, that
      allows to specify a TFTP server address other than the address of
      the DHCP server itself.
      
      This can be used to forward the BOOTP settings of the host down to the
      guest.  This is something that configurations such as Xen's default
      network achieve naturally, but must be done manually for NAT.
      
      * docs/formatnetwork.html.in: Document new attribute.
      * docs/schemas/network.rng: Add it to schema.
      * src/conf/network_conf.h: Add it to struct.
      * src/conf/network_conf.c: Add it to parser and pretty printer.
      * src/network/bridge_driver.c: Put it in the dnsmasq command line.
      * tests/networkxml2xmlin/netboot-proxy-network.xml
        tests/networkxml2xmlout/netboot-proxy-network.xml
        tests/networkxml2xmltest.c: add new tests
      936565c7
  19. 23 9月, 2009 1 次提交
    • P
      network: add 'bootp' and 'tftp' config · 738ee810
      Paolo Bonzini 提交于
      Currently, libvirtd will start a dnsmasq process for the virtual
      network, but (aside from killing the dnsmasq process and replacing it),
      there's no way to define tftp boot options.
      
      This change introduces the appropriate tags to the dhcp configuration:
      
       <network>
         <name>default</name>
         <bridge name="virbr%d" />
         <forward/>
         <ip address="192.168.122.1" netmask="255.255.255.0">
           <tftp root="/var/lib/tftproot" />
           <dhcp>
             <range start="192.168.122.2" end="192.168.122.254" />
             <bootp file="pxeboot.img"/>
           </dhcp>
         </ip>
       </network>
      
      When the attributes are present, these are passed to the
      arguments to dnsmasq:
      
       dnsmasq [...] --enable-tftp --tftp-root /srv/tftp --dhcp-boot pxeboot.img
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
                            from <tftp />                     from <bootp />
      
      At present, only local tftp servers are supported (ie, dnsmasq runs as
      the tftp server), but we could improve this in future by adding a
      server= attribute.
      Signed-off-by: NJeremy Kerr <jk@ozlabs.org>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      
      2009-09-21  Paolo Bonzini  <pbonzini@redhat.com>
                  Jeremy Kerr  <jk@ozlabs.org>
      
      	* docs/formatnetwork.html.in: Document new tags.
      	* docs/formatnetwork.html: Regenerate.
      	* docs/schemas/network.rng: Update.
      	* src/network_conf.c (virNetworkDefFree): Free new fields.
      	(virNetworkDHCPRangeDefParseXML): Parse <bootp>.
      	(virNetworkIPParseXML): New, parsing <dhcp> and <tftp>.
      	(virNetworkDefParseXML): Use virNetworkIPParseXML instead of
      	virNetworkDHCPRangeDefParseXML.
      	(virNetworkDefFormat): Pretty print new fields.
      	* src/network_conf.h (struct _virNetworkDef): Add netboot fields.
      	* src/network_driver.c (networkBuildDnsmasqArgv): Add
      	TFTP and BOOTP arguments.
      
      	* tests/Makefile.am (EXTRA_DIST): Add networkschemadata.
      	* tests/networkschematest: Look in networkschemadata.
      	* tests/networkschemadata/netboot-network.xml: New.
      738ee810
  20. 26 2月, 2009 1 次提交
  21. 09 7月, 2008 1 次提交
  22. 07 5月, 2008 1 次提交
  23. 29 4月, 2008 1 次提交
  24. 24 4月, 2008 1 次提交