In particular I was forgetting to take the qemuMonitorPrivatePtr
lock (via qemuDomainObjBeginJob), which would cause problems
if two users tried to access the same domain at the same time.
This patch also fixes a problem where I was forgetting to remove
a transient domain from the list of domains.

Thanks to Stephen Shaw for pointing out the problem and testing
out the initial patch.
Signed-off-by: NChris Lalancette <clalance@redhat.com>

With JSON qemu monitor, we get a STOP event from qemu whenever qemu
stops guests CPUs. The downside of it is that vm->state is changed to
PAUSED and a new generic paused event is send to applications. However,
when we ask qemu to stop the CPUs we are not really interested in qemu
event and we usually want to issue a more specific event.

By setting vm->status to PAUSED before actually sending the request to
qemu (and resetting it back if the request fails) we can ignore the
event since the event handler does nothing when the guest is already
paused. This solution is quite hacky but unfortunately it's the best
solution which I was able to come up with and it doesn't introduce a
race condition.

While doing some testing of the snapshot code I noticed that
if qemuDomainSnapshotLoad failed, it would print a NULL as
part of the error.  That's not desirable, so leave the
full_path variable around until after we are done printing
errors.
Signed-off-by: NChris Lalancette <clalance@redhat.com>

Cygwin has mntent.h but lacks getmntent_r. Update preprocessor
checks to catch this combination.

It's not needed and is currently ignored, but this is a bug.

It will get fixed soon and QMP will return an error for keys
it doesn't know about, this will break libvirt.

* src/qemu/qemu_monitor_json.c: remove qemuMonitorJSONCommandAddTimestamp()
  and the place where it's invoked in qemuMonitorJSONMakeCommand()

* The error messages coming from qemu's DAC support contain strings
  from the original SELinux security driver code.  This just removes
  references to "security context" and other SELinux-isms from the DAC
  code.
Signed-off-by: NSpencer Shimko <sshimko@tresys.com>
Signed-off-by: NEric Blake <eblake@redhat.com>

The hang fix in d376b7d6 was incomplete
since it left quite a few {Enter,Exit}Monitor calls which require driver
to be unlocked. Since the driver is locked throughout the whole
function, {Enter,Exit}MonitorWithDriver need to be used instead to
ensure driver is not locked when issuing monitor commands.

The comment in qemuDomainWaitForMigrationComplete says we are polling
every 50ms but the code sleeps only for 50us. This was already discussed
during review but apparently forgotten when the series was pushed.

The text monitor code was checking for a '\n' prefix on several
places. Previously this would work, but since the monitor code
re-write the '\n' is already stripped off, so mustn't be checked
for.

* src/qemu/qemu_monitor_text.c: Fix monitor error checking

Probably as a result of a merge error, the CPU hotplug command
names were completely wrong.

* src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_text.c: Fix
  the CPU hotplug command names

Adds ability to provide a preferred CPU model for CPUID data decoding.
Such model would be considered as the best possible model (if it's
supported by hypervisor) regardless on number of features which have to
be added or removed for describing required CPU.

So far, when CPUID data were converted into CPU model and features, the
features can only be added to the model. As a result, when a guest asked
for something like "qemu64,-svm" it would get a qemu32 plus a bunch of
additional features instead.

This patch adds support for removing feature from the base model.
Selection algorithm remains the same: the best CPU model is the model
which requires lowest number of features to be added/removed from it.

Qemu committed a patch which list some CPU names in [] when asked for
supported CPUs (qemu -cpu ?). Yet, it needs such CPUs to be passed
without those square braces. When probing for supported CPU models, we
can just strip the square braces and pretend we have never seen them.

First, inital VCPU pinning is set correctly but then it is reset by
assigning qemu process to a new cgroup (which contains all CPUs). It's
easily fixed by swapping these two actions.

Fixes http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578347

The initial boot of VMs uses -device for NICs where available. The
corresponding monitor command is device_add, but the network hotplug
code was still using device_del by mistake.

* src/qemu/qemu_driver.c: Use device_add for NIC hotplug where
  available

If either of the getfd or host_net_add monitor commands return
any text, this indicates an error condition. Don't ignore this!

* src/qemu/qemu_monitor_text.c: Report errors for getfd and
  host_net_add

The 'device_del' command expects a parameter called 'id' but we
were passing 'config'.

* src/qemu/qemu_monitor_json.c: Fix device_del command parameter

Disk devices in QEMU have two parts, the guest device and the host
backend driver. Historically these two parts have had the same
"unique" name. With the switch to using -device though, they now
have separate names. Thus when changing CDROM media, for guests
using -device syntax, we need to prepend the QEMU_DRIVE_HOST_PREFIX
constant

* src/qemu/qemu_conf.c, src/qemu/qemu_conf.h: Add helper function
  qemuDeviceDriveHostAlias() for building a host backend alias
* src/qemu/qemu_driver.c: Use qemuDeviceDriveHostAlias() to determine
  the host backend alias for performing eject/change commands in the
  monitor

The device_add command was added in JSON mode in a way I didn't
expect. Instead of passing the normal device string to the JSON
command:

    { "execute": "device_add", "arguments": { "device": "ne2k_pci,id=nic.1,netdev=net.1" } }

We need to split up the device string into a full JSON object

    { "execute": "device_add", "arguments": { "driver": "ne2k_pci", "id": "nic.1", "netdev": "net.1" } }

* src/qemu/qemu_conf.h, src/qemu/qemu_conf.c: Rename the
  qemuCommandLineParseKeywords method to qemuParseKeywords
  and export it to monitor
* src/qemu/qemu_monitor_json.c: Split up device string into
  a JSON object for device_add command

The parameter for the qemuMonitorDeviceDel() is a device alias,
not a device config string. Rename the parameter reflect this
and avoid confusion to readers.

* src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h,
  src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_json.h,
  src/qemu/qemu_monitor_text.c, src/qemu/qemu_monitor_text.h:
  Rename devicestr to devalias in qemuMonitorDeviceDel()

The QEMU developers have stated that they will not be porting
the commands 'pci_add', 'pci_del', 'usb_add', 'usb_del' to the
JSON mode monitor, since they're obsoleted by 'device_add'
and 'device_del'. libvirt has (untested) code that would have
supported those commands in theory, but since we already use
device_add/del where available, there's no need to keep the
legacy stuff anymore.

The text mode monitor keeps support for all commands for sake
of historical compatability.

* src/qemu/qemu_monitor_json.c: Remove 'pci_add', 'pci_del',
  'usb_add', 'usb_del' commands

The QEMU driver is mistakenly calling directly into the text
mode monitor for the domain memory stats query.

* src/qemu/qemu_driver.c: Replace qemuMonitorTextGetMemoryStats with
  qemuMonitorGetMemoryStats
* src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h: Add the new
  wrapper for qemuMonitorGetMemoryStats
* src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_json.h: Add
  qemuMonitorJSONGetMemoryStats implementation

Instead of reporting VIR_ERR_INTERNAL_ERROR use the more specific
VIR_ERR_CONFIG_UNSUPPORTED

* src/qemu/qemu_conf.c: Report VIR_ERR_CONFIG_UNSUPPORTED for
  unsupported video adapters

To avoid race-conditions, the tear down of a filter has to happen before
the tap interface disappears and another tap interface with the same
name can re-appear. This patch tries to fix this. In one place, where
communication with the qemu monitor may fail, I am only tearing the
filters down after knowing that the function did not fail.

I am also moving the tear down functions into an include file for other
drivers to reuse.

* src/qemu/qemu_driver.c (qemudDomainAttachSCSIDisk):
Initialize "cont" to NULL, so clang knows it's set.
Add an sa_assert so it knows it's non-NULL when dereferenced.

* Dan Kenigsberg requested explicit support for the qemu default disk error policy which is enospace

In a couple of cases typos meant we were firing the wrong type
of event. In the python code my previous commit accidentally
missed some chunks of the code.

* python/libvirt-override-virConnect.py: Add missing python glue
  accidentally left out of previous commit
* src/conf/domain_event.c, src/qemu/qemu_monitor_json.c: Fix typos
  in event name / method name to invoke

Currently when we attempt to change the cdrom in a qemu VM the monitor
doesn't generate an error if the target filename doesn't exist.  I've
submitted a patch[1] for this.  This patch is the libvirt qemu-driver
side which catches the error message from the monitor and reportes the
error to libvirt.  This means that virsh attach-disk cdrom commands
won't appear to succeed when qemu change command actually failed.

* src/qemu/qemu_monitor_text.c: in qemuMonitorTextChangeMedia() look
  for failure to access the new data

* src/qemu/qemu_driver.c (qemudDomainGetSecurityLabel): Remove store
and declaration.

There's no sense in advertising cpuselection capability when host CPU
is not properly detected and advertised in host capabilities.

When qemu libvirt driver doesn't support guest CPU selection with given
qemu binary, guests requiring specific CPU should fail to start instead
of being silently supplied with a default CPU.

* src/qemu/qemu_driver.c (qemuDomainSnapshotLoad): Remove dead store
into "snap", as well as its declaration.

* src/qemu/qemu_driver.c (qemudStartVMDaemon): Initialize "logfile"
to ensure that we don't use it uninitialized -- thus closing an
arbitrary file descriptor -- in the cleanup block.

Also rename ReportError to macvtapError.

and domainIsPersistent.
Signed-off-by: NChris Lalancette <clalance@redhat.com>

When starting up qemu VNC autoport guests, we were
only looking through ports 5900 to 6000, meaning we
were limited to 100 total clients.  Increase that
limit to 65535 (the last available port), so we can
have up to 59635 VNC autoport guests.
Signed-off-by: NChris Lalancette <clalance@redhat.com>