https://bugzilla.redhat.com/show_bug.cgi?id=1019053
(cherry picked from commit e3ef20d7)

Conflicts:
  missing support for changing migration listen address
	src/qemu/qemu.conf
	src/qemu/qemu_conf.h
	src/qemu/test_libvirtd_qemu.aug.in

If qemuParseCommandLine finds an arg it does not understand
it adds it to the QEMU passthrough custom arg list. If the
qemuParseCommandLine method hits an error for any reason
though, it just does 'VIR_FREE(cmd)' on the custom arg list.
This means all actual args / env vars are leaked. Introduce
a qemuDomainCmdlineDefFree method to be used for cleanup.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

On my machine, a guest fails to boot if it has a sound card, but not
graphical device/display is configured, because pulseaudio fails to
initialize since it can't access $HOME.

A workaround is removing the audio device, however on ARM boards there
isn't any option to do that, so -nographic always fails.

Set QEMU_AUDIO_DRV=none if no <graphics> are configured. Unfortunately
this has massive test suite fallout.

Add a qemu.conf parameter nographics_allow_host_audio, that if enabled
will pass through QEMU_AUDIO_DRV from sysconfig (similar to
vnc_allow_host_audio)

Following XML would fail :

    <disk type='network' device='lun'>
      <driver name='qemu' type='raw'/>
      <source protocol='iscsi' name='iqn.2013-07.com.example:iscsi/1'>
        <host name='example.com' port='3260'/>
      </source>
      <target dev='sda' bus='scsi'/>
    </disk>

With the message:

error: Failed to start domain iscsilun
error: Unable to get device ID 'iqn.2013-07.com.example:iscsi/1': No such fi

Cause was commit id '1f49b05a' which added 'virDomainDiskSourceIsBlockType'

Both virStoragePoolFree and virStorageVolFree reset the last error,
which might lead to the cryptic message:
An error occurred, but the cause is unknown

When the volume wasn't found, virStorageVolFree was called with NULL,
leading to an error:
invalid storage volume pointer in virStorageVolFree

This patch changes it to:
Storage volume not found: no storage vol with matching name 'tomato'

During qemuTranslateDiskSourcePool() execution, if the srcpool has been
defined with authentication information, then for iSCSI pools copy the
authentication and host information to virDomainDiskDef.

The difference with already supported pool types (dir, fs, block)
is: there are two modes for iscsi pool (or network pools in future),
one can specify it either to use the volume target path (the path
showed up on host) with mode='host', or to use the remote URI qemu
supports (e.g. file=iscsi://example.org:6000/iqn.1992-01.com.example/1)
with mode='direct'.

For 'host' mode, it copies the volume target path into disk->src. For
'direct' mode, the corresponding info in the *one* pool source host def
is copied to disk->hosts[0].

Introduce a new helper to check if the disk source is of block type

Convert the type of loop iterators named 'i', 'j', k',
'ii', 'jj', 'kk', to be 'size_t' instead of 'int' or
'unsigned int', also santizing 'ii', 'jj', 'kk' to use
the normal 'i', 'j', 'k' naming
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Just like previous patches, this changes qemuCheckSharedDisk
into qemuCheckSharedDevice, which takes a virDomainDeviceDefPtr
argument instead.

Just like what previous patches do, it refactors qemuSetUnprivSGIO
to take the virDomainDeviceDefPtr as argument instead.

unpriv_sgio setting is tight with the shared device helpers, let's
put them together in qemu_conf.c

SCSI host device will also support "sgio", and perhaps we could
use "sgio" in other places too in future, renaming the enum to
reuse.

This changes the helpers qemu{Add,Remove}SharedDisk into
qemu{Add,Remove}SharedDevice, as most of the code in the helpers
can be reused for scsi host device.

To track the shared scsi host device, first it finds out the
device path (e.g. /dev/s[dr]*) which is mapped to the sg device,
and use device ID of the found device path (/dev/s[dr]*) as the
hash key. This is because of the device ID is not unique between
between /dev/s[dr]* and /dev/sg*, e.g.

% sg_map
/dev/sg0  /dev/sda
/dev/sg1  /dev/sr0

% ls -l /dev/sda
brw-rw----. 1 root disk 8, 0 May  2 19:26 /dev/sda

%ls -l /dev/sg0
crw-rw----. 1 root disk 21, 0 May  2 19:26 /dev/sg0

"Shared disk" is not only the thing we should care about after "scsi
hostdev" is introduced. A same scsi device can be used as "disk" for
one domain, and as "scsi hostdev" for another domain at the same time.
That's why this patch renames qemu_driver->sharedDisks. Related functions
and structs are also renamed.

Adding a VNC WebSocket support for QEMU driver.  This functionality is
in upstream qemu from commit described as v1.3.0-982-g7536ee4, so the
capability is being recognized based on QEMU version for now.

The source code base needs to be adapted as well. Some files
include virutil.h just for the string related functions (here,
the include is substituted to match the new file), some include
virutil.h without any need (here, the include is removed), and
some require both.

After 78d7c3c5 we are strdup()-ing path to qemu-bridge-helper.
However, the check for its return value is missing. So it is
possible we've ignored the OOM error silently.

Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>

Since the source is already translated before. This just adds the
checking. Move !disk->shared and !disk->src to improve the performance
a bit.

To support "shareable" for volume type disk, we have to translate
the source before trying to add the shared disk entry. To achieve
the goal, this moves the helper qemuTranslateDiskSourcePool into
src/qemu/qemu_conf.c, and introduce an internal only member (voltype)
for struct _virDomainDiskSourcePoolDef, to record the underlying
volume type for use when building the drive string.

Later patch will support "shareable" volume type disk.

Currently when getting an instance of virCgroupPtr we will
create the path in all cgroup controllers. Only at the virt
driver layer are we attempting to filter controllers. This
is bad because the mere act of creating the dirs in the
controllers can have a functional impact on the kernel,
particularly for performance.

Update the virCgroupForDriver() method to accept a bitmask
of controllers to use. Only create dirs in the controllers
that are requested. When creating cgroups for domains,
respect the active controller list from the parent cgroup
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Use the qemu specific callback to fill this data in the qemu driver as
it's the only place where it was used and fix tests as the qemu test
capability object didn't configure the defaults for the tests.

This patch removes the defaultDiskDriverName from the virCaps
structure. This particular default value is used only in the qemu driver
so this patch uses the recently added callback to fill the driver name
if it's needed instead of propagating it through virCaps.

This patch implements the devices post parse callback and uses it to fill
the default qemu network card model into the XML if none is specified.

Libvirt assumes that the network card model for qemu is the "rtl8139".
Record this in the XML using the new callback to avoid user
confusion.

This patch adds instrumentation that will allow hypervisor drivers to
fill and validate domain and device definitions after parsed by the XML
parser.

With this patch, after the XML is parsed, a callback to the driver is
issued requesting to fill and validate driver specific details of the
configuration. This allows to use sensible defaults and checks on a per
driver basis at the time the XML is parsed.

Two callback pointers are stored in the new virDomainXMLConf object:
* virDomainDeviceDefPostParseCallback (devicesPostParseCallback)
  - called for a single device parsed and for every single device in a
    domain config. A virDomainDeviceDefPtr is passed along with the
    domain definition and virCaps.

* virDomainDefPostParseCallback, (domainPostParseCallback)
  - A callback that is meant to process the domain config after it's
  parsed.  A virDomainDefPtr is passed along with virCaps.

Both types of callbacks support arbitrary opaque data passed for the
callback functions.

Errors may be reported in those callbacks resulting in a XML parsing
failure.

This patch is the result of running:

for i in $(git ls-files | grep -v html | grep -v \.po$ ); do
  sed -i -e "s/virDomainXMLConf/virDomainXMLOption/g" -e "s/xmlconf/xmlopt/g" $i
done

and a few manual tweaks.

The virCaps structure gathered a ton of irrelevant data over time that.
The original reason is that it was propagated to the XML parser
functions.

This patch aims to create a new data structure virDomainXMLConf that
will contain immutable data that are used by the XML parser. This will
allow two things we need:

1) Get rid of the stuff from virCaps

2) Allow us to add callbacks to check and add driver specific stuff
after domain XML is parsed.

This first attempt removes pointers to private data allocation functions
to this new structure and update all callers and function that require
them.

At least one caller may call qemuSharedDiskEntryFree with NULL as the
first argument. Let's make the function similar to other *Free functions
and do nothing in such case.

Commit f506a4c1 changed virSetUIDGID() to be a noop
when uid/gid are -1, while it used to be a noop when
they are <= 0.

The changes in this commit broke creating new VMs in GNOME Boxes
as qemuDomainCheckDiskPresence gets called during domain creation/startup,
which in turn calls virFileAccessibleAs which fails after calling
virSetUIDGID(0, 0) (Boxes uses session libvirtd). virSetUIDGID is called with
(0, 0) as these are the default user/group values in virQEMUDriverConfig
for session libvirtd.

This commit changes virQEMUDriverConfigNew to use -1 as the unpriviledged
uid/gid. I've also looked at the various places where cfg->user is used,
and they all seem to handle -1 correctly.

There is a lock ordering problem in the QEMU close callback
APIs.

When starting a guest we have a lock on the VM. We then
set a autodestroy callback, which acquires a lock on the
close callbacks.

When running auto-destroy, we obtain a lock on the close
callbacks, then run each callbacks - which obtains a lock
on the VM.

This causes deadlock if anyone tries to start a VM, while
autodestroy is taking place.

The fix is to do autodestroy in 2 phases. First obtain
all the callbacks and remove them from the list under
the close callback lock. Then invoke each callback
from outside the close callback lock.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The virQEMUCloseCallbacksRunOne method was passing a uuid string
to virDomainObjListFindByUUID, when it actually expected to get
a raw uuid buffer. This was not caught by the compiler because
the method was using a 'void *uuid' instead of first casting
it to the expected type.

This regression was accidentally caused by refactoring in

  commit 568a6cda
  Author: Jiri Denemark <jdenemar@redhat.com>
  Date:   Fri Feb 15 15:11:47 2013 +0100

    qemu: Avoid deadlock in autodestroy
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Change the error label to "error" and simplify some error paths.

Since closeCallbacks were turned into virObjectLockable, we can no
longer call virQEMUCloseCallbacks APIs from within a registered close
callback.