If max_workers is set to zero, then the worker thread pool won't be
created, so when serializing state for pre-exec we must set various
parameters to zero.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently if the virNetServer instance is created with max_workers==0 to
request a non-threaded dispatch process, we deadlock during dispatch
#0 0x00007fb845f6f42d in __lll_lock_wait () from /lib64/libpthread.so.0
#1 0x00007fb845f681d3 in pthread_mutex_lock () from /lib64/libpthread.so.0
#2 0x000055a6628bb305 in virMutexLock (m=<optimized out>) at util/virthread.c:89
#3 0x000055a6628a984b in virObjectLock (anyobj=<optimized out>) at util/virobject.c:435
#4 0x000055a66286fcde in virNetServerClientIsAuthenticated (client=client@entry=0x55a663a7b960)
at rpc/virnetserverclient.c:1565
#5 0x000055a66286cc17 in virNetServerProgramDispatchCall (msg=0x55a663a7bc50, client=0x55a663a7b960,
server=0x55a663a77550, prog=0x55a663a78020) at rpc/virnetserverprogram.c:407
#6 virNetServerProgramDispatch (prog=prog@entry=0x55a663a78020, server=server@entry=0x55a663a77550,
client=client@entry=0x55a663a7b960, msg=msg@entry=0x55a663a7bc50) at rpc/virnetserverprogram.c:307
#7 0x000055a662871d56 in virNetServerProcessMsg (msg=0x55a663a7bc50, prog=0x55a663a78020, client=0x55a663a7b960,
srv=0x55a663a77550) at rpc/virnetserver.c:148
#8 virNetServerDispatchNewMessage (client=0x55a663a7b960, msg=0x55a663a7bc50, opaque=0x55a663a77550)
at rpc/virnetserver.c:227
#9 0x000055a66286e4c0 in virNetServerClientDispatchRead (client=client@entry=0x55a663a7b960)
at rpc/virnetserverclient.c:1322
#10 0x000055a66286e813 in virNetServerClientDispatchEvent (sock=<optimized out>, events=1, opaque=0x55a663a7b960)
at rpc/virnetserverclient.c:1507
#11 0x000055a662899be0 in virEventPollDispatchHandles (fds=0x55a663a7bdc0, nfds=<optimized out>)
at util/vireventpoll.c:508
#12 virEventPollRunOnce () at util/vireventpoll.c:657
#13 0x000055a6628982f1 in virEventRunDefaultImpl () at util/virevent.c:327
#14 0x000055a6628716d5 in virNetDaemonRun (dmn=0x55a663a771b0) at rpc/virnetdaemon.c:858
#15 0x000055a662864c1d in main (argc=<optimized out>,
#argv=0x7ffd105b4838) at logging/log_daemon.c:1235
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Currently virNetServerClientDispatchFunc implementations are only
responsible for free'ing the "msg" parameter upon success. Simplify the
calling convention by making it their unconditional responsibility to
free the "msg", and close the client if desired.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There's no reason why the virNetServerClientDispatchRead method needs to
acquire an extra reference on the "client" object. An extra reference is
only needed if the registered dispatch callback is going to keep hold of
the "client" for work in the background. Thus we can push reference
acquisition into virNetServerDispatchNewMessage.
Reviewed-by: John Ferlan <jferlan@redhat.com>
Reviewed-by: Jim Fehlig <jfehlig@suse.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Make sure we install the same packages lcitool would install on
the CentOS CI so that we have consistent results. The package
list is current as of libvirt-jenkins-ci commit ad84090b6f96.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
This function was introduced in commit 41f5c2ca27 as a way
to probe the same property for multiple devices at once.
Although the resulting representation is very compact, it
doesn't provide any extra features compared to the existing
virQEMUCapsProcessStringFlags() mechanism, which is already
used for pretty much all device properties.
Drop the custom function and datatypes and start using the
standard ones instead.
Note that, in theory, the end result is not identical
because we're no longer probing properties for
virtio-serial-pci
virtio-9p-pci
virtio-rng-pci
virtio-input-host-pci
virtio-keyboard-pci
virtio-mouse-pci
virtio-tablet-pci
However, chances of any of those devices being compiled
into a QEMU binary where
virtio-balloon-pci
virtio-blk-pci
virtio-scsi-pci
virtio-net-pci
virtio-gpu-pci
are compiled out are slim enough that it doesn't make any
difference in practice, as the lack of test suite churn
shows.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
In some cases, we are probing multiple devices for the same
property and setting the corresponding capability if it's
found on any of the devices: when that happens, we can quit
early after finding the first property and avoiding a bunch
of string comparisons.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Commit 4ae59411fa introduced the ability to make probing for
device properties conditional on a capability being set, but
didn't extend the use of this feature to existing devices.
This commit does the last bit of work, which results in a lot
of pointless QMP chatter no longer happening and our test suite
shrinking a fair bit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
The function used the 'cleanup' label only in error cases. This patch
makes the code pass the cleanup label in every case and removes few
unnecessary VIR_FREEs.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
In certain cases a xml contains paths that do not yet exist, but
are valid as qemu will create them later on - for example
vhostuser mode=server sockets.
In any such cases so far the check to virFileExists failed and due to
that the paths stayed non-resolved in regard to symlinks.
But for apparmor those non-resolved rules are non functional as they
are evaluated after resolving any symlinks.
Therefore for non-existent files and partially non-existent paths
resolve as much as possible to get valid rules.
Example:
<interface type='vhostuser'>
<model type='virtio'/>
<source type='unix' path='/var/run/symlinknet' mode='server'/>
</interface>
Got rendered as:
"/var/run/symlinknet" rw,
But correct with "/var/run" being a symlink to "/run" is:
"/run/symlinknet" rw,
Signed-off-by: Christian Ehrhardt <christian.ehrhardt@canonical.com>
Acked-by: Michal Privoznik <mprivozn@redhat.com>
When commit 3545cbef moved the sysfs attribute reading logic from
_udev.c module to virmdev.c, it had to replace our udev read wrappers
with the ones available from virfile.c. The problem is that the original
logic worked correctly with udev read wrappers which don't return an
error code for a missing attribute, virfile.c readers however - not so
much. Therefore add another parameter to the macro, so we can again
accept the fact that optional attributes may be missing.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
If the user tries to define a domain that has
<controller type='usb' model='none'/>
and also some USB devices, we report an error:
error: internal error: No free USB ports
Which is technically still correct for a domain with no USB ports.
Change it to:
USB is disabled for this domain, but USB devices are present in the domain XML
https://bugzilla.redhat.com/show_bug.cgi?id=1347550
Signed-off-by: Ján Tomko <jtomko@redhat.com>
When trying to destroy a domain (e.g. because we've seen EOF on
the monitor) we try to acquire QEMU_JOB_DESTROY. However, if
max_queued is set in qemu.conf this may fail and since our code
doesn't count on that we will still report domain as active even
though the qemu process is long gone. More specifically, if we've
seen EOF on the monitor, qemuProcessHandleMonitorEOF() is called
which sends MONITOR_EOF job to the event worker pool and
unregisters monitor from the event loop. The worker pool calls
processMonitorEOFEvent() which tries to set job which may fail
due to the limit as described above.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Let us introduce the xml and reply files for QEMU 2.11.0 on s390x.
Signed-off-by: Shalini Chellathurai Saroja <shalini@linux.vnet.ibm.com>
Reviewed-by: Bjoern Walk <bwalk@linux.vnet.ibm.com>
Reviewed-by: Boris Fiuczynski <fiuczy@linux.vnet.ibm.com>
When generating certificates we rely on GNUTLS' built-in default setup
for the ciphers used in the certs. We then currently run with the distro
specific TLS priority setup which can be much stronger, to the extent
that the certificates we generate are considered untrustworthy. We don't
care about the quality of the ciphers we use in the test suite, so just
force the priority to "NORMAL" which should ensure our certs are
accepted by GNUTLS.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Fix this common typo and assign a value rather than implicitly
type-casted comparison result. Introduced by commit b6a264e855.
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The diff files in gnulib/local may well contain trailing whitespace.
They are simply diff's of gnulib code which should not be modified to
follow libvirt style rules.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
GLibc deprecated libio.h in 2.27 and has removed it in current
code that will become 2.28. The latter is now in Fedora rawhide
and this change breaks gnulib which mistakenly still relies on
these ancient symbols. Add a local hack for gnulib until a
proper fix is available upstream.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
so it's not affected by flags that might be passed in $(*_LIBS) like
-L/usr/lib which might result in linking against system library and
requiring incorrect version of private symbols
Signed-off-by: Jan Palus <atler@pld-linux.org>
Pretty much any reasonable compiler would do this automatically,
but there's no harm in being explicit about it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Laine Stump <laine@laine.org>
The homebrew formula's ignored Python PEP-0394 recommendations and
changed the plain python binary in /usr/local/bin to point to Python 3
instead of Python 2. Python 2 is not even installed into a location that
is in $PATH by default anymore. The homebrew packages print a message
to stderr claiming to provide a way to fix this
[quote]
This formula installs a python2 executable to /usr/local/opt/python@2/bin
If you wish to have this formula's python executable in your PATH then add
the following to ~/.bash_profile:
export PATH="/usr/local/opt/python@2/libexec/bin:$PATH"
[/quote]
When trying to update $PATH are suggested we find out this message is a
lie and /usr/local/opt/python@2 does not even exist, instead Python
seems to end up in /usr/local/Cellar/python@2/2.7.14_1
Rather than hardcoding this version specific directory in our travis
config, we change to run "brew link --force python@2", to make it create
symlinks in /usr/local/bin for the python2 binary.
The original change triggering this problem was
https://github.com/Homebrew/homebrew-core/pull/24604#issue-171653084
There are countless bug reports against homebrew-core that are closed
without fixes, so it seems they are determined to ignore the Python
PEP 0394 recommendations on this.
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
We allow the postParse callbacks to fail for some reasons (missing
emulator binary) when parsing the configs from /etc/libvirt.
In that case, def->postParseFailed is set to true and the post
parse callbacks are re-executed on domain startup.
However this bool was only set when virDomainDefPostParse was called
with the ALLOW_POST_PARSE_FAIL flag set. If the callback failed
again on domain startup, the bool would be reset and subsequent
startups would not attempt to reexecute the callback.
Signed-off-by: Ján Tomko <jtomko@redhat.com>
