If we can choose live or config when setting, then we need to
be able to choose which one we are querying.

Also, make the documentation clear that set must use a non-empty
subset (some of the hypervisors fail if params is NULL).

* include/libvirt/libvirt.h.in
(virDomainGetSchedulerParametersFlags): New prototype.
* src/libvirt.c (virDomainGetSchedulerParametersFlags): Implement
it.
* src/libvirt_public.syms: Export it.
* python/generator.py (skip_impl): Don't auto-generate.
* src/driver.h (virDrvDomainGetSchedulerParametersFlags): New
callback.

The new type is identical to the three old types that it replaces,
and by creating a common type, this allows future patches to share
common code that manipulates typed parameters.

This change is backwards-compatible in API (recompilation works
without any edits) and ABI (an older client that has not been
recompiled uses the same layout) for code using only public
names; only code using private names (those beginning with _)
will have to adapt.

* include/libvirt/libvirt.h.in (virTypedParameterType)
(VIR_TYPED_PARAM_FIELD_LENGTH, _virTypedParameter): New enum,
macro, and type.
(virSchedParameter, virBlkioParameter, virMemoryParameter):
Rewrite in terms of a common type, while keeping all old public
names for backwards compatibility.
(struct _virSchedParameter, struct _virBlkioParameter)
(struct _virMemoryParameter): Delete - these are private names.
* python/generator.py (enum): Cope with the refactoring.

This new function allows aditional flags to be passed into from
the virsh command line.

This API is supposed to replace virDomainGetInfo when the only purpose
of calling it is getting current domain status.

This partially reverts (and fixes that part in a different way) commit
e4384459c93e3e786aa483c7f077d1d22148f689, which replaced
``/usr/bin/python'' with ``/usr/bin/env python'' in all examples or
scripts used during build to generate other files.

However, python bindings module is compiled and linked against a
specific python discovered or explicitly provided in configure phase.
Thus libvirt.py, which is generated and installed into the system,
should use the same python binary for which the module has been built.

The hunk in Makefile.am replaces $(srcdir) with $(PYTHON), which might
seem wrong but it is not. generator.py didn't use any of its command
line arguments so passing $(srcdir) to it was redundant.

Add virDomainSetBlkioParameters virDomainGetBlkioParameters

Signed-off-by: Gui Jianfeng <guijianfeng@cn.fujitsu.com>

Also cfg.mk is tweaked to force this for all future changes to *.py
files.

This is more flexible regarding the location of the python binary
but doesn't allow to pass the -u flag. The -i flag can be passed
from inside the script using the PYTHONINSPECT env variable.

This fixes a problem with the esx_vi_generator.py on FreeBSD.

This patch adds a structure virMemoryParameter, it contains the name of
the
parameter and the type of the parameter along with a union.

dv:
+ rename enums to VIR_DOMAIN_MEMORY_PARAM_*
+ remove some extraneous tabs

v4:
+ Add unsigned int flags to the public api for future extensions

v3:
+ Protoype for virDomainGetMemoryParameters and dummy python binding.

v2:
+ Includes dummy python bindings for the library to build cleanly.
+ Define string constants like "hard_limit", etc.
+ re-order this patch.

This involved a few fixes.  To start with,
an virDomainSnapshot object is really tied to a
domain, not a connection, so we have to generate
a slightly different object so that we can get
at self._dom for the object.

Next, we had to "dummy" up an override piece of
XML with a bogus argument that the function doesn't
actually take.  That's so that the generator places
virDomainRevertToSnapshot underneath the correct
class (namely, the virDomain class).

Finally, we had to hand-implement the
virDomainRevertToSnapshot implementation, ignoring the
bogus pointer we are being passed.

With all of this in place, I was able to successfully
take a snapshot and revert to it using only the
Python bindings.

Signed-off-by: Chris Lalancette <clalance@redhat.com>