A user was having an issue with this specific VMWare Fusion config and
he gave me permission to add it as part of our test suite to further
expand our VMX test coverage. Unfortunately our VMX parser and
generator does not support many features contained within and just
silently ignores fields it does not understand so they had to
be removed out in the xml2vmx test. The original unmodified version
exists in the vmx2xml test.

VMWare Fusion 5 can set the CD-ROM's device name to be 'auto detect' when
using the physical drive via 'cdrom-raw' device type. VMWare will then
connect to first available host CD-ROM to the virtual machine upon start
up according to VMWare documentation. If no device is available, it
appears that the device will remain disconnected.

To better model this a CD-ROM that is marked as "auto detect" when in
the off state would be modeled as the following with this patch:
  <disk type='block' device='lun'>
    <source startupPolicy='optional'/>
    <target dev='hda' bus='ide'/>
    <address type='drive' controller='0' bus='0' target='0' unit='0'/>
  </disk>

Once the domain transitions to the powered on state, libvirt can
populate the remaining source data with what is connected, if anything.
However future power cycles, the domain may not always start with that
device attached.

Currently the XML parser already allows the following syntax:
  <disk type='block' device='cdrom'>
    <source startupPolicy='optional'/>
    <target dev='hda' bus='ide'/>
    <address type='drive' controller='0' bus='0' target='0' unit='0'/>
  </disk>

But it if the dev value is NULL then it would not have the leading
"<source ", resulting in invalid XML.

A cross build to mingw fails with:

  CC       virsystemdtest-virsystemdtest.o
../../tests/virsystemdtest.c: In function 'testCreateNoSystemd':
../../tests/virsystemdtest.c:97:9: error: implicit declaration of function 'unsetenv' [-Werror=implicit-function-declaration]
         unsetenv("FAIL_NO_SERVICE");
         ^
../../tests/virsystemdtest.c:97:9: error: nested extern declaration of 'unsetenv' [-Werror=nested-externs]

We could cop out and pull in the gnulib unsetenv module.  But when
you stop and think about it, this test requires LD_PRELOAD to work,
and systemd is a Linux-only concept anyways, both of which mean
the test could never work on mingw in the first place.  Simpler is
to just fix the test to behave like our other LD_PRELOAD tests.

* tests/virsystemdtest.c: Provide non-Linux implementation.
Signed-off-by: NEric Blake <eblake@redhat.com>

Commit f92c7e31 fixed a regression for native builds, but introduced
a regression for cross-compilation builds; in particular,
./autobuild.sh on a Fedora system with mingw cross-compiler fails
with:

checking for qemu-kvm... /usr/bin/qemu-kvm
checking for yajl_parse_complete in -lyajl... no
checking for yajl_tree_parse in -lyajl... no
configure: error: You must install the libyajl library & headers to compile libvirt

Since we default $with_qemu to 'yes' rather than 'check', and then
flip that default based on platform-specific checks, those platform
specifics need to come prior to any library checks that depend on
the value of $with_qemu.

* configure.ac: Ensure system defaults are sane before checking
for things that make decisions based on system default.
Signed-off-by: NEric Blake <eblake@redhat.com>

* .gitignore: Ignore metadatatest.
Signed-off-by: NEric Blake <eblake@redhat.com>

Use the helper added in previous patch to quiesce errors from this test
that was spamming logs on normal test runs.

Multiple tests need to register a function to quiesce errors from
libvirt when using a connection and doing negative tests. Each of those
tests had a static function to do so. This can be replaced by a utility
function that enables the errors when debug is enabled.

This patch adds virtTestQuiesceLibvirtErrors() and refactors test that
use private handlers.

qemu/KVM also supports a tftp URL while specifying the cdrom ISO image.

The xml should be as following:

    <disk type='network' device='cdrom'>
      <source protocol='tftp' name='/url/path'>
        <host name='host.name' port='69'/>
      </source>
    </disk>
Signed-off-by: NAline Manera <alinefm@br.ibm.com>

The ftps protocol is another protocol supported by qemu/KVM while specifying
the cdrom ISO image.

The xml should be as following:

    <disk type='network' device='cdrom'>
      <source protocol='ftps' name='/url/path'>
        <host name='host.name' port='990'/>
      </source>
    </disk>
Signed-off-by: NAline Manera <alinefm@br.ibm.com>

The https protocol is also accepted by qemu/KVM when specifying the cdrom ISO
image.

The xml should be as following:

    <disk type='network' device='cdrom'>
      <source protocol='https' name='/url/path'>
        <host name='host.name' port='443'/>
      </source>
    </disk>
Signed-off-by: NAline Manera <alinefm@br.ibm.com>

Some systems apparently have a global variable/function called remove
and thus break compilation of virsh-domain.c. Rename the variable to
avoid this.

Reported by GuanQiang.

GCC 4.8.0+ whines about variable "new" being uninitialized since
commit 73bfac0e. This is a false positive as the
xmlFreeNode(new) statement can be only reached if new was actually
allocated successfully.

  CC       conf/libvirt_conf_la-domain_conf.lo
  conf/domain_conf.c: In function 'virDomainDefSetMetadata':
  conf/domain_conf.c:18650:24: error: 'new' may be used uninitialized in this function [-Werror=maybe-uninitialized]
               xmlFreeNode(new);

Reported independently by John Ferlan and Michal Privoznik.

Commit 073e1575 tried to set things up so that 1) generated files
to be shipped in the tarball always live in srcdir, and 2) we have
no files in SOURCES that depend on any other files with a literal
$(srcdir) in the name, because that situation can cause confusing
results for the make expansion of $@ depending on whether the file
is found locally or via VPATH.  But all my testing for that patch
was done incrementally, where all the protocol.[ch] files had
already been generated prior to the patch and were up-to-date in
the srcdir, and thus I missed one case where $@ causes grief in a
VPATH build from a fresh checkout:

We have a pattern rule for generating remote_protocol.[ch], and
what's more, the rule for protocol.c depends on protocol.h AND
on the protocol.x file.  The pattern for protocol.c is only
satisfied via the VPATH lookup for protocol.x, and if protocol.h
doesn't yet exist, the VPATH rule kicks in and we end up with a
dependency on a file with $(srcdir) in the name.  Based on make's
rules for $@, this resulted in make building remote_protocol.h
into srcdir (where we want it), then remote_protocol.c into
builddir (oops, not so good for the tarball), and also causes
the build to fail (the compiler can't find the .h if it lives
in a different directory than the .c):

  CC       remote/libvirt_driver_remote_la-remote_protocol.lo
remote/remote_protocol.c:7:29: fatal error: remote_protocol.h: No such file or directory
 #include "remote_protocol.h"
                             ^
compilation terminated.

As before, the fix is to hard-code the output file to go into
srcdir in spite of $@; but since this is in a pattern rule, we
are forced to use $@ in the recipe, so the patch is a bit
trickier than what was done in commit 073e1575.

* src/Makefile.am (%protocol.c, %protocol.h): Force output to srcdir.
Signed-off-by: NEric Blake <eblake@redhat.com>

Eric Blake suggested that we could do a little better in case copying of
the metadata to be set fails. With this patch, the old metadata is
discarded after the new string is copied successfuly.

If the ABI compatibility check with the "migratable" user XML is
successful, we would leak the originally parsed XML from the user that
would not be used in this case.

Reported by Ján Tomko.

This test exercises the virDomain[Get|Set]Metadata API and tests it for
regressions

virDomainSetMetadata when operating on the metadata element was
requesting the @key argument to be passed even if @metadata was NULL
used to delete the corresponding metadata element. This is not needed as
the key is only used when adding the element and matching is done via
the XML namespace.

The functionality wasn't originally implemented. This patch adds the
ability to modify domain's XML metadata using the API.

The virDomainGetMetadata function was designed to support also retrieval
of app specific metadata from the <metadata> element. This functionality
was never implemented originally.

The metadata modification functions will support modification of the XML
metadata. Add a virsh command to allow using this approach.

The code to set the metadata in a domain definition is common to live
and inactive domains. Factor it out into a common func.

The function implemented common behavior that can be reused for other
hypervisor drivers that use the virDomainObj data structures. Factor out
the core into a separate helper func.

The function implemented common behavior that can be reused for other
hypervisor drivers that use the virDomainObj data structures. Factor out
the core into a separate helper func.

Line up the array so that the grid is visible.

The "cmd" variable is actually used so remove the attribute.

In the original implementation of external checkpoints I've mistakenly
used the live definition to be stored in the save image. The normal
approach is to use the "migratable" definition. This was discovered when
commit 07966f6a changed the behavior to
use a converted XML from the user to do the compatibility check to fix
problem when using the regular machine saving.

As the previous patch added a compatibility layer, we can now change the
type of the XML in the image.

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

External checkpoints have a bug in the implementation where they use the
normal definition instead of the "migratable" one. This causes errors
when the snapshot is being reverted using the workaround method via
qemuDomainRestoreFlags() with a custom XML. This issue was introduced
when commit 07966f6a changed the code to
compare "migratable" XMLs from the user as we should have used
migratable in the image too.

This patch adds a compatibility layer, so that fixing the snapshot code
won't make existing snapshots fail to load.

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

What should be checked here is xmlbuf rather than buf.

CD-ROMs and Floppies are allowed to have no source to imply they are
empty or disconnected. Since the LUN type is used for raw CD-ROM access
with QEMU (and VMWare in the future), it also needs to allow an empty
source when the raw CD-ROM device is disconnected from the domain.

qemuMigrationEatCookie has flags to control if these should
be parsed, but it does not fill mig->flags. These cookies might
get leaked if these flags are not set by qemuMigrationBakeCookie.

42 (32 direct, 10 indirect) bytes in 1 blocks are definitely lost in
loss record 361 of 662
==123== by 0x1BA33FCA: qemuMigrationEatCookie (qemu_migration.c:678)
==123== by 0x1BA34A1E: qemuMigrationRun (qemu_migration.c:3108)
==123== by 0x1BA3622B: doNativeMigrate (qemu_migration.c:3343)
==123== by 0x1BA3B408: qemuMigrationPerform (qemu_migration.c:4138)

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

1,003 bytes in 1 blocks are definitely lost in loss record 599 of 635
==404== by 0x50728A7: virBufferAddChar (virbuffer.c:185)
==404== by 0x50BC466: virSystemdEscapeName (virsystemd.c:67)
==404== by 0x50BC6B2: virSystemdMakeSliceName (virsystemd.c:108)
==404== by 0x50BC870: virSystemdCreateMachine (virsystemd.c:169)
==404== by 0x5078267: virCgroupNewMachine (vircgroup.c:1498)

I spent far too long on a new machine trying to figure out why
./autobuild.sh failed due to an rpm build failure (complaining
that libvirt_parthelper was supposed to be packaged but was not
built), and finally traced it to a missing parted-devel
installation.  I learned that --nodeps is in place for
autobuilder setups, but for developers, removing it would make
rpmbuild error out much sooner for a less cryptic failure.

* autobuild.sh: Conditionally drop --nodeps from rpmbuild lines.
Signed-off-by: NEric Blake <eblake@redhat.com>

Bother those kernel developers.  In the latest rawhide, kernel
and glibc have now been unified so that <netinet/in.h> and
<linux/in6.h> no longer clash; but <linux/if_bridge.h> is still
not self-contained.  Because of the latest header change, the
build is failing with:

checking for linux/param.h... no
configure: error: You must install kernel-headers in order to compile libvirt with QEMU or LXC support

with details:

In file included from conftest.c:561:0:
/usr/include/linux/in6.h:71:18: error: field 'flr_dst' has incomplete type
  struct in6_addr flr_dst;

We need a workaround to avoid our workaround :)

* configure.ac (NETINET_LINUX_WORKAROUND): New test.
* src/util/virnetdevbridge.c (includes): Use it.
Signed-off-by: NEric Blake <eblake@redhat.com>

The function existed in two identical instances in lxc and qemu. Move it
to vircgroup.c and simplify it. Refactor the callers too.

Semantics of the libvirt helper are more clear. This change also allows
to clean up some pieces of code.