Commit Graph

37 Commits

Author SHA1 Message Date
Laine Stump
15b5902db9 network: don't add "no-resolv" if we still need DNS servers from resolv.conf
It was pointed out here:

  https://bugzilla.redhat.com/show_bug.cgi?id=1331796#c4

that we shouldn't be adding a "no-resolv" to the dnsmasq.conf file for
a network if there isn't any <forwarder> element that specifies an IP
address but no qualifying domain. If there is such an element, it will
handle all DNS requests that weren't otherwise handled by one of the
forwarder entries with a matching domain attribute. If not, then DNS
requests that don't match the domain of any <forwarder> would not be
resolved if we added no-resolv.

So, only add "no-resolv" when there is at least one <forwarder>
element that specifies an IP address but no qualifying domain.
2017-03-21 11:25:59 -04:00
Laine Stump
68a42bf6f7 conf: support configuring mtu size in a virtual network
Example:

  <network>
     ...
     <mtu size='9000'/>
     ...

If mtu is unset, it's assumed that we want the default for whatever is
the underlying transport (usually this is 1500).

This setting isn't yet wired in, so it will have no effect.

This partially resolves: https://bugzilla.redhat.com/1224348
2017-02-07 13:52:06 -05:00
Laine Stump
0b6336c2d9 network: allow limiting a <forwarder> element to certain domains
For some unknown reason the original implementation of the <forwarder>
element only took advantage of part of the functionality in the
dnsmasq feature it exposes - it allowed specifying the ip address of a
DNS server which *all* DNS requests would be forwarded to, like this:

   <forwarder addr='192.168.123.25'/>

This is a frontend for dnsmasq's "server" option, which also allows
you to specify a domain that must be matched in order for a request to
be forwarded to a particular server. This patch adds support for
specifying the domain. For example:

   <forwarder domain='example.com' addr='192.168.1.1'/>
   <forwarder domain='www.example.com'/>
   <forwarder domain='travesty.org' addr='10.0.0.1'/>

would forward requests for bob.example.com, ftp.example.com and
joe.corp.example.com all to the DNS server at 192.168.1.1, but would
forward requests for travesty.org and www.travesty.org to
10.0.0.1. And due to the second line, requests for www.example.com,
and odd.www.example.com would be resolved by the libvirt network's own
DNS server (i.e. thery wouldn't be immediately forwarded) even though
they also match 'example.com' - the match is given to the entry with
the longest matching domain. DNS requests not matching any of the
entries would be resolved by the libvirt network's own DNS server.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1331796
2016-08-19 21:34:51 -04:00
Laine Stump
9065cfaa88 network: allow disabling dnsmasq's DNS server
If you define a libvirt virtual network with one or more IP addresses,
it starts up an instance of dnsmasq. It's always been possible to
avoid dnsmasq's dhcp server (simply don't include a <dhcp> element),
but until now it wasn't possible to avoid having the DNS server
listening; even if the network has no <dns> element, it is started
using default settings.

This patch adds a new attribute to <dns>: enable='yes|no'. For
backward compatibility, it defaults to 'yes', but if you don't want a
DNS server created for the network, you can simply add:

   <dns enable='no'/>

to the network configuration, and next time the network is started
there will be no dns server created (if there is dhcp configuration,
dnsmasq will be started with "port=0" which disables the DNS server;
if there is no dhcp configuration, dnsmasq won't be started at all).
2016-08-19 21:10:34 -04:00
Laine Stump
25e8112d7c network: new network forward mode 'open'
The new forward mode 'open' is just like mode='route', except that no
firewall rules are added to assure that any traffic does or doesn't
pass. It is assumed that either they aren't necessary, or they will be
setup outside the scope of libvirt.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=846810
2016-08-19 21:05:15 -04:00
Brandon Bennett
47a0866bce Allow custom metadata in network configuration XML
This replicates the metadata field found in the domain configuration
    and adds it to the network configuration XML.
2016-07-01 13:05:25 -04:00
Laine Stump
3583e75d7e network: prevent duplicate entries in network device pools
Prior to this patch we didn't make any attempt to prevent two entries
in the array of interfaces/PCI devices from pointing to the same
device.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1002423
2016-04-19 12:39:13 -04:00
Martin Kletzander
1f24c1494a conf: Don't try formating non-existing addresses
Commit a6f9af8292 added checking for address colisions between
starting and ending addresses of forwarding addresses, but forgot that
there might be no addresses set at all.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-08-11 16:07:41 +02:00
Laine Stump
40961978ee conf: new network bridge device attribute macTableManager
The macTableManager attribute of a network's bridge subelement tells
libvirt how the bridge's MAC address table (used to determine the
egress port for packets) is managed. In the default mode, "kernel",
management is left to the kernel, which usually determines entries in
part by turning on promiscuous mode on all ports of the bridge,
flooding packets to all ports when the correct destination is unknown,
and adding/removing entries to the fdb as it sees incoming traffic
from particular MAC addresses.  In "libvirt" mode, libvirt turns off
learning and flooding on all the bridge ports connected to guest
domain interfaces, and adds/removes entries according to the MAC
addresses in the domain interface configurations. A side effect of
turning off learning and unicast_flood on the ports of a bridge is
that (with Linux kernel 3.17 and newer), the kernel can automatically
turn off promiscuous mode on one or more of the bridge's ports
(usually only the one interface that is used to connect the bridge to
the physical network). The result is better performance (because
packets aren't being flooded to all ports, and can be dropped earlier
when they are of no interest) and slightly better security (a guest
can still send out packets with a spoofed source MAC address, but will
only receive traffic intended for the guest interface's configured MAC
address).

The attribute looks like this in the configuration:

  <network>
    <name>test</name>
    <bridge name='br0' macTableManager='libvirt'/>
    ...

This patch only adds the config knob, documentation, and test
cases. The functionality behind this knob is added in later patches.
2014-12-08 14:41:37 -05:00
Laine Stump
07450cd429 conf: add trustGuestRxFilters attribute to network and domain interface
This new attribute will control whether or not libvirt will pay
attention to guest notifications about changes to network device mac
addresses and receive filters. The default for this is 'no' (for
security reasons). If it is set to 'yes' *and* the specified device
model and connection support it (currently only macvtap+virtio) then
libvirt will watch for NIC_RX_FILTER_CHANGED events, and when it
receives one, it will issue a query-rx-filter command, retrieve the
result, and modify the host-side macvtap interface's mac address and
unicast/multicast filters accordingly.

The functionality behind this attribute will be in a later patch. This
patch merely adds the attribute to the top-level of a domain's
<interface> as well as to <network> and <portgroup>, and adds
documentation and schema/xml2xml tests. Rather than adding even more
test files, I've just added the net attribute in various applicable
places of existing test files.
2014-10-06 11:49:10 -04:00
Peter Krempa
4cf1c3fab1 conf: net: Correctly switch how to format address fields
When formatting the forward mode addresses or interfaces the switch was
done based on the type of the network rather than of the type of the
individual <interface>/<address> element. In case a user would specify
an incorrect network type ("passhtrough") with <address> elements,
libvirtd would crash as it would attempt to format an <interface>.

Use the type of the individual element to format the XML.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1132347
2014-08-21 15:55:07 +02:00
Diego Woitasen
22547b4c98 Add forwarder attribute to <dns/> element
Useful to set custom forwarders instead of using the contents of
/etc/resolv.conf. It helps me to setup dnsmasq as local nameserver to
resolve VM domain names from domain 0, when domain option is used.

Signed-off-by: Diego Woitasen <diego.woitasen@vhgroup.net>
Signed-off-by: Eric Blake <eblake@redhat.com>
2013-09-17 17:47:33 -06:00
Ján Tomko
437b7944a8 Add '<nat>' element to '<forward>' network schemas
Commits 905629f4 and 1716e7a6 have added support for specifying
an IPv4 range and a port range to be used by NAT:
<forward mode='nat'>
  <nat>
    <address start='10.20.30.40' end='10.20.30.44'/>
    <port start='60000' end='65432'/>
  </nat>
</forward>

https://bugzilla.redhat.com/show_bug.cgi?id=1004364
2013-09-05 13:45:49 +02:00
Ján Tomko
2d9185a9f3 Test network update XML parsing
Add checks for updating sections of network definition via
virNetworkDefUpdateSection.

https://bugzilla.redhat.com/show_bug.cgi?id=989569
2013-08-28 08:05:46 +02:00
Ján Tomko
d8bd24a9ec Remove the space before the slash in network XML
This matches the style we use elsewhere and allows
nat-network-dns-srv-record{,-minimal}.xml to be tested in
network XML -> XML test.
2013-08-28 08:05:46 +02:00
Laine Stump
4f595ba61c network: permit upstream forwarding of unqualified DNS names
This resolves the issue that prompted the filing of

  https://bugzilla.redhat.com/show_bug.cgi?id=928638

(although the request there is for something much larger and more
general than this patch).

commit f3868259ca disabled the
forwarding to upstream DNS servers of unresolved DNS requests for
names that had no domain, but were just simple host names (no "."
character anywhere in the name). While this behavior is frowned upon
by DNS root servers (that's why it was changed in libvirt), it is
convenient in some cases, and since dnsmasq can be configured to allow
it, it must not be strictly forbidden.

This patch restores the old behavior, but since it is usually
undesirable, restoring it requires specification of a new option in
the network config. Adding the attribute "forwardPlainNames='yes'" to
the <dns> elemnt does the trick - when that attribute is added to a
network config, any simple hostnames that can't be resolved by the
network's dnsmasq instance will be forwarded to the DNS servers listed
in the host's /etc/resolv.conf for an attempt at resolution (just as
any FQDN would be forwarded).

When that attribute *isn't* specified, unresolved simple names will
*not* be forwarded to the upstream DNS server - this is the default
behavior.
2013-08-14 09:46:22 -04:00
james robson
861d40565e Configure native vlan modes on Open vSwitch ports
This patch adds functionality to allow libvirt to configure the
'native-tagged' and 'native-untagged' modes on openvswitch networks.

Signed-off-by: Laine Stump <laine@redhat.com>
2013-06-25 00:22:36 -04:00
Gene Czarcinski
ccff335f83 Support for static routes on a virtual bridge
network: static route support for <network>

This patch adds the <route> subelement of <network> to define a static
route.  the address and prefix (or netmask) attribute identify the
destination network, and the gateway attribute specifies the next hop
address (which must be directly reachable from the containing
<network>) which is to receive the packets destined for
"address/(prefix|netmask)".

These attributes are translated into an "ip route add" command that is
executed when the network is started. The command used is of the
following form:

  ip route add <address>/<prefix> via <gateway> \
               dev <virbr-bridge> proto static metric <metric>

Tests are done to validate that the input data are correct.  For
example, for a static route ip definition, the address must be a
network address and not a host address.  Additional checks are added
to ensure that the specified gateway is directly reachable via this
network (i.e. that the gateway IP address is in the same subnet as one
of the IP's defined for the network).

prefix='0' is supported for both family='ipv4' address='0.0.0.0'
netmask='0.0.0.0' or prefix='0', and for family='ipv6' address='::',
prefix=0', although care should be taken to not override a desired
system default route.

Anytime an attempt is made to define a static route which *exactly*
duplicates an existing static route (for example, address=::,
prefix=0, metric=1), the following error message will be sent to
syslog:

    RTNETLINK answers: File exists

This can be overridden by decreasing the metric value for the route
that should be preferred, or increasing the metric for the route that
shouldn't be preferred (and is thus in place only in anticipation that
the preferred route may be removed in the future).  Caution should be
used when manipulating route metrics, especially for a default route.

Note: The use of the command-line interface should be replaced by
direct use of libnl so that error conditions can be handled better.  But,
that is being left as an exercise for another day.

Signed-off-by: Gene Czarcinski <gene@czarc.net>
Signed-off-by: Laine Stump <laine@laine.org>
2013-05-13 16:14:40 -04:00
Laine Stump
d64e114f14 network: support <driver name='vfio'/> in network definitions
I remembered to document this bit, but somehow forgot to implement it.

This adds <driver name='kvm|vfio'/> as a subelement to the <forward>
element of a network (this puts it parallel to the match between
mode='hostdev' attribute in a network and type='hostdev' in an
<interface>).

Since it's already documented, only the parser, formatter, backend
driver recognition (it just translates/moves the flag into the
<interface> at the appropriate time), and a test case were needed.

(I used a separate enum for the values both because the original is
defined in domain_conf.h, which is unavailable from network_conf.h,
and because in the future it's possible that we may want to support
other non-hostdev oriented driver names in the network parser; this
makes sure that one can be expanded without the other).
2013-04-26 21:51:12 -04:00
Laine Stump
db2536a627 Revert "Add support for <option> tag in network config"
This reverts commit 383ebc4694.

We decided the xml for this feature needed more thought to make sure
we are doing it the best way, in particular wrt option values that
have multiple items.
2013-02-27 10:55:24 -05:00
Gene Czarcinski
0b73a763f3 use client id for IPv6 DHCP host definition
Originally, only a host name was used to associate a
DHCPv6 request with a specific IPv6 address.  Further testing
demonstrates that this is an unreliable method and, instead,
a client-id or DUID needs to be used.  According to DHCPv6
standards, this id can be a duid-LLT, duid-LL, or duid-UUID
even though dnsmasq will accept almost any text string.

Although validity checking of a specified string makes sure it is
hexadecimal notation with bytes separated by colons, there is no
rigorous check to make sure it meets the standard.

Documentation and schemas have been updated.

Signed-off-by: Gene Czarcinski <gene@czarc.net>
Signed-off-by: Laine Stump <laine@laine.org>
2013-02-25 02:49:06 -05:00
Pieter Hollants
383ebc4694 Add support for <option> tag in network config
This patch adds support for a new <option>-Tag in the <dhcp> block of
network configs, based on a subset of the fifth proposal by Laine
Stump in the mailing list discussion at
https://www.redhat.com/archives/libvir-list/2012-November/msg01054.html.
Any such defined option will result in a dhcp-option=<number>,"<value>"
statement in the generated dnsmasq configuration file.

Currently, DHCP options can be specified by number only and there is
no whitelisting or blacklisting of option numbers, which should
probably be added.

Signed-off-by: Pieter Hollants <pieter@hollants.com>
Signed-off-by: Laine Stump <laine@laine.org>
2013-02-22 19:45:19 -05:00
Gene Czarcinski
705e67d40b network: allow guest to guest IPv6 without gateway definition
This patch adds the capability for virtual guests to do IPv6
communication via a virtual network interface with no IPv6 (gateway)
addresses specified.  This capability has always been enabled by
default for IPv4, but disabled for IPv6 for security concerns, and
because it requires the ip6tables command to be operational (which
isn't the case on a system with the ipv6 module completely disabled).

This patch adds a new attribute "ipv6" at the toplevel of a <network>
object.  If ipv6='yes', the extra ip6tables rules required to permite
inter-guest communications are added when the network is started. If
it is 'no', or not present, those rules will not be added; thus the
default behavior doesn't change, so there should be no compatibility
issues with any existing installations.

Note that virtual guests cannot communication with the virtualization
host via this interface, because the following kernel tunable has
been set:

   net.ipv6.conf.<bridge_interface_name>.disable_ipv6 = 1

This assures that the bridge interface will not have an IPv6
link-local (fe80::) address.

To control this behavior so that it is not enabled by default, the parameter
ipv6='yes' on the <network> statement has been added.

Documentation related to this patch has been updated.
The network schema has also been updated.
2012-12-05 14:58:32 -05:00
Shradha Shah
1446003419 conf: parser/formatter/rng for <forward mode='hostdev'>
This patch introduces the new forward mode='hostdev' along with
attribute managed. Includes updates to the network RNG and new xml
parser/formatter code.

Signed-off-by: Shradha Shah <sshah@solarflare.com>
2012-08-17 15:43:26 -04:00
Laine Stump
3f9274a524 conf: add <vlan> element to network and domain interface elements
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.)
2012-08-15 13:10:57 -04:00
Laine Stump
4af3cbafdd conf: support partially-specified <virtualport> in parser and formatter
Until now, all attributes in a <virtualport> parameter list that were
acceptable for a particular type, were also required. There were no
optional attributes.

One of the aims of supporting <virtualport> in libvirt's virtual
networks and portgroups is to allow specifying the group-wide
parameters in the network's virtualport, and merge that with the
interface's virtualport, which will have the instance-specific info
(i.e. the interfaceid or instanceid).

Additionally, the guest's interface XML shouldn't need to know what
type of network connection will be used prior to runtime - it could be
openvswitch, 802.1Qbh, 802.1Qbg, or none of the above - but should
still be able to specify instance-specific info just in case it turns
out to be applicable.

Finally, up to now, the parser for virtualport has always generated a
random instanceid/interfaceid when appropriate, making it impossible
to leave it blank (which is what's required for virtualports within a
network/portprofile definition).

This patch modifies the parser and formatter of the <virtualport>
element in the following ways:

* because most of the attributes in a virNetDevVPortProfile are fixed
  size binary data with no reserved values, there is no way to embed a
  "this value wasn't specified" sentinel into the existing data. To
  solve this problem, the new *_specified fields in the
  virNetDevVPortProfile object that were added in a previous patch of
  this series are now set when the corresponding attribute is present
  during the parse.

* allow parsing/formatting a <virtualport> that has no type set. In
  this case, all fields are settable, but all are also optional.

* add a GENERATE_MISSING_DEFAULTS flag to the parser - if this flag is
  set and an instanceid/interfaceid is expected but not provided, a
  random one will be generated. This was previously the default
  behavior, but is now done only for virtualports inside an
  <interface> definition, not for those in <network> or <portgroup>.

* add a REQUIRE_ALL_ATTRIBUTES flag to the parser - if this flag is
  set the parser will call the new
  virNetDevVPortProfileCheckComplete() functions at the end of the
  parser to check for any missing attributes (based on type), and
  return failure if anything is missing. This used to be default
  behavior. Now it is only used for the virtualport defined inside an
  interface's <actual> element (by the time you've figured out the
  contents of <actual>, you should have all the necessary data to fill
  in the entire virtualport)

* add a REQUIRE_TYPE flag to the parser - if this flag is set, the
  parser will return an error if the virtualport has no type
  attribute. This also was previously the default behavior, but isn't
  needed in the case of the virtualport for a type='network' interface
  (i.e. the exact type isn't yet known), or the virtualport of a
  portgroup (i.e. the portgroup just has modifiers for the network's
  virtualport, which *does* require a type) - in those cases, the
  check will be done at domain startup, once the final virtualport is
  assembled (this is handled in the next patch).
2012-08-14 15:47:50 -04:00
Shradha Shah
b01b53de3f Adding the element pf to network xml.
This element will help the user to just specify the SR-IOV physical
function in order to access all the Virtual functions attached to it.
2012-01-11 13:10:21 -07:00
Michal Novotny
973af2362c Implement DNS SRV record into the bridge driver
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: Michal Novotny <minovotn@redhat.com>
2012-01-02 23:05:55 +08:00
Michal Privoznik
e5f1f9de77 bandwidth: Add test cases for network 2011-07-25 13:50:06 +08:00
Laine Stump
40fd7073be conf: support abstracted interface info in network XML
The network XML is updated in the following ways:

1) The <forward> element can now contain a list of forward interfaces:

     <forward .... >
       <interface dev='eth10'/>
       <interface dev='eth11'/>
       <interface dev='eth12'/>
       <interface dev='eth13'/>
     </forward>

   The first of these takes the place of the dev attribute that is
   normally in <forward> - when defining a network you can specify
   either one, and on output both will be present. If you specify
   both on input, they must match.

2) In addition to forward modes of 'nat' and 'route', these new modes
   are supported:

     private, passthrough, vepa - when this network is referenced by a
     domain's interface, it will have the same effect as if the
     interface had been defined as type='direct', e.g.:

        <interface type='direct'>
          <source mode='${mode}' dev='${dev}>
          ...
        </interface>

     where ${mode} is one of the three new modes, and ${dev} is an interface
     selected from the list given in <forward>.

     bridge - if a <forward> dev (or multiple devs) is defined, and
     forward mode is 'bridge' this is just like the modes 'private',
     'passthrough', and 'vepa' above. If there is no forward dev
     specified but a bridge name is given (e.g. "<bridge
     name='br0'/>"), then guest interfaces using this network will use
     libvirt's "host bridge" mode, equivalent to this:

       <interface type='bridge'>
          <source bridge='${bridge-name}'/>
          ...
       </interface>

3) A network can have multiple <portgroup> elements, which may be
   selected by the guest interface definition (by adding
   "portgroup='${name}'" in the <source> element along with the
   network name). Currently a portgroup can only contain a
   virtportprofile, but the intent is that other configuration items
   may be put there int the future (e.g. bandwidth config). When
   building a guest's interface, if the <interface> XML itself has no
   virtportprofile, and if the requested network has a portgroup with
   a name matching the name given in the <interface> (or if one of the
   network's portgroups is marked with the "default='yes'" attribute),
   the virtportprofile from that portgroup will be used by the
   interface.

4) A network can have a virtportprofile defined at the top level,
   which will be used by a guest interface when connecting in one of
   the 'direct' modes if the guest interface XML itself hasn't
   specified any virtportprofile, and if there are also no matching
   portgroups on the network.
2011-07-21 14:46:53 -04:00
Michal Novotny
9d4e2845d4 Network: Add support for DNS hosts definition to the network XML
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: Michal Novotny <minovotn@redhat.com>
Signed-off-by: Laine Stump <laine@laine.org>
2011-06-24 16:15:36 -04:00
Michal Novotny
5dd986dbd7 Add TXT record support for virtual DNS service
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: Michal Novotny <minovotn@redhat.com>
Signed-off-by: Laine Stump <laine@laine.org>
2011-06-24 16:15:12 -04:00
Laine Stump
5754dbd56d Give each virtual network bridge its own fixed MAC address
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
2011-02-17 13:36:32 -05:00
Laine Stump
a950dd2a31 Change virtual network XML parsing/formatting to support IPv6
This commit adds support for IPv6 parsing and formatting to the
virtual network XML parser, including moving around data definitions
to allow for multiple <ip> elements on a single network, but only
changes the consumers of this API to accommodate for the changes in
API/structure, not to add any actual IPv6 functionality. That will
come in a later patch - this patch attempts to maintain the same final
functionality in both drivers that use the network XML parser - vbox
and "bridge" (the Linux bridge-based driver used by the qemu
hypervisor driver).

* src/libvirt_private.syms: Add new private API functions.
* src/conf/network_conf.[ch]: Change C data structure and
  parsing/formatting.
* src/network/bridge_driver.c: Update to use new parser/formatter.
* src/vbox/vbox_tmpl.c: update to use new parser/formatter
* docs/schemas/network.rng: changes to the schema -
  * there can now be more than one <ip> element.
  * ip address is now an ip-addr (ipv4 or ipv6) rather than ipv4-addr
  * new optional "prefix" attribute that can be used in place of "netmask"
  * new optional "family" attribute - "ipv4" or "ipv6"
    (will default to ipv4)
  * define data types for the above
* tests/networkxml2xml(in|out)/nat-network.xml: add multiple <ip> elements
  (including IPv6) to a single network definition to verify they are being
  correctly parsed and formatted.
2010-12-23 15:53:55 -05:00
Laine Stump
008abeeeb9 make the <dhcp> element optional in network.rng
In practice this has always been optional, but the RNG has shown it as
mandatory, and since all the examples for make check had it, it was
never noticed. One of the existing test cases has been changed to
check for this.

I also noticed that the dhcp/host/ip was still defined as <text/>,
but should really be <ref name='ipv4-addr'/>
2010-12-23 15:53:44 -05:00
Paolo Bonzini
936565c701 Add support for an external TFTP boot server
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
2009-10-28 15:57:49 +01:00
Cole Robinson
6d8331fd58 tests: Add network XML to XML tests. 2009-10-16 10:52:26 -04:00