Signed-off-by: NChunyan Liu <cyliu@suse.com>

Only wait for kvm device cleanup if the driver is pci-stub

Extract general code from qemuPrepareHostdevPCIDevices to
virHostdevPrepareHostdevPCIDevices.

For extracting hostdev codes from qemu_hostdev.c to common library, change qemu
specific COLD_BOOT handling to be a flag, and pass it to hostdev functions.

For extracting hostdev codes from qemu_hostdev.c to common library, change qemu
specific cfg->relaxedACS handling to be a flag, and pass it to hostdev
functions.

Same logic of preparing/reattaching hostdevs could be used in attach/detach
hotplug places, so reuse hostdev interfaces to avoid duplicate, also for later
extracting general code to common library.

Update parameters from vm->def to specific name, hostdevs, nhostdevs to keep
consistentcy with PreparePCIDevices and PrepareSCSIDevices. And, at the same
time, make it reusable in later patch.

Use virObject to virHostdevManager, so that each driver using virHostdevManager
can keep a reference to it, and through counting refs to make virHostdevManager
get freed.

When libvirtd is run from a build directory without being installed, it
should not depend on files from a libvirt package installed in the
system. Not only because there may not be any libvirt installed at all.
We already do a good job for plugins but cpu_map.xml was still loaded
from the system.

The Makefile.am change is necessary to make this all work from VPATH
builds since libvirtd has no idea where to find libvirt sources. It only
knows the path from which it was started, i.e, a builddir.

https://bugzilla.redhat.com/show_bug.cgi?id=1074327Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

So far it's just virCommandSetDryRun.

This allows it to be used by the VIR_*_ELEMENT macros.

Also use them for parsing the definiton and remove the redundant
freeing of 'nodeset' before jumping to the cleanup label.

Open-coding one VIR_FREE in the test suite just doesn't seem right.

It quacks like a bool.

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

Add a missing goto err_exit in the error path where an unsupported
value is assigned to the CTRL_IP_LEARNING key.
Signed-off-by: NStefan Berger <stefanb@linux.vnet.ibm.com>

When attaching to a QEMU process, the def->seclabels array is
going to be empty. The qemuProcessAttach method must thus
populate it with data for the security drivers.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

While investigating https://bugzilla.redhat.com/show_bug.cgi?id=1061827
I noticed that we pass user input unscathed for block-pull, but
always pass a canonical absolute name through for block-commit.
[Note that we probably _ought_ to validate that the user's request
for block-pull actually matches the backing chain, the way we already
do for block-commit - but that's a separate issue.  Further note that
the ability to pass user input through unscathed allows backdoors
such as specifying a backing image that is a network URI such as
a gluster disk, instead of forcing things to the local file system;
which is an area still under active investigation on whether libvirt
needs to behave differently for network disks.]

Since qemu may write the name that the user passed in as the backing
file, a user may have a reason to want a relative file name passed
through to qemu, and always munging things to absolute prevents that.

Put another way, if you have the backing chain:

[A] <- [B(back=./A)] <- [C(back=./B)]

and commit B into A (virsh blockcommit $dom vda --base A --top B),
the metadata of C will have to be re-written. But should it be
rewritten as [C(back=./A)] or as [C(back=/path/to/A)]?  Still up in
the air is whether qemu's decision should be based on whether B
and/or C had relative paths, or on whether the --base and/or
--top arguments to the command were relative paths; but if we always
pass a canonical name, we've prevented the spelling of the command
arguments from being part of the hueristics that qemu uses.

I also audited the code, and verified that we never call
qemuMonitorBlockCommit() with a NULL base, either before or after
the change to qemu_driver.c.

* src/qemu/qemu_driver.c (qemuDomainBlockCommit): Preserve user's
spelling, since absolute vs. relative matters to qemu.
* src/qemu/qemu_monitor.h (qemuMonitorBlockCommit): Base is never
null.
* src/qemu/qemu_monitor.c (qemuMonitorBlockCommit): Likewise.
* src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockCommit):
Likewise.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockCommit):
Likewise.
Signed-off-by: NEric Blake <eblake@redhat.com>

Commit b9dd878f caused a regression in iptables interaction by
logging non-zero status at a higher level than VIR_INFO.  Revert
that portion of the commit, as well as adding a comment explaining
why we check the status ourselves.

Reported by Nehal J Wani.

* src/util/viriptables.c (virIpTablesOnceInit): Undo log regression.
Signed-off-by: NEric Blake <eblake@redhat.com>

Supporting sexpr in connectDomainXMLFromNative in the libxl driver
adds flexibility for users importing legacy Xen configuration into
libvirt.  E.g. this patch allows importing previous xend-managed
domains from /var/lib/xend/domains/<dom-uuid>/config.sxp into the
libvirt libxl driver.

From commit id 'd53bbfd1'

Found one core and one possible memory leak. Core seen during local
virt-test/tp_libvirt run for the vol_create_from test. The memory leak
was seen by inspection during a review of all VIR_APPEND_ELEMENT changes

In storage_backend_disk/virStorageBackendDiskMakeDataVol(), the 'vol'
needs to be kept around since it's used later, so use the _COPY macro.
This caused a segv in libvirtd:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe87c3700 (LWP 6919)]
virStorageBackendDiskMakeDataVol (vol=0x0, groups=0x7fffc8000d70, pool=0x7fffc8002460) at storage/storage_backend_disk.c:66
66          if (vol->target.path == NULL) {

In storage_backend_rbd/virStorageBackendRBDRefreshPool() there's a failure
path where the 'vol' needs to go through virStorageVolDefFree() since it
wouldn't be appended.

The qemu_bridge_filter.c file had some helpers for calling
the ebtablesXXX functions todo bridge filtering. The only
thing these helpers did was to overwrite the original error
message from the ebtables code. For added fun, the callers
of these helpers overwrote the errors yet again. For even
more fun, one of the helpers called another helper and
overwrite its errors too.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The ebtablesRemoveForwardPolicyReject method was unused and
would not do anything useful even if called.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The ebtRules data structure serves no useful purpose as
the table name is never used and only 1 single chain name
needs to be stored. Just store the chain name directly
in the ebtablesContext instead.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When adding/removing ebtables rules, the code would keep
an array of all rules in memory. This list of rules was
never used for any purpose and would be lost if libvirtd
restarted. Delete all the unused code.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The input_filter and nat_postrouting variables were never
used to create any firewall rules.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The ebtablesForwardPolicyReject method is only used internally
to the ebtables code and thus should have been static.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

There is no impl of the ebtablesSaveRules method and nothing
attempts to use it.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The bridge_driver_platform.h defines many functions that
a platform driver must implement. Only two of these
functions are actually called from the main bridge driver
code. The remainder can be made internal to the linux
driver only.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Extracting capabilities from QEMU takes a notable amount of time
when all QEMU binaries are installed. Each system emulator
needs about 200-300ms multiplied by 26 binaries == ~5-8 seconds.

This change causes the QEMU driver to save an XML file containing
the content of the virQEMUCaps object instance in the cache
dir eg /var/cache/libvirt/qemu/capabilities/$SHA256(binarypath).xml
or $HOME/.cache/libvirt/qemu/cache/capabilities/$SHA256(binarypath).xml

We attempt to load this and only if it fails, do we fallback to
probing the QEMU binary. The ctime of the QEMU binary and libvirtd
are stored in the cached file and its data discarded if either
of them change.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Debian's package manager will preserve mtime timestamp on binaries
from the time they are built, rather than installed. So if a
user downgrades their QEMU dpkg, the libvirt capabilities
cache will not refresh. The fix is to use ctime instead of mtime
since it cannot be faked.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The future QEMU capabilities cache needs to be able to invalidate
itself if the libvirtd binary or any loadable modules are changed
on disk. Record the 'ctime' value for these binaries and provide
helper APIs to query it. This approach assumes that if libvirt.so
is changed, then libvirtd will also change, which should usually
be the case with libtool's wrapper scripts that cause libvirtd to
get re-linked
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>