If a value of the first level object contains more objects needing
deflattening which would be wrapped in an actual object the function
would not recurse into them.

By this simple addition we can fully deflatten the objects.

As it turns out sometimes users pass in an arbitrarily nested structure
e.g. for the qemu backing chains JSON pseudo protocol. This new
implementation deflattens now a single object fully even with nested
keys.

Additionally it's not necessary now to stick with the "file." prefix for
the properties.

Add a few test cases to verify that the old behaviour does not break and
that new one behaves sanely.

Currently the function would deflatten the object by dropping the 'file'
prefix from the attributes. This does not really scale well or adhere to
the documentation.

Until we refactor the worker to properly deflatten everything we at
least simulate it by adding the "file" wrapper object back.

The code will become more universal so it makes more sense for it to
live with the rest of the JSON functions.

Allows testing whether a virJSONValue is an object.

Users may want to run the init command of a container as a special
user / group. This is achieved by adding <inituser> and <initgroup>
elements. Note that the user can either provide a name or an ID to
specify the user / group to be used.

This commit also fixes a side effect of being able to run the command
as a non-root user: the user needs rights on the tty to allow shell
job control.
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

Some containers may want the application to run in a special directory.
Add <initdir> element in the domain configuration to handle this case
and use it in the lxc driver.
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

virCommand is a version of virExec that doesn't fork, however it is
just calling execve and doesn't honors setting uid/gid and pwd.

This commit extrac those pieces from virExec() to a virExecCommon()
function that is called from both virExec() and virCommandExec().

When running an application container, setting environment variables
could be important.

The newly introduced <initenv> tag in domain configuration will allow
setting environment variables to the init program.
Reviewed-by: NDaniel P. Berrange <berrange@redhat.com>

All of these four functions (virStreamRecvAll, virStreamSendAll,
virStreamSparseRecvAll, virStreamSparseSendAll) take one or more
callback functions that handle various aspects of streams.
However, if any of them fails no error is reported therefore
caller does not know what went wrong.

At the same time, we silently presumed callbacks to set errno on
failure. With this change we should document it explicitly as the
error is not properly reported.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

If one these four functions fail (virStreamRecvAll,
virStreamSendAll, virStreamSparseRecvAll, virStreamSparseSendAll)
the stream is aborted by calling virStreamAbort(). This is  a
public API; therefore, the first thing it does is error reset. At
that point any error that caused us to abort stream in the first
place is gone.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Our documentation to the virStreamRecvAll, virStreamSendAll,
virStreamSparseRecvAll, and virStreamSparseSendAll functions
indicates that if these functions fail, then virStreamAbort is
called. But that is not necessarily true. For instance all of
these functions allocate a buffer to work with. If the allocation
fails, no virStreamAbort() is called despite -1 being returned.
It's the same story with argument sanity checks and a lot of
other checks.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Problem with our error reporting is that the error object is a
thread local variable. That means if there's an error reported
within the I/O thread it gets logged and everything, but later
when the event loop aborts the stream it doesn't see the original
error. So we are left with some generic error. We can do better
if we copy the error message between the threads.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

When the I/O thread quits (e.g. due to an I/O error, lseek()
error, whatever), any subsequent virFDStream API should return
error too. Moreover, when invoking stream event callback, we must
set the VIR_STREAM_EVENT_ERROR flag so that the callback knows
something bad happened.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This is only used in qemu_command.c, so move it, and clarify that
it's really about identifying if the serial config is a platform
device or not.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Some qemu arch/machine types have built in platform devices that
are always implicitly available. For platform serial devices, the
current code assumes that only old style -serial config can be
used for these devices.

Apparently though since -chardev was introduced, we can use -chardev
in these cases, like this:

  -chardev pty,id=foo
  -serial chardev:foo

Since -chardev enables all sorts of modern features, use this method
for platform devices.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Every qemu version we support has QEMU_CAPS_CHARDEV, so stop
explicitly tracking it and blacklist it like we've done for many
other feature flags.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Several tests are intending to test some serial/console related
bits but aren't setting QEMU_CAPS_CHARDEV. This will soon be enabled
unconditionally so let's add it ahead of time.

* q35-virt-manager-basic: Intended to test a virt-manager q35 config,
    which will include a serial/console device
* console-compat*: console/serial XML compat handling
* bios: Needs a serial device for sgabios CLI
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

These tests are exercising old style -serial command lines. That
code will soon be removed, so drop these tests.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Several cases have incidental <serial> or <console> XML which aren't
the features being tested for. Upcoming changes will cause some
churn here, so instead drop these bits now.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

AFAIK there aren't any cases where we will/should hit the old code
path for our supported qemu versions, so drop the old code.

Massive test suite churn follows
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

AFAIK there aren't any cases where we should fail these checks with
supported qemu versions, so just drop them.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

AFAIK there aren't any qemu arch/machine types with platform parallel
devices that would require old style -parallel config, so we shouldn't
ever need this nowadays.

Remove a now redundant test
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

This demonstrates that the previous qemu caps changes will use
-chardev for pci-serial on aarch64 machvirt
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

Rather than try to whitelist all device configs that can't use
-chardev, blacklist the only one that really can't, which is the
default serial/console target type=isa case.

ISA specifically isn't a valid config for arm/aarch64, but we've
always implicitly treated it to mean 'default platform device'.
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>
Signed-off-by: NCole Robinson <crobinso@redhat.com>

While looking to implement a migrate-getmaxdowntime command (coming),
I noticed that the setmaxdowntime is incorrectly looking at its
parameter as a signed longlong. Not sure how that got past gcc, but
here's a simple patch to make the command line parsing and the parameter to
the worker functions all have the correct (unsigned) type.
Signed-off-by: NScott Garfinkle <seg@us.ibm.com>

This removes the classical XSS vulnerability of using unquoted
PHP_SELF.
Reported-by: NJohn Lightsey <john@nixnuts.net>
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

vcpu properties gathered from query-hotpluggable cpus need to be passed
back to qemu. As qemu did not use the node-id property until now and
libvirt forgot to pass it back properly (it was parsed but not passed
around) we did not honor this.

This patch adds node-id to the structures where it was missing and
passes it around as necessary.

The test data was generated with a VM with following config:
    <numa>
      <cell id='0' cpus='0,2,4,6' memory='512000' unit='KiB'/>
      <cell id='1' cpus='1,3,5,7' memory='512000' unit='KiB'/>
    </numa>

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

This error message refers to the lack of network, not to yajl.
Signed-off-by: NPino Toscano <ptoscano@redhat.com>

The command 'domdisplay' is not freeing the domain pointer properly in
cleanup section. See the error below:

virsh # domdisplay WINDOWS7
vnc://127.0.0.1:0

virsh # quit

error: One or more references were leaked after disconnect from the hypervisor

Valgrind report:

==29168== 66 (56 direct, 10 indirect) bytes in 1 blocks are definitely lost in loss record 154 of 239
==29168==    at 0x4C2FB55: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==29168==    by 0x5505324: virAllocVar (viralloc.c:560)
==29168==    by 0x555A61B: virObjectNew (virobject.c:199)
==29168==    by 0x561F367: virGetDomain (datatypes.c:284)
==29168==    by 0x5680979: get_nonnull_domain (remote_driver.c:8143)
==29168==    by 0x5680979: remoteDomainLookupByName (remote_client_bodies.h:3047)
==29168==    by 0x5623D9A: virDomainLookupByName (libvirt-domain.c:425)
==29168==    by 0x160480: virshLookupDomainInternal (virsh-util.c:59)
==29168==    by 0x160547: virshCommandOptDomainBy (virsh-util.c:98)
==29168==    by 0x13D3A9: cmdDomDisplay (virsh-domain.c:10963)
==29168==    by 0x165680: vshCommandRun (vsh.c:1327)
==29168==    by 0x12E320: main (virsh.c:953)
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

There are no occurrences of tests related to Strings and Double numbers
inside virstringtest.c. This commit introduces some tests to validate the
conversion. The test does not include locale changes yet.
Signed-off-by: NJulio Faracco <jcfaracco@gmail.com>

Introduces support for virDomainSetMemory. This also serves an an
example for how to use the new method invocation API with a more
complicated method, this time including an EPR and embedded param.

This commit adds support for virDomainSendKey. It also serves as an
example of how to use the new method invocation APIs with a single
"simple" type parameter.

This commit adds support for invoking methods on remote objects
via hypervInvokeMethod.

Update the generator to generate basic property type information for
each CIM object representation. Right now, it generates arrays of
hypervCimType structs:

struct _hypervCimType {
    const char *name;
    const char *type;
    bool isArray;
};

This commit introduces functionality for creating and working with
invoke parameters. This commit does not include any code for serializing
and actually performing the method invocations; it merely defines the
functions and API for using invocation parameters in driver code.

HYPERV_DEFAULT_PARAM_COUNT was chosen because almost no method
invocations have more than 4 parameters.

Functions added:
* hypervInitInvokeParamsList
* hypervFreeInvokeParams
* hypervAddSimpleParam
* hypervAddEprParam
* hypervCreateEmbeddedParam
* hypervSetEmbeddedProperty
* hypervAddEmbeddedParam
* hypervFreeEmbeddedParam