Commit Graph

17637 Commits

Author SHA1 Message Date
Laine Stump
5f71959667 network: try to eliminate default network conflict during package install
Sometimes libvirt is installed on a host that is already using the
network 192.168.122.0/24. If the libvirt-daemon-config-network package
is installed, this creates a conflict, since that package has been
hard-coded to create a virtual network that also uses
192.168.122.0/24. In the past libvirt has attempted to warn of /
remediate this situation by checking for conflicting routes when the
network is started, but it turns out that isn't always useful (for
example in the case that the *other* interface/network creating the
conflict hasn't yet been started at the time libvirtd start its own
networks).

This patch attempts to catch the problem earlier - at install
time. During the %post install script for
libvirt-daemon-config-network, we use a case statement to look through
the output of "ip route show" for a route that exactly matches
192.168.122.0/24, and if found we search for a similar route that
*doesn't* match (e.g. 192.168.124.0/24) (note that the search starts
with "124" instead of 123 because of reports of people already
modifying their L1 host's network to 192.168.123.0/24 in an attempt to
solve exactly the problem we are also trying to solve).  When we find
an available route, we just replace all occurrences of "122" in the
default.xml that is being created with the newly found 192.168
subnet. This could obviously be made more complicated - examine the
template defaul.xml to automatically determine the existing network
address and mask rather than hard coding it in the specfile, etc, but
this scripting is simpler and gets the job done as long as we continue
to use 192.168.122.0/24 in the template. (If anyone with mad bash
skillz wants to suggest something to do that, by all means please do).

This is intended to at least "further reduce" occurrence of the
problems detailed in:

  https://bugzilla.redhat.com/show_bug.cgi?id=811967
2014-09-14 17:20:22 -04:00
Eric Blake
0a6a6b1ae7 blockjob: allow finer bandwidth tuning for set speed
We stupidly modeled block job bandwidth after migration
bandwidth, which in turn was an 'unsigned long' and therefore
subject to 32-bit vs. 64-bit interpretations.  To work around
the fact that 10-gigabit interfaces are possible but don't fit
within 32 bits, the original interface took the number scaled
as MiB/sec.  But this scaling is rather coarse, and it might
be nice to tune bandwidth finer than in megabyte chunks.

Several of the block job calls that can set speed are fed
through a common interface, so it was easier to adjust them all
at once.  Note that there is intentionally no flag for the new
virDomainBlockCopy; there, since the API already uses a 64-bit
type always, instead of a possible 32-bit type, and is brand
new, it was easier to just avoid scaling issues.  As with the
previous patch that adjusted the query side (commit db33cc24),
omitting the new flag preserves old behavior, and the
documentation now mentions limits of what happens when a 32-bit
machine is on either client or server side.

* include/libvirt/libvirt.h.in (virDomainBlockJobSetSpeedFlags)
(virDomainBlockPullFlags)
(VIR_DOMAIN_BLOCK_REBASE_BANDWIDTH_BYTES)
(VIR_DOMAIN_BLOCK_COMMIT_BANDWIDTH_BYTES): New enums.
* src/libvirt.c (virDomainBlockJobSetSpeed, virDomainBlockPull)
(virDomainBlockRebase, virDomainBlockCommit): Document them.
* src/qemu/qemu_driver.c (qemuDomainBlockJobSetSpeed)
(qemuDomainBlockPull, qemuDomainBlockRebase)
(qemuDomainBlockCommit, qemuDomainBlockJobImpl): Support new flag.

Signed-off-by: Eric Blake <eblake@redhat.com>
2014-09-12 08:11:11 -06:00
Eric Blake
eef91f9470 blockcopy: add qemu implementation of new tunables
Upstream qemu 1.4 added some drive-mirror tunables not present
when it was first introduced in 1.3.  Management apps may want
to set these in some cases (for example, without tuning
granularity down to sector size, a copy may end up occupying
more bytes than the original because an entire cluster is
copied even when only a sector within the cluster is dirty,
although tuning it down results in more CPU time to do the
copy).  I haven't personally needed to use the parameters, but
since they exist, and since the new API supports virTypedParams,
we might as well expose them.

Since the tuning parameters aren't often used, and omitted from
the QMP command when unspecified, I think it is safe to rely on
qemu 1.3 to issue an error about them being unsupported, rather
than trying to create a new capability bit in libvirt.

Meanwhile, all versions of qemu from 1.4 to 2.1 have a bug where
a bad granularity (such as non-power-of-2) gives a poor message:
error: internal error: unable to execute QEMU command 'drive-mirror': Invalid parameter 'drive-virtio-disk0'

because of abuse of QERR_INVALID_PARAMETER (which is supposed to
name the parameter that was given a bad value, rather than the
value passed to some other parameter).  I don't see that a
capability check will help, so we'll just live with it (and it
has since been improved in upstream qemu).

* src/qemu/qemu_monitor.h (qemuMonitorDriveMirror): Add
parameters.
* src/qemu/qemu_monitor.c (qemuMonitorDriveMirror): Likewise.
* src/qemu/qemu_monitor_json.h (qemuMonitorJSONDriveMirror):
Likewise.
* src/qemu/qemu_monitor_json.c (qemuMonitorJSONDriveMirror):
Likewise.
* src/qemu/qemu_driver.c (qemuDomainBlockCopyCommon): Likewise.
(qemuDomainBlockRebase, qemuDomainBlockCopy): Adjust callers.
* src/qemu/qemu_migration.c (qemuMigrationDriveMirror): Likewise.
* tests/qemumonitorjsontest.c (qemuMonitorJSONDriveMirror): Likewise.

Signed-off-by: Eric Blake <eblake@redhat.com>
2014-09-12 08:11:11 -06:00
Eric Blake
e3f5f8eefd blockcopy: add qemu implementation of new API
The hard part of managing the disk copy is already coded; all
this had to do was convert the XML and virTypedParameters into
the internal representation.

With this patch, all blockcopy operations that used the old
API should also work via the new API.  Additional extensions,
such as supporting the granularity tunable or a network rather
than file destination, will be added as later patches.

* src/qemu/qemu_driver.c (qemuDomainBlockCopy): New function.

Signed-off-by: Eric Blake <eblake@redhat.com>
2014-09-12 08:11:11 -06:00
Eric Blake
e53ee6c123 blockcopy: tweak how rebase calls into copy
In order to implement the new virDomainBlockCopy, the existing
block copy internal implementation needs to be adjusted.  The
new function will parse XML into a storage source, and parse
typed parameters into integers, then call into the same common
backend.  For now, it's easier to keep the same implementation
limits that only local file destinations are suported, but now
the check needs to be explicit.  Similar to qemuDomainBlockJobImpl
consuming 'vm', this code also consumes the caller's 'mirror'
description of the destination.

* src/qemu/qemu_driver.c (qemuDomainBlockCopy): Rename...
(qemuDomainBlockCopyCommon): ...and adjust parameters.
(qemuDomainBlockRebase): Adjust caller.

Signed-off-by: Eric Blake <eblake@redhat.com>
2014-09-12 08:11:10 -06:00
Michal Privoznik
dcf7d0423c formatdomain: Update <loader/> example to match the rest
At the beginning when I was inventing <loader/> attributes and
<nvram/> I've introduced this @readonly attribute to the loader
element. It accepted values 'on' and 'off'. However, later, during the
review process, that has changed to 'yes' and 'no', but the example
XML snippet wasn't updated, so while the description is correct, the
example isn't.

Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-12 14:26:34 +02:00
Michal Privoznik
273b6581ca virDomainUndefineFlags: Allow NVRAM unlinking
When a domain is undefined, there are options to remove it's
managed save state or snapshots. However, there's another file
that libvirt creates per domain: the NVRAM variable store file.
Make sure that the file is not left behind if the domain is
undefined.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-12 14:26:34 +02:00
John Ferlan
245134fc1d libxl: Resolve Coverity CHECKED_RETURN
Add a check of the return for virDomainHostdevInsert() like every
other call.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-12 06:12:50 -04:00
John Ferlan
78fbc79d85 qemu: Resolve Coverity FORWARD_NULL
If we end up at the cleanup lable before we've VIR_EXPAND_N the list,
then calling virQEMUCapsFreeStringList() with a NULL proplist could
theoretically deref proplist if nproplist was set. Coverity doesn't
seem to acknowledge the relationship between proplist and nproplist
assuming in virQEMUCapsFreeStringList that nproplist could be at
least 1 and thus have a null deref.  It only seems to follow the
NULL proplist.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-12 06:12:50 -04:00
John Ferlan
8d44f924ce virfile: Resolve Coverity RESOURCE_LEAK
With the virGetGroupList() change in place - Coverity further complains
that if we fail to virFork(), the groups will be leaked - which aha seems
to be the case. Adjust the logic to save off the -errno, free the groups,
and then return the value we saved

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-12 06:12:50 -04:00
John Ferlan
52e90b22cc virutil: Resolve Coverity RESOURCE_LEAK
This ends up being a very bizarre false positive. With an assist from
eblake, the claim is that mgetgroups() could return a -1 value, but yet
still have a groups buffer allocated, yet the example shown doesn't
seem to prove that.

Rather than fret about it, by adding a well placed sa_assert() on the
returned *list value we can "assure" ourselves that the mgetgroups()
failure path won't signal this condition.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-12 06:12:50 -04:00
John Ferlan
c77ac79d6b daemon: Resolve Coverity RESOURCE_LEAK
With eblake's help - adjust the checks for stdinfd/stdoutfd to ensure the
values are within the range we expect; otherwise the dup2()'s and subsequent
VIR_CLOSE() calls cause Coverity to believe there's a resource leak.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-12 06:12:50 -04:00
John Ferlan
be365d8dff virsh: Resolve Coverity NEGATIVE_RETURNS
Coverity notes that after we VIR_ALLOC_N(params, nparams) a failed call to
virDomainGetCPUStats could result in nparams being set to -1. In that case,
the subsequent virTypedParamsFree in cleanup will pass -1 which isn't good.

Use the returned value as the number of stats to display in the loop as
it will be the value reported from the hypervisor and may be less than
nparams which is OK

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-12 06:12:50 -04:00
Jiri Denemark
58252332eb virsh: Move --completed from resume to domjobinfo
Because of similar contexts, git rebase I did just before pushing the
series which added --completed option patched the wrong command.
2014-09-12 10:18:04 +02:00
Peter Krempa
2f2a992205 conf: snapshot: Don't default-snapshot empty drives
If a (floppy) drive isn't selected for snapshot explicitly and is empty
don't try to snapshot it. For external snapshots this would fail as we
can't generate a name for the snapshot from an empty drive.

Reported-by: Pavel Hrdina <phrdina@redhat.com>
2014-09-12 09:37:37 +02:00
Peter Krempa
5e3e991928 util: Add function to check if a virStorageSource is "empty"
To express empty drive we historically use storage source with empty
path. Unfortunately NBD disks may be declared without a path.

Add a helper to wrap this logic.
2014-09-12 09:37:37 +02:00
Michal Privoznik
3c07693aa2 libvirt.spec: Fix permission even for libvirt-driver-qemu
In my previous patch (37d8c75fad) I've tried to fix permissions
for nvram store path. The aim was to give the nvram directory
execute permission so that domain running under other users
than qemu:qemu can access their nvram file. However, my fix
was incomplete as the path belongs to libvirt-driver-qemu
package too and I've fixed it only for the libvirt-daemon
package.

Reported-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-12 09:01:46 +02:00
Jim Fehlig
817206cdc8 libxl: fix mapping of libvirt and libxl lifecycle actions
The libxl driver was blindly assigning libvirt's
virDomainLifecycleAction to libxl's libxl_action_on_shutdown, when
in fact the various actions take on different values in these enums.

Introduce helpers to properly map the enum values.

Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2014-09-11 15:40:56 -06:00
Daniel P. Berrange
47ffd5e8fd tests: Add more test suite mock helpers
Rename the VIR_MOCK_IMPL* macros to VIR_MOCK_WRAP*
and add new VIR_MOCK_IMPL macros which let you directly
implement overrides in the preloaded source.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2014-09-11 15:40:50 -06:00
Daniel P. Berrange
973173e6bf util: Allow port allocator to skip bind() check
Test suites using the port allocator don't want to have different
behaviour depending on whether a port is in use on the host. Add
a VIR_PORT_ALLOCATOR_SKIP_BIND_CHECK which test suites can use
to skip the bind() test. The port allocator will thus only track
ports in use by the test suite process itself. This is fine when
using the port allocator to generate guest configs which won't
actually be launched

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Signed-off-by: Jim Fehlig <jfehlig@suse.com>
2014-09-11 15:40:14 -06:00
Michal Privoznik
37d8c75fad nvram: Fix permissions
I've noticed two problem with the automatically created NVRAM varstore
file. The first, even though I run qemu as root:root for some reason I
get Permission denied when trying to open the _VARS.fd file. The
problem is, the upper directory misses execute permissions, which in
combination with us dropping some capabilities result in EPERM.

The next thing is, that if I switch SELinux to enforcing mode, I get
another EPERM because the vars file is not labeled correctly. It is
passed to qemu as disk and hence should be labelled as disk. QEMU may
write to it eventually, so this is different to kernel or initrd.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-11 16:16:27 +02:00
Pavel Hrdina
102eaa8817 util/virprocess.c: fix MinGW build
The build failed because of missing "sys/syscall.h".

Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
2014-09-11 15:16:02 +02:00
John Ferlan
6ff57f7475 libxl: Resolve Coverity NULL_RETURNS
With all the changes in my previous foray into this code, I forgot to
remove the libxlDomainEventQueue(driver, event); call inside the
dom == NULL condition.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:14 -04:00
John Ferlan
81a8fc34ad qemu: Resolve Coverity NEGATIVE_RETURNS
Coverity notes that if the virConnectListAllDomains returns a negative
value then the loop at the cleanup label that ends on numDomains will
have issues.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:14 -04:00
John Ferlan
b74a3fb307 qemu: Resolve Coverity NEGATIVE_RETURNS
Coverity notes that if qemuMonitorGetMachines() returns a negative
nmachines value, then the code at the cleanup label will have issues.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:14 -04:00
John Ferlan
947593f6e6 xen: Resolve Coverity NEGATIVE_RETURNS
Coverity notes that if the call to virBitmapParse() returns a negative
value, then when we jump to the error label, the call to
virCapabilitiesClearHostNUMACellCPUTopology() will have issues
with the negative nb_cpus

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:14 -04:00
John Ferlan
34476d720f nodeinfo: Resolve Coverity NEGATIVE_RETURNS
If the virNumaGetNodeCPUs() call fails with -1, then jumping to cleanup
with 'cpus == NULL' and calling virCapabilitiesClearHostNUMACellCPUTopology
will cause issues.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:14 -04:00
John Ferlan
35a50ea8c7 qemu: Resolve Coverity NEGATIVE_RETURNS
In qemuProcessInitPCIAddresses() if qemuMonitorGetAllPCIAddresses()
returns a negative (or zero) value, then no need to call the
qemuProcessDetectPCIAddresses().

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:14 -04:00
John Ferlan
8ffab1010a network_conf: Resolve Coverity FORWARD_NULL
The code compares def->forwarders when deciding to return 0 at a
couple of points, then uses "def->nfwds" as a way to index into
the def->forwarders array.  That reference results in Coverity
complaining that def->forwarders being NULL was checked as part
of an arithmetic OR operation where failure could be any one 5
conditions, but that is not checked when entering the loop to
dereference the array.  Changing the comparisons to use nfwds
will clear the warnings

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:14 -04:00
John Ferlan
e5baef83e1 qemu: Resolve Coverity FORWARD_NULL
If the qemuMigrationEatCookie() fails to set mig, we jump to cleanup:
which will call qemuMigrationCancelDriveMirror() without first checking
if mig == NULL

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:13 -04:00
John Ferlan
114ebecd98 virstring: Resolve Coverity FORWARD_NULL
Perhaps a false positive, but since Coverity doesn't understand the
relationship between the 'count' and the 'strings', rather than leave
the chance the on input 'strings' is NULL and causes a deref - just
check for it and return

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:13 -04:00
John Ferlan
d3f0708e84 network: Resolve Coverity FORWARD_NULL
If the VIR_STRDUP(exptime,...) fails, then we will jump to cleanup,
no need to check if exptime is set which causes Coverity to issue
a complaint in the virStrToLong_ll call because there wasn't a check
for a NULL value while there was one for the reference right after
the VIR_STRDUP().

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:13 -04:00
John Ferlan
f28a31fcc4 qemu: Resolve Coverity FORWARD_NULL
If we jump to cleanup before allocating the 'result', then the call
to virBlkioDeviceArrayClear will deref result causing a problem.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:13 -04:00
John Ferlan
0311be9435 lxc: Resolve Coverity FORWARD_NULL
If we jump to cleanup before allocating 'result', then the call to
virBlkioDeviceArrayClear() could dereference result

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:13 -04:00
John Ferlan
bf15f10abe qemu: Resolve Coverity FORWARD_NULL
If the virJSONValueNewObject() fails, then rather than going to error
and getting a Coverity false positive since it doesn't seem to understand
the relationship between nkeywords, keywords, and values and seems to
believe calling qemuFreeKeywords will cause a NULL deref - just return NULL

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:13 -04:00
John Ferlan
60b029c7a0 virsh: Resolve Coverity DEADCODE
Coverity points out that if 'dom' isn't returned from virDomainQemuAttach,
then the code already jumps to cleanup, so there was no need for the
subsequent if (dom != NULL) check.

I moved the error message about failure into the goto cleanup on failure
and then removed the if (dom != NULL)

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:13 -04:00
John Ferlan
a893b20eed tests: Resolve Coverity DEADCODE
Coverity complains that the various checks for autoincrement and changed
variables are DEADCODE - seems to me to be a false positive - so mark it.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:13 -04:00
John Ferlan
2676903fc0 qemu: Resolve Coverity DEADCODE
Add another 'dead_code_begin' - victims of our own coding practices

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:10:13 -04:00
John Ferlan
b46b7785ac virsh: Resolve Coverity DEADCODE
Coverity points out that by using EMPTYSTR(type) we are guarding against
the possibility that it could be NULL; however, based on how 'type' was
initialized to NULL, then using nested ternary if-then-else's (?:?:)
setting either "ipv4", "ipv6", or "" - there is no way it could be NULL.
Since "-" is supposed to mean something empty in a field - modify the
nested ternary to an easier to read/process if-then-else leaving the
initialization to NULL to mean "-" in the formatted output.

Also changed the name from 'type' to 'typestr'.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:06:16 -04:00
John Ferlan
6825bdad13 virfile: Resolve Coverity DEADCODE
Adjust the parentheses in/for the waitpid loops; otherwise, Coverity
points out:

(1) Event assignment:   Assigning: "waitret" = "waitpid(pid, &status, 0) == -1"
(2) Event between:      At condition "waitret == -1", the value of "waitret"
                        must be between 0 and 1.
(3) Event dead_error_condition:     The condition "waitret == -1" cannot
                        be true.
(4) Event dead_error_begin:     Execution cannot reach this statement:
                        "ret = -*__errno_location();".

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:03:37 -04:00
John Ferlan
daf27d4d82 virsh: Resolve Coverity DEADCODE
Since 0766783abb

Coverity complains that the EDIT_FREE definition results in DEADCODE.

As it turns out with the change to use the EDIT_FREE macro the call to
vir*Free() wouldn't be necessary nor would it happen...

Prior code to above commitid would :

  vir*Ptr foo = NULL;
  ...
  foo = vir*GetXMLDesc()
  ...
  vir*Free(foo);
  foo = vir*DefineXML()
  ...

And thus the free was needed.  With the change to use EDIT_FREE the
same code changed to:

  vir*Ptr foo = NULL;
  vir*Ptr foo_edited = NULL;
  ...
  foo = vir*GetXMLDesc()
  ...
  if (foo_edited)
      vir*Free(foo_edited);
  foo_edited = vir*DefineXML()
  ...

However, foo_edited could never be set in the code path - even with
all the goto's since the only way for it to be set is if vir*DefineXML()
succeeds in which case the code to allow a retry (and thus all the goto's)
never leaves foo_edited set

All error paths lead to "cleanup:" which causes both foo and foo_edited
to call the respective vir*Free() routines if set.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 08:03:37 -04:00
John Ferlan
f832aa3222 storage: Resolve Coverity OVERFLOW_BEFORE_WIDEN
Coverity complains that when multiplying to 32 bit values that eventually
will be stored in a 64 bit value that it's possible the math could
overflow unless one of the values being multiplied is type cast to
the proper size.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 07:33:19 -04:00
John Ferlan
9f845b1115 qemu: Resolve Coverity REVERSE_INULL
Coverity complains that checking for !domlist after setting doms = domlist
and making a deref of doms just above

It seems the call in question was intended to me made in the case that
'doms' was passed in and not when the virDomainObjListExport() call
allocated domlist and already called virConnectGetAllDomainStatsCheckACL().

Thus rather than check for !domlist - check that "doms != domlist" in
order to avoid the Coverity message.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 07:33:19 -04:00
John Ferlan
abddeb8434 vbox: Resolve Coverity UNUSED_VALUE
Handle a few places where Coverity complains about the value being
unused. For two of them (Close cases) - the comments above the close
indicate there is no harm to ignore the error - so added an ignore_value.
For the other condition, added an rc check like other callers.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 07:33:19 -04:00
John Ferlan
8ea809df15 storage: Resolve Coverity UNUSED_VALUE
Since cd4d547576

Coverity notes that setting 'ret = -3' prior to the unconditional
setting of 'ret = 0' will cause the value to be UNUSED.

Since the comment indicates that it is expect to allow the code
to continue, just remove the ret = -3 setting.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 07:33:19 -04:00
John Ferlan
f72f064269 qemu_driver: Resolve Coverity COPY_PASTE_ERROR
In qemuDomainSetBlkioParameters(), Coverity points out that the calls
to qemuDomainParseBlkioDeviceStr() are slightly different and points
out there may be a cut-n-paste error.

In the first call (AFFECT_LIVE), the second parameter is "param->field";
however, for the second call (AFFECT_CONFIG), the second parameter is
"params->field".  It seems the "param->field" is correct especially since
each path as a setting of "param" to "&params[i]".  Furthermore, there
were a few more instances of using "params[i]" instead of "param->"
which I cleaned up.

Signed-off-by: John Ferlan <jferlan@redhat.com>
2014-09-11 07:33:19 -04:00
Michal Privoznik
b635b7a1af selinux: Properly check TAP FD label
After a4431931 the TAP FDs ale labeled with image label instead
of the process label. On the other hand, the commit was
incomplete as a few lines above, there's still old check for the
process label presence while it should be check for the image
label instead.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2014-09-11 10:04:35 +02:00
Ján Tomko
6c555027dd qemu: remove leftover virResetLastError
As of commit 5d29ca0:
qemu: switch PCI address set from hash table to an array

There is no error to be reset.
2014-09-10 19:44:12 +02:00
Peter Krempa
78948e1c80 virsh: desc command in --title mode mentions description instead of title
Tweak the messages so that they mention "title" rather than
"description" when operating in title mode. Also fixes one missing "%s"
before non-formatted gettext message.

Before:
 $ virsh desc --title dom
 No description for domain: dom

After:
 $ virsh desc --title dom
 No title for domain: dom

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1140034
2014-09-10 14:39:46 +02:00
Peter Krempa
dc12cec6f6 util: storage: Convert disk locality check to switch statement
To allow the compiler to track future additions of disk types, convert
the function to use a switch statement with the correct type.
2014-09-10 13:12:45 +02:00