Moreover, since virAsprintf now does report OOM error, there's no need
to call virReportOOMError in error path.

When virAsprintf was changed from a function to a macro
reporting OOM error in dc6f2dad, it was documented as returning
0 on success. This is incorrect, it returns the number of bytes
written as asprintf does.

Some of the functions were converted to use virAsprintf's return
value directly, changing the return value on success from 0 to >= 0.

For most of these, this is not a problem, but the change in
virPCIDriverDir breaks PCI passthrough.

The return value check in virhashtest pre-dates virAsprintf OOM
conversion.

vmwareMakePath seems to be unused.

Merge the virCommandPreserveFD / virCommandTransferFD methods
into a single virCommandPasFD method, and use a new
VIR_COMMAND_PASS_FD_CLOSE_PARENT to indicate their difference
in behaviour
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

In all qemu APIs we tend to prefer qemuDomObjFromDomain over
virDomainObjListFindByUUID. But somehow the
qemuDomainGetSchedulerType left unattended.

Introduced in commit 24b08219; compilation on RHEL 6.4 complained:
qemu/qemu_hotplug.c: In function 'qemuDomainAttachChrDevice':
qemu/qemu_hotplug.c:1257: error: declaration of 'remove' shadows a global declaration [-Wshadow]
/usr/include/stdio.h:177: error: shadowed declaration is here [-Wshadow]

* src/qemu/qemu_hotplug.c (qemuDomainAttachChrDevice): Avoid the
name 'remove'.
Signed-off-by: NEric Blake <eblake@redhat.com>

A part of the returned monitor response was freed twice and caused
crashes of the daemon when using guest agent cpu count retrieval.

 # virsh vcpucount dom --guest

Introduced in v1.0.6-48-gc6afcb05

Implement the new API that will handle setting the balloon driver statistics
collection period in order to enable or disable the collection dynamically.

This patch will add the qemuMonitorJSONGetMemoryStats() to execute a
"guest-stats" on the balloonpath using "get-qom" replacing the former
mechanism which looked through the "query-ballon" returned data for
the fields.  The "query-balloon" code only returns 'actual' memory.
Rather than duplicating the existing code, have the JSON API use the
GetBalloonInfo API.

A check in the qemuMonitorGetMemoryStats() will be made to ensure the
balloon driver path has been set.  Since the underlying JSON code can
return data not associated with the balloon driver, we don't fail on
a failure to get the balloonpath.  Of course since we've made the check,
we can then set the ballooninit flag.  Getting the path here is primarily
due to the process reconnect path which doesn't attempt to set the
collection period.

At vm startup and attach attempt to set the balloon driver statistics
collection period based on the value found in the domain xml file. This
is not done at reconnect since it's possible that a collection period
was set on the live guest and making the set period call would reset to
whatever value is stored in the config file.

Setting the stats collection period has a side effect of searching through
the qom-list output for the virtio balloon driver and making sure that it
has the right properties in order to allow setting of a collection period
and eventually fetching of statistics.

The walk through the qom-list is expensive and thus the balloonpath will
be saved in the monitor private structure as well as a flag indicating
that the initialization has already been attempted (in the event that a
path is not found, no sense to keep checking).

This processing model conforms to the qom object model model which
requires setting object properties after device startup. That is, it's
not possible to pass the period along via the startup code as it won't
be recognized.

If users haven't configured guest agent then qemuAgentCommand() will
dereference a NULL 'mon' pointer, which causes crash of libvirtd when
using agent based cpu (un)plug.

With the patch, when the qemu-ga service isn't running in the guest,
a expected error "error: Guest agent is not responding: Guest agent
not available for now" will be raised, and the error "error: argument
unsupported: QEMU guest agent is not configured" is raised when the
guest hasn't configured guest agent.

GDB backtrace:

 (gdb) bt
 #0  virNetServerFatalSignal (sig=11, siginfo=<value optimized out>, context=<value optimized out>) at rpc/virnetserver.c:326
 #1  <signal handler called>
 #2  qemuAgentCommand (mon=0x0, cmd=0x7f39300017b0, reply=0x7f394b090910, seconds=-2) at qemu/qemu_agent.c:975
 #3  0x00007f39429507f6 in qemuAgentGetVCPUs (mon=0x0, info=0x7f394b0909b8) at qemu/qemu_agent.c:1475
 #4  0x00007f39429d9857 in qemuDomainGetVcpusFlags (dom=<value optimized out>, flags=9) at qemu/qemu_driver.c:4849
 #5  0x00007f3957dffd8d in virDomainGetVcpusFlags (domain=0x7f39300009c0, flags=8) at libvirt.c:9843

How to reproduce?

 # To start a guest without guest agent configuration
 # then run the following cmdline

 # virsh vcpucount foobar --guest
 error: End of file while reading data: Input/output error
 error: One or more references were leaked after disconnect from the hypervisor
 error: Failed to reconnect to the hypervisor

RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=984821Signed-off-by: NAlex Jia <ajia@redhat.com>
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>

Since previous patches has prepared everything for us, we may now
implement live hotplug of a character device.

There are two levels on which a device may be hotplugged: config
and live. The config level requires just an insert or remove from
internal domain definition structure, which is exactly what this
patch does. There is currently no implementation for a chardev
update action, as there's not much to be updated. But more
importantly, the only thing that can be updated is path or socket
address by which chardevs are distinguished. So the update action
is currently not supported.

Add a new qemuMonitorJSONSetObjectProperty() method to support invocation
of the 'qom-set' JSON monitor command with a provided path, property, and
expected data type to set.

NOTE: The set API was added only for the purpose of the qemumonitorjsontest

The test code uses the same "/machine/i440fx" property as the get test and
attempts to set the "realized" property to "true" (which it should be set
at anyway).

Add a new qemuMonitorJSONGetObjectProperty() method to support invocation
of the 'qom-get' JSON monitor command with a provided path, property, and
expected data type return. The qemuMonitorJSONObjectProperty is similar to
virTypedParameter; however, a future patch will extend it a bit to include
a void pointer to balloon driver statistic data.

NOTE: The ObjectProperty structures and API are added only for the
      purpose of the qemumonitorjsontest

The provided test will execute a qom-get on "/machine/i440fx" which will
return a property "realized".

Add a new qemuMonitorJSONGetObjectListPaths() method to support invocation
of the 'qom-list' JSON monitor command with a provided path.

NOTE: The ListPath structures and API's are added only for the
      purpose of the qemumonitorjsontest

The returned list of paired data fields of "name" and "type" that can
be used to peruse QOM configuration data and eventually utilize for the
balloon statistics.

The test does a "{"execute":"qom-list", "arguments": { "path": "/"}}" which
returns "{"return": [{"name": "machine", "type": "child<container>"},
{"name": "type", "type": "string"}]}" resulting in a return of an array
of 2 elements with [0].name="machine", [0].type="child<container>".  The [1]
entry appears to be a header that could be used some day via a command such
as "virsh qemuobject --list" to format output.

If an error occurs during qemuDomainAttachNetDevice after the macvtap
was created in qemuPhysIfaceConnect, the macvtap device gets left behind.
This patch adds code to the cleanup routine to delete the macvtap.
Signed-off-by: NMatthew Rosato <mjrosato@linux.vnet.ibm.com>
Reviewed-by: NViktor Mihajlovski <mihajlov@linux.vnet.ibm.com>

I recently patches the callers to virPCIDeviceReset() to not call it
if the current driver for a device was vfio-pci (since that driver
will always reset the device itself when appropriate. At the time, Dan
Berrange suggested that I could instead modify virPCIDeviceReset
to check the currently bound driver for the device, and decide
for itself whether or not to go ahead with the reset.

This patch removes the previously added checks, and replaces them with
a check down in virPCIDeviceReset(), as suggested.

The functional difference here is that previously we were deciding
based on either the hostdev configuration or the value of
stubDriverName in the virPCIDevice object, but now we are actually
comparing to the "driver" link in the device's sysfs entry
directly. In practice, both should be the same.

It's caller's responsibility to free return value of
qemuBuildChrDeviceStr().

Error out on negative index values.

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

The function being introduced is responsible for creating command
line argument for '-device' for given character device. Based on
the chardev type, it calls appropriate qemuBuild.*ChrDeviceStr(),
e.g.  qemuBuildSerialChrDeviceStr() for serial chardev and so on.

The chardev alias assignment is going to be needed in a separate
places, so it should be moved into a separate function rather
than copying code randomly around.

This function wraps 'chardev-remove' qemu monitor command around.
It takes chardev alias as its single argument besides qemu monitor
pointer.

The function being introduced is responsible for preparing and
executing 'chardev-add' qemu monitor command. Moreover, in case
of PTY chardev, the corresponding pty path is updated.

Currently, we are building InetSocketAddress qemu json type
within the qemuMonitorJSONNBDServerStart function. However, other
future functions may profit from the code as well. So it should
be moved into a static function.

Recent changes uncovered a possibility that 'last_processed_hostdev_vf'
was set to -1 in 'qemuPrepareHostdevPCIDevices' and would cause problems
in for loop end condition in the 'resetvfnetconfig' label if the
variable was never set to 'i' due to 'qemuDomainHostdevNetConfigReplace'
failure.

With current code, error reporting for unsupported devices for hot plug,
unplug and update is total mess. The VIR_ERR_CONFIG_UNSUPPORTED error
code is reported instead of VIR_ERR_OPERATION_UNSUPPORTED. Moreover, the
error messages are not helping to find the root cause (lack of
implementation).

For low-memory domains (roughly under 400MB) our automatic memory limit
computation comes up with a limit that's too low. This is because the
0.5 multiplication does not add enough for such small values. Let's
increase the constant part of the computation to fix this.

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>

CVE-2013-2230

Don't overwrite the callback ID returned by
virDomainEventStateRegisterID in ret by 0.

Introduced by abf75aea.

Remove assignment of the string freed by virURIFree
to hostname, since it's not used anywhere.

Double free introduced by ddf8ad82, useless code
introduced by f03dcc5d.

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

Introduced in commit d47eff88.

* src/qemu/qemu_driver.c (qemuDomainSetVcpusFlags): Fix spelling.
Signed-off-by: NEric Blake <eblake@redhat.com>

If a domain is configured to have all its memory locked, we need to set
RLIMIT_MEMLOCK so that QEMU is actually allowed to lock the memory.