Commit id 'b00d7f29' shifted the opening of the /sys/devices/intel_cqm/type
file from event enable to perf event initialization. If the file did not
exist, then an error would be written to the domain log:

2016-09-06 20:51:21.677+0000: 7310: error : virFileReadAll:1360 : Failed to open file '/sys/devices/intel_cqm/type': No such file or directory

Since the error is now handled in virPerfEventEnable by checking if the
event_attr->attrType == 0 for CMT, MBML, and MBMT events - we can just
use the Quiet API in order to not log the error we're going to throw away.

Additionally, rather than using virReportSystemError, use virReportError
and VIR_ERR_ARGUMENT_UNSUPPORTED in order to signify that support isn't there
for that type of perf event - adjust the error message as well.

Akin to previous commit but for "virsh cpu-baseline" which
computes a baseline CPU for a set of host cpu elements.
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Implement support for "virsh cpu-compare" so that we can calculate
common cpu element between a pool of hosts, which had a requirement
of providing host cpu description.
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Parse libxl_hwcap accounting for versions since Xen 4.4 - Xen 4.7.
libxl_hwcaps is a set of cpuid leaves output that is described in [0] or
[1] in Xen 4.7. This is a collection of CPUID leaves that we version
in libvirt whenever feature words are reordered or added. Thus we keep the
common ones in one struct and others for each version. Since
libxl_hwcaps doesn't appear to have a stable format across all supported
versions thus we need to keep track of changes as a compromise until it's
exported in xen libxl API. We don't fail in initializing the driver in case
parsing of hwcaps failed for that reason. In addition, change the notation
on PAE feature such that is easier to read which bit it corresponds.

[0] xen/include/asm-x86/cpufeature.h
[1] xen/include/public/arch-x86/cpufeatureset.h
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>

Add support for describing cpu topology in host cpu element.  In doing
so, refactor hwcaps part to its own helper namely libxlCapsInitCPU to
handle all host cpu related operations, including topology.
Signed-off-by: NJoao Martins <joao.m.martins@oracle.com>

Qemu always opens the tray if forced to. Skip the waiting step in such
case.

This also helps if qemu does not report the tray change event when
opening the cdrom forcibly (the documentation says that the event will
not be sent although qemu in fact does trigger it even if @force is
selceted).

This is a workaround for a qemu issue where qemu does not send the tray
change event in some cases (after migration with empty closed locked
drive) and thus renders the cdrom useless from libvirt's point of view.

Partially resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1368368

When a source image is dropped when missing due to startup policy the
policy needs to be cleared since it was relevant only for the given
storage source. New sources need to update it if needed.

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

Just like in the previous commit, teach qemu driver to detect
whether qemu supports this configuration knob or not.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

QEMU added another virtio-net tunable [1]. It basically allows
users to set the size of RX virtio ring. But because virtio-net
uses two separate ring buffers to pass data from/to guest they
named it explicitly rx_queue_size. We should expose it in our XML
too.

1: http://lists.nongnu.org/archive/html/qemu-devel/2016-08/msg02029.htmlSigned-off-by: NMichal Privoznik <mprivozn@redhat.com>

Add a new secret usage type known as "tls" - it will handle adding the
secret objects for various TLS objects that need to provide some sort
of passphrase in order to access the credentials.

The format is:

   <secret ephemeral='no' private='no'>
     <description>Sample TLS secret</description>
     <usage type='tls'>
       <name>mumblyfratz</name>
     </usage>
</secret>

Once defined and a passphrase set, future patches will allow the UUID
to be set in the qemu.conf file and thus used as a secret for various
TLS options such as a chardev serial TCP connection, a NBD client/server
connection, and migration.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If the incoming XML defined a path to a TLS X.509 certificate environment,
add the necessary 'tls-creds-x509' object to the VIR_DOMAIN_CHR_TYPE_TCP
character device.

Likewise, if the environment exists the hot unplug needs adjustment as
well.  Note that all the return ret were changed to goto cleanup since
the cfg needs to be unref'd
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

When building a chardev device string for tcp, add the necessary pieces to
access provide the TLS X.509 path to qemu.  This includes generating the
'tls-creds-x509' object and then adding the 'tls-creds' parameter to the
VIR_DOMAIN_CHR_TYPE_TCP command line.

Finally add the tests for the qemu command line. This test will make use
of the "new(ish)" /etc/pki/qemu setting for a TLS certificate environment
by *not* "resetting" the chardevTLSx509certdir prior to running the test.
Also use the default "verify" option (which is "no").
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Add a new TLS X.509 certificate type - "chardev". This will handle the
creation of a TLS certificate capability (and possibly repository) for
properly configured character device TCP backends.

Unlike the vnc and spice there is no "listen" or "passwd" associated. The
credentials eventually will be handled via a libvirt secret provided to
a specific backend.

Make use of the default verify option as well.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Rather than specify perhaps multiple TLS X.509 certificate directories,
let's create a "default" directory which can then be used if the service
(e.g. for now vnc and spice) does not supply a default directory.

Since the default for vnc and spice may have existed before without being
supplied, the default check will first check if the service specific path
exists and if so, set the cfg entry to that; otherwise, the default will
be set to the (now) new defaultTLSx509certdir.

Additionally add a "default_tls_x509_verify" entry which can also be used
to force the peer verification option (for vnc it's a x509verify option).
Add/alter the macro for the option being found in the config file to accept
the default value.
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

If a migration of a domain which is already defined on the destination
host failed early (before we tried to start QEMU), we would forget to
remove the incoming transient definition. Later on when someone starts
the domain on the destination host, we will use the stale incoming
definition and the persistent definition will just be ignored.

https://bugzilla.redhat.com/show_bug.cgi?id=1368774Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

The code for replacing domain's transient definition with the persistent
one is repeated in several places and we'll need to add one more. Let's
make a nice helper for it.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Signed-off-by: NErik Skultety <eskultet@redhat.com>

srv-list command was missing in the man page.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

When using
virsh net-event non-existing-net
the error message says that 'either --list or event type is required'
This is misleading as 'virsh net-event $valid-event-type' is not going
to work either. What is expected is 'virsh net-event --event
$valid-event-type'

This commit fixes the string in pool-event, nodedev-event, event, and
net-event.

There is an issue with a wrong label inside vah_add_path().
The compilation fails with the error:
make[3]: Entering directory '/tmp/libvirt/src'
  CC       security/virt_aa_helper-virt-aa-helper.o
security/virt-aa-helper.c: In function 'vah_add_path':
security/virt-aa-helper.c:769:9: error: label 'clean' used but not defined
         goto clean;

This patch moves 'clean' label to 'cleanup' label.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

This patch fixes a segfault in virt-aa-helper caused by attempting to
modify a static string literal. It is triggered when a domain has a
<filesystem> with type='mount' configured read-only and libvirt is
using the AppArmor security driver for sVirt confinement. An "R" is
passed into the function and converted to 'r'.

This patch is to delete the extra wrap "\n" after failed vol-resize
error for both "Failed to change size of volume to" and "Failed to change
size of volume by". For error with wrap, there will be an extra wrap
between two errors, such as:

   (1)# virsh vol-resize --pool default --vol vol-test 5M
        error: Failed to change size of volume 'vol-test' to 5M

        error: invalid argument: Can't shrink capacity below current capacity unless shrink flag explicitly specified

   (2)# virsh vol-resize /var/lib/libvirt/images/volds --shrink --delta 10M
        error: Failed to change size of volume 'volds' by 10M

        error: invalid argument: can't shrink capacity below existing allocation

At this point it's guaranteed that 'persistentDef' is non-NULL so we
don't need to check it again.

Similarly to vcpu hotplug the emulator thread cgroup numa mapping needs
to be relaxed while hot-adding vcpus so that the threads can allocate
data in the DMA zone.

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

When hot-adding vcpus qemu needs to allocate some structures in the DMA
zone which may be outside of the numa pinning. Extract the code doing
this in a set of helpers so that it can be reused.

Unfortunately, commit a8962f70 only fixed first half of the reported issue of
virt-admin outputting negative values where unsigned int is expected by
BZ below, so this commit represents the other missing half of the fix.

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

There is a possibility that qemu driver frees by unreferencing its
closeCallbacks pointer as it has the only reference to the object,
while in fact not all users of CloseCallbacks called thier
virCloseCallbacksUnset.

Backtrace is the following:
Thread #1:
0  in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
1  in virCondWait (c=<optimized out>, m=<optimized out>)
    at util/virthread.c:154
2  in virThreadPoolFree (pool=0x7f0810110b50)
    at util/virthreadpool.c:266
3  in qemuStateCleanup () at qemu/qemu_driver.c:1116
4  in virStateCleanup () at libvirt.c:808
5  in main (argc=<optimized out>, argv=<optimized out>)
    at libvirtd.c:1660

Thread #2:
0  in virClassIsDerivedFrom (klass=0xdeadbeef, parent=0x7f0837c694d0) at util/virobject.c:169
1  in virObjectIsClass (anyobj=anyobj@entry=0x7f08101d4760, klass=<optimized out>) at util/virobject.c:365
2  in virObjectLock (anyobj=0x7f08101d4760) at util/virobject.c:317
3  in virCloseCallbacksUnset (closeCallbacks=0x7f08101d4760, vm=vm@entry=0x7f08101d47b0, cb=cb@entry=0x7f081d078fc0 <qemuProcessAutoDestroy>) at util/virclosecallbacks.c:163
4  in qemuProcessAutoDestroyRemove (driver=driver@entry=0x7f081018be50, vm=vm@entry=0x7f08101d47b0) at qemu/qemu_process.c:6368
5  in qemuProcessStop (driver=driver@entry=0x7f081018be50, vm=vm@entry=0x7f08101d47b0, reason=reason@entry=VIR_DOMAIN_SHUTOFF_SHUTDOWN, asyncJob=asyncJob@entry=QEMU_ASYNC_JOB_NONE, flags=flags@entry=0) at qemu/qemu_process.c:5854
6  in processMonitorEOFEvent (vm=0x7f08101d47b0, driver=0x7f081018be50) at qemu/qemu_driver.c:4585
7  qemuProcessEventHandler (data=<optimized out>, opaque=0x7f081018be50) at qemu/qemu_driver.c:4629
8  in virThreadPoolWorker (opaque=opaque@entry=0x7f0837c4f820) at util/virthreadpool.c:145
9  in virThreadHelper (data=<optimized out>) at util/virthread.c:206
10 in start_thread () from /lib64/libpthread.so.0

Let's reference CloseCallbacks object in virCloseCallbacksSet and
unreference in virCloseCallbacksUnset.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

A separate error code will help recognize real failures from
necessity to try again
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

In the latest glibc, major() and minor() functions are marked as
deprecated (glibc commit dbab6577):

  CC       util/libvirt_util_la-vircgroup.lo
util/vircgroup.c: In function 'virCgroupGetBlockDevString':
util/vircgroup.c:768:5: error: '__major_from_sys_types' is deprecated:
  In the GNU C Library, `major' is defined by <sys/sysmacros.h>.
  For historical compatibility, it is currently defined by
  <sys/types.h> as well, but we plan to remove this soon.
  To use `major', include <sys/sysmacros.h> directly.
  If you did not intend to use a system-defined macro `major',
  you should #undef it after including <sys/types.h>.
  [-Werror=deprecated-declarations]
     if (virAsprintf(&ret, "%d:%d ", major(sb.st_rdev), minor(sb.st_rdev)) < 0)
     ^~
In file included from /usr/include/features.h:397:0,
                 from /usr/include/bits/libc-header-start.h:33,
                 from /usr/include/stdio.h:28,
                 from ../gnulib/lib/stdio.h:43,
                 from util/vircgroup.c:26:
/usr/include/sys/sysmacros.h:87:1: note: declared here
 __SYSMACROS_DEFINE_MAJOR (__SYSMACROS_FST_IMPL_TEMPL)
 ^

Moreover, in the glibc commit, there's suggestion to keep
ordering of including of header files as implemented here.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This patch changes the signature of vshCompleters, allowing to pass along
some data that we might want to along with the completers; for example,
we might want to pass the autocomplete vshControl along with the
completer, in case the completer requires a connection to libvirtd.
Signed-off-by: NNishith Shah <nishithshah.2211@gmail.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Current implementation uses the dev.cpu.0.freq sysctl that is
provided by the cpufreq(4) framework and returns the actual
CPU frequency. However, there are environments where it's not available,
e.g. when running nested in KVM. In this case fall back to hw.clockrate
that reports CPU frequency at the boot time.

Resolves (hopefully):
https://bugzilla.redhat.com/show_bug.cgi?id=1369964

Having After=libvirtd.service merely ensures that, if both
services are asked to start, libvirtd.service will start
first.

What we really want is for libvirtd.service to be started
whenever libvirt-guests.service is asked to start. Adding a
Requires= relationship guarantees that will happen.

We use a separate line for each After= relationship in other
unit files: do the same here for consistency's sake, and also
to make future changes nicer to diff

libvirt-guests.service does both suspend *and* resume guests,
depending on whether it's being started or stopped: the
description should reflect this, to avoid confusing messages
during startup.

Replace "active" with "running" (to match virsh list's output)
and don't capitalize libvirt.

We already guarantee that virtlogd.socket is enabled/disabled
along with libvirtd.service, but if libvirtd.service has just
been installed and is started before rebooting, then
virtlogd.socket will not be running and guest startup will
fail.

Add Requires=virtlogd.socket to libvirtd.service to make sure
virtlogd.socket is always started along with libvirtd.service,
and add Before=libvirtd.service to both virtlogd.socket and
virtlogd.service so that virtlogd never disappears before
libvirtd has exited.

Also add PartOf=libvirtd.service to both virtlogd.socket and
virtlogd.service, so that virtlogd can be shut down when not
needed.

Resolves: https://bugzilla.redhat.com/1372576

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

Debug priority is good enough for this.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We already have the ability to turn off dumping of guest
RAM via the domain XML. This is not particularly useful
though, as it is under control of the management application.
What is needed is a way for the sysadmin to turn off guest
RAM defaults globally, regardless of whether the mgmt app
provides its own way to set this in the domain XML.

So this adds a 'dump_guest_core' option in /etc/libvirt/qemu.conf
which defaults to false. ie guest RAM will never be included in
the QEMU core dumps by default. This default is different from
historical practice, but is considered to be more suitable as
a default because

 a) guest RAM can be huge and so inflicts a DOS on the host
    I/O subsystem when dumping core for QEMU crashes

 b) guest RAM can contain alot of sensitive data belonging
    to the VM owner. This should not generally be copied
    around inside QEMU core dumps submitted to vendors for
    debugging

 c) guest RAM contents are rarely useful in diagnosing
    QEMU crashes
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently the QEMU processes inherit their core dump rlimit
from libvirtd, which is really suboptimal. This change allows
their limit to be directly controlled from qemu.conf instead.