There were a bunch of commentary blocks that were literally useless in
terms of describing what the code following them does, since most of
them were documenting "the obvious" or it just wouldn't help at all.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

Similarly to previous patch, for some types of interface domain
and host are on the same side of RX/TX barrier. In that case, we
need to set up the QoS differently. Well, swapped.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Back in the day when I was implementing QoS for networks there
were no self inflating virBitmaps. Only the static ones.
Therefore, I had to allocate the whole 8KB of memory in order to
keep track of used/unused class IDs. This is rather wasteful
because nobody is ever gonna use that much classes (kernel
overhead would drastically lower the bandwidth). Anyway, now that
we have self inflating bitmaps we can start small and allocate
more if there's need for it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

To be consistent with the API definition, use the @maxnames instead
of @nnames when describing/comparing against the maximum names to
be provided for the *ConnectList[Defined]Networks APIs.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation to privatize the virNetworkObj - create an accessor function
to get the current @persistent value.  Also change the value to a bool rather
than an unsigned int (since that's how it's generated anyway).
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In order to privatize the virNetworkObj create accessors in virnetworkobj
in order to handle the get/set of the active value.

Also rather than an unsigned int, convert it to a boolean to match other
drivers representation and the reality of what it is.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for privatizing the virNetworkObj structure, create
accessors for the obj->autostart.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for making the object private, create a couple of API's
to get the obj->def & obj->newDef and set the obj->def.

While altering networkxml2conftest.c to use the virNetworkObjSetDef
API, fix the name of the variable from @dev to @def
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for making the object private, create a couple of API's
to get/set the obj->floor_sum.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for privatizing virNetworkObj, create accessor function to
fetch the @classIdMap.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Change the variable name to be a bit more descriptive and less confusing
when used with the data.network.actual->class_id.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for making the object private, create/use a couple of API's
to get/set the obj->dnsmasqPid and obj->radvdPid.

NB: Since the pid's can sometimes changed based on intervening functions,
be sure to always fetch the latest value.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

In preparation for having a private virNetworkObj - let's create/move some
API's that handle the obj->macmap. The API's will be renamed to have a
virNetworkObj prefix to follow conventions and the arguments slightly
modified to accept what's necessary to complete their task.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Move networkMacMgrFileName into src/util/virmacmap.c and rename to
virMacMapFileName. We're about to move some more MacMgr processing
files into virnetworkobj and it doesn't make sense to have this helper
in the driver or in virnetworkobj.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Use @obj for a virNetworkObjPtr

Use @net for a virNetworkPtr
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Modify code to have two spaces between functions, follow function more
recent function formatting w/r/t args per line and function return type
and name on separate lines.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If a remote call fails during event registration (more than likely from
a network failure or remote libvirtd restart timed just right), then when
calling the virObjectEventStateDeregisterID we don't want to call the
registered @freecb function because that breaks our contract that we
would only call it after succesfully returning.  If the @freecb routine
were called, it could result in a double free from properly coded
applications that free their opaque data on failure to register, as seen
in the following details:

    Program terminated with signal 6, Aborted.
    #0  0x00007fc45cba15d7 in raise
    #1  0x00007fc45cba2cc8 in abort
    #2  0x00007fc45cbe12f7 in __libc_message
    #3  0x00007fc45cbe86d3 in _int_free
    #4  0x00007fc45d8d292c in PyDict_Fini
    #5  0x00007fc45d94f46a in Py_Finalize
    #6  0x00007fc45d960735 in Py_Main
    #7  0x00007fc45cb8daf5 in __libc_start_main
    #8  0x0000000000400721 in _start

The double dereference of 'pyobj_cbData' is triggered in the following way:

    (1) libvirt_virConnectDomainEventRegisterAny is invoked.
    (2) the event is successfully added to the event callback list
        (virDomainEventStateRegisterClient in
        remoteConnectDomainEventRegisterAny returns 1 which means ok).
    (3) when function remoteConnectDomainEventRegisterAny is hit,
        network connection disconnected coincidently (or libvirtd is
        restarted) in the context of function 'call' then the connection
        is lost and the function 'call' failed, the branch
        virObjectEventStateDeregisterID is therefore taken.
    (4) 'pyobj_conn' is dereferenced the 1st time in
        libvirt_virConnectDomainEventFreeFunc.
    (5) 'pyobj_cbData' (refered to pyobj_conn) is dereferenced the
         2nd time in libvirt_virConnectDomainEventRegisterAny.
    (6) the double free error is triggered.

Resolve this by adding a @doFreeCb boolean in order to avoid calling the
freeCb in virObjectEventStateDeregisterID for any remote call failure in
a remoteConnect*EventRegister* API. For remoteConnect*EventDeregister* calls,
the passed value would be true indicating they should run the freecb if it
exists; whereas, it's false for the remote call failure path.

Patch based on the investigation and initial patch posted by
fangying <fangying1@huawei.com>.

If the network isn't active during networkNotifyActualDevice(), we
would log an error message stating that the bridge device didn't
exist. This patch adds a check to see if the network is active, making
the logs more useful in the case that it isn't.

Partially resolves: https://bugzilla.redhat.com/1442700

Nothing that could happen during networkNotifyActualDevice() could
justify unceremoniously killing the qemu process, but that's what we
were doing.

In particular, new code added in commit 85bcc022 (first appearred in
libvirt-3.2.0) attempts to reattach tap devices to their assigned
bridge devices when libvirtd restarts (to make it easier to recover
from a restart of a libvirt network). But if the network has been
stopped and *not* restarted, the bridge device won't exist and
networkNotifyActualDevice() will fail.

This patch changes networkNotifyActualDevice() and
qemuProcessNotifyNets() to return void, so that qemuProcessReconnect()
will soldier on regardless of what happens (any errors will still be
logged though).

Partially resolves: https://bugzilla.redhat.com/1442700

This patch makes use of the virNetDevSetCoalesce() function to make
appropriate settings effective for devices that support them.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1414627Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Use "virNetworkObj" as a prefix for any external API in virnetworkobj.

Also a couple of functions were local to virnetworkobj.c, so remove their
external defs in virnetworkobj.h.

Rename the API to be a better description of what it does. Besides, a
subsequent patch will rename virNetworkAssignDef to virNetworkObjAssignDef
so rather than make that patch confusing we'll take the intermittent step
in this patch.

Move all the virNetworkObj related API/data structures into their own
modules virnetworkobj.{c,h} from the network_conf.{c,h}

Purely code motion at this point plus adjustments to cleanly build

The virMacMap module is there for dumping [domain, <list of is
MACs>] pairs into a file so that libvirt_guest NSS module can use
it. Whenever a interface is allocated from network (e.g. on
domain<F2> startup or NIC hotplug), network is notified and so is
virMacMap module subsequently. The module update functions
networkMacMgrAdd() and networkMacMgrDel() gracefully handle the
case when there's no module. The problem is, the module is
created if and only if network is freshly started, or if the
daemon restarts and network previously had the module.

This is not very user friendly - if users want to use the NSS
module they need to destroy their network and bring it up again
(and subsequently all the domains using it).

One disadvantage of this approach implemented here is that one
may get just partial results: any already running network does
not record mac maps, thus only newly plugged domains will be
stored in the module. The network restart scenario is not touched
by this of course. But one can argue that older libvirts had
never recorded the mac maps anyway.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Imagine the following scenario:

1) virsh net-start default
2) virsh start myFavouriteDomain
3) virsh net-destroy default
4) virsh destroy myFavouriteDomain

(assuming myFavouriteDomain has an interface from default
network)

Regardless of how unlikely this scenario looks like, we should
not crash. The problem is, on net-destroy in
networkShutdownNetworkVirtual() the virMacMap module is unrefed,
but the stale pointer is kept around. Thus when the domain
destroy procedure comes in, networkReleaseActualDevice() and
subsequently networkMacMgrDel() is called. This function sees the
stale pointer and starts calling the virMacMap module APIs which
work over freed memory.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This adds a few validations to the devices listed for a hostdev network:

* devices must be listed by PCI address, not by netdev name

* listing a device by PCI address is valid only for hostdev networks, not
  for other types of network (e.g. macvtap passthrough).

* each device in a hostdev pool must be an SR-IOV VF

Resolves: https://bugzilla.redhat.com/1004676

commit 00d28a78 added a check to see if there were any IPv6 routes
added by RA (Router Advertisement) via an interface that had accept_ra
set to something other than "2". The check was being done
unconditionally, but it's only relevant if IPv6 forwarding is going to
be turned on, and that will only happen if the network has an IPv6
address.

The prototype requires a NONNULL argument and the only caller passes in
a non-null parameter. Besides the "else if" condition would deref it anyway.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If a network is destroyed and restarted, or its bridge is changed, any
tap devices that had previously been connected to the bridge will no
longer be connected. As a first step in automating a reconnection of
all tap devices when this happens, this patch modifies
networkNotifyActualDevice() (which is called once for every
<interface> of every active domain whenever libvirtd is restarted) to
reconnect any tap devices that it finds disconnected.

With this patch in place, you will need to restart libvirtd to
reconnect all the taps to their proper bridges. A future patch will
add a callback that hypervisor drivers can register with the network
driver to that the network driver can trigger this behavior
automatically whenever a network is started.

When enabling IPv6 on all interfaces, we may get the host Router
Advertisement routes discarded. To avoid this, the user needs to set
accept_ra to 2 for the interfaces with such routes.

See https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
on this topic.

To avoid user mistakenly losing routes on their hosts, check
accept_ra values before enabling IPv6 forwarding. If a RA route is
detected, but neither the corresponding device nor global accept_ra
is set to 2, the network will fail to start.

Replace a few occurences of /proc/sys by the corresponding macro
defined a few lines after: SYSCTL_PATH

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.

In GCC 7 there is a new warning triggered when a switch
case has a conditional statement (eg if ... else...) and
some of the code paths fallthrough to the next switch
statement. e.g.

conf/domain_conf.c: In function 'virDomainChrEquals':
conf/domain_conf.c:14926:12: error: this statement may fall through [-Werror=implicit-fallthrough=]
         if (src->targetTypeAttr != tgt->targetTypeAttr)
            ^
conf/domain_conf.c:14928:5: note: here
     case VIR_DOMAIN_CHR_DEVICE_TYPE_CONSOLE:
     ^~~~
conf/domain_conf.c: In function 'virDomainChrDefFormat':
conf/domain_conf.c:22143:12: error: this statement may fall through [-Werror=implicit-fallthrough=]
         if (def->targetTypeAttr) {
            ^
conf/domain_conf.c:22151:5: note: here
     default:
     ^~~~~~~

GCC introduced a __attribute__((fallthrough)) to let you
indicate that this is intentionale behaviour rather than
a bug.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This resolves: https://bugzilla.redhat.com/1224348

virNetDevTapCreateInBridgePort() has always set the new tap device to
the current MTU of the bridge it's being attached to. There is one
case where we will want to set the new tap device to a different
(usually larger) MTU - if that's done with the very first device added
to the bridge, the bridge's MTU will be set to the device's MTU. This
patch allows for that possibility by adding "int mtu" to the arg list
for virNetDevTapCreateInBridgePort(), but all callers are sending -1,
so it doesn't yet have any effect.

Since the requested MTU isn't necessarily what is used in the end (for
example, if there is no MTU requested, the tap device will be set to
the current MTU of the bridge), and the hypervisor may want to know
the actual MTU used, we also return the actual MTU to the caller (if
actualMTU is non-NULL).

After 478ddedc a bug is fixed where we wrongly presumed loopack
device name on non-Linux systems. It's lo0. However, the fix is
not reflected in the tests which are failing now.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Similarly to localOnly DNS domain, localPtr attribute can be used to
tell the DNS server not to forward reverse lookups for unknown IPs which
belong to the virtual network.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Now that we have a module that's able to track
<domain, mac addres list> pairs, hook it up into
our network driver.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In dd7bfb2c I've removed locking of the network driver upon
it's allocation. However, I forgot to remove one location of the
driver unlock.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

 On BSD family OSes (Free/Net/Open/DragonFlyBSD, Mac OS) and
 Solaris loopback interface is called 'lo0' instead of just 'lo'.