This doesn't add very much value for now, but future test for virresctrl will
take information from vircaps2xmldata (since it is dependent on the same info
then why duplicate it) and this particular use case helps us cover bit more of
the code regarding proper formatting and handling errors.  And one more test for
vircaps2xmltest doesn't hurt either.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This patch modifies some not yet used test data so that the adding a test using
this data is a clean patch and not an addition of huge file with some
adjustments in small files that will be hidden in the middle of that commit.
These changes include:

- Add system dir in vircaps2xmldata/linux-caches

  Back when data for systems with resctrl support were added they had the
  /sys/fs/system directory put into a system/ subdir of the test and
  /sys/fs/resctrl in a resctrl/ subdir of that test.  However, if we also want a
  negative test for the resctrl (requesting allocation on a system that does not
  support resctrl), we need one a test case with any sensible (with cache info)
  system/ subdir and no resctrl/ one.  Easiest way is to add a
  system -> . symlink into existing test case.

- Change default group schemata for linux-resctrl and linux-resctrl-cdp

  That way we can fit some allocation in.

- Remove one cache from resctrl-skx's schemata and make some room for
  allocations

  That system already has only one cache, so that file was wrong anyway.  We
  have a version with 2 caches already (linux-resctrl-skx-twocaches), so this
  will also add variety to future tests.

- Add some empty allocation for resctrl-skx

  Just to have slightly more coverage and variety.  We can be sure nothing bad
  happens if such allocation exists in case we have that in the tests.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Because the cache banks are initialized based on the order in which their
respective directories exist on the filesystem, they can appear in different
order.  This is here mainly for tests because the cache directory might have
different order of children nodes and tests would fail otherwise.  It should not
be the case with sysfs, but one can never be sure.  And this does not take
almost any extra time, mainly because it gets initialized once per driver.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Sometimes the size of the bitmap matters and it might not be guessed correctly
when parsing from some type of input.  For example virBitmapNewData() has Byte
granularity, virBitmapNewString() has nibble granularity and so on.
virBitmapParseUnlimited() can be tricked into creating huge bitmap that's not
needed (e.g.: "0-2,^99999999").  This function provides a way to shrink the
bitmap.  It is not supposed to free any memory.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Already introduced in the past with 9479642f, but then renamed to
virBitmapIntersect by a908e9e4.  This time we'll really use it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Our bitmaps can be represented as data (raw bytes for which we have
virBitmapNewData() and virBitmapToData()), human representation (list
of numbers in a string for which we have virBitmapParse() and
virBitmapFormat()) and hexadecimal string (for which we have only
virBitmapToString()).  So let's add the missing complement for the
last one so that we can parse hexadecimal strings.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Truncate the output so that it is only as big as is needed to fit all
the bits, not all the units from the map.  This will be needed in the
future in order to properly format bitmaps for kernel's sysfs files.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

It is literally only a wrapper around virBitmapNewData() and
virBitmapFormat(), only the naming was wrong since it was introduced.
And because we have virBitmap*String functions where the meaning of
the 'String' is constant, this might confuse someone.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This follows the virBitmapToData() function and, similarly to
virBitmapNewData(), we'll be able to have virBitmapNewString() later
on without name confusion.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

We can't output better memory sizes if we want to be compatible with libvirt
older than the one which introduced /memory/unit, but for new things we can just
output nicer capacity to the user if available.  And this function enables that.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Currenty virTestInit() outputs all capabilities that it created when running
with VIR_TEST_DEBUG=1.  Since this is quite a lot of output for every call of
this function (and it is not needed until debugging a really deep-down issue)
let's just output the info when VIR_TEST_DEBUG is strictly greater than 1.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

If _CFLAGS for a binary is not specified it uses AM_CFLAGS.  So doing

  $binary_CFLAGS = $(AM_CFLAGS)

or

  $binary_CFLAGS = $(AM_CFLAGS) $(something_that_is_already_in_AM_CFLAGS)

is pointless.  So remove it for cleaner Makefile.am
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Since update to glibc-2.26 removed the /usr/include/rpc/rpc.h we used until now,
it showed us a problem with not using XDR_CFLAGS properly.  On linux that
variable has usually -I/usr/include/tirpc because we already probe for it
properly, we just don't use it everywhere we need.  It is needed by wireshark
dissector as well as testutilsqemu.c (through includes) so the build fails with:

wireshark/src/packet-libvirt.c:33:10: fatal error: rpc/xdr.h: No such file or directory
 #include <rpc/xdr.h>
          ^~~~~~~~~~~

and

In file included from ../src/logging/log_manager.h:29:0,
                 from ../src/qemu/qemu_domain.h:40,
                 from testutilsqemu.c:11:
../src/logging/log_protocol.h:9:10: fatal error: rpc/rpc.h: No such file or directory
 #include <rpc/rpc.h>
          ^~~~~~~~~~~

Since lot of tests use testutilsqemu.c it is easier to add XDR_CFLAGS to
AM_CFLAGS than adding it to all $binary_CFLAGS.  It's just for tests and we
already have bunch of CFLAGS there anyway.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Commit 03d0959a introduced a compilation error in
src/xenconfig/xen_xl.c on ARM. Found by Xen's osstest

http://logs.test-lab.xenproject.org/osstest/logs/116216/build-armhf-libvirt/6.ts-libvirt-build.log

While we have collective knowledge about the support status of various
parts of libvirt, this has never been formally documented, leaving our
users to guess.

Note, this document makes one change to our previous policy. It explicitly
declares the RPC protocol of libvirtd as being a supported interface. THis
accepts the reality that we can a) never change it without breaking compat
with old libvirt.so, b) there are both rust + go impls that are written
against the RPC protocol already.
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJim Fehlig <jfehlig@suse.com>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The XML namespace URI for the QEMU/LXC drivers must use http as the protocol
otherwise it won't match the parser's expectations.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Resolve a storage driver crash as a result of a long running
storageVolCreateXML when the virStorageVolPoolRefreshThread is
run as a result of when a storageVolUpload completed and ran the
virStoragePoolObjClearVols without checking if the creation
code was currently processing a buildVol after incrementing
the driver->asyncjob count.

The refreshThread will now check the pool asyncjob count before
attempting to pursue the pool refresh. Adjust the documentation
to describe the condition.

Crash from valgrind is as follows (with a bit of editing):

==21309== Invalid read of size 8
==21309==    at 0x153E47AF: storageBackendUpdateVolTargetInfo
==21309==    by 0x153E4C30: virStorageBackendUpdateVolInfo
==21309==    by 0x153E52DE: virStorageBackendVolRefreshLocal
==21309==    by 0x153DE29E: storageVolCreateXML
==21309==    by 0x562035B: virStorageVolCreateXML
==21309==    by 0x147366: remoteDispatchStorageVolCreateXML
...
==21309==  Address 0x2590a720 is 64 bytes inside a block of size 336 free'd
==21309==    at 0x4C2F2BB: free
==21309==    by 0x54CB9FA: virFree
==21309==    by 0x55BC800: virStorageVolDefFree
==21309==    by 0x55BF1D8: virStoragePoolObjClearVols
==21309==    by 0x153D967E: virStorageVolPoolRefreshThread
...
==21309==  Block was alloc'd at
==21309==    at 0x4C300A5: calloc
==21309==    by 0x54CB483: virAlloc
==21309==    by 0x55BDC1F: virStorageVolDefParseXML
==21309==    by 0x55BDC1F: virStorageVolDefParseNode
==21309==    by 0x55BE5A4: virStorageVolDefParse
==21309==    by 0x153DDFF1: storageVolCreateXML
==21309==    by 0x562035B: virStorageVolCreateXML
==21309==    by 0x147366: remoteDispatchStorageVolCreateXML
...

This is similar to the virDomainQemuMonitorCommand API, it can change
the domain state in a way that libvirt may not understand.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The 'set-lifcycle-action' is throwing a weird error after executing it with
the '--help' option. The command output is showing the options 'type' and
'action' are as optional, but they aren't. Both are required.

virsh # set-lifecycle-action --help
...
  SYNOPSIS
    set-lifecycle-action <domain> [--type <string>] [--action <string>] ...
...
  OPTIONS
    [--domain] <string>  domain name, id or uuid
error: internal error: bad options in command: 'set-lifecycle-action'

After applying this patch, both arguments are required now.

virsh # set-lifecycle-action --help
...
  SYNOPSIS
    set-lifecycle-action <domain> <type> <action> [--config] ...

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1509870Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

We need to call it anyway, so the else branch is redundant here.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

We put the server into a hash table as we do with the other daemons,
there is no compelling reason why it should have another pointer
dedicated just to the server. Besides, the locking daemon doesn't have
it and virtlogd is essentially a copy paste of virtlockd.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

In the definition of virHookQemuOpType and virHookNetworkOpType,
we should use 'stopped' rather than 'shutdown'.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Most of the time it's okay to leave this up to negotiation between
the guest and the host, but in some situations it can be useful to
manually decide the behavior, especially to enforce its availability.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1308743Signed-off-by: NAndrea Bolognani <abologna@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Some compilers may get confused and decide we are calling strcmp with
NULL argument from test_virCapsDomainDataLookupLXC. Although this does
not really happen since the call is guarded with
(data->machinetype != expect_machinetype), using STRNEQ_NULLABLE is
easier to understand, less fragile, and doing so makes sure strcmp is
never called with NULL argument.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Add two new entries under new features for 3.10.0. One
advertising support for specifying distance between vNUMA cells
and another advertising Xen's support for vNUMA configuration.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>
Reviewed-by: NPavel Hrdina <phrdina@redhat.com>

Reword the message and drop the numbers (which were reversed) from it
so that it actually makes sense.

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

Setup everything related to disks in one place rather than calling in
from various places.

The change to ordering of the setup steps is necessary since secrets
need the master key to be present.

In some cases it does not make sense to pursue that the private data
will be allocated (especially when we don't need to put anything in it).

Ensure that the code works without it.

This also fixes few crashes pointed out in
https://bugzilla.redhat.com/show_bug.cgi?id=1510323

Use virDomainDiskDefNew instead of VIR_ALLOC in
qemuParseCommandLineDisk.

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

If creation of the main JSON object containing the storage portion of a
virStorageSource would fail but we'd allocate the server structure we'd
leak it. Found by coverity.

Return NULL right away in qemuBlockStorageSourceGetBackendProps when an
invalid storage source is presented so that virJSONValueObjectAdd isn't
called with a NULL argument.

Found by coverity.

The terminator would not be parsed properly since the XPath selector was
looking for an populated element, and also the code did not bother
assigning the terminating virStorageSourcePtr to the backingStore
property of the parent.

Some tests would catch it if there wasn't bigger fallout from the change
to backing store termination in a693fdba. Fix them properly now.

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