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

Since commit v1.0.5-56-g449e6b1b (Pull parsing of migration xml up into
QEMU driver APIs) any attempt to rename a domain during migration fails
with the following error message:

    internal error Incoming cookie data had unexpected name DOM vs DOM2

This is because migration cookies always use the original domain name
and the mentioned commit failed to propagate the name back to
qemuMigrationPrepareAny.

The @qemunbd variable can be used uninitialized.

The @profile_name variable can be used uninitialized.

Change source file copyright notice to prevailing libvirt style.

Similar to the QEMU and LXC drivers, add a helper function to
lookup a domain, and use it instead of much copy and paste.

Now that most fields of libxlDriverPrivate struct are immutable
or self-locking, there is no need to acquire the driver lock in
much of the libxl driver.

Move the libxl driver lock/unlock functions from libxl_driver.c
to libxl_conf.h so they can be used by other source files.

Similar to the QEMU and LXC drivers, annotate the fields of
libxlDriverPrivate struct to indicate the locking rules for
their use.

The libxlDriverPrivate struct contains an variety of data with
varying access needs. Similar to the QEMU and LXC drivers,
move all the static config data into a dedicated libxlDriverConfig
object. The only locking requirement is to hold the driver lock
while obtaining an instance of libxlDriverConfig. Once a reference
is held on the config object, it can be used completely lockless
since it is immutable.

libxlDomainGetInfo() uses the driver-wide libxl ctx when
it would be more appropriate to use the per-domain ctx
associated with the domain.  Switch to using the per-domain
libxl ctx.

libxlMakeDomCreateInfo() uses the driver-wide libxl ctx when
it would be more appropriate to use the per-domain ctx
associated with the domain.  Switch to using the per-domain
libxl ctx.

libxl version info is static data as far as the libxl driver
is concerned, so retrieve this info when the driver is initialized
and stash it in the libxlDriverPrivate object.  Subsequently use
the stashed info instead of repeatedly calling libxl_get_version_info().

Detect early on in libxl driver initialization if the driver
should be loaded at all, avoiding needless initialization steps
that only have to be undone later.  While at it, move the
detection to a helper function to improve readability.

After detecting that the driver should be loaded, subsequent
failures such as initializing the log stream, allocating libxl
ctx, etc. should be treated as failure to initialize the driver.

Create libxl_domain.[ch] and move all functions operating on
libxlDomainObjPrivate to these files.  This will be useful for
future patches that e.g. add job support for libxlDomainObjPrivate.

Detecting whether or not to autoballoon is configuration related,
so move the code to libxl_conf.

Bug introduced in commit 5c6ff422; 'make dist' fails:

make[3]: Entering directory `/home/eblake/libvirt-tmp/build3/examples/python'
make[3]: *** No rule to make target `topoology.py', needed by `distdir'.  Stop.
make[3]: Leaving directory `/home/eblake/libvirt-tmp/build3/examples/python'

* examples/python/Makefile.am (EXTRA_DIST): Spell topology right.
Signed-off-by: NEric Blake <eblake@redhat.com>

New Coverity release found a couple of error paths where memory would be
leaked in an error/goto path before being properly handled.

New coverity installation determined that the muliple if condition for
"*Alloc" and "*AppendToList" could fail during AppendToList thus leaking
memory.

The test should refer to Virtlockd.lns, which is the name of
the module + lens in virtlockd.aug.

Add a demo script originally written by Amador Pahim to parse topology
of the host from data provided in the capabilities XML.

Man page for signal states:

 "The effects of signal() in a multithreaded process are unspecified."

Switch signal() to sigaction in virsh console code.

Move the function to virsh.c to the rest of the TTY managing functions
and change the code so that it mirrors the rest.

Currently, kernel supports up to 8 queues for a multiqueue tap device.
However, if user tries to enter a huge number (e.g. one million) the tap
allocation fails, as expected. But what is not expected is the log full
of warnings:

    warning : virFileClose:83 : Tried to close invalid fd 0

The problem is, upon error we iterate over an array of FDs (handlers to
queues) and VIR_FORCE_CLOSE() over each item. However, the array is
pre-filled with zeros. Hence, we repeatedly close stdin. Ouch.
But there's more. The queues allocation is done in virNetDevTapCreate()
which cleans up the FDs in case of error. Then, its caller, the
virNetDevTapCreateInBridgePort() iterates over the FD array and tries to
close them too. And so does qemuNetworkIfaceConnect() and
qemuBuildInterfaceCommandLine().

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

The vshWatchJob function registers a SIGINT handler that is used to
abort the active job and does not terminate virsh. Unfortunately, this
breaks when using the ssh transport as SIGINT is sent to the foreground
process group including the ssh transport processes which terminate.
This breaks the connection and migration is left in a insane state.

With this patch the terminal is modified to ignore key binding that
sends SIGINT and does the handling manually.

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

This patch adds instrumentation to allow modification of config of the
terminal in virsh and successful reset of the state afterwards.

The added helpers allow to disable receiving of SIGINT when pressing the
key sequence (Ctrl+C usualy). This normally sends SIGINT to the
foreground process group which kills ssh processes used for transport of
the data.

According to VMWare's documentation 'cdrom-raw' is an acceptable value
for deviceType for a CD-ROM drive. The documentation states that the VMX
configuration for a CD-ROM deviceType is as follows:

ide|scsi(n):(n).deviceType = "cdrom-raw|atapi-cdrom|cdrom-image"

From the documentation it appears the following is true:
- cdrom-image = Provides the ISO to the VM
- atapi-cdrom = Provides a NEC emulated ATAPI CD-ROM on top of the host
  CD-ROM
- cdrom-raw = Passthru for a host CD-ROM drive. Allows CD-R burning from
  within the guest.

A CD-ROM prior to this patch would always provide an 'atapi-cdrom' is
modeled as:
  <disk type='block' device='cdrom'>
    <source dev='/dev/scd0'/>
    <target dev='hda' bus='ide'/>
    <address type='drive' controller='0' bus='0' target='0' unit='0'/>
  </disk>

This patch allows the 'device' attribute to be set to 'lun' for a raw
acccess CD-ROM such as:
  <disk type='block' device='lun'>
    <source dev='/dev/scd0'/>
    <target dev='hda' bus='ide'/>
    <address type='drive' controller='0' bus='0' target='0' unit='0'/>
  </disk>

Sometimes a serial port might not be actually wired to a device when the
user does not have the VM powered on and we should not consider this a
fatal error.

Starting with qemu 1.6, the qemu-system-arm vexpress-a9 model has a
hardcoded virtio-mmio transport which enables attaching all virtio
devices.

On the command line, we have to use virtio-XXX-device rather than
virtio-XXX-pci, thankfully s390 already set the precedent here so
it's fairly straight forward.

At the XML level, this adds a new device address type virtio-mmio.
The controller and addressing don't have any subelements at the
moment because we they aren't needed for this usecase, but could
be added later if needed.

Add a test case for an ARM guest with one of every virtio device
enabled.

Similar to the chardev bit, ARM boards depend on the old style '-net nic'
for actually instantiating net devices. But we can't block out
-netdev altogether since it's needed for upcoming virtio support.

And add tests for working ARM XML with console, disk, and networking.

This corresponds to '-sd' and '-drive if=sd' on the qemu command line.
Needed for many ARM boards which don't provide any other way to
pass in storage.

QEMU ARM boards don't give us any way to explicitly wire in
a -chardev, so use the old style -serial options.

Unfortunately this isn't as simple as just turning off the CHARDEV flag
for qemu-system-arm, as upcoming virtio support _will_ use device/chardev.

And add test cases for a basic working ARM guest.

This should be a no-op change for now.

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)

This gives us a RO got, otherwise Debian's lintian complains:

W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_qemu.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_storage.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_uml.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_vbox.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_xen.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_nwfilter.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_storage.so
W: libvirt-bin: hardening-no-relro usr/lib/libvirt/connection-driver/libvirt_driver_uml.so
W: libvirt-sanlock: hardening-no-relro usr/lib/libvirt/lock-driver/sanlock.so