libvirtd.c: In function 'daemonSetupAccessManager':
libvirtd.c:730:18: error: declaration of 'driver' shadows
  a global declaration [-Werror=shadow]
     const char **driver = (const char **)config->access_drivers;
                  ^
In file included from libvirtd.c:95:0:
../src/node_device/node_device_driver.h:43:36: error: shadowed
  declaration is here [-Werror=shadow]
 extern virNodeDeviceDriverStatePtr driver;
                                    ^

When creating a RAW file, we don't take advantage
of clone of btrfs.

Add a VIR_STORAGE_VOL_CREATE_REFLINK flag to request
a reflink copy.
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Add a wrapper for BTRFS_IOC_CLONE ioctl.
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>
Signed-off-by: NJán Tomko <jtomko@redhat.com>

For stateless, client side drivers, it is never correct to
probe for secondary drivers. It is only ever appropriate to
use the secondary driver that is associated with the
hypervisor in question. As a result the ESX & HyperV drivers
have both been forced to do hacks where they register no-op
drivers for the ones they don't implement.

For stateful, server side drivers, we always just want to
use the same built-in shared driver. The exception is
virtualbox which is really a stateless driver and so wants
to use its own server side secondary drivers. To deal with
this virtualbox has to be built as 3 separate loadable
modules to allow registration to work in the right order.

This can all be simplified by introducing a new struct
recording the precise set of secondary drivers each
hypervisor driver wants

struct _virConnectDriver {
    virHypervisorDriverPtr hypervisorDriver;
    virInterfaceDriverPtr interfaceDriver;
    virNetworkDriverPtr networkDriver;
    virNodeDeviceDriverPtr nodeDeviceDriver;
    virNWFilterDriverPtr nwfilterDriver;
    virSecretDriverPtr secretDriver;
    virStorageDriverPtr storageDriver;
};

Instead of registering the hypervisor driver, we now
just register a virConnectDriver instead. This allows
us to remove all probing of secondary drivers. Once we
have chosen the primary driver, we immediately know the
correct secondary drivers to use.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

A bunch of code is wrapped in #if WITH_LIBVIRTD in order to
enable the virStateDriver to be disabled when libvirtd is not
built. Disabling this code doesn't have any real functional
benefit beyond removing 1 pointer from the virConnectPtr struct,
while having a cost of many more conditionals.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Now all drivers are converted to use their global state
directly, there is no need for private data fields for
the secondary drivers in virConnectPtr

The udev driver can be implemented using global state instead
of the connect private data.

The node device driver can rely on its global state instead
of the connect private data.

The vbox driver can use the main hypervisor private data and
so does not need to use the storage/network private data fields.

The nwfilter driver can rely on its global state instead
of the connect private data.

The secret driver can rely on its global state instead
of the connect private data.

The code modifies the domain configuration but doesn't take a MODIFY
type job to do so.

The function just queries status so there's no need for a MODIFY type
job.

The code modifies the domain configuration but doesn't take a MODIFY
type job to do so.

The code modifies the domain configuration but doesn't take a MODIFY
type job to do so.

The code modifies the domain configuration but doesn't take a MODIFY
type job to do so.

This patch also fixes a few very long lines of code around the touched
parts.

The code modifies the domain configuration but doesn't take a MODIFY
type job to do so.

The domain modifies the domain configuration but doesn't take a MODIFY
type job to do it.

* docs/news.html.in libvirt.spec.in: updated for the release
* po/*.po*: regenerated the po

The function may return NULL if something went wrong. In some places
in the tests we are not checking the return value rather than
accessing the pointer directly resulting in SIGSEGV.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Coverity reports that my commit af1c98e4 introduced
two memory leaks:
the cpumap if ncpus == 0 in virCgroupGetPercpuStats
and the params array in the test of the function.

After the 8-byte size header, there are two one-byte headers
and two bytes of padding before the crypt_header field.

Our QCOW1_HDR_CRYPT constant did not skip the padding.
http://git.qemu.org/?p=qemu.git;a=blob;f=block/qcow.c;h=ece22697#l41

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

Add a virDBusErrorIsUnknownMethod helper so that callers
don't need todo string comparisons themselves to detect
standard error names.

The virDBusMethodCall method has a DBusError as one of its
parameters. If the caller wants to pass a non-NULL value
for this, it immediately makes the calling code require
DBus at build time. This has led to breakage of non-DBus
builds several times. It is desirable that only the virdbus.c
file should need WITH_DBUS conditionals, so we must ideally
remove the DBusError parameter from the method.

We can't simply raise a libvirt error, since the whole point
of this parameter is to give the callers a way to check if
the error is one they want to ignore, without having the logs
polluted with an error message. So, we add a virErrorPtr
parameter which the caller can then either ignore or raise
using the new virReportErrorObject method.

This new method is distinct from virSetError in that it
ensures the logging hooks are run.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

For distros that want to add versioned machine types, they will add
(downstream) machine types like "virt-foo-1.2.3".  Detect these as
MMIO too.
Signed-off-by: NRichard W.M. Jones <rjones@redhat.com>

Previous patch of this series fixed the issue with adding a new PCI bridge
when all the slots were reserved by devices with user specified addresses.
In case there are still some PCI devices waiting to get a slot reserved
by qemuAssignDevicePCISlots, this means a new bus needs to be
created along with a corresponding bridge controller. By adding an
additional check, this scenario now results in a reasonable error
instead of generating wrong qemu command line.

Commit 93c8ca tried to fix the issue with auto-adding of a PCI bridge
controller, but didn't work properly in all scenarios.

This patch provides a better fix of the issue when all slots on a PCI bus
are reserved by devices with user specified addresses and no additional
bridges need to be created.

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

In order to be able to test for fully reserved PCI buses, assignment of
PCI slots for integrated devices needs to be moved to a separate function.
This also might be a good preparation if we decide to add support for
other chipsets as well.

Move qemuDomainAssignPCIAddresses after the definition
of the static function qemuDomainValidateDevicePCISlotsQ35.

This lets us define a new static function using
qemuDomainValidateDevicePCISlots* and use it in
qemuDomainAssignPCIAddresses without a forward declaration.
Signed-off-by: NJán Tomko <jtomko@redhat.com>

Allow reuse of the type.

The function doesn't allow to modify the array in any way, thus the
argument can be const.

@def is modified in the function indirectly although it's marked as
const.

After refactor to use the virTristateSwitch enum the comment in the
struct was not adjusted.

Apparmor must not prevent access to required helper programs. The following
helpers should be allowed to run in unconfined execution mode:

 - libvirt_parthelper
 - libvirt_iohelper

The network and nwfilter tests contained in the libvirt-TCK testkit can fail
unless access to raw network packets is granted. Without this access, the
following apparmor error can be seen while running the tests:

  apparmor="DENIED" operation="create" parent=1 profile="/usr/sbin/libvirtd"
  pid=94731 comm="libvirtd" family="packet" sock_type="raw" protocol=768

In order for apparmor to work properly in Xen environments, the following
access rights need to be allowed:

 - Allow CAP_SYS_PACCT, which is required when resetting some multi-port
   Broadcom cards by writting to the PCI config space

 - Allow CAP_IPC_LOCK, which is required to lock/unlock memory. Without
   this setting, an error 'Resource temporarily unavailable' can be seen
   while attempting to mmap memory. At the same time, the following
   apparmor message is seen:

   apparmor="DENIED" operation="capable" parent=1 profile="/usr/sbin/libvirtd"
   pid=2097 comm="libvirtd" pid=2097 comm="libvirtd" capability=14
   capname="ipc_lock"

 - Allow access to distribution specific directories:
     /usr/{lib,lib64}/xen/bin

Previously the function returned either -1 in case of an error or 0 on
success. However, we should also distinguish between a case we
successfully added a controller and a case there wasn't a need to add any
controller

As it turned out, fix of dead code 419a22 changed the affected condition
from "never true" to "always true", so better fix would be to change the
return code of virDomainMaybeAddController from 0 to 1 if
a new bridge has been added, thus distinguishing case when we didn't need to
add any controller and case we successfully added one.

The return code is changed in the next commit

My commit af1c98e4 broke the build on RHEL-6:
vircgrouptest.c: In function 'testCgroupGetPercpuStats':
vircgrouptest.c:566: error: nested extern declaration of
'_gl_verify_function2' [-Wnested-externs]

The only thing that needs checking is that the array size
is at least EXPECTED_NCPUS, to prevent access beyond the array.

We can ensure the minimum size also by specifying the array
size upfront.