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: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The actual network def was updated to save the bridge name back
in 1.2.11:

  commit a3609121
  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: NLaine Stump <laine@laine.org>
Signed-off-by: NDaniel 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: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NDaniel 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: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This helps in a scenarios where vCPUs run with a priority that is so high they
might starve the emulator thread.  And it also fits with the rest of the
settings.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Just one missing occurrence of iothreadsched fixed plus some rewording for this
to make more sense for the readers.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This will be used later when we want to format emulator scheduler parameters
which don't apply for multiple threads.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This will become useful later when parsing emulatorsched parameters which don't
need the rest of the current function.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Qemu commit 767abe7 ("chardev: forbid 'wait' option with client
sockets") effectively deprecates usage of "wait" with client sockets
starting with qemu 4.0, and earlier versions ignored the value.

Cc: Daniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NAdrian Brzezinski <redhat@adrb.pl>

Failed new gnutls context allocations in virNetTLSContextNew function
results in double free and segfault. Occasional memory leaks may also
occur.
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NAdrian Brzezinski <redhat@adrb.pl>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

We're setting seclabels on unix sockets but never restoring them.
Surprisingly, we are doing so in SELinux driver.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NPino Toscano <ptoscano@redhat.com>

When writing the VMX file from the domain XML, write the firmware key
according to the firmware autoselection.  Though, at the moment only
'efi' is supported.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NPino Toscano <ptoscano@redhat.com>

Convert the firmware key to a type of autoselected firmware.

Only the 'efi' firmware is allowed for now, in case the key is present.
It seems VMware (at least ESXi) does not write the key in VMX files when
setting BIOS as firmware.
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Signed-off-by: NPino Toscano <ptoscano@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: NLaine Stump <laine@laine.org>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

When virDBusMessageRead() and virDBusMessageDecode were first added in
commit 834c9c94, they were identical except that virDBusMessageRead()
would unref the message after decoding it.

This difference was eliminated later in commit dc7f3ffc after it
became apparent that unref-ing the message so soon was never the right
thing to do. The two identical functions remained though, with the
tests and virDBus library itself calling the Decode variant, and all
other users calling the Read variant.

This patch eliminates the duplication, switching all users to
virDBusMessageDecode (and moving the nice API documentation comment
from the Read function up to the Decode function).
Signed-off-by: NLaine Stump <laine@laine.org>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Support for compiling this version was dropped in an earlier commit.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Support for compiling this version was dropped in an earlier commit.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Support for compiling this version was dropped in an earlier commit.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Support for compiling this version was dropped in an earlier commit.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Support for compiling this version was dropped in an earlier commit.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Support for compiling this version was dropped in an earlier commit.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Support for all the 4.x releases was ended by VirtualBox maintainers in
Dec 2015. Even the "newest" 4.3.40 of those is only supported on old
versions of Linux (Ubuntu <= 13.03, RHEL <= 6, SLES <= 11), which are all
discontinued hosts from libvirt's POV.

We can thus reasonably drop all 4.x support from the libvirt VirtualBox
driver.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Since:

  commit 9f4e35dc
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Mon Mar 18 17:31:21 2019 +0000

    network: improve error report when firewall chain creation fails

We cache an error when failing to create the top level firewall chains.
This commit failed to account for fact that we may invoke
networkPreReloadFirewallRules() many times while libvirtd is running.
For example when firewalld is restarted.

When this happens the original failure may no longer occurr and we'll
successfully create our top level chains. We failed to clear the cached
error resulting in us failing to start virtual networks.
Reviewed-by: NLaine Stump <laine@laine.org>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The table included in the sample output for 'list --title' is
unnecessarily wide, which causes man to complain:

  warning [p 8, 0.5i]: can't break line

Make the table narrower.

Spotted by Lintian (manpage-has-errors-from-man tag).
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>

Apparently "allow(s) to frobnicate" is not correct English, and
either "allow(s) one to frobnicate" or "allow(s) frobnicating"
should be used instead.

Spotted by Lintian (spelling-error-in-{binary,manpage} tags).
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>

Spotted by Lintian (manpage-has-bad-whatis-entry tag).
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

We need commit 6280c94f306d in order to fix our generated
man pages.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

My earlier commit be46f613 was incomplete. It removed caching of
microcode version in the CPU driver, which means the capabilities XML
will see the correct microcode version. But it is also cached in the
QEMU capabilities cache where it is used to detect whether we need to
reprobe QEMU. By missing the second place, the original commit
be46f613 made the situation even worse since libvirt would report
correct microcode version while still using the old host CPU model
(visible in domain capabilities XML).
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Support for kqemu was dropped in libvirt by commit 8e91a400 and even
back then we never set these capabilities when doing QMP probing.

Since no QEMU we aim to support has these, drop them completely.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

This is a zero-cost workaround for a bug in GCC 8.3.0 which causes the
compilation to fail, because the compiler thinks that the value might be used
uninitialized even though it clearly cannot be.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Though it used to be called "Mac OS X" and "OS X" in the past,
it was never "MacOS X" nor "OS-X", and it's just "macOS" now.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

We have occasionally failed to document certain categories
of changes in the release notes, yet still left the
corresponding sections in the file even though they were
completely empty.
Signed-off-by: NAndrea Bolognani <abologna@redhat.com>

In e17d1038 these functions were mistakenly moved into an #ifdef
block, but remained used outside of it leaving the build broken
for platforms where #ifdef evaluated to false.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Model specific registers are a thing only on x86. Also, the
/dev/cpu/0/msr path exists only on Linux and the fallback
mechanism (asking KVM) exists on Linux and FreeBSD only.

Therefore, move the function within #ifdef that checks all
aforementioned constraints and provide a dummy stub for all
other cases.

This fixes the build on my arm box, mingw-* builds, etc.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>