Since a9331394 (first release v2.1.0), specifying a manual
security_driver setting in qemu.conf causes the daemon to fail to
start, erroring with 'Duplicate security driver X'.

The duplicate checking was incorrectly comparing every entry
against itself, guaranteeing a false positive.

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

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virQEMUDriverConfig object contains lists of
loader:nvram pairs to advertise firmwares supported by
by the driver, and qemu_conf.c contains code to populate
the lists, all of which is useful for other drivers too.

To avoid code duplication, introduce a virFirmware object
to encapsulate firmware details and switch the qemu driver
to use it.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

For disks sources described by a libvirt volume we don't need to do a
complicated check since virStorageTranslateDiskSourcePool already
correctly determines the actual disk type.

Replace the checks using a new accessor that does not open-code the
whole logic.

Instead of setting the default qemu stdio logging approach in
virQEMUDriverConfigLoadFile set it in virQEMUDriverConfigNew so that
it's properly set even when the config is not present.

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

Which is the only user. That was the only reason for including
qemu_command.h, though we need to explicitly include qemu_domain.h
afterwards.

Currently the QEMU stdout/stderr streams are written directly to
a regular file (eg /var/log/libvirt/qemu/$GUEST.log). While those
can be rotated by logrotate (using copytruncate option) this is
not very efficient. It also leaves open a window of opportunity
for a compromised/broken QEMU to DOS the host filesystem by
writing lots of text to stdout/stderr.

This makes it possible to connect the stdout/stderr file handles
to a pipe that is provided by virtlogd. The virtlogd daemon will
read from this pipe and write data to the log file, performing
file rotation whenever a pre-determined size limit is reached.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

This reverts commit 69b850fe.

This change broke the ability to "clear" or reset unfiltered back
to filtered.

RedHat and Debian based distros use different locations

Reference: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=790935

Rather than provide a somewhat generic error message when the API
returns false, allow the caller to supply a "report = true" option
in order to cause virReportError's to describe which of the 3 paths
that can cause failure.

Some callers don't care about what caused the failure, they just want
to have a true/false - for those, calling with report = false should
be sufficient.

Our atomic increment (virAtomicIntInc) uses (if available) gcc
__sync_add_and_fetch builtin. In qemu driver though, we'd profit more
from __sync_fetch_and_add builtin. To keep it simplistic, this patch
adjusts qemu driver initialization rather than adding a new atomic
increment macro.

This fixes

  CC     qemu/libvirt_driver_qemu_impl_la-qemu_conf.lo
  qemu/qemu_conf.c: In function 'qemuRemoveSharedDevice':
  qemu/qemu_conf.c:1384:9: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Setting of 'val' is a boolean expression, so handle it that way and
adjust the check/return logic to be clearer
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Set to ret = -1 and prove otherwise, like usual
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Since a future patch will need the device path generated when adding a
shared host device, remove the qemuAddSharedHostdev and inline the two
calls into qemuAddSharedHostdev and qemuRemoveSharedHostdev
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Split out the current function in order to share the code with hostdev
in a future patch. Failure to match the expected sgio value against what
is stored will cause an error which the caller would need to handle since
only the caller has the disk (or eventually hostdev) specific data in
order to uniquely identify the disk in an error message.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Introduce a convenience function to handle formulating the hostdev path
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add a single boolean function to handle whether the hostdev is shared or not.

Use the new function for the qemu{Add|Remove}SharedHostdev calls as well
as qemuSetUnprivSGIO. NB: This third usage fixes a possible bug where
if this feature is enabled at some time in the future and the shareable flag
wasn't set, the sgio would have been erroneously set.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

The privileged flag will not change while the configuration might
change. Make the 'privileged' flag member of the driver again and mark
it immutable. Should that ever change add an accessor that will group
reads of the state.

Similar to what was done for the channel socket in the previous commit.

Rather than depend on the RPM to put it in place, since this doesn't
cover the qemu:///session case. Currently auto allocated socket path is
completely busted with qemu:///session

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

And because we chown the directory at driver startup now, this also fixes
autosocket startup failures when using user/group=root

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

Rather than duplicate libDir for each new path

- Remove all qemu emulators
- Restart libvirtd
- Install qemu emulators
- Call 'virsh version' -> errors

The only thing that will force the qemu driver to refresh it's cached
capablities info is an explict API call to GetCapabilities.

However in the case when the initial caps lookup at driver connect didn't
find a single qemu emulator to poll, the driver is effectively useless
and really can't do anything until it's populated some qemu capabilities
info.

With the above steps, the user would have to either know about the
magic refresh capabilities call, or restart libvirtd to pick up the
changes.

Instead, this patch changes things so that every time a part of th
driver requests access to capabilities info, check to see if
we've previously seen any emulators. If not, force a refresh.

In the case of 'still no emulators found', this is still very quick, so
I can't think of a downside.

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

The AAVMF and OVMF names were swapped. Reorder the one usage where it
matters so behavior doesn't change.

Well, even though users can pass the list of UEFI:NVRAM pairs at the
configure time, we may maintain the list of widely available UEFI
ourselves too. And as arm64 begin to rises, OVMF was ported there too.
With a slight name change - it's called AAVMF, with AAVMF_CODE.fd
being the UEFI firmware and AAVMF_VARS.fd being the NVRAM store file.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Up until now there are just two ways how to specify UEFI paths to
libvirt. The first one is editing qemu.conf, the other is editing
qemu_conf.c and recompile which is not that fancy. So, new
configure option is introduced: --with-loader-nvram which takes a
list of pairs of UEFI firmware and NVRAM store. This way, the
compiled in defaults can be passed during compile time without
need to change the code itself.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Using the same driver multiple times is pointless and
it can result in confusing errors:

$ virsh start test
error: Failed to start domain test
error: internal error: security label already defined for VM

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

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

There's nothing we need to do for shared iSCSI devices in
qemuAddSharedHostdev and qemuRemoveSharedHostdev. The iSCSI layer
takes care about that for us.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

In our config files users are expected to pass several integer values
for different configuration knobs. However, majority of them expect a
nonnegative number and only a few of them accept a negative number too
(notably keepalive_interval in libvirtd.conf).
Therefore, a new type to config value is introduced: VIR_CONF_ULONG
that is set whenever an integer is positive or zero. With this
approach knobs accepting VIR_CONF_LONG should accept VIR_CONF_ULONG
too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

When enabling the migration_address option, by default it is
set to "127.0.0.1", but it's not a valid address for migration.
so we should add verification and set the default migration_address
to "0.0.0.0".
Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NChen Fan <chen.fan.fnst@cn.fujitsu.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Commit f36a94f2 introduced a double free on all success paths
in qemuSharedDeviceEntryInsert.

Only call qemuSharedDeviceEntryFree on the error path and
set entry to NULL before jumping there if the entry already
is in the hash table.

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

When using split UEFI image, it may come handy if libvirt manages per
domain _VARS file automatically. While the _CODE file is RO and can be
shared among multiple domains, you certainly don't want to do that on
the _VARS file. This latter one needs to be per domain. So at the
domain startup process, if it's determined that domain needs _VARS
file it's copied from this master _VARS file. The location of the
master file is configurable in qemu.conf.

Temporary, on per domain basis the location of master NVRAM file can
be overridden by this @template attribute I'm inventing to the
<nvram/> element. All it does is holding path to the master NVRAM file
from which local copy is created. If that's the case, the map in
qemu.conf is not consulted.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Acked-by: NLaszlo Ersek <lersek@redhat.com>

On some places in the libvirt code we have:

  f(a,z)

instead of

  f(a, z)

This trivial patch fixes couple of such occurrences.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Instead of tediously copying of the disk source to remove it later
ensure that the media change function removes the old device after it
succeeds.

Both addition and removal of a shared hostdev share the code to generate
the hostdev key. Split it out into a separate function and refactor
them.

Removing a shared device needs special steps for disks and hostdevs.
Instead of having one function dealing this split the code into two
separate functions that can be used with better granularity.