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.

Partially reverts commit 5754dbd5.

The code in the specfile adds a MAC address to every <bridge>,
even for <forward mode='bridge'> for which we don't support
changing MAC addresses.

Remove it completely. For new networks, we have been adding
MAC addresses on definition/creation since the commit mentioned above.
For existing networks (pre-0.9.0), the MAC is added by this commit.

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

Libvirt's RPMs have been adding it to networks which don't support it.

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

The function virNetworkObjListExport() in network_conf.c had a call to
the public API virNetworkFree() which was causing a link error:

CCLD     libvirt_driver_vbox_network_impl.la
 ./.libs/libvirt_conf.a(libvirt_conf_la-network_conf.o): In function `virNetworkObjListExport':
/home/laine/devel/libvirt/src/conf/network_conf.c:4496: undefined reference to `virNetworkFree'

This would happen when I added

  #include "network_conf.h"

into domain_conf.h, then attempted to call a new function from that
file (and enum converter, similar to virNetworkForwardTypeToString())

In the end, virNetworkFree() ends up just calling virObjectUnref(obj)
anyway (after clearing all pending errors, which we probably *don't*
want to do in the cleanup of a utility function), so this is likely
more correct than the original code as well.

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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.

When spanning tree protocol is allowed in bridge settings, forward delay
value is set as well (default is 0 if omitted). Until now, there was no
check for delay value validity. Delay makes sense only as a positive
numerical value.

Note: However, even if you provide positive  numerical value, brctl
utility only uses values from range <2,30>, so the number provided can
be modified (kernel most likely) to fall within this range.

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

The code compares def->forwarders when deciding to return 0 at a
couple of points, then uses "def->nfwds" as a way to index into
the def->forwarders array.  That reference results in Coverity
complaining that def->forwarders being NULL was checked as part
of an arithmetic OR operation where failure could be any one 5
conditions, but that is not checked when entering the loop to
dereference the array.  Changing the comparisons to use nfwds
will clear the warnings
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Need to VIR_FREE the startip/endip we allocated for the error message

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

Replace all three-state (default/yes/no) enums with it:
virDomainBIOSUseserial
virDomainBootMenu
virDomainPMState
virDomainGraphicsSpiceClipboardCopypaste
virDomainGraphicsSpiceAgentFileTransfer
virNetworkDNSForwardPlainNames

Also fix the error message if an IPv6 host with no MAC
is not found.

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

Replace:
if (virBufferError(&buf)) {
    virBufferFreeAndReset(&buf);
    virReportOOMError();
    ...
}

with:
if (virBufferCheckError(&buf) < 0)
    ...

This should not be a functional change (unless some callers
misused the virBuffer APIs - a different error would be reported
then)

It already reports an error if STRDUP fails.

In "src/conf/" there are many enumeration (enum) declarations.
Similar to the recent cleanup to "src/util" directory, it's
better to use a typedef for variable types, function types and
other usages. Other enumeration and folders will be changed to
typedef's in the future. Most of the files changed in this commit
are reltaed to Network (network_conf.* and interface_conf.*) enums.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

When reading configuration files, we were silently ignoring
directory read failures.  While unlikely, we might as well
report them.

* src/conf/domain_conf.c (virDomainObjListLoadAllConfigs): Report
readdir errors.
* src/conf/network_conf.c (virNetworkLoadAllState)
(virNetworkLoadAllConfigs): Likewise.
* src/conf/nwfilter_conf.c (virNWFilterLoadAllConfigs): Likewise.
* src/conf/storage_conf.c (virStoragePoolLoadAllConfigs):
Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

libvirt attempts to determine at startup time which networks are
already active, and set their active flags. Previously it has done
this by assuming that all networks are inactive, then setting the
active flag if the network has a bridge device associated with it and
that bridge device exists. This is not useful for macvtap and hostdev
based networks, since they do not use a bridge device.

Of course the reason that such a check had to be done was that the
presence of a status file in the network "stateDir" couldn't be
trusted as an indicator of whether or not a network was active. This
was due to the network driver mistakenly using
/var/lib/libvirt/network to store the status files, rather than
/var/run/libvirt/network (similar to what is done by every other
libvirt driver that stores status xml for its objects). The difference
is that /var/run is cleared out when the host reboots, so you can be
assured that the state file you are seeing isn't just left over from a
previous boot of the host.

Now that the network driver has been switched to using
/var/run/libvirt/network for status, we can also modify it to assume
that any network with an existing status file is by definition active
- we do this when reading the status file. To fine tune the results,
networkFindActiveConfigs() is changed to networkUpdateAllState(),
and only sets active = 0 if the conditions for particular network
types are *not* met.

The result is that during the first run of libvirtd after the host
boots, there are no status files, so no networks are active. Any time
libvirtd is restarted, any network with a status file will be marked
as active (unless the network uses a bridge device and that device for
some reason doesn't exist).

Experimentation showed that if virNetworkCreateXML() was called for a
network that was already defined, and then the network was
subsequently shutdown, the network would continue to be persistent
after the shutdown (expected/desired), but the original config would
be lost in favor of the transient config sent in with
virNetworkCreateXML() (which would then be the new persistent config)
(obviously unexpected/not desired).

To fix this, virNetworkObjAssignDef() has been changed to

1) properly save/free network->def and network->newDef for all the
various combinations of live/active/persistent, including some
combinations that were previously considered to be an error but didn't
need to be (e.g. setting a "live" config for a network that isn't yet
active but soon will be - that was previously considered an error,
even though in practice it can be very useful).

2) automatically set the persistent flag whenever a new non-live
config is assigned to the network (and clear it when the non-live
config is set to NULL). the libvirt network driver no longer directly
manipulates network->persistent, but instead relies entirely on
virNetworkObjAssignDef() to do the right thing automatically.

After this patch, the following sequence will behave as expected:

virNetworkDefineXML(X)
virNetworkCreateXML(X') (same name but some config different)
virNetworkDestroy(X)

At the end of these calls, the network config will remain as it was
after the initial virNetworkDefine(), whereas previously it would take
on the changes given during virNetworkCreateXML().

Another effect of this tighter coupling between a) setting a !live def
and b) setting/clearing the "persistent" flag, is that future patches
which change the details of network lifecycle management
(e.g. upcoming patches to fix detection of "active" networks when
libvirtd is restarted) will find it much more difficult to break
persistence functionality.

A patch submitted by Steven Malin last week pointed out a problem with
libvirt's DNS SRV record configuration:

  https://www.redhat.com/archives/libvir-list/2014-March/msg00536.html

When searching for that message later, I found another series that had
been posted by Guannan Ren back in 2012 that somehow slipped between
the cracks:

  https://www.redhat.com/archives/libvir-list/2012-July/msg00236.html

That patch was very much out of date, but also pointed out some real
problems.

This patch fixes all the noted problems by refactoring
virNetworkDNSSrvDefParseXML() and networkDnsmasqConfContents(), then
verifies those fixes by added several new records to the test case.

Problems fixed:

* both service and protocol now have an underscore ("_") prepended on
  the commandline, as required by RFC2782.

  <srv service='sip' protocol='udp' domain='example.com'
       target='tests.example.com' port='5060' priority='10'
       weight='150'/>

  before: srv-host=sip.udp.example.com,tests.example.com,5060,10,150
  after:  srv-host=_sip._udp.example.com,tests.example.com,5060,10,150

* if "domain" wasn't specified in the <srv> element, the extra
  trailing "." will no longer be added to the dnsmasq commandline.

  <srv service='sip' protocol='udp' target='tests.example.com'
       port='5060' priority='10' weight='150'/>

  before: srv-host=sip.udp.,tests.example.com,5060,10,150
  after:  srv-host=_sip._udp,tests.example.com,5060,10,150

* when optional attributes aren't specified, the separating comma is
  also now not placed on the dnsmasq commandline. If optional
  attributes in the middle of the line are not specified, they are
  replaced with a default value in the commandline (1 for port, 0 for
  priority and weight).

  <srv service='sip' protocol='udp' target='tests.example.com'
       port='5060'/>

  before: srv-host=sip.udp.,tests.example.com,5060,,
  after:  srv-host=_sip._udp,tests.example.com,5060

  (actually the would have generated an error, because "optional"
  attributes weren't really optional.)

* The allowed characters for both service and protocol are now limited
  to alphanumerics, plus a few special characters that are found in
  existing names in /etc/services and /etc/protocols. (One exception
  is that both of these files contain names with an embedded ".", but
  "."  can't be used in these fields of an SRV record because it is
  used as a field separator and there is no method to escape a "."
  into a field.) (Previously only the strings "tcp" and "udp" were
  allowed for protocol, but this restriction has been removed, since
  RFC2782 specifically says that it isn't limited to those, and that
  anyway it is case insensitive.)

* the "domain" attribute is no longer required in order to recognize
  the port, priority, and weight attributes during parsing. Only
  "target" is required for this.

* if "target" isn't specified, port, priority, and weight are not
  allowed (since they are meaningless - an empty target means "this
  service is *not available* for this domain").

* port, priority, and weight are now truly optional, as the comments
  originally suggested, but which was not actually true.

This was very simple, since the only place that had hardcoded
indentation was a few items in the network status xml.

This fixes a possible double free. In virNetworkAssignDef() if
virBitmapNew() fails, then virNetworkObjFree(network) is called.
However, with network->def pointing to actual @def. So if caller
frees @def again, ...

Moreover, this fixes one possible memory leak too. In
virInterfaceAssignDef() if appending to the list of interfaces
fails, we ought to call virInterfaceObjFree() instead of bare
VIR_FREE().

Although, in order to do that some array size variables needs
to be turned into size_t rather than int.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Basically, the idea is copied from domain code, where tainting
exists for a while. Currently, only one taint reason exists -
VIR_NETWORK_TAINT_HOOK to mark those networks which caused invoking
of hook script.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the next patch I'm going to need the network format function that
takes virBuffer as argument. However, slightly change of name is more
appropriate then: virNetworkDefFormatBuf to match the rest of functions
that format an object to buffer.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the network status XML we may have the <floor/> element with the
'sum' attribute. The attribute represents sum of all 'floor'-s of
computed over each interface connected to the network (this is needed to
guarantee certain bandwidth for certain domain). The sum is therefore a
number. However, if the number was mangled (e.g. by an user's
interference to network status file), we've just ignored it without
refusing to parse such file. This was all due to 'goto error' missing.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The previous patch fixed "forwardPlainNames" so that it really is
doing only what is intended, but left the default to be
"forwardPlainNames='no'". Discussion around the initial version of
that patch led to the decision that the default should instead be
"forwardPlainNames='yes'" (i.e. the original behavior before commit
f3886825). This patch makes that change to the default.

Currently, during XML parsing, when a call to a FromString() function to
get an enum value fails, the error which is reported is either
VIR_ERR_CONFIG_UNSUPPORTED, VIR_ERR_INTERNAL_ERROR or VIR_ERR_XML_ERROR.

This commit makes such conversion failures consistently return
VIR_ERR_CONFIG_UNSUPPORTED.

Most of our code base uses space after comma but not before;
fix the remaining uses before adding a syntax check.

* src/conf/capabilities.c: Consistently use commas.
* src/conf/domain_conf.c: Likewise.
* src/conf/network_conf.c: Likewise.
* src/conf/storage_conf.c: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

'const fooPtr' is the same as 'foo * const' (the pointer won't
change, but it's contents can).  But in general, if an interface
is trying to be const-correct, it should be using 'const foo *'
(the pointer is to data that can't be changed).

Fix up remaining offenders in src/conf, and their fallout.

* src/conf/snapshot_conf.h (virDomainSnapshotAssignDef)
(virDomainSnapshotFindByName): Drop attempt at const.
* src/conf/interface_conf.h (virInterfaceObjIsActive)
(virInterfaceDefFormat): Use intended type.
(virInterfaceFindByMACString, virInterfaceFindByName)
(virInterfaceAssignDef, virInterfaceRemove): Drop attempt at
const.
* src/conf/network_conf.h (virNetworkObjIsActive)
(virNetworkDefFormat, virNetworkDefForwardIf)
(virNetworkDefGetIpByIndex, virNetworkIpDefPrefix)
(virNetworkIpDefNetmask): Use intended type.
(virNetworkFindByUUID, virNetworkFindByName, virNetworkAssignDef)
(virNetworkObjAssignDef, virNetworkRemoveInactive)
(virNetworkBridgeInUse, virNetworkSetBridgeName)
(virNetworkAllocateBridge): Drop attempt at const.
* src/conf/netdev_vlan_conf.h (virNetDevVlanFormat): Make
const-correct.
* src/conf/node_device_conf.h (virNodeDeviceHasCap)
(virNodeDeviceDefFormat): Use intended type.
(virNodeDeviceFindByName, virNodeDeviceFindBySysfsPath)
(virNodeDeviceAssignDef, virNodeDeviceObjRemove)
(virNodeDeviceGetParentHost): Drop attempt at const.
* src/conf/secret_conf.h (virSecretDefFormat): Use intended type.
* src/conf/snapshot_conf.c (virDomainSnapshotAssignDef)
(virDomainSnapshotFindByName): Fix fallout.
* src/conf/interface_conf.c (virInterfaceBridgeDefFormat)
(virInterfaceBondDefFormat, virInterfaceVlanDefFormat)
(virInterfaceProtocolDefFormat, virInterfaceDefDevFormat)
(virInterfaceDefFormat, virInterfaceFindByMACString)
(virInterfaceFindByName, virInterfaceAssignDef)
(virInterfaceRemove): Likewise.
* src/conf/network_conf.c
(VIR_ENUM_IMPL, virNetworkFindByName, virNetworkObjAssignDef)
(virNetworkAssignDef, virNetworkRemoveInactive)
(virNetworkDefGetIpByIndex, virNetworkIpDefPrefix)
(virNetworkIpDefNetmask, virNetworkDHCPHostDefParseXML)
(virNetworkIpDefFormat, virNetworkRouteDefFormat)
(virPortGroupDefFormat, virNetworkForwardNatDefFormat)
(virNetworkDefFormatInternal, virNetworkBridgeInUse)
(virNetworkAllocateBridge, virNetworkSetBridgeName)
(virNetworkDNSDefFormat, virNetworkDefFormat): Likewise.
* src/conf/netdev_vlan_conf.c (virNetDevVlanFormat): Likewise.
* src/conf/node_device_conf.c (virNodeDeviceHasCap)
(virNodeDeviceFindBySysfsPath, virNodeDeviceFindByName)
(virNodeDeviceAssignDef, virNodeDeviceObjRemove)
(virNodeDeviceDefFormat, virNodeDeviceGetParentHost): Likewise.
* src/conf/secret_conf.c (virSecretDefFormatUsage)
(virSecretDefFormat): Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

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: NDiego Woitasen <diego.woitasen@vhgroup.net>
Signed-off-by: NEric Blake <eblake@redhat.com>

Add checks for updating sections of network definition via
virNetworkDefUpdateSection.

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

This matches the style we use elsewhere and allows
nat-network-dns-srv-record{,-minimal}.xml to be tested in
network XML -> XML test.

Re-arrange the code so that the returned bitmap is always initialized to
NULL even on early failures and return an error message as some callers
are already expecting it. Fix up the rest not to shadow the error.

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.