If neither BLKID or PARTED is available and we're not writing, then
just return 0 which allows the underlying storage pool to generate
a failure. If both are unavailable and we're writing, then generate
a more generic error message.

When running on s390 with a kernel that does not support cpu model checking and
with a Qemu new enough to support query-cpu-model-expansion, the gathering of qemu
capabilities will fail. Qemu responds to the query-cpu-model-expansion qmp
command with an error because the needed kernel ioct does not exist. When this
happens a guest cannot even be defined due to missing qemu capabilities data.

This patch fixes the problem by silently ignoring generic errors stemming from
calls to query-cpu-model-expansion.
Reported-by: NFarhan Ali <alifm@linux.vnet.ibm.com>
Signed-off-by: NCollin L. Walling <walling@linux.vnet.ibm.com>
Signed-off-by: NJason J. Herne <jjherne@linux.vnet.ibm.com>

When creating new /dev/* for qemu, we do chown() and copy ACLs to
create the exact copy from the original /dev. I though that
copying SELinux labels is not necessary as SELinux will chose the
sane defaults. Surprisingly, it does not leaving namespace with
the following labels:

crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0     random
crw-------. root root system_u:object_r:tmpfs_t:s0     rtc0
drwxrwxrwt. root root system_u:object_r:tmpfs_t:s0     shm
crw-rw-rw-. root root system_u:object_r:tmpfs_t:s0     urandom

As a result, domain is unable to start:

error: internal error: process exited while connecting to monitor: Error in GnuTLS initialization: Failed to acquire random data.
qemu-kvm: cannot initialize crypto: Unable to initialize GNUTLS library: Failed to acquire random data.

The solution is to copy the SELinux labels as well.
Reported-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the documentation we are mixing libvirt-guest and
libvirt_guest module name. The correct name is the latter.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The check is pointless since LVM is capable to detect it's own members
and the check is flawed as it would fail if neither libblkid nor parted
is installed.

We don't really need to babysit LVM in this way.

This reverts commit cb38b6cb.

The check does not work properly (crashes) with netfs filesystems and
also checking that a device is not empty when attempting to mount a
filesystem is not very usefull since the mount will fail anyways.

As the code would improve only a very minor corner case I don't really
see a reason to have this code at all.

This code would also fail if libvirt is compiled without support for
blkid and without parted.

This reverts commit a11fd697.

For HVM domains, pae is only set in libxl_domain_build_info when
explicitly specified in the hypervisor <features> config. This is
fine for i686 machines, but is incorrect behavior for x86_64 machines
where pae must always be enabled. See the following discussion for
additional details

https://www.redhat.com/archives/libvir-list/2017-January/msg00254.html

This element has been introduced in fe053dbe, but isn't
documented yet. After exactly 6 years I guess we can finally
document it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>

The query-cpu-model-expansion is currently implemented for s390(x) only
and all CPU properties it returns are booleans. However, x86
implementation will report more types of properties. Without making the
code more tolerant older libvirt would fail to probe newer QEMU
versions.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The qemuMonitorJSONParseCPUModelProperty function is a callback for
virJSONValueObjectForeachKeyValue and is called for each key/value pair,
thus it doesn't really make sense to check whether key is NULL.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NMarc Hartmayer <mhartmay@linux.vnet.ibm.com>

In f55afd83 I've made libvirt to construct hugepage path on
per-domain basis. However, this change was not reflected in
the NEWS file.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far the decision whether /dev/* entry is created in the qemu
namespace is really simple: does the path starts with "/dev/"?
This can be easily fooled by providing path like the following
(for any considered device like disk, rng, chardev, ..):

  /dev/../var/lib/libvirt/images/disk.qcow2

Therefore, before making the decision the path should be
canonicalized.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far the namespaces were turned on by default unconditionally.
For all non-Linux platforms we provided stub functions that just
ignored whatever namespaces setting there was in qemu.conf and
returned 0 to indicate success. Moreover, we didn't really check
if namespaces are available on the host kernel.

This is suboptimal as we might have ignored user setting.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is a simple wrapper over mount(). However, not every system
out there is capable of moving a mount point. Therefore, instead
of having to deal with this fact in all the places of our code we
can have a simple wrapper and deal with this fact at just one
place.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This is unnecessary wrapper around virProcessNamespaceAvailable().
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Other drivers (like qemu) would like to know if the namespaces
are available therefore it makes sense to move this function to
a shared module.

At the same time, this function had some default namespaces that
are checked with every call. It is not necessary - let callers
pass just those namespaces they are interested in.

With the move the function is renamed to
virProcessNamespaceAvailable.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Due to a copy-paste error, the debug message reads:

  Setting up disks

It should have been:

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

Add "New Features" entry to describe the overwrite flag for logical backend.

Add bug fixes description of overwrite changes for a file system storage pool

Add "Improvements" for commit id 'bb74a7ff' and '78be2e8b' which add
support for using the parent wwnn/wwpn or fabric_name rather than just
using the parent by scsi_hostX name.

Commit id 'bb74a7ff' forgot to adjust the storage docs to describe the
new fields.

List indexes where mixed up in the code looping over the USB
input devices.

When composing the path to the default known_hosts file (for the libssh
and libssh2 drivers), do not check whether the configuration directory
(determined by virGetUserConfigDirectory()) exists: both the drivers can
handle non-existing files, and are able to create them (and their
directories) in that case.

This adds a small behaviour change: before, the key for an unknown host,
and manually accepted, was saved only if the configuration directory
existed -- a bit incoherent behaviour though.

If any of them is specified for the libssh and libssh2 drivers, there is
no need to depend on checks based on other paths: in particular, a
specified path for known_hosts was ignored if the local config directory
could not be determined, and the path for keyfile was ignored if the
home could not be determined.

Instead, lazily determine and use these two paths only in case they are
needed.

Make sure that virNetLibsshSessionSetHostKeyVerification accepts a NULL
value for the path to the known_hosts file:
- call ssh_options_set(SSH_OPTIONS_KNOWNHOSTS) anyway, using /dev/null,
  otherwise libssh will use its default path
- do not call ssh_write_knownhost when no known hosts file was set

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

Suggested-by: NJohn Ferlan <jferlan@redhat.com>

Surprisingly there was a virDomainPCIAddressReleaseAddr() function
already, but it was completely unused. Since we don't reserve entire
slots at once any more, there is no need to release entire slots
either, so we just replace the single call to
virDomainPCIAddressReleaseSlot() with a call to
virDomainPCIAddressReleaseAddr() and remove the now unused function.

The keen observer may be concerned that ...Addr() doesn't call
virDomainPCIAddressValidate(), as ...Slot() did. But really the
validation was pointless anyway - if the device hadn't been suitable
to be connected at that address, it would have failed validation
before every being reserved in the first place, so by definition it
will pass validation when it is being unplugged. (And anyway, even if
something "bad" happened and we managed to have a device incorrectly
at the given address, we would still want to be able to free it up for
use by a device that *did* validate properly).

This function doesn't actually reserve an entire slot any more, it
reserves a single PCI address, so this name is more appropriate.

This function is only called in two places, and the function itself is
just adding a single argument and calling
virDomainPCIAddressReserveNextAddr(), so we can remove it and instead
call virDomainPCIAddressReserveNextAddr() directly. (The main
motivation for doing this is to free up the name so that
qemuDomainPCIAddressReserveNextSlot() can be renamed in the next
patch, as its current name is now inaccurate and misleading).

This function doesn't actually reserve an entire slot any more, it
reserves a single PCI address, so this name is more appropriate.

This is in preparation for renaming virDomainPCIAddressReserveSlot()
to virDomainPCIAddressReserveAddr(), which is a better description of
what it does.

It is now only used in domain_addr.c.

All occurences of the former use fromConfig=true, and that's exactly
how virDomainPCIAddressReserveSlot() calls
virDomainPCIaddressReserveAddr(), so just use *Slot() so that *Addr()
can be made static to conf/domain_addr.c (both functions will be
renamed in upcoming patches).

Since we don't actually reserve an entire slot at a time anymore, the
name of this function is just confusing, and it's almost identical in
operation to virDomainPCIAddressReserveNextAddr() anyway, so remove
the *Slot() function and replace calls to it with calls to *Addr(...,
-1).

With the advent of VIR_PCI_CONNECT_AGGREGATE_SLOT, the new name is
more appropriate, since the address returned may be another address
on the same slot as last time, not necessarily a new slot.

fromConfig should be true if the caller wants
virDomainPCIAddressValidate() to loosen restrictions on its
interpretation of the pciConnectFlags. In particular, either
PCI_DEVICE or PCIE_DEVICE will be counted as equivalent to both, and
HOTPLUG will be ignored. In a few cases where libvirt was manually
overriding automatic address assignment, it was setting fromConfig to
false when validating the hardcoded manual override. This patch
changes those to fromConfig=true as a preemptive strike against any
future bugs that might otherwise surface.

Although setting virDomainPCIAddressReserveAddr()'s fromConfig=true is
correct when a PCI addres is coming from a domain's config, the *true*
purpose of the fromConfig argument is to lower restrictions on what
kind of device can plug into what kind of controller - if fromConfig
is true, then a PCIE_DEVICE can plug into a slot that is marked as
only compatible with PCI_DEVICE (and vice versa), and the HOTPLUG flag
is ignored.

For a long time there have been several calls to
virDomainPCIAddressReserveAddr() that have fromConfig incorrectly set
to false - it's correct that the addresses aren't coming from user
config, but they are coming from hardcoded exceptions in libvirt that
should, if anything, pay *even less* attention to following the
pciConnectFlags (under the assumption that the libvirt programmer knew
what they were doing).

See commit b87703cf for an example of an actual bug caused by the
incorrect setting of the "fromConfig" argument to
virDomainPCIAddressReserveAddr(). Although they haven't resulted in
any reported bugs, this patch corrects all the other incorrect
settings of fromConfig in calls to virDomainPCIAddressReserveAddr().