Since the introduction of the virNetworkPort object, the network driver
has a persistent record of ports that have been created against the
networks. Thus the hypervisor drivers no longer communicate to the
network driver during libvirtd restart.

This change, however, meant that the connection usage counts were
no longer re-initialized during a libvirtd restart. To deal with this we
must iterate over all virNetworkPortDefPtr objects we have and invoke
the notify callback to record the connection usage count.
Reviewed-by: NLaine Stump <laine@laine.org>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The virTestOOMActive method was deleted in

  commit 2c52ecd9
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Thu Aug 29 13:04:07 2019 +0100

    util: purge all code for testing OOM handling
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

This fixes bug in

  commit bbe2aa62
  Author: Daniel P. Berrangé <berrange@redhat.com>
  Date:   Thu Jul 26 17:24:30 2018 +0100

    conf: simplify link from hostdev back to network device

    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>

which mistakenly deleted the assignment to the 'net' variable,
which meant we never invoked the network driver release callback
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The functions are left returning an "int" to avoid an immediate
big-bang cleanup. They'll simply never return anything other
than 0.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Only a few of the _QUIET allocation macros are used. Since we're no
longer reporting OOM as errors, we want to eliminate all the _QUIET
variants. This starts with the easy, unused, cases.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The functions are left returning an "int" to avoid an immediate
big-bang cleanup. They'll simply never return anything other
than 0, except for virInsertN which can still return an error
if the requested insertion index is out of range. Interestingly
in that case, the _QUIET function would none the less report
an error.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The OOM handling requires special build time options which we never
enable in our CI. Even once enabled the tests are incredibly slow and
typically require manual inspection of the results to weed out false
positives.

Since there was previous agreement to switch to abort on OOM in libvirt
code, there's no point continuing to keep the unused OOM testing code.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The virNetworkPortDef config stores the 'managed' attribute
as the virTristateBool type.

The virDomainDef config stores the 'managed' attribute as
the bool type.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

If the hypervisor driver has not yet created the network port, the
portid field will be "00000000-0000-0000-0000-000000000000".

If a failure occurs during early VM startup, the hypervisor driver may
none the less try to release the network port, resulting in an
undesirable warning:

2019-09-12 13:17:42.349+0000: 16544: error :
virNetworkObjLookupPort:1679 : network port not found: Network port with
UUID 00000000-0000-0000-0000-000000000000 does not exist

By checking if the portid UUID is valid, we can avoid polluting the logs
in this way.
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The pci_dev->physical_function is rewritten in
virPCIGetPhysicalFunction() to a newly allocated pointer.
Therefore, we must free the old one to avoid memleak.
Signed-off-by: NJiang kun <jiang.kun2@zte.com.cn>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The LIBVIRT_RESULT function takes two or three arguments. The
first one is the name of the result (aka CHECK_NAME). It is
printed before the colon character. The rest of the arguments is
printed after the character. To produce colourized output a
couple of changes needs to be made.

Firstly, we need to print the CHECK_NAME using "echo -n" so that
the new line is not appended at the end of the message. To
achieve this, AS_MESSAGE_N function is introduced. It's a
verbatim copy of AS_MESSAGE (which is just another alias to
AC_MSG_NOTICE) except it doesn't put '\n' at the EOL.

The alias is defined at /usr/share/autoconf-*/autoconf/general.m4
and the AS_MESSAGE is then defined at
/usr/share/autoconf-2.69/m4sugar/m4sh.m4.

Secondly, the rest of the arguments are printed colourized and to
achieve that and also keep printing them into the log file the
_AS_ECHO and COLORIZE_RESULT functions need to be called.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

If we're running from a TTY we can put some colors around 'yes',
'no' and other messages.

Shamelessly copied from Ruby source code and modified a bit to
comply with syntax-check.

https://github.com/ruby/ruby/commit/e4879592873abd4cd8aeed56f4cbaa360a3d3736Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

Now that we have qemuFirmwareGetSupported() so that it also
returns a list of FW image paths, we can use it to report them in
domain capabilities instead of the old time default list.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

There is one hack hidden here, but since this is in a test, it's
okay. In order to get a list of expected firmwares in
virFirmwarePtr form I'm using virFirmwareParseList(). But
usually, in real life scenario, this function is used only to
parse a list of UEFI images which have NVRAM split out. In other
words, this function expects ${FW}:${NVRAM} pairs. But in this
test, we also want to allow just a single path: ${FW} because
some reported firmwares are just a BIOS image really. To avoid
writing some parser function, let's just pass "NULL" as ${NVRAM}
and fix the result later.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

The qemuFirmwareGetSupported() function is called from qemu
driver to generate domain capabilities XML based on FW descriptor
files. However, the function currently reports only some features
from domcapabilities XML and not actual FW image paths. The paths
reported in the domcapabilities XML are still from pre-FW
descriptor era and therefore the XML might be a bit confusing.
For instance, it may say that secure boot is supported but
secboot enabled FW is not in the listed FW image paths.

To resolve this problem, change qemuFirmwareGetSupported() so
that it also returns a list of FW images (we have the list
anyway). Luckily, we already have a structure to represent a FW
image - virFirmware.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

This function is going to get some new arguments. Document the
current ones for clarity.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

This function frees a _virFirmware struct. So far, it doesn't
need to be called from outside of the module, but this will
change shortly. In the light of recent VIR_DEFINE_AUTOPTR_FUNC()
additions, do the same to virFirmwareFree().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

The times, when we had small CRTs are long gone. Now, in the era
of wide screens we can be more generous when it comes to aligning
the output of configure. The longest string before the colon is
'wireshark_dissector' which counts 19 characters.  Therefore,
align the strings at 20.

At the same time, drop the useless result alignment. It behaves
oddly - it puts a space at the end of each "no" because of the
%-3s format we use.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

One of the advantages is that LIBVIRT_RESULT aligns the resulting
message for us.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>

Rewrite some parts for clarity, elaborate the meaning of some of the XML
attributes.  And where necessary, distinguish that we're dealing with
two different XML documents here:

  - the domainCapabilities XML, to detect the host "hypervisor"
    (QEMU/KVM) capabilities, and what libvirt knows about them.

  - the guest XML definition, i.e. what features a guest can use, based
    on the capabilities (of QEMU and libvirt and the host) reported in
    the domainCapabilities XML.
Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Currently the RPM spec doesn't add the 'secboot'-variant OVMF binaries
(an unintentional omission, checking with Cole on #virt, OFTC) for
'x86_64' and 'ia32'.  Add them.

This way, getDomainCapabilities() will report all the OVMF binaries that
are present on the system.  E.g. on Fedora 29, if you only have the
edk2-ovmf-20190308stable-1.fc29.noarch package installed, then running
`virsh domcapabilities` will enumerate _both_ the OVMF binaries (instead
of just the OVMF_CODE.fd):

  $> virsh getdomcapabilities
    ...
    <loader supported='yes'>
      <value>/usr/share/edk2/ovmf/OVMF_CODE.fd</value>
      <value>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</value>
    ...

(
Learnt this from a discussion with Michal Privoznik in this bug,
comment#2:

    https://bugzilla.redhat.com/show_bug.cgi?id=1733940 -- RFE: Report
    firmware (FW) paths in domainCapabilities based on FW descriptor
    files
)
Signed-off-by: NKashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: NCole Robinson <crobinso@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

The snapshot-create operation of running guests saves the live
XML and uses it to replace the active and inactive domain in
case of revert. So, the config XML is ignored by the snapshot
process. This commit changes it and adds the config XML in the
snapshot XML as the <inactiveDomain> entry.

In case of offline guest, the behavior remains the same and the
config XML is saved in the snapshot XML as <domain> entry. The
behavior of older snapshots of running guests, that don't have
the new <inactiveDomain>, remains the same too. The revert, in
this case, overrides both active and inactive domain with the
<domain> entry. So, the <inactiveDomain> in the snapshot XML is
not required to snapshot work, but it's useful to preserve the
config XML of running guests.
Signed-off-by: NMaxiwell S. Garcia <maxiwell@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

The function virDomainDefFormatInternal() has the predefined root name
"domain" to format the XML. But to save both active and inactive domain
in the snapshot XML, the new root name "inactiveDomain" was created.
So, the new function virDomainDefFormatInternalSetRootName() allows to
choose the root name of XML. The former function became a tiny wrapper
to call the new function setting the correct parameters.
Signed-off-by: NMaxiwell S. Garcia <maxiwell@linux.ibm.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Tested-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NJiri Denemark <jdenemar@redhat.com>

Once we copy the domain definition from virDomainSnapshotDef, we either
need to assign it to the domain object or free it to avoid memory leaks.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Commit f1056279 introduced a regression: if reverting to a snapshot
fails early (such as when we refuse to revert to an external
snapshot), we lose track of the domain's current snapshot.

Before that patch, we were tracking the notion of the domain's current
snapshot via two means: vm->current_snapshot (which was left untouched
on early exit) and snap->def->current (which only controls what gets
written to XML to remember snapshots across libvirtd restarts).  That
patch was fixing a real bug: if a revert operation failed early, later
questions from the same libvirtd did not see any change to the current
snapsthot, but restarting libvirtd would now claim there is no current
snapshot.  But it fixed it in the wrong direction, in that the current
snapshot was forgotten unconditionally, rather than only when the
snapshot to revert to has a chance of being useful.

It didn't help that the code after that patch had two separate spots
clearing the old notion of the current snapshot - one after
determining the snapshot to revert to was viable, the other
unconditionally on all failure exit paths.  At any rate, the fix is
simple: drop the unconditional cleanup on error paths, and rely only
on the normal cleanup after early checks.

Sadly, it is not possible to test this bug in the existing
tests/virsh-snapshot, as the test driver does not have the same
prohibition against reverting to an external snapshot as the qemu
driver.

See: https://bugzilla.redhat.com/1738747Signed-off-by: NEric Blake <eblake@redhat.com>
Message-Id: <20190909205242.15406-1-eblake@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

In recent commit of 3d21ff72 the virNetDevMacVLanTapOpen() and
virNetDevMacVLanTapSetup() functions were exported in our private
symbols. But these functions live in an #ifdef so they need a
stub implementation.
Then in 1b46566e the virNetDevMacVLanIsMacvtap() function was
implemented but again, only for #idef and without stub.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The Perl bindings for libvirt use the test driver for unit tests. This
tries to load the cpu_map/index.xml file, and when run from an
uninstalled build will fail.

The problem is that virFileActivateDirOverride is called by our various
binaries like libvirtd, virsh, but is not called when a 3rd party app
uses libvirt.so

To deal with this we allow the LIBVIRT_DIR_OVERRIDE=1 env variable to be
set and make virInitialize look for this. The 'run' script will set it,
so now build using this script to run against an uninstalled tree we
will correctly resolve files to the source tree.
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>
Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>

The only caller for which this check makes sense is virDomainDefParse.
Thus the check should be moved there.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

This reverts commit 39dded7b.

This commit broke virpolkittest on Ubuntu 18 which has an old
dbus (v1.12.2). Any other distro with the recent one works
(v1.12.16) which hints its a bug in dbus somewhere. Revert the
commit to stop tickling it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

There are two 'cleanup' labels - one in
virQEMUDriverConfigHugeTLBFSInit() and the other in
virQEMUDriverConfigSetDefaults() that do nothing more than
return and integer value. No memory freeing or anything important
is done there. Drop them in favour of returning immediately.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Our naming rules prefer qemuObjectOperation() scheme rather than
qemuOperationObject() for function names. These were not honoured
in recent commits to qemu_conf.c.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel Henrique Barboza <danielhb413@gmail.com>

Traditionally, macvtap devices are supported using <interface
type='direct'>, but that type requires specifying a source device name
and macvtap mode which can't be altered after the initial device
creation (and may not even be available to the management software
that's creating the XML config to feed to libvirt).

But the attributes in the <source> are essentially describing how the
device will be connected to the network, and if libvirt is to be
supplied with the name of a macvtap device that has already been
created, that device will also already be connected to the network
(and the connection can't be changed). Thus it seems more appropriate
to use type='ethernet', which was created explicitly for this purpose
- for devices that have already been (or will be) connected to the
external network by someone/something outside of libvirt. The fact
that it is a *macv*tap rather than a contentional tap device is just a
detail.

This patch supports using an existing macvtap device with <interface
type='ethernet'> by checking the supplied target dev name to see if it
is a macvtap device and, when this is the case, calling
virNetDevMacVLanTapOpen() instead of virNetDevTapCreate(). For
consistency, this is only done when target managed='no'.

Resolves: https://bugzilla.redhat.com/1723367 (partially)
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>

If managed='no', then the tap device must already exist, and setting
of MAC address and online status (IFF_UP) is skipped.

NB: we still set IFF_VNET_HDR and IFF_MULTI_QUEUE as appropriate,
because those bits must be properly set in the TUNSETIFF we use to set
the tap device name of the handle we've opened - if IFF_VNET_HDR has
not been set and we set it the request will be honored even when
running libvirtd unprivileged; if IFF_MULTI_QUEUE is requested to be
different than how it was created, that will result in an error from
the kernel. This means that you don't need to pay attention to
IFF_VNET_HDR when creating the tap devices, but you *do* need to set
IFF_MULTI_QUEUE if you're going to use multiple queues for your tap
device.

NB2: /dev/vhost-net normally has permissions 600, so it can't be
opened by an unprivileged process. This would normally cause a warning
message when using a virtio net device from an unprivileged
libvirtd. I've found that setting the permissions for /dev/vhost-net
permits unprivileged libvirtd to use vhost-net for virtio devices, but
have no idea what sort of security implications that has. I haven't
changed libvrit's code to avoid *attempting* to open /dev/vhost-net -
if you are concerned about the security of opening up permissions of
/dev/vhost-net (probably a good idea at least until we ask someone who
knows about the code) then add <driver name='qemu'/> to the interface
definition and you'll avoid the warning message.

Note that virNetDevTapCreate() is the correct function to call in the
case of an existing device, because the same ioctl() that creates a
new tap device will also open an existing tap device.

Resolves: https://bugzilla.redhat.com/1723367 (partially)
Signed-off-by: NLaine Stump <laine@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>