When LIBXL_HAVE_QED is defined, xlconfigtest fails

 9) Xen XL-2-XML Format disk-qed  ... command line: config parsing error
 in disk specification: no vdev specified in
 `target=/var/lib/libvirt/images/XenGuest2,format=qed,backendtype=qdisk,vdev=hda,access=rw'
FAILED

As per the xl-disk-configuration(5) man page, target= must come
last in the disk specification when specified by name:

When this parameter is specified by name, ie with the target=
syntax in the configuration file, it consumes the whole rest of the
DISKSPEC including trailing whitespaces.  Therefore in that case
it must come last.

Change tests/xlconfigdata/test-disk-qed.cfg to adhere to this
restriction.

The problem is in the way how the list item is created prior to
appending it to the transaction list - the @path argument is just a
shallow copy instead of deep copy of the hostdev device's path.
Unfortunately, the hostdev devices from which the @path is extracted, in
order to add them into the transaction list, are only temporary and
freed before the buildup of the qemu namespace, thus making the @path
attribute in the transaction list NULL, causing 'permission denied' or
'double free' or 'unknown cause' errors.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1413773Signed-off-by: NErik Skultety <eskultet@redhat.com>

The problem is in the way how the list item is created prior to
appending it to the transaction list - the @path attribute is just a
shallow copy instead of deep copy of the hostdev device's path.
Unfortunately, the hostdev devices from which the @path is extracted, in
order to add them into the transaction list, are only temporary and
freed before the buildup of the qemu namespace, thus making the @path
attribute in the transaction list NULL, causing 'permission denied' or
'double free' or 'unknown cause' errors.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1413773Signed-off-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

While all the code that deals with qemu namespaces correctly
detects whether we are running as root (and turn into NO-OP for
qemu:///session) the actual unshare() call is not guarded with
such check. Therefore any attempt to start a domain under
qemu:///session shall fail as unshare() is reserved for root.

The fix consists of moving unshare() call (for which we have a
wrapper called virProcessSetupPrivateMountNS) into
qemuDomainBuildNamespace() where the proper check is performed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Tested-by: NRichard W.M. Jones <rjones@redhat.com>

This reverts commit ae16c95f.

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

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

For case VIR_STORAGE_BLKID_PROBE_DIFFERENT, clean up the message to
avoid using the virsh like --overwrite syntax. Additionally provide
a different error message when not writing the label to avoid confusion.

Rather than special casing the VIR_STORAGE_BLKID_PROBE_UNKNOWN after
calling virStorageBackendBLKIDFindPart, just allow the switch statement
handle setting ret = -2.

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>