To allow changing the name that is recorded in the top of the current
image chain used in a block pull/rebase operation, we need to specify
the backing name to qemu. This is done via the "backing-file" attribute
to the block-stream commad.

To allow changing the name that is recorded in the overlay of the TOP
image used in a block commit operation, we need to specify the backing
name to qemu. This is done via the "backing-file" attribute to the
block-commit command.

This command allows to change the backing file name recorded in the
metadata of a qcow (or other) image. The capability also notifies that
the "block-stream" and "block-commit" commands understand the
"backing-file" attribute.

Pass the virStorageSource struct to the auditing function and check if
storage is local before auditing.

Extract common operations done when creating an audit message to a
separate generic function that can be reused and convert RNG, disk, FS
and net audit to use it.

The audit functions usually take the old definition before the new one
in the argument list. Unify RNG device to use the same order.

There's a lot of places where we skip doing actions based on the
locality of given storage type. The usual pattern is to skip it if:

virStorageSourceGetActualType(src) == VIR_STORAGE_TYPE_NETWORK

Add a simple helper to simplify the pattern to
virStorageSourceIsLocalStorage(src)

Replace the authType, chap, and cephx unions in virStoragePoolSource
with a single pointer to a virStorageAuthDefPtr.  Adjust all users of
the previous chap/cephx and secret unions with the source->auth data.

Fix a couple of typos ('chap' should have been 'iscsi' and there was
a stray 'iqn.2013-07.com.example:iscsi-pool' entry.  Clean up the
description of the <auth> element for the disk

Replace the inline "auth" struct in virStorageSource with a pointer
to a virStorageAuthDefPtr and utilize between the domain_conf, qemu_conf,
and qemu_command sources for finding the auth data for a domain disk

Ressurect the disk-drive-network-iscsi-auth and disk-drive-network-rbd-auth
tests.  Make adjustments to the args and xml file to be compatible with
other changes made to the non "-auth" so that the only difference is the
authentication information.

Adjust the qemuargv2xmltest.c to filter out "<secret" and "</auth>" since
the args -> xml has no concept of usage it doesn't get printed. This results
in the </auth> being printed on the same line as "<secret" and the secret
XML is not closed - a bit of an issue, but soon to be fixed.

Introduce virStorageAuthDef and friends.  Future patches will merge/utilize
their view of storage source/pool auth/secret definitions.

New API's include:
    virStorageAuthDefParse:  Parse the "<auth/>" XML data for either the
                             domain disk or storage pool returning a
                             virStorageAuthDefPtr
    virStorageAuthDefCopy:   Copy a virStorageAuthDefPtr - to be used by
                             the qemuTranslateDiskSourcePoolAuth when it
                             copies storage pool auth data into domain
                             disk auth data
    virStorageAuthDefFormat: Common output of the "<auth" in the domain
                             disk or storage pool XML
    virStorageAuthDefFree:   Free memory associated with virStorageAuthDef

Subsequent patches will utilize the new functions for the domain disk and
storage pools.

Future work in the hostdev pass through can then make use of common data
structures and code.

Use the probing functionality added in the last patch to turn on
a capability bit when active commit is present, and gate active
commit on that capability.

For my own reference: the difference between BLOCKJOB_SYNC and
BLOCKJOB_ASYNC is whether qemu generated an event at the
conclusion of blockpull; basically, RHEL 6.2 was the only release
of qemu that has the sync semantics and lacks the event.  RHEL
6.3 added blockcopy, but also picked up on the upstream style
of qemu generating events.  As no one is likely to backport
active commit to RHEL 6.2, it's safe for blockcommit to always
require async blockjob support.

Modifying qemucapabilitiestest is painful; the .replies files would
be so much easier if they had comments correlating which command
generated the given reply.  Maybe I'll fix that up later...

* src/qemu/qemu_capabilities.h (QEMU_CAPS_ACTIVE_COMMIT): New
capability.
* src/qemu/qemu_driver.c (qemuDomainBlockCommit): Use the new bit
* src/qemu/qemu_capabilities.c (virQEMUCaps): Name the new bit.
(virQEMUCapsProbeQMPCommands): Set it.
* tests/qemucapabilitiesdata/caps_1.3.1-1.replies: Update.
* tests/qemucapabilitiesdata/caps_1.4.2-1.replies: Likewise.
* tests/qemucapabilitiesdata/caps_1.5.3-1.replies: Likewise.
* tests/qemucapabilitiesdata/caps_1.6.0-1.replies: Likewise.
* tests/qemucapabilitiesdata/caps_1.6.50-1.replies: Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

We are about to turn on support for active block commit.  Although
qemu 2.0 was the first version to mostly support it, that version
mis-handles 0-length files, and doesn't have anything available for
easy probing.  But qemu 2.1 fixed bugs, and made life simpler by
letting the 'top' argument be optional.  Unless someone begs for
active commit with qemu 2.0, for now we are just going to enable
it only by probing for qemu 2.1 behavior (anyone backporting active
commit can also backport the optional argument behavior).  This
requires qemu.git commit 7676e2c597000eff3a7233b40cca768b358f9bc9.

Although all our actual uses of block-commit supply arguments for
both base and top, we can omit both arguments and use a bogus
device string to trigger an interesting behavior in qemu.  All QMP
commands first do argument validation, failing with GenericError
if a mandatory argument is missing.  Once that passes, the code
in the specific command gets to do further checking, and the qemu
developers made sure that if device is the only supplied argument,
then the block-commit code will look up the device first, with a
failure of DeviceNotFound, before attempting any further argument
validation (most other validations fail with GenericError).  Thus,
the category of error class can reliably be used to decipher
whether the top argument was optional, which in turn implies a
working active commit.  Since we expect our bogus device string to
trigger an error either way, the code is written to return a
distinct return value without spamming the logs.

* src/qemu/qemu_monitor.h (qemuMonitorSupportsActiveCommit): New
prototype.
* src/qemu/qemu_monitor.c (qemuMonitorSupportsActiveCommit):
Implement it.
* src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockCommit):
Allow NULL for top and base, for probing purposes.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockCommit):
Likewise, implementing the probe.
* tests/qemumonitorjsontest.c (mymain): Enable...
(testQemuMonitorJSONqemuMonitorSupportsActiveCommit): ...a new test.
Signed-off-by: NEric Blake <eblake@redhat.com>

The problem is, since 614581f3 domaincapstest is linked with
$(LDADDS) by default. Then, since 94e3f23e the test may be
conditionally linked with $(qemu_LDADDS) which already contains
$(LDADDS). And some linkers doesn't cope with this nicely:

  CCLD     domaincapstest
../src/libvirt_probes.o:(.probes+0x0): multiple definition of `libvirt_event_poll_add_handle_semaphore'
../src/libvirt_probes.o:(.probes+0x0): first defined here
../src/libvirt_probes.o:(.probes+0x2): multiple definition of `libvirt_event_poll_update_handle_semaphore'
../src/libvirt_probes.o:(.probes+0x2): first defined here
../src/libvirt_probes.o:(.probes+0x4): multiple definition of `libvirt_event_poll_remove_handle_semaphore'
../src/libvirt_probes.o:(.probes+0x4): first defined here
../src/libvirt_probes.o:(.probes+0x6): multiple definition of `libvirt_event_poll_dispatch_handle_semaphore'
../src/libvirt_probes.o:(.probes+0x6): first defined here

And so on.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

So far only information on disks and host devices are exposed in the
capabilities XML. Well, at least something. Even a new test is
introduced. The qemu capabilities are stolen from already existing
qemucapabilities test. There's one tricky point though. Functions that
checks host's KVM and VFIO capabilities, are impossible to mock
currently. So in the test, we are setting the capabilities by hand.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Sometimes it may be useful to get a default machine for given qemu
binary. Fortunately, the default machine is stored always on the first
position in the supported machines array.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This internal API is meant to answer the question 'Is this machine
type supported by given qemu?'.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The API may come handy if somebody has an architecture and wants to
look through available qemus if the architecture is supported or not.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Later on, we the qemu capabilities XML parsing code may come handy so
instead of duplicating the code make the already existing one shared.
By the same time, make the function accept file name instead of XML
document stored already in memory.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The API is exposed under 'domcapabilities' command. Currently, with
the variety of drivers that libvirt supports, none of the command
arguments is obligatory, but all are optional instead.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The API should expose the information contained in virDomainCapsPtr.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This new module holds and formats capabilities for emulator. If you
are about to create a new domain, you may want to know what is the
host or hypervisor capable of. To make sure we don't regress on the
XML, the formatting is not something left for each driver to
implement, rather there's general format function.

The domain capabilities is a lockable object (even though the locking
is not necessary yet) which uses reference counter.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In the lastest rework (9e7ecabf) a cleanup label was left over which
results in compilation error.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The functions called here report an OOM error when the allocation
fails, or quietly return -1 on wrong usage (which is not the case
here)

They report errors in all other cases.

It sets the errno on all other errors, do it here too.
Also report an error.

Replace:
if (virBufferError(&buf)) {
    virBufferFreeAndReset(&buf);
    virReportOOMError();
    ...
}

with:
if (virBufferCheckError(&buf) < 0)
    ...

This should not be a functional change (unless some callers
misused the virBuffer APIs - a different error would be reported
then)

So far, we only report an error if formatting the siblings bitmap
in NUMA topology fails.

Be consistent and always report error in virCapabilitiesFormatXML.

Check if the buffer is in error state and report an error if it is.

This replaces the pattern:
if (virBufferError(buf)) {
    virReportOOMError();
    goto cleanup;
}
with:

if (virBufferCheckError(buf) < 0)
    goto cleanup;

Document typical buffer usage to favor this.
Also remove the redundant FreeAndReset - if an error has
been set via virBufferSetError, the content is already freed.

This function didn't report an error on OOM. Better delete it
and use virStringReplace instead. :)

If v6present is false, this code is not reachable.
Also, there is no need to check for errors twice.

Reindent nwfilter gentech driver and one block in rbd storage backend.

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

We now support startupPolicy='optional' for disks, but this
should work only for cold boot, not for restore or migrate.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The comments for lxcDomainCreateXMLWithFiles are out of date. So update them.
And add comments for lxcDomainCreateXML
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>
Signed-off-by: NYue wenyuan <yuewenyuan@huawei.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

By default, the bus type is inferred from the style of the device
name('target' in this command), e.g. a device named 'sda' will
typically be exported using a SCSI bus. Actually, not only SCSI bus,
but USB/SATA bus also use this kind of device name. So add '--bus'
option for attach-disk command to allow user specify the target bus.
Signed-off-by: NYanbing Du <ydu@redhat.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

My commit fba6bc47 iterated over the features in cpu definition
without checking if there is one.