The check for whether the cgroup devices ACL is available is
done quite late during LXC hotplug - in fact after the device
node is already created in the container in some cases. Better
to do it upfront so we fail immediately.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The LXC disk hotplug code was allowing block or character devices
to be given as disk. A disk is always a block device.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

When detaching a USB device from an LXC guest we must remove
the device from the cgroup ACL. Unfortunately we were telling
the cgroup code to use the guest /dev path, not the host /dev
path, and the guest device node had already been unlinked.
This was, however, fortunate since the code passed &priv->cgroup
instead of priv->cgroup, so would have crash if the device node
were accessible.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

After hotplugging a USB device, the LXC driver forgot
to add the device def to the virDomainDefPtr.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The LXC code missed the 'usb' component out of the path
/dev/bus/usb/$BUSNUM/$DEVNUM, so it failed to actually
setup cgroups for the device. This was in fact lucky
because the call to virLXCSetupHostUsbDeviceCgroup
was also mistakenly passing '&priv->cgroup' instead of
just 'priv->cgroup'. So once the path is fixed, libvirtd
would then crash trying to access the bogus virCgroupPtr
pointer. This would have been a security issue, were it
not for the bogus path preventing the pointer reference
being reached.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

virDomainDefCompatibleDevice blocks use of USB if no USB
controller is present. This is not correct for containers
since devices can be assigned directly regardless of any
controllers.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Currently, there's just one place where we care if hook script is
changing the domain XML: migration hook for incoming migration. In
all other places where a hook script is executed, we don't read the
XML back from the script.

Anyway, the hook script can alter domain XML and hence we should taint
it if the script did.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

This new flag is to be used for tainting domains which
XML definition was altered at runtime by a hook script.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The internal pools were an idea in one of the first iterations of the
gluster series, which we decided not to use. Somehow the patch still
got pushed. Remove it as the internal flag isn't needed.

This reverts commit 362da820.

also validate it against the RNG schema.

This belongs to the pool definition.

Yet another variable name frowned upon by older compilers. Introduced in
commit b73c029d.

Also try to bind on IPv6 to check if the port is occupied.

Change the mocked bind in the test to return EADDRINUSE
for some ports only for the IPv4/IPv6 socket if we're testing
on a host with IPv6 compiled in.

Also mock socket() to make it fail with EAFNOTSUPPORTED
if LIBVIRT_TEST_IPV4ONLY is set in the environment, to
simulate a host without IPv6 support in the kernel. The
tests are repeated again with this variable set.

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

In a44b7b87 I've introduced a function
that initializes a storage file wrapper object on gluster based volumes.

The initialization function leaks the private data pointer in case of
failure. This patch fixes it.

Reported by John Ferlan.

In commit e3226818 I accidentally added
twice a typedef for virStorageFileBackend when I moved it between files
across patch iterations. The double declaration breaks build on older
compilers in RHEL5 and FreeBSD.

Remove the spurious definition.

Add support for gluster backed images as sources for snapshots in the
qemu driver. This will also simplify adding further network backed
volumes as sources for snapshot in case qemu will support them.

Use the new storage driver based "stat" api to detect exiting files just
as we did with local files.

Use the new storage driver APIs to delete snapshot backing files in case
of failure instead of directly relying on "unlink". This will help us in
the future when we will be adding network based storage without local
representation in the host.

Implement storage backend functions to deal with gluster volumes and
implement the "stat" and "unlink" backend APIs.

Implement the "stat" and "unlink" function for "file" volumes and "stat"
for "block" volumes using the regular system calls.

Add APIs that will allow to use the storage driver to assist in
operations on files even for remote filesystems without native
representation as files in the host.

All the data for getting the actual type is present in the snapshot
config. There is no need to have this function private to the qemu
driver and it will be re-used later in other parts of libvirt

All the data for getting the actual type is present in the domain
config. There is no need to have this function private to the qemu
driver and it will be re-used later in other parts of libvirt

Similar to cf76c4b3, if modules are used, then nwfilter configuration
requires the nwfilter driver module.
Signed-off-by: NEric Blake <eblake@redhat.com>

This reverts commit 8d6c3659.

After further list discussion, it was decided that pulling in
wireshark as a dependency is a bit too much for the base 'libvirt'
package.  Remember also that 'libvirt-devel' is also not pulled in
by the base 'libvirt' - the metapackage exists for full
functionality of libvirtd, rather than to pull in all subpackages.

Remove double "is".
Consistent spelling of all-uppercase I/O.
Signed-off-by: NPhilipp Hahn <hahn@univention.de>

In general, the 'libvirt' metapackage should pull in all subpackages.
Fix this for the wireshark subpackage created in commit f9ada9f3.

* libvirt.spec.in (Requires): Add dependency.
Signed-off-by: NEric Blake <eblake@redhat.com>

When building modules, libvirt-daemon-config-network requires
libvirt-daemon-driver-network to ensure the 'default' network
is setup properly
Signed-off-by: NEric Blake <eblake@redhat.com>

Signed-off-by: NEric Blake <eblake@redhat.com>

The problem with VLAN is that the user still has to manually create the
vlan interface on the host. Then the generated configuration will use
it as a nerwork hostdev device. So the generated configurations of the
following two fragments are equivalent (see rhbz#1059637).

lxc.network.type = phys
lxc.network.link = eth0.5

lxc.network.type = vlan
lxc.network.link = eth0
lxc.network.vlan.id = 5