The comment claimed that virPCIDeviceReattach() does not reattach
a device to the host driver; except it actually does, so the
comment is just confusing and we're better off removing it.

Replace the term "loop" with the more generic "step". This allows us
to be more flexible and eg. have a step that consists in a single
function call.

Don't include the number of steps in the first comment of the
function, so that we can add or remove steps without having to worry
about keeping that comment in sync.

For the same reason, remove the summary contained in that comment.

Clean up some weird vertical spacing while we're at it.

If the stars are in the right position and you're building with
VBox >= 4.2.0 it will happen that compiler thinks an array
allocated on the stack may be unbounded:

In file included from vbox/vbox_V4_2.c:13:0:
vbox/vbox_tmpl.c: In function '_virtualboxCreateMachine':
vbox/vbox_tmpl.c:2811:1: error: stack usage might be unbounded [-Werror=stack-usage=]
 _virtualboxCreateMachine(vboxGlobalData *data, virDomainDefPtr def, IMachine **machine, char *uuidstr ATTRIBUTE_UNUSED)
 ^

Well, given how the variable is declared, I had some hard time
seeing it is actually bounded. Surprisingly compiler does not
complain because of -Wframe-larger-than. This is because
variable length arrays do not count into that warning.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

So far it hasn't bitten us, but if the next value wasn't 4, then
the logic used to check flag bits would have issues.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1315059Signed-off-by: NShanzhi Yu <shyu@redhat.com>

The code does not handle renaming of the save state file. In addition to
that the resuming code would need to be tweaked to handle the name
change since the XML is extracted from the save image. The easies option
is to make the rename API even less useful by forbiding this.

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

This is an error message I've just seen. Fix it by initializing
@inode.

  CC       lxc/libvirt_driver_lxc_impl_la-lxc_process.lo
lxc/lxc_process.c: In function 'virLXCProcessMonitorInitNotify':
lxc/lxc_process.c:767:23: error: 'inode' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     virDomainAuditInit(vm, initpid, inode);
                       ^
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Original current flag expansion does not filter out non
_CONFIG and _LIVE flags explicitly but they are prohibited
earlier by virCheckFlags.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Flag expansion is the same as in virDomainObjUpdateModificationImpact
which virDomainLiveConfigHelperMethod calls internally. The difference
is merely in implementation. Note that VIR_DOMAIN_MEM_CONFIG is the
same as VIR_DOMAIN_AFFECT_CONFIG.  Additionally, the called functions
will properly use flag OR and thus handle the VIR_DOMAIN_MEM_MAXIMUM case.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

While trying to build with -Os couple of compile errors showed
up.

conf/domain_conf.c: In function 'virDomainChrRemove':
conf/domain_conf.c:13666:24: error: 'ret' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     virDomainChrDefPtr ret, **arrPtr = NULL;
                        ^
Compiler fails to see that @ret is used only if set in the loop,
but whatever, there's no harm in initializing the variable.

In vboxAttachDrivesNew and _vboxAttachDrivesOld compiler thinks
that @rc may be used uninitialized. Well, not directly, but maybe
after some optimization. Yet again, no harm in initializing a
variable.

In file included from ./util/virthread.h:26:0,
                 from ./datatypes.h:28,
                 from vbox/vbox_tmpl.c:43,
                 from vbox/vbox_V3_1.c:37:
vbox/vbox_tmpl.c: In function '_vboxAttachDrivesOld':
./util/virerror.h:181:5: error: 'rc' may be used uninitialized in this function [-Werror=maybe-uninitialized]
     virReportErrorHelper(VIR_FROM_THIS, code, __FILE__,              \
     ^
In file included from vbox/vbox_V3_1.c:37:0:
vbox/vbox_tmpl.c:1041:14: note: 'rc' was declared here
     nsresult rc;
              ^
Yet again, one uninitialized variable:

qemu/qemu_driver.c: In function 'qemuDomainBlockCommit':
qemu/qemu_driver.c:17194:9: error: 'baseSource' may be used uninitialized in this function [-Werror=maybe-uninitialized]
         qemuDomainPrepareDiskChainElement(driver, vm, baseSource,
         ^

And another one:

storage/storage_backend_logical.c: In function 'virStorageBackendLogicalMatchPoolSource.isra.2':
storage/storage_backend_logical.c:618:33: error: 'thisSource' may be used uninitialized in this function [-Werror=maybe-uninitialized]
                       thisSource->devices[j].path))
                                 ^
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

While trying to build with -Os I've encountered some build
failures.

util/vircommand.c: In function 'virCommandAddEnvFormat':
util/vircommand.c:1257:1: error: inlining failed in call to 'virCommandAddEnv': call is unlikely and code size would grow [-Werror=inline]
 virCommandAddEnv(virCommandPtr cmd, char *env)
 ^
util/vircommand.c:1308:5: error: called from here [-Werror=inline]
     virCommandAddEnv(cmd, env);
     ^
This function is big enough for the compiler to be not inlined.
This is the error message I'm seeing:

Then virDomainNumatuneNodeSpecified is exported and called from
other places. It shouldn't be inlined then.

In file included from network/bridge_driver_platform.h:30:0,
                 from network/bridge_driver_platform.c:26:
network/bridge_driver_linux.c: In function 'networkRemoveRoutingFirewallRules':
./conf/network_conf.h:350:1: error: inlining failed in call to 'virNetworkDefForwardIf.constprop': call is unlikely and code size would grow [-Werror=inline]
 virNetworkDefForwardIf(const virNetworkDef *def, size_t n)
 ^
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Reporting status of a control connection makes no sense for an inactive
domain.

https://bugzilla.redhat.com/show_bug.cgi?id=1281706Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

More fallout from changing to using virPolkitAgent and handling error
paths.  Needed to clear the 'cmd' once stored and of course add the
virCommandFree(cmd) in the error: label.

Older compilers fail to see that 'close' is not used a function
rather than a variable and produce the following error:

cc1: warnings being treated as errors
../../src/datatypes.c: In function 'virConnectCloseCallbackDataReset':
../../src/datatypes.c:149: error: declaration of 'close' shadows a global declaration [-Wshadow]

Replace all the 'close' occurrences with 'closeData' to resolve
this.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

In virPolkitAgentCreate neglected to initialize agent to NULL. If
there was an error in the pipe, then we jump to error and would have
an issue. Found by coverity.

libxlDomainPinVcpuFlags calls virDomainLiveConfigHelperMethod which will
call virDomainObjUpdateModificationImpact make the same AFFECT_LIVE flags
and !active check, so remove this duplicated check.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

Prior to commit id '3d021381' virDomainObjUpdateModificationImpact was
part of virDomainLiveConfigHelperMethod and the *flags if condition
VIR_DOMAIN_AFFECT_CONFIG checked the ->persistent boolean and made the
virDomainObjGetPersistentDef call.

Since the functions were split the ->persistent check is all that remained
and thus could be combined into one if statement.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

in commit 81a110, multiqueue for macvtap is enabled but forget
to support hotplugging enabled
Signed-off-by: NShanzhi Yu <shyu@redhat.com>

When SPICE graphics is configured for a domain but we did not ask the
client to switch to the destination, we should not wait for
SPICE_MIGRATE_COMPLETED event (which will never come).

https://bugzilla.redhat.com/show_bug.cgi?id=1151723Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Migration statistics are not available on the destination host and
starting a query job during incoming migration is not allowed. Trying to
do that would result in

    Timed out during operation: cannot acquire state change lock (held
    by remoteDispatchDomainMigratePrepare3Params)

error. We should not even try to start the job.

https://bugzilla.redhat.com/show_bug.cgi?id=1278727Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

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

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

Signed-off-by: NAlexander Burluka <aburluka@virtuozzo.com>

This functions setups per-domain cpu bandwidth parameters
Signed-off-by: NAlexander Burluka <aburluka@virtuozzo.com>

Signed-off-by: NAlexander Burluka <aburluka@virtuozzo.com>

This parameter controls the maximum bandwidth to be used
within a period for whole domain.
Signed-off-by: NAlexander Burluka <aburluka@virtuozzo.com>

This parameter represents top level period cgroup
that limits whole domain enforcement period for a quota
Signed-off-by: NAlexander Burluka <aburluka@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

We don't need locks in dispose functions as they can only
be run in one thread for given object.

closeCallback pointer is immutable (set on connection object creation)
and self-locking.

If connect close is fired then following unregister will fail
as we set callback to NULL and thus callback equality checking
will fail.

Callback is set to NULL to make it fired only one time probabaly.
Instead lets use connection equality to NULL to check if callback
is already fired.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

We have reference to connection object in virConnectCloseCallbackData
object thus we have to refcount it. Obviously we have problems
in dispose and call functions. Let's fix it.
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>