My commit 3e428670 started filling out the video size in post-parse,
but did not adjust the tests.

Move filling out the default video (v)ram to DeviceDefPostParse.

This means it can be removed from virDomainVideoDefParseXML
and qemuParseCommandLine. Also, we no longer need to special case
VIR_DOMAIN_VIRT_XEN, since the per-driver callback gets called
before the generic one.

Commit 6879be48 moved adding of an implicit video device after XML
parsing. As a result, libxlDomainDeviceDefPostParse() is no longer
called to set the default vram when adding an implicit device.
Commit 6879be48 assumes virDomainVideoDefaultRAM() will set the
default vram, but it returns 0 if the domain virtType is
VIR_DOMAIN_VIRT_XEN. Attempting to start an HVM domain with vram=0
results in

error: unsupported configuration: videoram must be at least 4MB for CIRRUS

The default vram setting for Xen HVM domains depends on the device
model used (qemu-xen vs qemu-traditional), hence setting the
default is deferred to libxlDomainDeviceDefPostParse().

Call the device post-parse callback even for implicit video,
to fill out the default vram even for VIR_DOMAIN_VIRT_XEN.

https://bugzilla.redhat.com/show_bug.cgi?id=1334557Most-of-commit-message-by: NJim Fehlig <jfehlig@suse.com>

Future commit will call DeviceDefPostParse on a device auto-added
in DomainDefPostParse.

Both virGetLastError and virGetLastErrorMessage call virLastErrorObject method
that returns a thread-local error object. However, if a direct call to malloc
or pthread_setspecific (probably also due to malloc, since it sets ENOMEM)
fail, virLastErrorObject returns NULL which, although incorrectly interpreted
by virGetLastError as no error, still requires the caller to check for NULL
pointer. This isn't the case with virGetLastErrorMessage that also treated it
incorrectly as no error, but returned the literal "no error".
This patch tweaks the checks in the virGetLastErrorMessage function, so that
if virLastErrorObject failed, it returned "unknown error" which is equivalent
to the current approach with virGetLastError and if it returned NULL,
"unknown error" was set.
Signed-off-by: NErik Skultety <eskultet@redhat.com>

syntax-check complained about broken indentation in libvirt.spec.in which was
broken by commit 3694e038Signed-off-by: NErik Skultety <eskultet@redhat.com>

We were adding a sheepdog requirement at runtime, but forgetting
to turn it on at build time, so the underlying code was never
built.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The %changelog entries in the RPM are just a poor immitation
of the release notes, which is not what %changelog section
is for. It should be reflecting changes in the RPM packaging,
not changes in the application releases. Further, this bogus
list of changes has to be manually deleted every time we sync
the RPM with Fedora. Remove them, since they serve no useful
purpose.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Rather than letting the configure script auto-detect features
we expect, use --with-xxx to explicitly mandate them. This
ensures that we get an error upfront when running configure,
rather than a failure later during build or RPM file packaging
time.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build the nss plugin at all times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with libnl3 at all times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with macvtap at all times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with libpcap at all times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with the nwfilter driver enabled
at all times
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with the nodedev driver enabled
at all times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with the storage driver and
most of its sub-drivers enabled at all times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with the network driver
enabled at all times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with the interface driver
enabled at all times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with selinux enabled at all
times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with yajl enabled at all times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with polkit enabled at all
times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with sasl enabled at all times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with dtrace enabled at all
times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with audit enabled at all
times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with netcf enabled at all
times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with udev enabled at all
times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with capng enabled at all
times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Neither RHEL or Fedora build apparmor
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Neither RHEL or Fedora build HAL anymore.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with avahi enabled at all
times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with libvirtd enabled at
all times.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Both RHEL and Fedora build with driver modules enabled by
default, so there is no need for any conditional.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

A client only build dates back to RHEL5 where some architectures
did not build the libvirtd daemon, only the clients. Since RHEL5
was dropped this is no longer required.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Simplify conditionals to assume Fedora >= 20 or RHEL >= 6

The %prep section will explicitly check the version and
refuse to run if insufficient.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

The xenapi & vz drivers won't build in Fedora or RHEL
since their deps don't exist there.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Commit id 'df1011ca' modified virStorageBackendDiskDeleteVol to use
"dmsetup remove --force" to remove the volume, but left things in an
inconsistent state since the partition still existed on the disk and
only the device mapper device (/dev/dm-#) was removed.

Prior to commit '1895b421' (or '1ffd82bb' and '471e1c4e'), this could
go unnoticed since virStorageBackendDiskRefreshPool wasn't called.
However, the pool would be unusable since the /dev/dm-# device would
be removed even though the partition was not removed unless a multipathd
restart reset the link. That would of course make the volume appear again
in the pool after a refresh or pool start after libvirt reload.

This patch removes the 'dmsetup' logic and re-implements the partition
deletion logic for device mapper devices. The removal of the partition
via 'parted rm --script #' will cause udev device change logic to allow
multipathd to handle removing the dm-* device associated with the partition.

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

Commit id '020135dc' didn't quite get the algorithm correct when a
device mapper source ended with a non numeric value (e.g. ends with
an alphabet value).

This patch modifies the 'part_separator' logic to add the "p" separator
to the attempted target path name only when specified as part_separator='yes'.

For a source name that already ends with a number, the logic doesn't change
as the part separator would need to be there.

For a source name that ends with something other than a number, this allows
the possibility that a "p" separator can be added. The default for one of
these source devices is to not add the separator.

The key for device mapper and the need for a partition separator "p" is
the presence of a number in the last character of the device name link
in /dev/mapper.  A name such as "/dev/mapper/mpatha1" would generate
a "/dev/mapper/mpatha1p1" partition, while "/dev/mapper/mpatha" would
generate partition "/dev/mapper/mpatha1". Similarly for a device
mapper entry not using friendly names or an alias, a device such as
"/dev/mapper/3600a0b80005b10ca00005ad656fd8d93" would generate a
paritition "/dev/mapper/3600a0b80005b10ca00005ad656fd8d93p1", while
a device such as "/dev/mapper/3600a0b80005b10ca00005e115729093f" would
generate a partition "/dev/mapper/3600a0b80005b10ca00005e115729093f1".
The long number is the WWID of the device. It's also possible to assign
an alias for a device mapper entry, that alias follows the same rules
with respect to ending with a number or not when adding a "p" to create
the target device path.

Prior to calling the 'refreshPool' during CreatePool or UploadPool
operations, we need to clear the pool; otherwise, the pool will
have duplicated entries.

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

Commit id 'dd519a29' caused a regression cloning a volume into a
logical pool by removing just the 'allocation' adjustment during
storageVolCreateXMLFrom. Combined with the change to not require the
new volume input XML to have a capacity listed (commit id 'e3f1d2a8')
left the possibility that a zero allocation value (e.g., not provided)
would create a thin/sparse logical volume. When a thin lv becomes fully
populated, then LVM sets the partition 'inactive' and the subsequent
fdatasync() fails.

Add a new 'has_allocation' flag to be set at XML parse time to indicate
that allocation was provided. This is done so that if it's not provided
the create-from code uses the capacity value since we document that if
omitted, the volume will be fully allocated at time of creation.

For a logical backend, that creation time is 'createVol', while for a
file backend, creation doesn't set the size, but the 'createRaw' called
during buildVolFrom will decide whether the file is sparse or not based
on the provided capacity and allocation value.

For volume clones that provide different allocation and capacity values
to allow for sparse files, there is no change.