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

A long time ago I've implemented support for so called multiqueue
net.  The idea was to let guest network traffic be processed by
multiple host CPUs and thus increasing performance. However, this
behavior is enabled by QEMU via special ioctl() iterated over the
all tap FDs passed in by libvirt. Unfortunately, SELinux comes in
and disallows the ioctl() call because the /dev/net/tun has label
system_u:object_r:tun_tap_device_t:s0 and 'attach_queue' ioctl()
is not allowed on tun_tap_device_t type. So after discussion with
a SELinux developer we've decided that the FDs passed to the QEMU
should be labelled with svirt_t type and SELinux policy will
allow the ioctl(). Therefore I've made a patch
(cf976d9d) that does exactly this. The patch
was fixed then by a4431931 and
b635b7a1. However, things are not
that easy - even though the API to label FD is called
(fsetfilecon_raw) the underlying file is labelled too! So
effectively we are mangling /dev/net/tun label. Yes, that broke
dozen of other application from openvpn, or boxes, to qemu
running other domains.

The best solution would be if SELinux provides a way to label an
FD only, which could be then labeled when passed to the qemu.
However that's a long path to go and we should fix this
regression AQAP. So I went to talk to the SELinux developer again
and we agreed on temporary solution that:

1) All the three patches are reverted
2) SELinux temporarily allows 'attach_queue' on the
tun_tap_device_t
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

 - docs/formatstorage.html.in: document 'zfs' pool type, add it
   to a list of pool types that could use source physical devices
 - docs/storage.html.in: update a ZFS pool example XML with
   source physical devices, mention that starting from 1.2.9 a
   pool could be created from this devices by libvirt and in earlier
   versions user still has to create a pool manually
 - docs/drvbhyve.html.in: add an example with ZFS pools

 - Provide an implementation for buildPool and deletePool operations
   for the ZFS storage backend.
 - Add VIR_STORAGE_POOL_SOURCE_DEVICE flag to ZFS pool poolOptions
   as now we can specify devices to build pool from
 - storagepool.rng: add an optional 'sourceinfodev' to 'sourcezfs' and
   add an optional 'target' to 'poolzfs' entity
 - Add a couple of tests to storagepoolxml2xmltest

Free str unconditionally since we allocate it without WITH_AUDIT
too.

virVasprintf sets the output to NULL on failure.

Plug a memory leak and silence a warning.

Commit de0aeafe introduced a memory leak.

When trying to remove nonexistent metadata from XML, libvirt daemon
crashes due to dereferencing NULL pointer.

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

If the qemu being used doesn't support JSON, then querying for IOThread
data would fail. In that case, ensure the *iothreads is NULL and return 0
as the count of iothreads available.

Currently, build with clang fails with:

  CC       qemu/libvirt_driver_qemu_impl_la-qemu_command.lo
qemu/qemu_command.c:6580:58: error: implicit conversion from enumeration type
'virMemAccess' to different enumeration type 'virTristateSwitch'
[-Werror,-Wenum-conversion]
        virTristateSwitch memAccess = def->cpu->cells[i].memAccess;
                          ~~~~~~~~~   ~~~~~~~~~~~~~~~~~~~^~~~~~~~~
1 error generated.

Fix that by using virMemAccess instead of virTristateSwitch.

Commit f05b6a91 added virQEMUDriverConfigPtr argument to the
virQEMUCapsFillDomainCaps function and it uses forward declaration
of virQEMUDriverConfig and virQEMUDriverConfigPtr that casues clang
build to fail:

gmake[3]: Entering directory `/usr/home/novel/code/libvirt/src'
  CC       qemu/libvirt_driver_qemu_impl_la-qemu_capabilities.lo
In file included from qemu/qemu_capabilities.c:43:
In file included from qemu/qemu_hostdev.h:27:
qemu/qemu_conf.h:63:37: error: redefinition of typedef 'virQEMUDriverConfig'
is a C11 feature [-Werror,-Wtypedef-redefinition]
typedef struct _virQEMUDriverConfig virQEMUDriverConfig;
                                    ^
qemu/qemu_capabilities.h:328:37: note: previous definition is here
typedef struct _virQEMUDriverConfig virQEMUDriverConfig;
                                    ^

Fix that by passing loader and nloader config attributes directly
instead of passing complete config.

Commit b20d39a5 introduced a new argument for the
virNetDevTapCreateInBridgePort function, however, its mock
in bhyve tests wasn't updated, so the build failed.

Fix build by adding this new argument to the mock version.

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

Now that we have a simple function to check locality of storage, reuse
it in qemuDomainCheckDiskPresence().

Also reuse check for empty storage source.

The formatted UUID isn't used anywhere else in
qemuDomainCheckDiskStartupPolicy. Drop it.

Clean up all _virDomainMemoryStat.
Signed-off-by: NJames <james.wangyufei@huawei.com>
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Clean up all _virDomainBlockStats.
Signed-off-by: NJames <james.wangyufei@huawei.com>
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Clean up all _virDomainInterfaceStats.
Signed-off-by: NWang Yufei <james.wangyufei@huawei.com>
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

Live definition was used to look up the disk index while persistent one
was indexed leading to a crash in qemuDomainGetBlockIoTune. Use the
correct def and report a nice error.

Unfortunately it's accessible via read-only connection, though it can
only crash libvirtd in the cases where the guest is hot-plugging disks
without reflecting those changes to the persistent definition.  So
avoiding hotplug, or doing hotplug where persistent is always modified
alongside live definition, will avoid the out-of-bounds access.

Introduced in: eca96694a (v0.9.8)
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1140724Reported-by: NLuyao Huang <lhuang@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

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

There are two ways how to tell qemu to use huge pages. The first one
is suitable for domains with NUMA nodes: the path to hugetlbfs mount
is appended to NUMA node definition on the command line. The second
one is suitable for UMA domains: here there's this global '-mem-path'
argument that accepts path to the hugetlbfs mount point. However, the
latter case was not used for all the cases that it should be. For
instance:

  <memoryBacking>
    <hugepages>
      <page size='2048' unit='KiB' nodeset='0'/>
    </hugepages>
  </memoryBacking>

didn't trigger the '-mem-path' so the huge pages - despite being
configured - were not used at all.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

As of 136ad497 it is possible to specify different huge pages per
guest NUMA node. However, there's no check if nodeset specified in
./hugepages/page contains only those guest NUMA nodes that exist.
In other words with current code it is possible to define meaningless
combination:

  <memoryBacking>
    <hugepages>
      <page size='1048576' unit='KiB' nodeset='0,2-3'/>
      <page size='2048' unit='KiB' nodeset='1,4'/>
    </hugepages>
  </memoryBacking>
  <vcpu placement='static'>4</vcpu>
  <cpu>
    <numa>
      <cell id='0' cpus='0' memory='1048576'/>
      <cell id='1' cpus='1' memory='1048576'/>
      <cell id='2' cpus='2' memory='1048576'/>
      <cell id='3' cpus='3' memory='1048576'/>
    </numa>
  </cpu>

Notice the node 4 in <hugepages/>?
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Document the fields returned.

Add a note to make the users aware that some stats groups or fields may
be missing in certain cases.

State that full stats for the stats groups are available in the
virConnectGetAllDomainStats documentation section rather than
duplicating the docs.

Add new bulk stats groups to the domstats command.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>

This patch implements the VIR_DOMAIN_STATS_BLOCK group of statistics.

To do so, a helper function to get the block stats of all the disks of
a domain is added.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

This patch implements the VIR_DOMAIN_STATS_INTERFACE group of
statistics.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

This patch implements the VIR_DOMAIN_STATS_VCPU group of statistics. To
do so, this patch also extracts a helper to gather the vCPU information.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

This patch implements the VIR_DOMAIN_STATS_BALLOON group of statistics.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>

This patch implements the VIR_DOMAIN_STATS_CPU_TOTAL group of
statistics.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Future patches which will implement more bulk stats groups for QEMU will
need to access the connection object.

To accommodate that, a few changes are needed:

* enrich internal prototype to pass qemu driver object

* add per-group flag to mark if one collector needs monitor access or not

* If at least one collector of the requested stats needs monitor access
  we must start a query job for each domain.  The specific collectors
  will run nested monitor jobs inside that.

* If the job can't be acquired we pass flags to the collector so
  specific collectors that need monitor access can be skipped in order
  to gather as much data as is possible.
Signed-off-by: NFrancesco Romani <fromani@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

As of f05b6a91 the test produces the list of paths that can
be passed to <loader/> and libvirt knows about them. However,
during the process of generating the list the paths are checked
for their presence. This may produce different results on
different systems.  Therefore, the path - if missing - is
added to pretend it's there.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This way it behaves more like the daemon itself does (acquiring a
pidfile, deleting the socket before binding, etc.).

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=927369
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1138604Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Check to see if the UEFI binary mentioned in qemu.conf actually
exists, and if so expose it in domcapabilities like

<loader ...>
  <value>/path/to/ovmf</value>
</loader>

We introduce some generic domcaps infrastructure for handling
a dynamic list of string values, it may be of use for future bits.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Up till now the virQEMUCapsFillDomainCaps() was type of void as
there was no way for it to fail. This is, however, going to
change in the next commit.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

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

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

qemu for IBM Power processor architecture is adding functionality for
supporting multiple 'pseries' machine type versions, each with different
capabilities. This patch is for supporting the same
Signed-off-by: NPradipta Kr. Banerjee <bpradip@in.ibm.com>

As of 54289916 we learned libvirt to use UEFI for domains.
However, management applications may firstly query if libvirt
supports it. And this is where virConnectGetDomainCapabilities()
API comes handy.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>