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.

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

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

Along with the legacy URI based syntax add support for the brand-new
fully object based syntax.

http(s), ftp(s) and tftp use URIs for volume definitions in the JSON
pseudo protocol so it's pretty straightforward to add support for them.

JSON pseudo protocol for qemu allows to explicitly specify devices.
Add convertor to the internal type.

Add a modular parser that will allow to parse 'json' backing definitions
that are supported by qemu. The initial implementation adds support for
the 'file' driver.

Due to the approach qemu took to implement the JSON backing strings it's
possible to specify them in two approaches.

The object approach:
    json:{ "file" : { "driver":"file",
                      "filename":"/path/to/file"
                    }
         }

And a partially flattened approach:
    json:{"file.driver":"file"
          "file.filename":"/path/to/file"
         }

Both of the above are supported by qemu and by the code added in this
commit. The current implementation de-flattens the first level ('file.')
if possible and required. Other handling may be added later but
currently only one level was possible anyways.

As we already test that the extraction of the backing store string works
well additional tests for the backing store string parser can be made
simpler.

Export virStorageSourceNewFromBackingAbsolute and use it to parse the
backing store strings, format them using virDomainDiskSourceFormat and
match them against expected XMLs.

This function doesn't follow our convention of naming functions.

This function doesn't follow our convention of naming functions.

This function doesn't follow our convention of naming functions.

This function doesn't follow our convention of naming functions.

This an ubuntu/debian packaging convention. At one point it may have
been an actually different binary, but at least as of ubuntu precise
(the oldest supported ubuntu distro, released april 2012) kvm-img is
just a symlink to qemu-img for back compat.

I think it's safe to drop support for it

If a storage file would be backed with a NBD device without path
(nbd://localhost) libvirt would crash when parsing the backing path for
the disk as the URI structure's path element is NULL in such case but
the NBD parser would access it shamelessly.

I'm going to add a few test cases so it's the best time to convert the
test to automatic numbering.

As we now have a common function to parse backing store string for RBD
backing store we can reuse it in the backing store walker so that we
don't fail on files backed by RBD storage.

This patch also adds a few tests to verify that the parsing works as
expected.

To be able to fully test parsing of networked storage strings we need to
add a few fields for: hostname, protocol and auth string.

The code that parses the schema from the URI touches the "hosts[0]"
member of the storage file source structure in case the URI contains a
schema. The hosts array was not yet allocated at the point in the code
where the transport protocol was parsed and set. This lead to a crash of
libvirtd.

Fix the code by allocating the "hosts" array upfront and add a test case
to verify this scenario. (Unfortunately this requires shuffling the test
case numbers too).

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

Add a new parameter to virStorageFileGetMetadata that will break the
backing chain detection process and report useful error message rather
than having to use virStorageFileChainGetBroken.

This patch just introduces the option, usage will be provided
separately.

Instead of just returning the parent path, return the complete parent
source structure.

The parent directory doesn't necessarily need to be stored after we
don't mangle the path stored in the image. Remove it and tweak the code
to avoid using it.

Store backing chain paths as non-canonical. The canonicalization step
will be already taken. This will allow to avoid storing unnecessary
amounts of data.

After we don't test relative paths, remove even more unnecessary cruft
from the test code.

libvirt always uses an absolute path to address the top image of an
image chain. Our storage test tests also the relative path which won't
ever be used. Additionally it makes the test more complicated.

Now that we store only relative names in virStorageSource's member
relPath the backingRelative member is obsolete. Remove it and adapt the
code to the removal.

Separately remove the now unused variable.

Due to various refactors and compatibility with the virstoragetest the
relPath field of the virStorageSource structure was always filled either
with the relative name or the full path in case of absolutely backed
storage. Return its original purpose to store only the relative name of
the disk if it is backed relatively and tweak the tests.

Now that we changed ordering of the stored metadata so that the backing
store is described by the child element the test should reflect this
change too.

Remove the expected backing store field as it's actually described by
the next element in the backing chain, so there's no need for
duplication.

This patch introduces a function that will allow us to resolve a
relative difference between two elements of a disk backing chain. This
function will be used to allow relative block commit and block pull
where we need to specify the new relative name of the image to qemu.

This patch also adds unit tests for the function to verify that it works
correctly.

Commit 2cff94cc fixed the shadowed 'link' added by commit 975f0e2e,
but forgot the 'link' added by commit 08aa22ec.

Introduce a common function that will take a callback to resolve links
that will be used to canonicalize paths on various storage systems and
add extensive tests.

The block commit code looks for an explicit base file relative
to the discovered top file; so for a chain of:
  base <- snap1 <- snap2 <- snap3
and a command of:
  virsh blockcommit $dom vda --base snap2 --top snap1
we got a sane message (here from libvirt 1.0.5):
error: invalid argument: could not find base 'snap2' below 'snap1' in chain for 'vda'

Meanwhile, recent refactoring has slightly reduced the quality of the
libvirt error messages, by losing the phrase 'below xyz':
error: invalid argument: could not find image 'snap2' in chain for 'snap3'

But we had a one-off, where we were not excluding the top file
itself in searching for the base; thankfully qemu still reports
the error, but the quality is worse:
  virsh blockcommit $dom vda --base snap2 --top snap2
error: internal error unable to execute QEMU command 'block-commit': Base '/snap2' not found

Fix the one-off in blockcommit by changing the semantics of name
lookup - if a starting point is specified, then the result must
be below that point, rather than including that point.  The only
other call to chain lookup was blockpull code, which was already
forcing the lookup to omit the active layer and only needs a
tweak to use the new semantics.

This also fixes the bug exposed in the testsuite, where when doing
a lookup pinned to an intermediate point in the chain, we were
unable to return the name of the parent also in the chain.

* src/util/virstoragefile.c (virStorageFileChainLookup): Change
semantics for non-NULL startFrom.
* src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Adjust caller,
to keep existing semantics.
* tests/virstoragetest.c (mymain): Adjust to expose new semantics.
Signed-off-by: NEric Blake <eblake@redhat.com>

Add some more tests of what happens when we restrict a lookup
to begin at a point in the middle of a chain.  In particular,
we want to ensure that a parent is not found when starting at
the child.  This commit also demonstrates that we have a slight
difference in behavior on what parent we report when filtering
is in effect; as the determination of the parent affects the
code in block commit, exposing this in the testsuite will help
justify changes in future patches that tweak the semantics of
what lookups are allowed.

* tests/virstoragetest.c (testStorageLookup): Test user input.
(TEST_LOOKUP_TARGET): Add parameter.
(mymain): Add lookup tests.
Signed-off-by: NEric Blake <eblake@redhat.com>

The next patch will be adding tests, including adding a parameter
for testing more conditions.  For ease of review of that patch, I
want to create common context lines that don't change when the new
tests are added (it's easier to visually review additions than it
is to review an entire chunk of tests rewritten into another
larger chunk of tests).

* tests/virstoragetest.c (mymain): Add a parameter and renumber
the lookup tests.
Signed-off-by: NEric Blake <eblake@redhat.com>

Typing chain->backingStore->backingStore gets old after a while;
introduce some alias variables to make the test more compact.

* tests/virstoragetest.c (mymain): Introduce some shorthand.
Signed-off-by: NEric Blake <eblake@redhat.com>

When the test is failing but the debug output isn't enabled the
resulting line would look ugly like and would not contain the actual
difference.

TEST: virstoragetest
      .................chain member 1!chain member 1!chain member 1!

Store the member index in the actual checked string to hide this problem

All the fields crammed into two lines weren't easy to parse by human
eyes. Split up the format string into lines and put it into a central
variable so that changes in two places aren't necessary.

Use the new backing store parser in the backing chain crawler. This
change needs one test change where information about the NBD image are
now parsed differently.

Stat the path of the storage file being tested to set the correct type
into the virStorageSource. This will avoid breaking the test suite when
inquiring metadata of directory paths in the next patches.