The sys/sysctl.h header is only needed on BSD platforms to get
the sysctlbyname() function declaration. On Linux we talk to
procfs instead to change sysctls.
Unfortunately a legacy sys/sysctl.h header does exist on Linux
and including it has recently started triggering a deprecation
warning from glibc.
Protect its inclusion with a HAVE_SYSCTLBYNAME check instead
so that it only gets used on platforms where we need that
function declaration.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Change the domain conf so invoke the new network port public APIs instead
of the network callbacks.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This initial implementation just wires up the APIs and does tracking of
the port XML definitions. It is not yet integrated into the resource
allocation logic.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Separate network port bandwidth update code from the domain driver
network callback implementation.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Separate network port deletion code from the domain driver network
callback implementation.
Reivewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Separate network port notification code from the domain driver network
callback implementation.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Separate network port allocation code from the domain driver network
callback implementation.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The current qemu driver code for changing bandwidth on a NIC first asks
the network driver if the change is supported, then changes the
bandwidth on the VIF, and then tells the network driver to update the
bandwidth on the bridge.
This is potentially racing if a parallel API call causes the network
driver to allocate bandwidth on the bridge between the check and the
update phases.
Change the code to just try to apply the network bridge update
immediately and rollback at the end if something failed.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
When (un)plugging an interface into a network, the 'plugged'
and 'unplugged' operations are invoked in the hook script.
The data provided to the script contains the network XML, the
domain XML and the domain interface XML. When we strictly split the
drivers up this will no longer be possible and thus breakage is
unavoidable. The hook scripts are not considered to be covered by the
API guarantee so this is OK.
To avoid existing scripts taking the wrong action, the existing
operations are changed to 'port-created' and 'port-deleted'
instead. These will receive the network XML and the network port
XML.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Convert the virDomainNetDef object into a virNetworkPortDef object
at the start of networkReleaseActualDevice. This largely decouples
the method impl from the domain object type.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Convert the virDomainNetDef object into a virNetworkPortDef object
at the start of networkNotifyActualDevice. This largely decouples
the method impl from the domain object type.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Convert the virDomainNetDef object into a virNetworkPortDef object
at the start of networkAllocateActualDevice. This largely decouples
the method impl from the domain object type.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Stop passing a virDomainNetDefPtr parameter to networkLogAllocation,
instead just pass in the MAC address. The actual device type is also not
required, since virNetworkForwardIfDefPtr has a type field that can be
used instead.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Creating firewall rules for the virtual networks causes the kernel to
load the conntrack module. This imposes a significant performance
penalty on Linux network traffic. Thus we want to only take that hit if
we actually have virtual networks running.
We need to create global firewall rules during startup in order to
"upgrade" rules for any running networks created by older libvirt.
If no running networks are present though, we can safely delay setup
until the time we actually start a network.
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In attempt to getting rid of errN labels let's start with the
most upper one and rename it to 'error'.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
This caused the live XML to report the 'bridge' type instead of the
'network' type, which is a behavioural regression.
It also breaks 'virsh domif-setlink', 'virsh update-device' and
'virsh domiftune'
This reverts commit 518026e159.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
If there's an error when setting up QoS on a bridge the control
jumps over to 'err5' label. Here, the virNetDevBandwidthClear()
is called to clear out any partially set QoS. This function can
also report an error which would overwrite the actual error that
caused us jumping here. Use virErrorPreserveLast() to preserve
the original error.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Replaced usage of virSaveLastError and virSetError/virFreeError with
virErrorPreserveLast and virErrorRestore respectively.
Signed-off-by: Syed Humaid <syedhumaidbinharoon@gmail.com>
During initial NIC setup the hypervisor drivers are responsible for
attaching the TAP device to the bridge device. Any fixup after libvirtd
restarts should thus also be their responsibility.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Ports allocated on virtual networks with type=nat|route|open all get
given an actual type of 'network'.
Only ports in networks with type=bridge use an actual type of 'bridge'.
This distinction makes little sense since the virtualization drivers
will treat both actual types in exactly the same way, as they're all
just bridge devices a VM needs to be connected to.
This doesn't affect user visible XML since the "actual" device XML
is internal only, but we need code to convert the data upgrades.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Reword error messages to make it clear that the combined floor settings
of all NICs are exceeding the network inbound peak/average
settings. Including the actual values being checked helps to diagnose
what is actually wrong.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In extreme cases libvirt can get mixed up about what VMs are running and
attached to a network leading to the cached floor sum value being
outdated. When this happens the only option is to destroy the network
and then restart libvirtd. If we set floor sum back to zero when
starting the network, we avoid the need for a libvirtd restart at least.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The networkPlugBandwidth & networkUnplugBandwidth methods currently take
a virDomainNetDefPtr. To remove the dependency on the domain config
struct, pass individual parameters instead.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
All but one of the network types supports port profiles. Rather than
duplicating the code to merge profiles 3 times, do it once and then
later report an error if used from the wrong place.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Switch over to use the new API for re-attaching the bridge device
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In the case of a network with forward=bridge, which has a bridge device
listed, we are capable of setting bandwidth limits but fail to call the
function to register them.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
hostdevs have a link back to the original network device. This is fairly
generic accepting any type of device, however, we don't intend to make
use of this approach in future. It can thus be specialized to network
devices.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The actual network def was updated to save the bridge name back
in 1.2.11:
commit a360912179
Author: Laine Stump <laine@laine.org>
Date: Fri Nov 21 12:20:37 2014 -0500
network: save bridge name in ActualNetDef when actualType==network too
The chance that someone is running libvirt < 1.2.11 and wants
todo a live upgrade to 5.3.0 without a host reboot is essentially
zero. We can thus reasonably drop the back compat code now.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The APIs for allocating/notifying/removing network ports just take
an internal domain interface struct right now. As a step towards
turning these into public facing APIs, add a virNetworkPtr argument
to all of them.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The port allocation APIs are currently called unconditionally for all
types of NIC, but (mostly) only do anything for NICs with type=network.
The exception is the port allocate API which does some validation even
for NICs with type!=network. Relying on this validation is flawed,
however, since the network driver may not even be installed. IOW virt
drivers must not delegate validation to the network driver for NICs
with type != network.
This change allows us to report errors when the virtual network driver
is not registered.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The network driver used to reload the firewall rules whenever a dbus
NameOwnerChanged message for org.fedoraproject.FirewallD1 was
received. Presumably at some point in the past this was successful at
reloading our rules after a firewalld restart. Recently though I
noticed that once firewalld was restarted, libvirt's logs would get this
message:
The name org.fedoraproject.FirewallD1 was not provided by any .service files
After this point, no networks could be started until libvirtd itself
was restarted.
The problem is that the NameOwnerChanged message is sent twice during
a firewalld restart - once when the old firewalld is stopped, and
again when the new firewalld is started. If we try to reload at the
point the old firewalld is stopped, none of the firewalld dbus calls
will succeed.
The solution is to check the new_owner field of the message - we
should reload our firewall rules only if new_owner is non-empty (it is
set to "" when firewalld is stopped, and some sort of epoch number
when it is again started).
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
The unprivileged libvirtd does not have permission to create firewall
rules, or bridge devices, or do anything to the host network in
general. Historically we still activate the network driver though and
let the network start API call fail.
The startup code path which reloads firewall rules on active networks
would thus effectively be a no-op when unprivileged as it is impossible
for there to be any active networks
With the change to use a global set of firewall chains, however, we now
have code that is run unconditionally.
Ideally we would not register the network driver at all when
unprivileged, but the entanglement with the virt drivers currently makes
that impractical. As a temporary hack, we just make the firewall reload
into a no-op.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
During startup we create some top level chains in which all
virtual network firewall rules will be placed. The upfront
creation is done to avoid slowing down creation of individual
virtual networks by checking for chain existance every time.
There are some factors which can cause this upfront creation
to fail and while a message will get into the libvirtd log
this won't be seen by users who later try to start a virtual
network. Instead they'll just get a message saying that the
libvirt top level chain does not exist. This message is
accurate, but unhelpful for solving the root cause.
This patch thus saves any error during daemon startup and
reports it when trying to create a virtual network later.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
According to the official documentation for autoconf[1], the
correct names for these variables are abs_top_{src,build}dir
rather than abs_top{src,build}dir; in fact, we're already
using the correct names in various places, so let's just make
everything nice and consistent.
[1] https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/Preset-Output-Variables.html
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1685151
This reverts commit cefb97fb81.
The stateAutoStart callback will be removed in the next commit.
Therefore move autostarting of domains, networks and storage
pools back into stateInitialize callbacks.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
dnsmasq documentation says that the *IPv4* prefix/network
address/broadcast address sent to dhcp clients will be automatically
determined by dnsmasq by looking at the interface it's listening on,
so the original libvirt code did not add a netmask to the dnsmasq
commandline (or later, the dnsmasq conf file).
For *IPv6* however, dnsmasq apparently cannot automatically determine
the prefix (functionally the same as a netmask), and it must be
explicitly provided in the conf file (as a part of the dhcp-range
option). So many years after IPv4 DHCP support had been added, when
IPv6 dhcp support was added the prefix was included at the end of the
dhcp-range setting, but only for IPv6.
A user had reported a bug on a host where one of the interfaces was a
superset of the libvirt network where dhcp is needed (e.g., the host's
ethernet is 10.0.0.20/8, and the libvirt network is 10.10.0.1/24). For
some reason dnsmasq was supplying the netmask for the /8 network to
clients requesting an address on the /24 interface.
This seems like a bug in dnsmasq, but even if/when it gets fixed
there, it looks like there is no harm in just always adding the
netmask to all IPv4 dhcp-range options similar to how prefix is added
to all IPv6 dhcp-range options.
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: John Ferlan <jferlan@redhat.com>
Support for firewalld is a feature that can be selectively enabled or
disabled (using --with-firewalld/--without-firewalld), not merely
something that must be accounted for in the code if it is present with
no exceptions. It is more consistent with other usage in libvirt to
use WITH_FIREWALLD rather than HAVE_FIREWALLD.
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This adds an additional directive to the dnsmasq configuration file that
notifies clients via dhcp about the link's MTU. Guests can then choose
adjust their link accordingly.
Signed-off-by: Casey Callendrello <cdc@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Allow the platform driver impls to run logic before and after the
firewall reload process.
Reviewed-by: Laine Stump <laine@laine.org>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
networkMigrateStateFiles was added nearly 5 years ago when the network
state directory was moved from /var/lib/libvirt to /var/run/libvirt
just prior to libvirt-1.2.4). It was only required to maintain proper
state information for networks that were active during an upgrade that
didn't involve rebooting the host. At this point the likelyhood of
anyone upgrading their libvirt from pre-1.2.4 directly to 5.0.0 or
later *without rebooting the host* is probably so close to 0 that no
properly informed bookie would take *any* odds on it happening, so it
seems appropriate to remove this pointless code.
Signed-off-by: Laine Stump <laine@laine.org>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
In many files there are header comments that contain an Author:
statement, supposedly reflecting who originally wrote the code.
In a large collaborative project like libvirt, any non-trivial
file will have been modified by a large number of different
contributors. IOW, the Author: comments are quickly out of date,
omitting people who have made significant contribitions.
In some places Author: lines have been added despite the person
merely being responsible for creating the file by moving existing
code out of another file. IOW, the Author: lines give an incorrect
record of authorship.
With this all in mind, the comments are useless as a means to identify
who to talk to about code in a particular file. Contributors will always
be better off using 'git log' and 'git blame' if they need to find the
author of a particular bit of code.
This commit thus deletes all Author: comments from the source and adds
a rule to prevent them reappearing.
The Copyright headers are similarly misleading and inaccurate, however,
we cannot delete these as they have legal meaning, despite being largely
inaccurate. In addition only the copyright holder is permitted to change
their respective copyright statement.
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
All of the ones being removed are pulled in by internal.h. The only
exception is sanlock which expects the application to include <stdint.h>
before sanlock's headers, because sanlock prototypes use fixed width
int, but they don't include stdint.h themselves, so we have to leave
that one in place.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
It doesn't really make sense for us to have stdlib.h and string.h but
not stdio.h in the internal.h header.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
When starting network a macmap object is created (which stores
MAC -> domain name mappings). However, if something goes wrong
(e.g. virNetDevIPCheckIPv6Forwarding() fails) then the object is
leaked.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
