The API docs state that the API queries pinning info for all vCPUs and
thus we should allocate the bitmap even for the inactive ones.
The API will currently return bitmap only for the active vCPUs but that
will change in the future.
The VIR_DOMAIN_EVENT_ID_JOB_COMPLETED event will be triggered once a job
(such as migration) finishes and it will contain statistics for the job
as one would get by calling virDomainGetJobStats. Thanks to this event
it is now possible to get statistics of a completed migration of a
transient domain on the source host.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
We would happily report and free statistics of a completed migration
even before it actually completed (on the source host while migration is
in the Finish phase).
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Computing a total downtime during a migration requires us to store a
time stamp when guest CPUs get stopped. The value (and all other
statistics) is then transferred to the destination to compute the
downtime. Because the stopped time stamp is stored by a STOP event
handler while the statistics which will be sent over to the destination
are copied synchronously within qemuMigrationWaitForCompletion.
Depending on the timing of STOP and MIGRATION events, we may end up
copying (and transferring) statistics without the stopped time stamp
set. Let's make sure we always use the correct time stamp.
https://bugzilla.redhat.com/show_bug.cgi?id=1282744
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
With a very old QEMU which doesn't support events we need to explicitly
call qemuMigrationSetOffline at the end of migration to update our
internal state. On the other hand, if we talk to QEMU using QMP, we
should just wait for the STOP event and let the event handler update the
state and trigger a libvirt event.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
We should not overwrite all migration statistics on the source with the
numbers sent by the destination since the source may have an updated
view in some cases (such as post-copy migration). It's safer to update
just the timing info we need to get from the destination and be prepared
for the future. And we should only do all this after a successful
migration.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Statistics for a completed migration only make sense if the migration
was successful. Let's not store them in priv->job.completed until we
are sure it was a success.
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
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.
The 'actualCount' variable, formerly just 'count', is only used
internally by the macro, so it's better to move its declaration
inside the macro as well: this way, it doesn't have to be declared
by every single user.
The new name is less generic to make clashes less likely.
When checking the number of devices added to a device list, use the
nhostdevs variable instead of its value, so that the test can keep
working even if more hostdevs are added.
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: Michal Privoznik <mprivozn@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: Michal 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: Nikolay 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: Nikolay 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: Michal 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: Michal Privoznik <mprivozn@redhat.com>
remoteDispatchConnectCloseCallbackRegister introduced in
f484310a has problems. It refcounts network client object and in case of NOOP
driver operations for registering/unregistering close callback (any driver
except for vz) nobody will unref it later. As a result, client connection
will not be disposed and driver connection will not be closed.
The fix is easy. We don't need to refcount at all. We don't get a dangling
pointer because in remoteClientFreeFunc, which is called
upon disposing this network client object, we unregister the close
callback.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: Erik Skultety <eskultet@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: Michal 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.
Commit 1199edb1d4 added config option max_queued_clients and documented the
default value as 1000 but never actually set that value. This patch sets the
default value.
This addresses an issue whereby the following error message is reported if too
many migrations are started simultaneously:
error: End of file while reading data: Ncat: Invalid argument.: Input/output error
The problem is that too many ncat processes are spawned on the destination
system. They all attempt to connect to the libvirt socket. Because the
destination libvirtd cannot respond to the connect requests quickly enough we
overrun the socket's pending connections queue.
Signed-off-by: Jason J. Herne <jjherne@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
libxlDomainPinVcpuFlags calls virDomainLiveConfigHelperMethod which will
call virDomainObjUpdateModificationImpact make the same AFFECT_LIVE flags
and !active check, so remove this duplicated check.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: John 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: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Signed-off-by: John Ferlan <jferlan@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=1151723
Signed-off-by: Jiri 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=1278727
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
