Since all APIs are also RPC calls, we automatically get all APIs covered
with thread jobs.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Every thread created as a worker thread within a pool gets a name
according to virThreadPoolJobFunc name.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Automatically assign a job to every thread created by virThreadCreate.
The name of the virThreadFunc function passed to virThreadCreate is used
as the job or worker name in case no name is explicitly passed.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

We want all threads to be set as workers or to have a job assigned to
them, which can easily be achieved in virThreadCreate wrapper to
pthread_create. Let's make sure we always use the wrapper.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Each thread can use a thread local variable to keep the name of a job
which is currently running in the job.

The virThreadJobSetWorker API is supposed to be called once by any
thread which is used as a worker, i.e., it is waiting in a pool, woken
up to do a job, and returned back to the pool.

The virThreadJobSet/virThreadJobClear APIs are to be called at the
beginning/end of each job.
Signed-off-by: NJiri Denemark <jdenemar@redhat.com>

Although needed in the Xen 4.1 libxl days, there is no longer any
benefit to having per-domain libxl_ctx.  On the contrary, their use
makes the code unecessarily complicated and prone to deadlocks under
load.  As suggested by the libxl maintainers, use a single libxl_ctx
as a handle to libxl instead of per-domain ctx's.

One downside to using a single libxl_ctx is there are no longer
per-domain log files for log messages emitted by libxl.  Messages
for all domains will be sent to /var/log/libvirt/libxl/libxl-driver.log.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

libxlDomainFreeMem() is only used in libxl_domain.c and thus should
be declared static.  While at it, change the signature to take a
libxl_ctx instead of libxlDomainObjPrivatePtr, since only the
libxl_ctx is needed.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

This function now only enables domain death events.  Simply call
libxl_evenable_domain_death() instead of an unnecessary wrapper.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Change the domain event handler code to use the driver-wide
libxl_ctx instead of the domain-specific one.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Register a domain event handler with the driver-wide libxl_ctx
during driver initialization.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Informing libxl how to handle its child proceses should be done once
during driver initialization, not once for each domain-specific
libxl_ctx object.  The related libxl documentation in
$xen-src/tools/libxl/libxl_event.h even mentions that "it is best to
call this at initialisation".
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

Long ago I incorrectly associated libxl fd and timer registrations
with per-domain libxl_ctx objects.  When creating a libxlDomainObjPrivate,
a libxl_ctx is allocated, and libxl_osevent_register_hooks is called
passing a pointer to the libxlDomainObjPrivate.  When an fd or timer
registration occurred, the registration callback received the
libxlDomainObjPrivate, containing the per-domain libxl_ctx.  This
libxl_ctx was then used when informing libxl about fd events or
timer expirations.

The problem with this approach is that fd and timer registrations do not
share the same lifespan as libxlDomainObjPrivate, and hence the per-domain
libxl_ctx ojects.  The result is races between per-domain libxl_ctx's being
destoryed and events firing on associated fds/timers, typically manifesting
as an assert in libxl

libxl_internal.h:2788: libxl__ctx_unlock: Assertion `!r' failed

There is no need to associate libxlDomainObjPrivate objects with libxl's
desire to use libvirt's event loop.  Instead, the driver-wide libxl_ctx can
be used for the fd and timer registrations.

This patch moves the fd and timer handling code away from the
domain-specific code in libxl_domain.c into libxl_driver.c.  While at it,
function names were changed a bit to better describe their purpose.

The unnecessary locking was also removed since the code simply provides a
wrapper over the event loop interface.  Indeed the locks may have been
causing some deadlocks when repeatedly creating/destroying muliple domains.
There have also been rumors about such deadlocks during parallel OpenStack
Tempest runs.
Signed-off-by: NJim Fehlig <jfehlig@suse.com>

We don't have to modify cpuset.mems on hosts without NUMA.  It also
fixes an error message that you get instead of success if you trying
update vcpus of a guest on a host without NUMA.

error: internal error: NUMA isn't available on this host
Signer-off-by: NPavel Hrdina <phrdina@redhat.com>

Remove unnecessary maximum variable.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

We should call virDomainLiveConfigHelperMethod ASAP because this
function transfers VIR_DOMAIN_AFFECT_CURRENT to VIR_DOMAIN_AFFECT_LIVE
or VIR_DOMAIN_AFFECT_CONFIG.  All other additional checks for those two
flags should consider that the user give us VIR_DOMAIN_AFFECT_CURRENT.

Remove the unnecessary check whether the domain is live in case of
VIR_DOMAIN_VCPU_GUEST because this check is done by
virDomainLiveConfigHelperMethod.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

by rewriting it completely from:
error: unsupported configuration: virtio only support device address
type 'PCI'

to:

error: unsupported configuration: virtio disk cannot have an address of type
drive

Since we now support CCW addresses as well.

While debugging the support for responding to qemu RX_FILTER_CHANGED
events, I had changed the "ignoring this event" log message from
VIR_DEBUG to VIR_WARN, but forgot to change it back before
pushing. Since many guest OSes make enough changes to multicast lists
and/or promiscuous mode settings to trigger this message, it's
starting to show up as a red herring in bug reports.

Commit 5bba61fd changed the XPath strings to be absolute when parsing
the VM NUMA configuration. Unfortunately the <domain> element is not a
top level element when parsing the domain status XML thus the absolute
XPath string doesn't match.

Use the relative string so that the <numa> settings are not lost.
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

Add code to hot-remove memory devices from qemu. Unfortunately QEMU
doesn't support this right now, so this is just for completenes.

Add code to hot-add memory devices to running qemu instances.

Add a few helpers that allow to operate with memory device definitions
on the domain config and use them to implement memory device coldplug in
the qemu driver.

Add support to start qemu instance with 'pc-dimm' device. Thanks to the
refactors we are able to reuse the existing function to determine the
parameters.

Make sure that libvirt has all vital information needed to reliably
represent configuration of guest's memory devices in case of a
migration.

This patch forbids migration in case the required slot number and module
base address are not present (failed to be loaded from qemu via
monitor).

When using 'dimm' memory devices with qemu, some of the information
like the slot number and base address need to be reloaded from qemu
after process start so that it reflects the actual state. The state then
allows to use memory devices across migrations.

This patch adds code that parses and formats configuration for memory
devices.

A simple configuration would be:
<memory model='dimm'>
  <target>
    <size unit='KiB'>524287</size>
    <node>0</node>
  </target>
</memory>

A complete configuration of a memory device:
<memory model='dimm'>
  <source>
    <pagesize unit='KiB'>4096</pagesize>
    <nodemask>1-3</nodemask>
  </source>
  <target>
    <size unit='KiB'>524287</size>
    <node>1</node>
  </target>
</memory>

This patch preemptively forbids use of the <memory> device in individual
drivers so the users are warned right away that the device is not
supported.

Dimm devices are described by the slot and base address. Add a new
address type to be able to describe such address.

To enable memory hotplug the maximum memory size and slot count need to
be specified. As qemu supports now other units than mebibytes when
specifying memory, use the new interface in this case.

Add a XML element that will allow to specify maximum supportable memory
and the count of memory slots to use with memory hotplug.

To avoid possible confusion and misuse of the new element this patch
also explicitly forbids the use of the maxMemory setting in individual
drivers's post parse callbacks. This limitation will be lifted when the
support is implemented.

With the current control flow the post parse callback returned success
right away for fully virtualized VMs. To allow adding additional checks
into the post parse callback tweak the conditions so that the function
doesn't return early except for error cases.

To clarify the original piece of code borrow the wording from the commit
message for the patch that introduced the code.

The function comment states that @props is always consumed, even on
failure. This was not true with the failure if the monitor is not using
QMP.

In the last section if the function determines that the config is
invalid when QEMU doesn't support the memory device the JSON config
object would be returned even if it doesn't make sense.

Assign the object to be returned only on success.

When no model is specified in the domain definition for
a scsi controller and the architectur is s390 than virtio-scsi
is set as default model.
Signed-off-by: NBoris Fiuczynski <fiuczy@linux.vnet.ibm.com>
Reviewed-by: NDaniel Hansel <daniel.hansel@linux.vnet.ibm.com>
Reviewed-by: NStefan Zimmermann <stzi@linux.vnet.ibm.com>
Reviewed-by: NJens Freimann <jfrei@linux.vnet.ibm.com>
Reviewed-by: NMichal Privoznik <mprivozn@redhat.com>

Always add udev linker flags when WITH_UDEV is enabled to avoid
underlinking.

See commit 43dbcb15 (interface: always build all available backends)
Signed-off-by: NNatanael Copa <ncopa@alpinelinux.org>

Commit cf54c606 introduced the ability
to create missing storage volumes during migration. For network disks,
however, we may not necessarily be able to detect whether they already
exist -- there is no straight-forward way to map the disk to a storage
volume, and even if there were it's possible no configured storage pool
actually contains the disk.

It is better to assume the network disk exists in this case, rather than
aborting the migration completely. If the volume really is missing, QEMU
will generate an appropriate error later in the migration.
Signed-off-by: NMichael Chapman <mike@very.puzzling.org>

This function does not make any sense now, that network driver is
(almost) dropped. I mean, previously, when threads were
serialized, this function was there to check, if no other network
with the same name or UUID exists. However, nowadays that threads
can run more in parallel, this function is useless, in fact it
gives misleading return values. Consider the following scenario.
Two threads, both trying to define networks with same name but
different UUID (e.g. because it was generated during XML parsing
phase, whatever). Lets assume that both threads are about to call
networkValidate() which immediately calls
virNetworkObjIsDuplicate().

T1: calls virNetworkObjIsDuplicate() and since no network with
given name or UUID exist, success is returned.
T2: calls virNetworkObjIsDuplicate() and since no network with
given name or UUID exist, success is returned.

T1: calls virNetworkAssignDef() and successfully places its
network into the virNetworkObjList.
T2: calls virNetworkAssignDef() and since network with the same
name exists, the network definition is replaced.

Okay, this is mainly because virNetworkAssignDef() does not check
whether name and UUID matches. Well, lets make it so! And drop
useless function too.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

There's no need to lock the network driver, as network driver
initialization is done prior accepting any client. There's nobody
to hop in and do something over partially initialized driver. Nor
qemu driver is doing that.

==30532== Observed (incorrect) order is: acquisition of lock at 0x1439EF50
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x5307E86: virObjectLock (virobject.c:323)
==30532==    by 0x5396440: virNetworkObjListForEach (network_conf.c:4511)
==30532==    by 0x19B29308: networkStateInitialize (bridge_driver.c:686)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==    by 0x4C30456: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0xA1EC1F2: start_thread (in /lib64/libpthread-2.19.so)
==30532==    by 0xA4EDC8C: clone (in /lib64/libc-2.19.so)
==30532==
==30532==  followed by a later acquisition of lock at 0x1439CD60
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x19B27B2C: networkDriverLock (bridge_driver.c:102)
==30532==    by 0x19B27B60: networkGetDnsmasqCaps (bridge_driver.c:113)
==30532==    by 0x19B2856A: networkUpdateState (bridge_driver.c:389)
==30532==    by 0x53963E9: virNetworkObjListForEachHelper (network_conf.c:4488)
==30532==    by 0x52E2224: virHashForEach (virhash.c:521)
==30532==    by 0x539645B: virNetworkObjListForEach (network_conf.c:4512)
==30532==    by 0x19B29308: networkStateInitialize (bridge_driver.c:686)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==
==30532== Required order was established by acquisition of lock at 0x1439CD60
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x19B27B2C: networkDriverLock (bridge_driver.c:102)
==30532==    by 0x19B28DF9: networkStateInitialize (bridge_driver.c:609)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==    by 0x4C30456: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0xA1EC1F2: start_thread (in /lib64/libpthread-2.19.so)
==30532==    by 0xA4EDC8C: clone (in /lib64/libc-2.19.so)
==30532==
==30532==  followed by a later acquisition of lock at 0x1439EF50
==30532==    at 0x4C31A26: pthread_mutex_lock (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0x5324895: virMutexLock (virthread.c:88)
==30532==    by 0x5307E86: virObjectLock (virobject.c:323)
==30532==    by 0x538A09C: virNetworkAssignDef (network_conf.c:527)
==30532==    by 0x5391EB2: virNetworkLoadState (network_conf.c:3008)
==30532==    by 0x53922D4: virNetworkLoadAllState (network_conf.c:3128)
==30532==    by 0x19B2929A: networkStateInitialize (bridge_driver.c:671)
==30532==    by 0x53E1CCC: virStateInitialize (libvirt.c:777)
==30532==    by 0x11DEB7: daemonRunStateInit (libvirtd.c:906)
==30532==    by 0x5324B6A: virThreadHelper (virthread.c:197)
==30532==    by 0x4C30456: ??? (in /usr/lib64/valgrind/vgpreload_helgrind-amd64-linux.so)
==30532==    by 0xA1EC1F2: start_thread (in /lib64/libpthread-2.19.so)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Wikipedia's list of common misspellings [1] has a machine-readable
version.  This patch fixes those misspellings mentioned in the list
which don't have multiple right variants (as e.g. "accension", which can
be both "accession" and "ascension"), such misspellings are left
untouched.  The list of changes was manually re-checked for false
positives.

[1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machinesSigned-off-by: NMartin Kletzander <mkletzan@redhat.com>

We've never set the cpuset.memory_migrate value to anything, keeping it
on default.  However, we allow changing cpuset.mems on live domain.
That setting, however, don't have any consequence on a domain unless
it's going to allocate new memory.

I managed to make 'virsh numatune' move all the memory to any node I
wanted even without disabling libnuma's numa_set_membind(), so this
should be safe to use with it as well.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1198497Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>