Statistics provided through PCS SDK. As we have only async interface in SDK we
need to be subscribed to statistics in order to get it. Trivial solution on
every stat request to subscribe, wait event and then unsubscribe will lead to
significant delays in case of a number of successive requests, as the event
will be delivered on next PCS server notify cycle. On the other hand we don't
want to keep unnesessary subscribtion. So we take an hibrid solution to
subcsribe on first request and then keep a subscription while requests are
active. We populate cache of statistics on subscribtion events and use this
cache to serve libvirts requests.
* Cache details.
Cache is just handle to last arrived event, we call this cache
as if this handle is valid it is used to serve synchronous
statistics requests. We use number of successive events count
to detect that user lost interest to statistics. We reset this
count to 0 on every request. If more than PARALLELS_STATISTICS_DROP_COUNT
successive events arrive we unsubscribe. Special value of -1
of this counter is used to differentiate between subscribed/unsubscribed state
to protect from delayed events.
Values of PARALLELS_STATISTICS_DROP_COUNT and PARALLELS_STATISTICS_TIMEOUT are
just drop-ins, choosen without special consideration.
* Thread safety issues
Use parallelsDomObjFromDomainRef in parallelsDomainBlockStats as
we could wait on domain lock down on stack in prlsdkGetStatsParam
and if we won't keep reference we could get dangling pointer
on return from wait.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@parallels.com>
qemu 2.3.0 added the -cpu host,aarch64=off option, which allows using
qemu-system-aarch64 KVM to run armv7l VMs.
Add a capabilities check for it, wire it up in qemu_command, and test
the command line generation.
2 reasons to to this.
1. PCS SDK really don't care of handler return value.
2. It hard to imagine how notifier can handle
subscriber failures. Even if there are some situations
we probably will use some special error codes and
not just throw error codes we get from SDK itself.
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@parallels.com>
Use issuer type instead of event type to group
vm related events. This saves us from
explicit enumeration of all vm event types in
prlsdkHandleVmEvent.
Not every architecture out there has 'char' signed by default.
For instance, my arm box has it unsigned by default:
$ gcc -dM -E - < /dev/null | grep __CHAR_UNSIGNED__
#define __CHAR_UNSIGNED__ 1
Therefore, after 65c61e50 the test if failing for me. Problem is,
we are trying to assign couple of negative values into char
assuming some will overflow and some don't. That can't be the
case if 'char' is unsigned by default. Lets use more explicit types
instead: int8_t and uint8_t where is no ambiguity.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Commit 825df8c3 refactored virProcess{Set,Get}Affinity routines,
however broke BSD implementation because of the incorrect variable
name. Fix build by using a proper variable name.
Pushing as trivial and build break fix.
The stubs for the two functions that are compiled on platforms that
don't have HAVE_GETPWUID_R and friends defined do not return error but
report an error message. The calling code then assumes that the @uid or
@gid arguments were filled, which is not the case in the stubs.
When traversing through the QOM tree, we're looking for
a link to a device, e.g.:
link<virtio-balloon-pci>
Introduce a helper that will format the link name at the start,
instead of doing it every time while recursing through the tree.
Ref service passed as a parameter to the callback. And don't unref the
socket that is part of the service being passed at another point in code.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Append privateData of the client only if there are any, otherwise the
previous value (socket data) will get there again.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
When building without avahi support, we used VIR_DEBUG() to note that to
the user. However, functions that fail because of that (return NULL/-1)
did not set the error message. This was the only file that forgot to do
such thing.
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1181087
The virStorageBackendFileSystemIsMounted is called from three source paths
checkPool, startPool, and stopPool. Both start and stop validate the FS
fields before calling *IsMounted; however the check path there is no call.
This could lead the code into returning a true in "isActive" if for some
reason the target path for the pool was mounted. The assumption being
that if it was mounted, then we believe we started/mounted it.
It's also of note that commit id '81165294' added an error message for
the start/mount path regarding that the target is already mounted so
fail the start. That check was adjusted by commit id '13fde7ce' to
only message if actually mounted.
At one time this led to the libvirtd restart autostart code to declare
that the pool was active even though the startPool would inhibit startup
and the stopPool would inhibit shutdown. The autostart path changed as
of commit id '2a31c5f0' as part of the keep storage pools started between
libvirtd restarts.
This patch adds the same check made prior to start/mount and stop/unmount
to ensure we have a valid configuration before attempting to see if the
target is already mounted to declare "isActive" or not. Finding an improper
configuration will now cause an error at checkPool, which should make it
so we can no longer be left in a situation where the pool was started and
we have no way to stop it.
https://bugzilla.redhat.com/show_bug.cgi?id=1181087
Currently the assumption on the error message is that there are
no source device paths defined when the number of devices check
fails, but in reality the XML could have had none or it could have
had more than the value supported. Adjust the error message accordingly
to make it clearer what the error really is.
Commit 1882c0bd accidentally used ',' instead of ';'; oddly
enough, the result was still syntactically valid (yes, C is
a fun language). But it made me do a double take; it's better
to use idiomatic syntax.
* daemon/remote.c (remoteRelayDomainEventDeviceAdded): Fix
harmless typo.
Signed-off-by: Eric Blake <eblake@redhat.com>
In qemuDomainUpdateCurrentMemorySize I misplaced the actual update of
the balloon size to a place where it may not be initialized. Move it a
few lines above.
Coverity rightfully determined that in commit 3d021381c7
I made a mistake in the first check if @persDef is not NULL is
dereferencing it rather than checking.
Additionally if the vm is online the code would set @liveDef twice
rather than modifying @persDef. Fix both mistakes.
When getting block device I/O tuning data there is no check for whether
QEMU supports such options and the call fails on
qemuMonitorGetBlockIoThrottle() when getting the particular throttle
data. So try reporting a better error when blkdeviotune is not
supported.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1224053
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
virDomainLiveConfigHelperMethod that is used for this job now does
modify the flags but still requires the callers to extract the correct
definition objects.
In addition coverity and other static analyzers are usually unhappy as
they don't grasp the fact that @flags are upadted according to the
correct def to be present.
To work this issue around and simplify the calling chain let's add a new
helper that will work only on drivers that always copy the persistent
def to a transient at start of a vm. This will allow to drop a few
arguments. The new function syntax will also fill two definition
pointers rather than modifying the @flags parameter.
The vCPU pinning definition gets removed when the domain definition is
being freed later. If there is no next configuration it would remove the
configured pinning.
This reverts commit 01692bb167.
Quoting the original commit message:
"Not sure if it's the correct way to add cputune xml for xend driver..."
It is not. The defition created that is converted from the internal xend
structures would also be leaked since it isn't used any more.
Revert the commit since it does not make sense to keep the info
internally.
In the pre-NUMA ages pinning a vCPU to all pCPUs was eaqual to deleting
the pinning info. Now it does not entirely work that way. Pinning a vCPU
to all pCPUs might be a desired operation. Additionally removal of the
pinning will result into using the default pinning information at the
next boot which might be different from all vcpus.
This patch removes the false assumption that we should remove the
pinning after pinning to all vCPUs and tweaks the documentation for
virsh.
A later patch will implement a new flag for the virDomainPinVcpuFlags
API that will allow to remove the pinning in a sane way.
