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 f3868259 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.

Before, missing attributes were only OK when adding entries;
modification and deletion required all of them.

Now, only deletion works with missing attributes, as long as
the host is uniquely identified.

parentIndex is used in virNetworkDefUpdateIPDHCPRange

ip has to be NULL at this point.

This fixes a crash if one of them is missing.

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

Decrementing it when it was already 0 causes an invalid free
in virNetworkDefUpdateDNSHost if virNetworkDNSHostDefParseXML
fails and virNetworkDNSHostDefClear gets called twice.

virNetworkForwardDefClear left the number untouched even if it
freed all the elements.

Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Similarly to VIR_STRDUP, we want the OOM error to be reported in
VIR_ALLOC and friends.

Ensure that all APIs which list network objects filter
them against the access control system.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

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: NGene Czarcinski <gene@czarc.net>
Signed-off-by: NLaine Stump <laine@laine.org>

Use virBufferAddLit or virBufferAddChar instead.

The source code base needs to be adapted as well. Some files
include virutil.h just for the string related functions (here,
the include is substituted to match the new file), some include
virutil.h without any need (here, the include is removed), and
some require both.

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).

1. Handle invalid ULong prefix specified.
When parsing for @prefix as a ULong, a -2 can be returned
if the specification is not a valid ULong.

2.  Error out if address= is not specified.

3.  Merge netmask process/tests under family tests.

4. Max sure that prefix does not exceed maximum.
.
Signed-off-by: NGene Czarcinski <gene@czarc.net>

Create the utility function virSocketAddrGetIpPrefix() to
determine the prefix for this network.  The code in this
function was adapted from virNetworkIpDefPrefix().

Update virNetworkIpDefPrefix() in src/conf/network_conf.c
to use the new utility function.
Signed-off-by: NGene Czarcinski <gene@czarc.net>

Until now tranisent networks weren't really useful as libvirtd wasn't
able to remember them across restarts. This patch adds support for
loading status files of transient networks (that already were generated)
so that the status isn't lost.

This patch chops up virNetworkObjUpdateParseFile and turns it into
virNetworkLoadState and a few friends that will help us to load status
XMLs and refactors the functions that are loading the configs to use
them.

 ==5306== 8 bytes in 1 blocks are definitely lost in loss record 24 of 277
 ==5306==    at 0x4C28B2F: calloc (vg_replace_malloc.c:593)
 ==5306==    by 0x5293CAF: virAllocN (viralloc.c:152)
 ==5306==    by 0x52DFEAE: virXPathNodeSet (virxml.c:611)
 ==5306==    by 0x5313DD9: virNetworkDefParseXML (network_conf.c:1408)
 ==5306==    by 0x53170F6: virNetworkObjUpdateParseFile (network_conf.c:2031)
 ==5306==    by 0x131DA63C: networkStartup (bridge_driver.c:279)
 ==5306==    by 0x53481DF: virStateInitialize (libvirt.c:822)
 ==5306==    by 0x40DF44: daemonRunStateInit (libvirtd.c:877)
 ==5306==    by 0x52D2FF5: virThreadHelper (virthreadpthread.c:161)
 ==5306==    by 0x5D00C52: start_thread (in /usr/lib64/libpthread-2.17.so)
 ==5306==    by 0x6410ECC: clone (in /usr/lib64/libc-2.17.so)

When libvirtd loads active network configs from network state directory,
it should release the class_id memory block which was allocated
at the time of loading xml from network config directory.
virBitmapParse will create a new memory block of bitmap class_id which
causes a memory leak.

This happens when at least one virtual network is active before.

==12234== 8,216 (24 direct, 8,192 indirect) bytes in 1 blocks are definitely \
              lost in loss record 702 of 709
==12234==    at 0x4A06B2F: calloc (vg_replace_malloc.c:593)
==12234==    by 0x37AB04D77D: virAlloc (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB04EF89: virBitmapNew (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB0BFB37: virNetworkAssignDef (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB0BFD31: ??? (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x37AB0BFE92: virNetworkLoadAllConfigs (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x10650E5A: ??? (in /usr/lib64/libvirt/connection-driver/libvirt_driver_network.so)
==12234==    by 0x37AB0EB72F: virStateInitialize (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x40DE04: ??? (in /usr/sbin/libvirtd)
==12234==    by 0x37AB0832E8: ??? (in /usr/lib64/libvirt.so.0.1000.3)
==12234==    by 0x3796807D14: start_thread (in /usr/lib64/libpthread-2.16.so)
==12234==    by 0x37960F246C: clone (in /usr/lib64/libc-2.16.so)

This reverts commit 383ebc46.

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.

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: NGene Czarcinski <gene@czarc.net>
Signed-off-by: NLaine Stump <laine@laine.org>

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: NPieter Hollants <pieter@hollants.com>
Signed-off-by: NLaine Stump <laine@laine.org>

We pass over the address/port start/end values many times so we put
them in structs.
Signed-off-by: NNatanael Copa <ncopa@alpinelinux.org>
Signed-off-by: NLaine Stump <laine@laine.org>

Let users set the port range to be used for forward mode NAT:

...
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
...
Signed-off-by: NNatanael Copa <ncopa@alpinelinux.org>
Signed-off-by: NLaine Stump <laine@laine.org>

Support setting which public ip to use for NAT via attribute
address in subelement <nat> in <forward>:

...
  <forward mode='nat'>
      <address start='1.2.3.4' end='1.2.3.10'/>
  </forward>
...

This will construct an iptables line using:

  '-j SNAT --to-source <start>-<end>'

instead of:

  '-j MASQUERADE'
Signed-off-by: NNatanael Copa <ncopa@alpinelinux.org>
Signed-off-by: NLaine Stump <laine@laine.org>

The virNetworkObjUpdateParseFile() function was not freeing the xml
variable, leaving us with a memory leak.

virNetworkObjUpdateParseFile used ',' as the termination character for
virBitmapParse. This would break if an non-contiguous range would be
parsed.

Commit '07d1b6b5' added class_id bitmap to virNetworkObj but never freed
it.

gcc 4.1.2 on RHEL 5 warned:
conf/network_conf.c:3136: warning: 'foundIdx' may be used uninitialized in this function

The warning is spurious, but initializing the variable doesn't hurt.

* src/conf/network_conf.c (virNetworkDefUpdateDNSHost): Silence
unused variable warning.

gcc -O2 complained:
../../src/conf/network_conf.c: In function 'virNetworkDefUpdateDNSSrv':
../../src/conf/network_conf.c:3232: error: 'foundIdx' may be used uninitialized in this function [-Wuninitialized]

It turned out to be a spurious warning (we didn't use foundIdx
unless foundCt was non-zero).  But in investigating that, I noticed
a worse problem: we were using 'if (foundCt > 1)', but since foundCt
was bool, it could never be > 1.

* src/conf/network_conf.c (virNetworkDefUpdateDNSHost): Use
correct type.
(virNetworkDefUpdateDNSSrv): Likewise, and silence compiler
warning.

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>