Signed-off-by: NDaniel P. Berrange <berrange@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>

RBD in qemu still uses only the legacy 'filename' syntax.

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

Commit 2ed772cd forgot to set proper protocol. This was also present in
the test data.

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

With current perf framework, this patch adds support and documentation
for more perf events, including cache misses, cache references, cpu cycles,
and instructions.
Signed-off-by: NQiaowei Ren <qiaowei.ren@intel.com>

xen-xm doesn't support mult serial devices at all, so these tests are
meaningless.
Signed-off-by: NBob Liu <bob.liu@oracle.com>

Adding tests for domXML <-> xl.cfg conversions containing multiple
serial devices.
Signed-off-by: NBob Liu <bob.liu@oracle.com>

Add support for using the new approach to hotplug vcpus using device_add
during startup of qemu to allow sparse vcpu topologies.

There are a few limitations imposed by qemu on the supported
configuration:
- vcpu0 needs to be always present and not hotpluggable
- non-hotpluggable cpus need to be ordered at the beginning
- order of the vcpus needs to be unique for every single hotpluggable
  entity

Qemu also doesn't really allow to query the information necessary to
start a VM with the vcpus directly on the commandline. Fortunately they
can be hotplugged during startup.

The new hotplug code uses the following approach:
- non-hotpluggable vcpus are counted and put to the -smp option
- qemu is started
- qemu is queried for the necessary information
- the configuration is checked
- the hotpluggable vcpus are hotplugged
- vcpus are started

This patch adds a lot of checking code and enables the support to
specify the individual vcpu element with qemu.

Individual vCPU hotplug requires us to track the state of any vCPU. To
allow this add the following XML:

<domain>
  ...
  <vcpu current='2'>3</vcpu>
  <vcpus>
    <vcpu id='0' enabled='yes' hotpluggable='no' order='1'/>
    <vcpu id='1' enabled='yes' hotpluggable='yes' order='2'/>
    <vcpu id='1' enabled='no' hotpluggable='yes'/>
  </vcpus>
  ...

The 'enabled' attribute allows to control the state of the vcpu.
'hotpluggable' controls whether given vcpu can be hotplugged and 'order'
allows to specify the order to add the vcpus.

The reported data is unusual so add it to the test suite.

Test the algorithm that extracts the order in which the vcpu entries
were plugged in on a sample of data created by plugging in vcpus
arbitrarily.

Power 8 platform's basic hotpluggable unit is a core rather than a
thread for x86_64 family. This introduces most of the complexity of the
matching code and thus needs to be tested.

The test data contain data captured from in-order cpu hotplug and
unplug operations.

During review it was reported that adding at least 11 vcpus creates a
collision of prefixes in the monitor matching algorithm. Add a test case
to verify that the problem won't happen.

As the combination algorithm is rather complex and ugly it's necessary
to make sure it works properly. Add test suite infrastructure for
testing it along with a basic test based on x86_64 platform.

To allow matching up the data returned by query-cpus to entries in the
query-hotpluggable-cpus reply for CPU hotplug it's necessary to extract
the QOM path as it's the only link between the two.

QEMU reports whether 'query-hotpluggable-cpus' is supported for a given
machine type. Extract and cache the information using the capability
cache.

When copying the capabilities for a new start of qemu, mask out the
presence of QEMU_CAPS_QUERY_HOTPLUGGABLE_CPUS if the machine type
doesn't support hotpluggable cpus.

Prepare to extract more data by returning an array of structs rather than
just an array of thread ids. Additionally report fatal errors separately
from qemu not being able to produce data.

Turn various vshPrint() informative messages into vshPrintExtra(), so
they are not printed when requesting the quiet mode; neither XML/info
outputs nor the results of commands are affected.
Also change the expected outputs of the virsh-undefine test, since virsh
is invoked in quiet mode there.

Some informative messages might still be converted (and thus silenced
when in quiet mode), but this is an improvements nonetheless.

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

For some unknown reason the original implementation of the <forwarder>
element only took advantage of part of the functionality in the
dnsmasq feature it exposes - it allowed specifying the ip address of a
DNS server which *all* DNS requests would be forwarded to, like this:

   <forwarder addr='192.168.123.25'/>

This is a frontend for dnsmasq's "server" option, which also allows
you to specify a domain that must be matched in order for a request to
be forwarded to a particular server. This patch adds support for
specifying the domain. For example:

   <forwarder domain='example.com' addr='192.168.1.1'/>
   <forwarder domain='www.example.com'/>
   <forwarder domain='travesty.org' addr='10.0.0.1'/>

would forward requests for bob.example.com, ftp.example.com and
joe.corp.example.com all to the DNS server at 192.168.1.1, but would
forward requests for travesty.org and www.travesty.org to
10.0.0.1. And due to the second line, requests for www.example.com,
and odd.www.example.com would be resolved by the libvirt network's own
DNS server (i.e. thery wouldn't be immediately forwarded) even though
they also match 'example.com' - the match is given to the entry with
the longest matching domain. DNS requests not matching any of the
entries would be resolved by the libvirt network's own DNS server.

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

If you define a libvirt virtual network with one or more IP addresses,
it starts up an instance of dnsmasq. It's always been possible to
avoid dnsmasq's dhcp server (simply don't include a <dhcp> element),
but until now it wasn't possible to avoid having the DNS server
listening; even if the network has no <dns> element, it is started
using default settings.

This patch adds a new attribute to <dns>: enable='yes|no'. For
backward compatibility, it defaults to 'yes', but if you don't want a
DNS server created for the network, you can simply add:

   <dns enable='no'/>

to the network configuration, and next time the network is started
there will be no dns server created (if there is dhcp configuration,
dnsmasq will be started with "port=0" which disables the DNS server;
if there is no dhcp configuration, dnsmasq won't be started at all).

The new forward mode 'open' is just like mode='route', except that no
firewall rules are added to assure that any traffic does or doesn't
pass. It is assumed that either they aren't necessary, or they will be
setup outside the scope of libvirt.

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

==18324== 32 bytes in 1 blocks are still reachable in loss record 41 of 114
==18324==    at 0x4C2C070: calloc (vg_replace_malloc.c:623)
==18324==    by 0x4EA479B: virAlloc (viralloc.c:144)
==18324==    by 0x4EA674A: virBitmapNewQuiet (virbitmap.c:77)
==18324==    by 0x4EA67F7: virBitmapNew (virbitmap.c:106)
==18324==    by 0x4EC777D: dnsmasqCapsNewEmpty (virdnsmasq.c:801)
==18324==    by 0x4EC781B: dnsmasqCapsNewFromBuffer (virdnsmasq.c:815)
==18324==    by 0x407CF4: mymain (networkxml2conftest.c:99)
==18324==    by 0x409CF0: virTestMain (testutils.c:982)
==18324==    by 0x4080EA: main (networkxml2conftest.c:136)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The marginally nicer error message is not worth the extra lines in
cfg.mk.

Also drop the excludes since there was only one offender in the tests.

The script was returning success unless it failed on the last file.
This went unnoticed because sc_prohibit_long_lines forbids lines
longer than 90 characters in .arg[sv] files.

Check whether the disable-legacy property is present on the following
devices:
  virtio-balloon-pci
  virtio-blk-pci
  virtio-scsi-pci
  virtio-serial-pci
  virtio-9p-pci
  virtio-net-pci
  virtio-rng-pci
  virtio-gpu-pci
  virtio-input-host-pci
  virtio-keyboard-pci
  virtio-mouse-pci
  virtio-tablet-pci

Assuming that if QEMU knows other virtio devices where this property
is applicable, it will have at least one of these devices.

Added in QEMU by:
commit e266d421490e0ae83044bbebb209b2d3650c0ba6
    virtio-pci: add flags to enable/disable legacy/modern

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

Since libvirt still uses a legacy qemu arg format to add a disk, the
manner in which the 'password-secret' argument is passed to qemu needs
to change to prepend a 'file.' If in the future, usage of the more
modern disk format, then the prepended 'file.' can be removed.

Fix based on Jim Fehlig <jfehlig@suse.com> posting and subsequent
upstream list followups, see:

http://www.redhat.com/archives/libvir-list/2016-August/msg00777.html

for details. Introduced by commit id 'a1344f70'.

The first argument should be const char ** instead of
char **, because this is a search function and as such it
doesn't, and shouldn't, alter the haystack in any way.

This change means we no longer have to cast arrays of
immutable strings to arrays of mutable strings; we still
have to do the opposite, though, but that's reasonable.

qemu uses 'url' instead of 'uri'. They unfortunately look very similar.

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

If any of the devices referenced a USB hub that does not exist,
defining the domain would either fail with:
error: An error occurred, but the cause is unknown
(if only the last hub in the path is missing)
or crash.

Return a proper error instead of crashing.

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

Commit 11567cf6 added some libxl tests into domaincapstest and
added libvirt_driver_libxl_impl.la to domaincapstest_LDADD.

This causes link fail on systems without GNU regex implementation:

gmake[2]: Entering directory '/usr/home/novel/code/libvirt/tests'
  CCLD     domaincapstest
  ../src/.libs/libvirt_driver_libxl_impl.a(libvirt_driver_libxl_impl_la-libxl_capabilities.o):
  In function `libxlMakeCapabilities':
  libxl/libxl_capabilities.c:(.text+0x6b2): undefined reference to
  `rpl_regcomp'
  libxl/libxl_capabilities.c:(.text+0x6d0): undefined reference to
  `rpl_regerror'
  libxl/libxl_capabilities.c:(.text+0x803): undefined reference to
  `rpl_regexec'
  libxl/libxl_capabilities.c:(.text+0xa58): undefined reference to
  `rpl_regfree'
  clang-3.8: error: linker command failed with exit code 1 (use -v to
  see invocation)

This happens because on these system it tries to use gnulib's builtin
regex implementation, but doesn't link to gnulib.

Fix by adding $(GNULIB_LIBS) along with libvirt_driver_libxl_impl.la to
domaincapstest_LDADD.

It may happen that a developer wants to run just a specific
subset of tests:

tests $ VIR_TEST_RANGE=22 ../run ./virschematest

This now fails miserably:

    ==6840== Invalid read of size 8
    ==6840==    at 0x4F397C0: virXMLValidatorValidate (virxml.c:1216)
    ==6840==    by 0x402B72: testSchemaFile (virschematest.c:53)
    ==6840==    by 0x403737: virTestRun (testutils.c:180)
    ==6840==    by 0x402CF5: testSchemaDir (virschematest.c:98)
    ==6840==    by 0x402EB1: testSchemaDirs (virschematest.c:131)
    ==6840==    by 0x40314D: mymain (virschematest.c:194)
    ==6840==    by 0x4051AF: virTestMain (testutils.c:982)
    ==6840==    by 0x4035A9: main (virschematest.c:217)
    ==6840==  Address 0x10 is not stack'd, malloc'd or (recently) free'd

Problem is, we are trying to do two types of tests here: validate
RNG schema itself, and validate XML files against RNG schemas.
And the latter tries to re-use a resource allocated in the
former. Therefore if the former is skipped (due to
VIR_TEST_RANGE) we have to allocate the resource manually.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

When the user doesn't specify any model for a USB controller,
we use an architecture-dependent default, but we don't reflect
it in the guest XML.

Pick the default USB controller model when parsing the guest
XML instead of when creating the QEMU command line, so that
our choice is saved back to disk.

==8630== Invalid read of size 8
==8630==    at 0x4EA4F0F: virFree (viralloc.c:582)
==8630==    by 0x4F398F0: virXMLValidatorFree (virxml.c:1257)
==8630==    by 0x40305C: mymain (virschematest.c:191)
==8630==    by 0x405159: virTestMain (testutils.c:982)
==8630==    by 0x403553: main (virschematest.c:215)
==8630==  Address 0xcd72243 is 131 bytes inside a block of size 177 free'd
==8630==    at 0x4C2B1F0: free (vg_replace_malloc.c:473)
==8630==    by 0x4EA4F19: virFree (viralloc.c:582)
==8630==    by 0x4ED0973: virFindFileInPath (virfile.c:1646)
==8630==    by 0x405149: virTestMain (testutils.c:980)
==8630==    by 0x403553: main (virschematest.c:215)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

On UNIX like systems there are no constraints on what characters
can be in file/dir names (except for NULL, obviously). Moreover,
some values that we think of as paths (e.g. disk source) are not
necessarily paths at all. For instance, some hypervisors take
that as an arbitrary identifier and corresponding file is then
looked up by hypervisor in its table. Instead of trying to fix
our regular expressions (and forgetting to include yet another
character there), lets drop the validation completely.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

More misunderstanding/mistaken assumptions on my part - I had thought
that a pci-expander-bus could be plugged into any legacy PCI slot, and
that pcie-expander-bus could be plugged into any PCIe slot. This isn't
correct - they can both be plugged ontly into their respective root
buses. This patch adds that restriction.

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

libvirt had allowed a dmi-to-pci-bridge to be plugged in anywhere a
normal PCIe endpoint can be connected, but this is wrong - it will
only work if it's plugged into pcie-root (the PCIe root complex) or a
pcie-expander-bus (the qemu device pxb-pcie). This patch adjusts the
connection flags accordingly.

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

Since the introduction of CMT features (commit v1.3.5-461-gf294b83e)
starting a domain with host-model CPU on a host which supports CMT fails
because QEMU complains about unknown 'cmt' feature:

    qemu-system-x86_64: CPU feature cmt not found

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

The generated command line wouldn't work since QEMU doesn't know what
'cmt' is. The following patch will fix this issue.

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

Doing a load, copy, format cycle on all QEMU capabilities XML files
should make sure we don't forget to update virQEMUCapsNewCopy when
adding new elements to QEMU capabilities.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>