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

If a secret was not provided for what was determined to be a LUKS
encrypted disk (during virStorageFileGetMetadata processing when
called from qemuDomainDetermineDiskChain as a result of hotplug
attach qemuDomainAttachDeviceDiskLive), then do not attempt to
look it up (avoiding a libvirtd crash) and do not alter the format
to "luks" when adding the disk; otherwise, the device_add would
fail with a message such as:

   "unable to execute QEMU command 'device_add': Property 'scsi-hd.drive'
    can't find value 'drive-scsi0-0-0-0'"

because of assumptions that when the format=luks that libvirt would have
provided the secret to decrypt the volume.

Access to unlock the volume will thus be left to the application.

Currently, bhyvexml2xmltest does only one test. We can do better.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the next patch we will need a stable mac address for
<interface/>.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

After c07d1c1c got merged it uncovered couple of broken domain
XMLs for bhyvexml2argv test. Some disk drives had incompatible
type of address configured.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

After 478ddedc a bug is fixed where we wrongly presumed loopack
device name on non-Linux systems. It's lo0. However, the fix is
not reflected in the tests which are failing now.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

If the nss module is disabled we don't need to build the
supplementary library for it either.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

If the nss module is disabled we shouldn't run the tests that
include it either.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The plugin depends on more modules than we currently check for,
i.e. network driver and yajl library.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the Makefile in tests/ we initialize couple of variables like
test_programs, test_libraries and test_helpers. These variables
contain all the targets that we need to build in order to run
the test suite. So we initialize test_programs and test_helpers
and then conditionally add targets to them depending on what we
are building with. Then we repeat the same process with
test_libraries. It makes no sense to have two separate if-endif
sequences.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Since the internal implementation relies on a json parser being
available, it make no sense to run this test if there's none
available.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Due to nature of operations we do over the string list (more
precisely due to how virStringListRemove() works), it is not the
best idea to use dataFree callback. Problem is, on MAC address
remove, the string list remove function modifies the original
list in place. Then, virHashUpdateEntry() is called which frees
all the data stored in the list rendering @newMacsList point to
freed data.

==16002== Invalid read of size 8
==16002==    at 0x50BC083: virFree (viralloc.c:582)
==16002==    by 0x513DC39: virStringListFree (virstring.c:251)
==16002==    by 0x51089B4: virMacMapHashFree (virmacmap.c:67)
==16002==    by 0x50EF30B: virHashAddOrUpdateEntry (virhash.c:352)
==16002==    by 0x50EF4FD: virHashUpdateEntry (virhash.c:415)
==16002==    by 0x5108BED: virMacMapRemoveLocked (virmacmap.c:129)
==16002==    by 0x51092D5: virMacMapRemove (virmacmap.c:346)
==16002==    by 0x402F02: testMACRemove (virmacmaptest.c:107)
==16002==    by 0x403F15: virTestRun (testutils.c:180)
==16002==    by 0x4032C4: mymain (virmacmaptest.c:205)
==16002==    by 0x405A3B: virTestMain (testutils.c:992)
==16002==    by 0x403D87: main (virmacmaptest.c:237)
==16002==  Address 0xdd5a4d0 is 0 bytes inside a block of size 24 free'd
==16002==    at 0x4C2AD6F: realloc (vg_replace_malloc.c:693)
==16002==    by 0x50BB99B: virReallocN (viralloc.c:245)
==16002==    by 0x513DC0B: virStringListRemove (virstring.c:235)
==16002==    by 0x5108BA6: virMacMapRemoveLocked (virmacmap.c:124)
==16002==    by 0x51092D5: virMacMapRemove (virmacmap.c:346)
==16002==    by 0x402F02: testMACRemove (virmacmaptest.c:107)
==16002==    by 0x403F15: virTestRun (testutils.c:180)
==16002==    by 0x4032C4: mymain (virmacmaptest.c:205)
==16002==    by 0x405A3B: virTestMain (testutils.c:992)
==16002==    by 0x403D87: main (virmacmaptest.c:237)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In virMacMapRemoveLocked() we have two variables: @macsList and
@newMacsList. Obviously, @newMacsList is supposed to hold pointer
to modified list but in fact it holds pointer to the old list.
It's confusing.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

7fa7fe22 updated gnulib to the latest upstream commit,
but forgot to include the corresponding bootstrap changes.

Required for the copyright year bump to keep 'make syntax-check'
happy, and also pulls in several portability fixes.

* .gnulib: Update to latest.
* bootstrap: Resync from upstream.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

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

Add the description for <physical>... One is a new feature - the API
and the other is an improvement for the volume xml output.

A CT disk statistics is reported with prefix "hdd" and we should use
it to extract data.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

Before, boot devices information for CTs was always empty and we
didn't indicate that containers can boot from disk.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

Virtuozzo SDK interface doesn't differ filesystems from disks and sees them as disks.
Before, we always mistakenly presented disks based on files as filesystems, which is
not completely correct. Now we are going to show either disks or filesystems depending
on a hint, which uses boot device section of VZ config. Though this information
doesn't change booting order of a CT, it is used by vz libvirt interface as a hint
for libvirt representation of disks. Since now, if we have filesystems in input xml,
then we add them to VZ booting devices list and rely on this information to show
corresponding libvirt xml.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

Implicit devices like controllers are confusing for CTs and
function virDomainDefAddImplicitDevices never intended to be called
for CTs.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

This is necessary to show CTs created out of libvirt correctly.
Signed-off-by: NMaxim Nestratov <mnestratov@virtuozzo.com>

This tests uses preload, which should work on any ELF-based platform
(and indeed it passes on Linux, GNU/kFreeBSD, and FreeBSD).

Also remove the WITH_DBUS conditional, as the test is already built
based on that conditional.

LIBVIRT_ARG_WITH_ALT is more generic than LIBVIRT_ARG_WITH, which
is tailored at switching features on and off.

Rename the macros according to their intended purpose, and add
some documentation to help developers pick between the two.

They're not just used, or supposed to be just used, for
library-related arguments, so they deserve to have their
own separate file.

Commit 943ddcb7 partially fixed this bug in gnutls configure code.
However we also need to backup and modify CFLAGS and do if for
AC_CHECK_HEADERS as well.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Sigh, autoconf has AC_CHECK_FUNC and AC_CHECK_FUNCS and both check
whether some function exists or not.  However in addition to the obvious
difference that the later is able to check multiple functions it also
defines HAVE_FUNCTION_NAME for each function.

Commit 680d2f49 moved the code to separate file, but also blindly
changed the macro to AC_CHECK_FUNC without confronting the
documentation.
Reported-by: NJohn Ferlan <jferlan@redhat.com>

<https://www.redhat.com/archives/libvir-list/2016-December/msg01086.html>
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Introduced by commit 25034b3c and reused by commit 4519e94b.
This patch silences warning printed by configure:

  configure: WARNING: unrecognized options: --with-qemu-user
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The bug was introduced by commit 08c2d148.  The string must be quoted
because it is used as function argument.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

virQEMUCapsSupportsChardev existing checks returns true
for spapr-vty alone. Instead verify spapr-vty validity
and let the logic to return true for other device types
so that virtio-console passes.

The non-pseries machines dont have spapr-vio-bus. So, the
function always returned false for them before.

Fixes - https://bugzilla.redhat.com/show_bug.cgi?id=1257813Signed-off-by: NShivaprasad G Bhat <sbhat@linux.vnet.ibm.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Signed-off-by: NPavel Hrdina <phrdina@redhat.com>