Make MIGRATION_OUT use the new helper methods.

This also introduces new protection to migration v3 process: the
migration job is held from Begin to Confirm to avoid changes to a domain
during migration (esp. between Begin and Perform phases). This change is
automatically applied to p2p and tunneled migrations. For normal
migration, this requires support from a client. In other words, if an
old (pre 0.9.4) client starts normal migration of a domain, the domain
will not be protected against changes between Begin and Perform steps.

Now that virDomainSetVcpusFlags knows about VIR_DOMAIN_AFFECT_CURRENT,
so should virDomainGetVcpusFlags.

Unfortunately, the virsh counterpart 'virsh vcpucount' has already
commandeered --current for a different meaning, so teaching virsh
to expose this in the next patch will require a bit of care.

* src/libvirt.c (virDomainGetVcpusFlags): Allow
VIR_DOMAIN_AFFECT_CURRENT.
* src/libxl/libxl_driver.c (libxlDomainGetVcpusFlags): Likewise.
* src/qemu/qemu_driver.c (qemudDomainGetVcpusFlags): Likewise.
* src/test/test_driver.c (testDomainGetVcpusFlags): Likewise.
* src/xen/xen_driver.c (xenUnifiedDomainGetVcpusFlags): Likewise.

* src/libvirt.c: implement the main entry points

Modifying the xml on either save or restore only gets you so
far - you have to remember to 'virsh dumpxml dom' just prior
to the 'virsh save' in order to have an xml file worth modifying
that won't be rejected due to abi breaks.  To make this more
powerful, we need a way to grab the xml embedded within a state
file, and from there, it's not much harder to also support
modifying a state file in-place.

Also, virDomainGetXMLDesc didn't document its flags.

* include/libvirt/libvirt.h.in (virDomainSaveImageGetXMLDesc)
(virDomainSaveImageDefineXML): New prototypes.
* src/libvirt.c (virDomainSaveImageGetXMLDesc)
(virDomainSaveImageDefineXML): New API.
* src/libvirt_public.syms: Export them.
* src/driver.h (virDrvDomainSaveImageGetXMLDesc)
(virDrvDomainSaveImgeDefineXML): New driver callbacks.

This introduces new API virDomainDestroyFlags to allow
domain destroying with flags, as the existing API virDomainDestroy
misses flags.

The set of flags is defined in virDomainDestroyFlagsValues enum,
which is currently commented, because it is empty.

Calling this API with no flags set (@flags == 0) is equivalent calling
virDomainDestroy.

In order to choose whether to use O_DIRECT when saving a domain image
to a file, we need a new flag.  But virDomainSave was implemented
before our policy of all new APIs having a flag argument.  Likewise
for virDomainRestore when restoring from a file.

The new flag name is chosen as CACHE_BYPASS so as not to preclude
a future solution that uses posix_fadvise once the Linux kernel has
a smarter implementation of that interface.

* include/libvirt/libvirt.h.in (virDomainCreateFlags)
(virDomainCoreDumpFlags): Add a flag.
(virDomainSaveFlags, virDomainRestoreFlags): New prototypes.
* src/libvirt.c (virDomainSaveFlags, virDomainRestoreFlags): New API.
* src/libvirt_public.syms: Export them.
* src/driver.h (virDrvDomainSaveFlags, virDrvDomainRestoreFlags):
New driver callbacks.

* src/conf/domain_event.c (virDomainEventDispatch): Fix typo.
* src/internal.h (ATTRIBUTE_FMT_PRINTF): Likewise.
* src/libvirt.c (virStreamEventUpdateCallback): Likewise.
* src/remote/remote_driver.c (doRemoteOpen): Likewise.
* src/storage/storage_backend_fs.c (virStorageBackendProbeTarget):
Likewise.
* src/util/virterror.c (virConnCopyLastError, virCopyLastError):
Likewise.
* src/xen/xend_internal.h (xend_wait_for_devices): Likewise.

This introduces a new API virDomainUndefineFlags to control the
domain undefine process, as the existing API virDomainUndefine
doesn't support flags.

Currently only flag VIR_DOMAIN_UNDEFINE_MANAGED_SAVE is supported.
If the domain has a managed save image, including
VIR_DOMAIN_UNDEFINE_MANAGED_SAVE in @flags will also remove that
file, and omitting the flag will cause undefine process to fail.

This patch also changes the behavior of virDomainUndefine, if the
domain has a managed save image, the undefine will be refused.

There were two API in driver.c that were silently masking flags
bits prior to calling out to the drivers, and several others
that were explicitly masking flags bits.  This is not
forward-compatible - if we ever have that many flags in the
future, then talking to an old server that masks out the
flags would be indistinguishable from talking to a new server
that can honor the flag.  In general, libvirt.c should forward
_all_ flags on to drivers, and only the drivers should reject
unknown flags.

In the case of virDrvSecretGetValue, the solution is to separate
the internal driver callback function to have two parameters
instead of one, with only one parameter affected by the public
API.  In the case of virDomainGetXMLDesc, it turns out that
no one was ever mixing VIR_DOMAIN_XML_INTERNAL_STATUS with
the dumpxml path in the first place; that internal flag was
only used in saving and restoring state files, which happened
to be in functions internal to a single file, so there is no
mixing of the internal flag with a public flags argument.
Additionally, virDomainMemoryStats passed a flags argument
over RPC, but not to the driver.

* src/driver.h (VIR_DOMAIN_XML_FLAGS_MASK)
(VIR_SECRET_GET_VALUE_FLAGS_MASK): Delete.
(virDrvSecretGetValue): Separate out internal flags.
(virDrvDomainMemoryStats): Provide missing flags argument.
* src/driver.c (verify): Drop unused check.
* src/conf/domain_conf.h (virDomainObjParseFile): Delete
declaration.
(virDomainXMLInternalFlags): Move...
* src/conf/domain_conf.c: ...here.  Delete redundant include.
(virDomainObjParseFile): Make static.
* src/libvirt.c (virDomainGetXMLDesc, virSecretGetValue): Update
clients.
(virDomainMemoryPeek, virInterfaceGetXMLDesc)
(virDomainMemoryStats, virDomainBlockPeek, virNetworkGetXMLDesc)
(virStoragePoolGetXMLDesc, virStorageVolGetXMLDesc)
(virNodeNumOfDevices, virNodeListDevices, virNWFilterGetXMLDesc):
Don't mask unknown flags.
* src/interface/netcf_driver.c (interfaceGetXMLDesc): Reject
unknown flags.
* src/secret/secret_driver.c (secretGetValue): Update clients.
* src/remote/remote_driver.c (remoteSecretGetValue)
(remoteDomainMemoryStats): Likewise.
* src/qemu/qemu_process.c (qemuProcessGetVolumeQcowPassphrase):
Likewise.
* src/qemu/qemu_driver.c (qemudDomainMemoryStats): Likewise.
* daemon/remote.c (remoteDispatchDomainMemoryStats): Likewise.

Commit 13555416 introduced a nice feature without documenting it.

* src/libvirt.c (virDomainMigrate2): Add paragraph.

This patch extends virDomainSetVcpusFlags API to support
VIR_DOMAIN_AFFECT_CURRENT flag.

Now because most APIs accept VIR_DOMAIN_AFFECT_CURRENT flags,
virDomainSetVcpusFlags API should also do.
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>

Most APIs use 'unsigned int flags'; but a few stragglers were using
a signed value.  In particular, the vir*GetXMLDesc APIs were
split-brain, with inconsistent choice of types.  Although it is
an API break to use 'int' instead of 'unsigned int', it is ABI
compatible (pre-compiled apps will have no difference in behavior),
and generally apps can be recompiled without any issue (only rare
apps that compiled with extremely high warning levels, or which
pass libvirt API around as typed function pointers, would have to
make any code changes to deal with the change).

The migrate APIs use 'unsigned long flags', which can't be changed,
due to ABI constraints.

This patch intentionally touches only the public API, to prove the
claim that most existing code (including driver callbacks and virsh)
still compiles just fine in spite of the type change.

* include/libvirt/libvirt.h.in (virConnectOpenAuth)
(virDomainCoreDump, virDomainGetXMLDesc, virNetworkGetXMLDesc)
(virNWFilterGetXMLDesc): Use unsigned int for flags.
(virDomainHasCurrentSnapshot): Use consistent spelling.
* src/libvirt.c (virConnectOpenAuth, virDomainCoreDump)
(virDomainGetXMLDesc, virNetworkGetXMLDesc)
(virNWFilterGetXMLDesc, do_open): Update accordingly.

Debugging decimal flags is a pain.

* src/libvirt.c: Always print flags in hex.

We already have a public virDomainPinVcpu, which implies that
Pin and Vcpu are treated as separate words.  Unreleased commit
e261987c introduced virDomainGetVcpupinInfo as the first public
API that used Vcpupin, although we had prior internal uses of
that spelling.  For consistency, change the spelling to be two
words everywhere, regardless of whether pin comes first or last.

* daemon/remote.c: Treat vcpu and pin as separate words.
* include/libvirt/libvirt.h.in: Likewise.
* src/conf/domain_conf.c: Likewise.
* src/conf/domain_conf.h: Likewise.
* src/driver.h: Likewise.
* src/libvirt.c: Likewise.
* src/libvirt_private.syms: Likewise.
* src/libvirt_public.syms: Likewise.
* src/libxl/libxl_driver.c: Likewise.
* src/qemu/qemu_driver.c: Likewise.
* src/remote/remote_driver.c: Likewise.
* src/xen/xend_internal.c: Likewise.
* tools/virsh.c: Likewise.
* src/remote/remote_protocol.x: Likewise.
* src/remote_protocol-structs: Likewise.
Suggested by Matthias Bolte.

This patch introduces a new libvirt API (virDomainGetVcpupinInfo),
as a counterpart to virDomainPinVcpuFlags.

We can use virDomainGetVcpus API to retrieve CPU affinity information,
but can't use this API against inactive domains (at least in case of KVM),
as it lacks a flags parameter.
The usual thing is to add a new virDomainGetVcpusFlags, but that API name
is already occupied by the counterpart to virDomainGetMaxVcpus, which
has a completely different signature.

The virDomainGetVcpupinInfo is the new API to retrieve CPU affinity
information of active and inactive domains.  While the usual convention
is to list an array before its length, this API violates that rule
in order to be more like virDomainGetVcpus (where maxinfo was doing
double-duty as the length of two different arrays).
Signed-off-by: NTaku Izumi <izumi.taku@jp.fujitsu.com>

Integer overflow and remote code are never a nice mix.

This has existed since commit 56cd4140.

* src/libvirt.c (virDomainGetVcpus): Reject overflow up front.
* src/remote/remote_driver.c (remoteDomainGetVcpus): Avoid overflow
on sending rpc.
* daemon/remote.c (remoteDispatchDomainGetVcpus): Avoid overflow on
receiving rpc.

When adding virDomainGetVcpusFlags in commit ea3f5c68, I did
enough rebasing that the doc comments in libvirt.c no longer
matched the final chosen enum names in libvirt.h.

And now we've gone ahead and deprecated the names
VIR_DOMAIN_VCPU_{LIVE,CONFIG}.

* src/libvirt.c (virDomainGetVcpusFlags): Fix comment.

This reverts commit 6419f596.

If an application is using libvirt + KVM as a piece of its
internal infrastructure to perform a specific task, it can
be desirable to guarentee the VM dies when the virConnectPtr
disconnects from libvirtd. This ensures the app can't leak
any VMs it was using. Adding VIR_DOMAIN_START_AUTOKILL as
a flag when starting guests enables this to be done.

* include/libvirt/libvirt.h.in: All VIR_DOMAIN_START_AUTOKILL
* src/qemu/qemu_driver.c: Support automatic killing of guests
  upon connection close
* tools/virsh.c: Add --autokill flag to 'start' and 'create'
  commands

apibuild.py expects a sentence that starts with "Returns"
describing the return value of a function.

* src/libvirt.c (virConnectClose): Mention reference count return.
Reported by Michal Novotny, analyzed by Matthias Bolte.

The API can be used to query current state of an interface to VMM used
to control a domain. In QEMU world this translates into monitor
connection.

virStreamRecv is for reading.

Also add some missing punctuation to virStreamSend's documentation.

Even though rpc uses 'unsigned int' for the _len parameter that
passes the length of item<length>, the public libvirt APIs all
use 'int' and filter out lengths < 0, except for virDomainSendKey.

* include/libvirt/libvirt.h.in (virDomainSendKey): All other APIs
use int for array length.
* src/libvirt.c (virDomainSendKey): Adjust.
* src/driver.h (virDrvDomainSendKey): Likewise.
* daemon/remote_generator.pl: Likewise.

* src/libvirt.c: implement the main entry points
Signed-off-by: NAdam Litke <agl@us.ibm.com>
Acked-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NMinoru Usui <usui@mxm.nes.nec.co.jp>

Signed-off-by: NMinoru Usui <usui@mxm.nes.nec.co.jp>

Signed-off-by: NLai Jiangshan <laijs@cn.fujitsu.com>

Qemu once supported following memory stats which will returned by
"query_balloon":

    stat_put(dict, "actual", actual);
    stat_put(dict, "mem_swapped_in", dev->stats[VIRTIO_BALLOON_S_SWAP_IN]);
    stat_put(dict, "mem_swapped_out", dev->stats[VIRTIO_BALLOON_S_SWAP_OUT]);
    stat_put(dict, "major_page_faults", dev->stats[VIRTIO_BALLOON_S_MAJFLT]);
    stat_put(dict, "minor_page_faults", dev->stats[VIRTIO_BALLOON_S_MINFLT]);
    stat_put(dict, "free_mem", dev->stats[VIRTIO_BALLOON_S_MEMFREE]);
    stat_put(dict, "total_mem", dev->stats[VIRTIO_BALLOON_S_MEMTOT]);

But it later disabled all the stats except "actual" by commit
07b0403dfc2b2ac179ae5b48105096cc2d03375a.

libvirt doesn't parse "actual", so user will always see a empty result
with "virsh dommemstat $domain". Even qemu haven't disabled the stats,
we should support parsing "actual".

This patch deprecates following enums:

VIR_DOMAIN_MEM_CURRENT
VIR_DOMAIN_MEM_LIVE
VIR_DOMAIN_MEM_CONFIG

VIR_DOMAIN_VCPU_LIVE
VIR_DOMAIN_VCPU_CONFIG

VIR_DOMAIN_DEVICE_MODIFY_CURRENT
VIR_DOMAIN_DEVICE_MODIFY_LIVE
VIR_DOMAIN_DEVICE_MODIFY_CONFIG

And modify internal codes to use virDomainModificationImpact.

This patch introduces a new libvirt API virDomainPinVcpuFlags,
a direct extension from the existing virDomainPinVcpu

Detected by Coverity.  Commit a98d8f0d tried to make uuid debugging
more robust, but missed some APIs.  And on the APIs that it visited,
the mere act of preparing the debug message ends up dereferencing
uuid prior to the null check.  Which means the APIs which are supposed
to gracefully reject NULL arguments now end up with SIGSEGV.

* src/libvirt.c (VIR_UUID_DEBUG): New macro.
(virDomainLookupByUUID, virDomainLookupByUUIDString)
(virNetworkLookupByUUID, virNetworkLookupByUUIDString)
(virStoragePoolLookupByUUID, virStoragePoolLookupByUUIDString)
(virSecretLookupByUUID, virSecretLookupByUUIDString)
(virNWFilterLookupByUUID, virNWFilterLookupByUUIDString): Avoid
null dereference.

virGetVersion itself doesn't take a virConnectPtr, but in order to obtain
the hypervisor version against which libvirt was compiled it is used in
combination with virConnectGetType like this:

hvType = virConnectGetType(conn)
virGetVersion(&libVer, hvType, &typeVer)

When virConnectGetType is called on a remote connection then the remote
driver returns the type of the underlying driver on the server side, for
example QEMU. Then virGetVersion compares hvType to a set of strings that
depend on configure options and returns LIBVIR_VERSION_NUMBER in most
cases. Now this fails in case libvirt on the client side is just compiled
with the remote driver enabled only and the server side has the actual
driver such as the QEMU driver. It just happens to work when the actual
driver is enabled on client and server side. But that's not always true.
I noticed this on FreeBSD:

freebsd# virsh -c qemu+tcp://192.168.178.22/system version
Compiled against library: libvir 0.9.2
error: failed to get the library version
error: this function is not supported by the connection driver: virGetVersion

This is not FreeBSD specific, happens on Windows as well due to the
similar driver support configuration. The problem is that virConnectGetType
returns QEMU, but virGetVersion on the client side only accepts Remote
as hvType due to all other drivers being disabled on the client side.

Daniel P. Berrange suggested to get rid of all the conditional code in
virGetVersion, ignoring the hvType and always setting typeVer to
LIBVIR_VERSION_NUMBER. virConnectGetVersion is supposed to be used to
obtain the hypervisor version.

This commit is safe precisely because there has been no release
for any of the enum values being deleted (they were added post-0.9.1).

After the 0.9.2 release, we can then take advantage of
virDomainModificationImpact in more places.

* include/libvirt/libvirt.h.in (virDomainModificationImpact): New
enum.
(virDomainSchedParameterFlags, virMemoryParamFlags): Delete, since
these were never released, and the new enum works fine here.
* src/libvirt.c	(virDomainGetMemoryParameters)
(virDomainSetMemoryParameters)
(virDomainGetSchedulerParametersFlags)
(virDomainSetSchedulerParametersFlags): Update documentation.
* src/qemu/qemu_driver.c (qemuDomainSetMemoryParameters)
(qemuDomainGetMemoryParameters, qemuSetSchedulerParametersFlags)
(qemuSetSchedulerParameters, qemuGetSchedulerParametersFlags)
(qemuGetSchedulerParameters): Adjust clients.
* tools/virsh.c (cmdSchedinfo, cmdMemtune): Likewise.
Based on ideas by Daniel Veillard and Hu Tao.

* tools/virsh.c: Add screenshot command
* tools/virsh.pod: Document new command
* src/libvirt.c: Fix off-be-one error

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.

Rather mechanical in nature.

* src/driver.h: Use newer virTypedParameter API names.
* src/libvirt.c: Likewise.
* daemon/remote.c: Likewise.
* src/esx/esx_driver.c: Likewise.
* src/libxl/libxl_driver.c: Likewise.
* src/lxc/lxc_driver.c: Likewise.
* src/qemu/qemu_driver.c: Likewise.
* src/remote/remote_driver.c: Likewise.
* src/test/test_driver.c: Likewise.
* src/xen/xen_driver.c: Likewise.
* src/xen/xen_hypervisor.c: Likewise.
* src/xen/xen_hypervisor.h: Likewise.
* src/xen/xend_internal.c: Likewise.
* tools/virsh.c: Likewise.

drivers implementing domainSetSchedulerParametersFlags should check
flags themselves.