The storage driver helper functions that deal with parted were put into
the disk backend code but are used commonly across.

While local builds succeed fine, a build worker building in a
chroot environment is encountering the following error with
libvirt 3.0.0 release candidates

[  162s] shunloadtest.o: In function `main':
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:110: undefined reference to `dlopen'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:114: undefined reference to `dlsym'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:133: undefined reference to `dlclose'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:111: undefined reference to `dlerror'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:115: undefined reference to `dlerror'
[  162s] /home/abuild/rpmbuild/BUILD/libvirt-3.0.0/tests/shunloadtest.c:116: undefined reference to `dlclose'

Fix by appending DLOPEN_LIBS to shunloadtest_LDADD.

This patch will allow --uuid and --name in one cmd.
The pool's UUID and name will be printed side by side.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

This patch will introduce option --name.
If specified, only name of pools will be printed out.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

This patch will introduce option --uuid.
If specified, only UUID of pools will be printed out.
Signed-off-by: NChen Hanxiao <chenhanxiao@gmail.com>

fabric_name is one of many fc_host attributes in Linux that is optional
and left to the low-level driver to decide if it is implemented.
The zfcp device driver does not provide a fabric name for an fcp host.

This patch removes the requirement for a fabric name by making it optional.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

File open errors are prevented by a file exists check before
virFileReadAll is called since all callers of the virReadFCHost
method handle errors themselves based on the NULL return anyway.
Also included is a minor spelling correction in a comment.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>

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

If libvirt_parthelper is erroneously told to append the partition
separator 'p' onto the generated output for a disk pool using device
mapper that has 'user_friendly_names' set to true, then the error
recovery path will fail to find volume resulting in the pool being
in an unusable state.

So, augment the documentation to provide the better hint that the
part_separator='yes' should be set when user_friendly_names are not
being used. Additionally, once we're in the error path where the
returned name doesn't match the expected partition name try to see
if the reason is because the 'p' was erroneosly added. If so alter
the about to be removed vol->target.path so that the DiskDeleteVol
code can find the partition that was created and remove it.

If the voldef type is VIR_STORAGE_VOL_BLOCK, then as long as the
format is known, let's allow the probe to happen - gets a truer value
and the same probe/update would be allowed for the same volume defined
in a domain.

For volume processing in virStorageBackendUpdateVolTargetInfo to get
the capacity commit id 'a760ba3a' added the ability to probe a volume
that didn't list a target format. Unfortunately, the code used the
virStorageSource  (e.g. target->type - virStorageType) rather than
virStorageVolDef (e.g. vol->type - virStorageVolType) in order to
make the comparison. As it turns out target->type for a volume is
not filled in at all for a voldef as the code relies on vol->type.
Ironically the result is that only VIR_STORAGE_VOL_BLOCK's would get
their capacity updated.

This patch will adjust the code to check the "vol->type" field instead
as an argument. This way for a voldef, the correct comparison is made.

Additionally for a backingStore, the 'type' field is never filled in;
however, since we know that the provided path is a location at which
the backing store can be accessed on the local filesystem thus just
pass VIR_STORAGE_VOL_FILE in order to satisfy the adjusted voltype
check. Whether it's a FILE or a BLOCK only matters if we're trying to
get more data based on the target->format.

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

Starting from a245abce another set of tests for
qemuhotplugtest has been introduced. This time for vcpu hotplug.
However, the test data (which live in qemuhotplugtestcpus dir)
are not being distributed properly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The gluster command line tool that is used to lookup storage pool
sources moved from the gluster-client package to gluster-cli.

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

The tool is used for pool discovery. Since we call an external binary we
don't really need to compile out the code that uses it. We can check
whether it exists at runtime.

Similarly to the 'netfs' pool, return an error if the host does not have
any volumes.

In commit 4090e153 we went back from reporting no errors if no storage
pools were found on a given host to reporting a bad error. And only in
cases when gluster was not installed.

Report a less bad error in case there are no volumes. Also report the
error when gluster is installed but no volumes were found, since
virStorageBackendFindGlusterPoolSources would return success in that
case.

Add a positive test and few negative tests.

Test that the old approach generates correct commands.

The cpu hotplug operation is rather complex so the testing code needs to
provide quite lot of data and monitor conversations to successfully test
it. The code mainly tests the selection of cpus according to the target
count request.

Similar to the existing qemuMonitorTestNewFromFile the *Full version
will allow to check both commands and supply responses for a better
monitor testing.

Add test monitor infrastructure that will test the commands verbatim
rather than trying to do any smart handling.

Move all the worker code into the appropriate file. This will also allow
testing of cpu hotplug.

Extract the call to qemuDomainSelectHotplugVcpuEntities outside of
qemuDomainSetVcpusLive and decide whether to hotplug or unplug the
entities specified by the cpumap using a boolean flag.

This will allow to use qemuDomainSetVcpusLive in cases where we prepare
the list of vcpus to enable or disable by other means.

For use in test cases it will be helpful to allow reformatting JSON
strings. Add a wrapper on top of the parser and formatter to achieve
this.

In cases where CPU hotplug is supported by qemu force the monitor to
reject invalid or broken responses to 'query-cpus'. It's expected that
the command returns usable data in such case.

When LIBXL_HAVE_QED is defined, xlconfigtest fails

 9) Xen XL-2-XML Format disk-qed  ... command line: config parsing error
 in disk specification: no vdev specified in
 `target=/var/lib/libvirt/images/XenGuest2,format=qed,backendtype=qdisk,vdev=hda,access=rw'
FAILED

As per the xl-disk-configuration(5) man page, target= must come
last in the disk specification when specified by name:

When this parameter is specified by name, ie with the target=
syntax in the configuration file, it consumes the whole rest of the
DISKSPEC including trailing whitespaces.  Therefore in that case
it must come last.

Change tests/xlconfigdata/test-disk-qed.cfg to adhere to this
restriction.

The problem is in the way how the list item is created prior to
appending it to the transaction list - the @path argument is just a
shallow copy instead of deep copy of the hostdev device's path.
Unfortunately, the hostdev devices from which the @path is extracted, in
order to add them into the transaction list, are only temporary and
freed before the buildup of the qemu namespace, thus making the @path
attribute in the transaction list NULL, causing 'permission denied' or
'double free' or 'unknown cause' errors.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1413773Signed-off-by: NErik Skultety <eskultet@redhat.com>

The problem is in the way how the list item is created prior to
appending it to the transaction list - the @path attribute is just a
shallow copy instead of deep copy of the hostdev device's path.
Unfortunately, the hostdev devices from which the @path is extracted, in
order to add them into the transaction list, are only temporary and
freed before the buildup of the qemu namespace, thus making the @path
attribute in the transaction list NULL, causing 'permission denied' or
'double free' or 'unknown cause' errors.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1413773Signed-off-by: NErik Skultety <eskultet@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

While all the code that deals with qemu namespaces correctly
detects whether we are running as root (and turn into NO-OP for
qemu:///session) the actual unshare() call is not guarded with
such check. Therefore any attempt to start a domain under
qemu:///session shall fail as unshare() is reserved for root.

The fix consists of moving unshare() call (for which we have a
wrapper called virProcessSetupPrivateMountNS) into
qemuDomainBuildNamespace() where the proper check is performed.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Tested-by: NRichard W.M. Jones <rjones@redhat.com>

This reverts commit ae16c95f.

Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

For case VIR_STORAGE_BLKID_PROBE_DIFFERENT, clean up the message to
avoid using the virsh like --overwrite syntax. Additionally provide
a different error message when not writing the label to avoid confusion.

Rather than special casing the VIR_STORAGE_BLKID_PROBE_UNKNOWN after
calling virStorageBackendBLKIDFindPart, just allow the switch statement
handle setting ret = -2.