Replace the virCgroupNew{Vcpu|Emulator|IOThread} calls with the common
virCgroupNewThread API
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>

 131,088 bytes in 16 blocks are definitely lost in loss record 2,174 of 2,176
    at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x4C2BACB: realloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
    by 0x52A026F: virReallocN (viralloc.c:245)
    by 0x52BFCB5: saferead_lim (virfile.c:1268)
    by 0x52C00EF: virFileReadLimFD (virfile.c:1328)
    by 0x52C019A: virFileReadAll (virfile.c:1351)
    by 0x52A5D4F: virCgroupGetValueStr (vircgroup.c:763)
    by 0x1DDA0DA3: qemuRestoreCgroupState (qemu_cgroup.c:805)
    by 0x1DDA0DA3: qemuConnectCgroup (qemu_cgroup.c:857)
    by 0x1DDB7BA1: qemuProcessReconnect (qemu_process.c:3694)
    by 0x52FD171: virThreadHelper (virthread.c:206)
    by 0x82B8DF4: start_thread (pthread_create.c:308)
    by 0x85C31AC: clone (clone.S:113)
Signed-off-by: NLuyao Huang <lhuang@redhat.com>

==19015== 968 (416 direct, 552 indirect) bytes in 1 blocks are definitely lost in loss record 999 of 1,049
==19015==    at 0x4C2C070: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19015==    by 0x52ADF14: virAllocVar (viralloc.c:560)
==19015==    by 0x5302FD1: virObjectNew (virobject.c:193)
==19015==    by 0x1DD9401E: virQEMUDriverConfigNew (qemu_conf.c:164)
==19015==    by 0x1DDDF65D: qemuStateInitialize (qemu_driver.c:666)
==19015==    by 0x53E0823: virStateInitialize (libvirt.c:777)
==19015==    by 0x11E067: daemonRunStateInit (libvirtd.c:905)
==19015==    by 0x53201AD: virThreadHelper (virthread.c:206)
==19015==    by 0xA1EE1F2: start_thread (in /lib64/libpthread-2.19.so)
==19015==    by 0xA4EFC8C: clone (in /lib64/libc-2.19.so)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

==19015== 1,064 (656 direct, 408 indirect) bytes in 2 blocks are definitely lost in loss record 1,002 of 1,049
==19015==    at 0x4C2C070: calloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==19015==    by 0x52AD74B: virAlloc (viralloc.c:144)
==19015==    by 0x52B47CA: virCgroupNew (vircgroup.c:1057)
==19015==    by 0x52B53E5: virCgroupNewVcpu (vircgroup.c:1451)
==19015==    by 0x1DD85A40: qemuSetupCgroupForVcpu (qemu_cgroup.c:1013)
==19015==    by 0x1DDA66EA: qemuProcessStart (qemu_process.c:4844)
==19015==    by 0x1DDF1807: qemuDomainObjStart (qemu_driver.c:7265)
==19015==    by 0x1DDF1A66: qemuDomainCreateWithFlags (qemu_driver.c:7320)
==19015==    by 0x1DDF1ACD: qemuDomainCreate (qemu_driver.c:7337)
==19015==    by 0x53F87EA: virDomainCreate (libvirt-domain.c:6820)
==19015==    by 0x12690A: remoteDispatchDomainCreate (remote_dispatch.h:3481)
==19015==    by 0x126827: remoteDispatchDomainCreateHelper (remote_dispatch.h:3457)
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

The function doesn't make sense. There's a simpler way to achieve the
same.

The function doesn't make sense. There's a simpler way to achieve the
same.

The function is used to set cpuset.cpus in various other helpers.

Two places would call to qemuPrepareCpumap() with priv->autoNodeset to
convert it to a cpuset. Remove the function and use the prepared cpuset
automatically.

When the default cpuset or automatic numa placement is used libvirt
would place the whole parent cgroup in the specified cpuset. This then
disallowed to re-pin the vcpus to a different cpu.

This patch pins only the vcpu threads to the default cpuset and thus
allows to re-pin them later.

The following config would fail to start:
<domain type='kvm'>
  ...
  <vcpu placement='static' cpuset='0-1' current='2'>4</vcpu>
  <cputune>
    <vcpupin vcpu='0' cpuset='2-3'/>
    ...

This is a regression since a39f69d2.

Use the default or auto cpuset if they are provided for IOThreads.

The automatic cpuset can be stored along with automatic nodeset and it
does not have to be recreated when used.

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>

Since we're not specifically a vcpu related structure anymore...

As pointed out by jtomko in his review of the IOThreads pinning code:

http://www.redhat.com/archives/libvir-list/2015-March/msg00495.html

there are some comments sprinkled in indicating IOThreads were using
the same structure as the VcpuPin code...

This is the first patch of a few that will change the virDomainVcpuPin*
structures and code to just virDomainPin* - starting with the data
structure naming...

There was a mess in the way how we store unlimited value for memory
limits and how we handled values provided by user.  Internally there
were two possible ways how to store unlimited value: as 0 value or as
VIR_DOMAIN_MEMORY_PARAM_UNLIMITED.  Because we chose to store memory
limits as unsigned long long, we cannot use -1 to represent unlimited.
It's much easier for us to say that everything greater than
VIR_DOMAIN_MEMORY_PARAM_UNLIMITED means unlimited and leave 0 as valid
value despite that it makes no sense to set limit to 0.

Remove unnecessary function virCompareLimitUlong.  The update of test
is to prevent the 0 to be miss-used as unlimited in future.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1146539Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

The structure will gradually become the only place for NUMA related
config, thus rename it appropriately.

If 'virNumaGetHostNodeset()' fails then the error path will try to free
uninitialized pointer mem_mask. Introduced by commit af2a1f05.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Record the index of each TAP device created and report them to
systemd, so they show up in machinectl status for the VM.

systemd-machined introduced a new method CreateMachineWithNetwork
that obsoletes CreateMachine. It expects to be given a list of
VETH/TAP device indexes for the host side device(s) associated
with a container/machine.

This falls back to the old CreateMachine method when the new
one is not supported.

Commit af2a1f05 tried clearly separating each condition in
qemuRestoreCgroupState() for the sake of readability, however somehow
one condition body was missing.  That means that the body of the next
condition got executed only if both of there were true, which is
impossible, thus resulting in a dead code and a logic error.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Instead of setting the value of cpuset.mems once when the domain starts
and then re-calculating the value every time we need to change the child
cgroup values, leave the cgroup alone and rather set the child data
every time there is new cgroup created.  We don't leave any task in the
parent group anyway.  This will ease both current and future code.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Thanks to that we don't need to drag the pointer everywhere and future
code will get cleaner.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

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

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

If the memory mode is specified as 'strict' and with one node, we
get the following error when starting domain.

error: Unable to write to '$cgroup_path/cpuset.mems': Device or resource busy

XML is configured with numatune as follows:
  <numatune>
    <memory mode='strict' nodeset='0'/>
  </numatune>

It's broken by Commit 411cea63
which moved qemuSetupCgroupForEmulator() before setting cpuset.mems
in qemuSetupCgroupPostInit.

Directory '$cgroup_path/emulator/' is created in qemuSetupCgroupForEmulator.
But '$cgroup_path/emulator/cpuset.mems' it not set and has a default value
(all nodes, such as 0-1). Then we setup '$cgroup_path/cpuset.mems' to the
nodemask (in this case it's '0') in qemuSetupCgroupPostInit. It must fail.

This patch makes '$cgroup_path/emulator/cpuset.mems' is set before
'$cgroup_path/cpuset.mems'. The action is similar with that in
qemuDomainSetNumaParamsLive.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

If the memory mode in numatune is specified as 'preferred' with one node
(such as nodeset='0'), domain's memory is not all in node 0 absolutely.
Assumption that node 0 doesn't have enough memory, memory can be allocated
on node 1 when qemu process startup. Then if we set cpuset.mems to '0',
it may invoke OOM.

Commit 1a7be8c6 changed the former logic of
checking memory mode in virDomainNumatuneGetNodeset. This patch adds the
check as before.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

Commit 4882618e added the code that
requests driver cfg, but forgot to unref it.
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

If we don't properly clean up all processes in the
machine-<vmname>.scope systemd won't remove the cgroup and subsequent vm
starts fail with

  'CreateMachine: File exists'

Additional processes can e.g. be added via

  echo $PID > /sys/fs/cgroup/systemd/machine.slice/machine-${VMNAME}.scope/tasks

but there are other cases like

  http://bugs.debian.org/761521

Invoke TerminateMachine to be on the safe side since systemd tracks the
cgroup anyway. This is a noop if all processes have terminated already.

Introduced by commit 0dce260c.

qemuDomainEventQueue was called with qemuDomainObjPrivatePtr instead
of virQEMUDriverPtr.

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

For the new VIR_DOMAIN_EVENT_ID_TUNABLE event we have a bunch of
constants added

   VIR_DOMAIN_EVENT_CPUTUNE_<blah>
   VIR_DOMAIN_EVENT_BLKDEVIOTUNE_<blah>

This naming convention is bad for two reasons

  - There is no common prefix unique for the events to both
    relate them, and distinguish them from other event
    constants

  - The values associated with the constants were chosen
    to match the names used with virConnectGetAllDomainStats
    so having EVENT in the constant name is not applicable in
    that respect

This patch proposes renaming the constants to

    VIR_DOMAIN_TUNABLE_CPU_<blah>
    VIR_DOMAIN_TUNABLE_BLKDEV_<blah>

ie, given them a common VIR_DOMAIN_TUNABLE prefix.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Now we have universal tunable event so we can use it for reporting
changes to user. The cputune values will be prefixed with "cputune" to
distinguish it from other tunable events.
Signed-off-by: NPavel Hrdina <phrdina@redhat.com>

Plug a memory leak and silence a warning.

Change "i+1" to "i + 1"

In order to support cpuset setting, introduce qemuSetupCgroupIOThreadsPin
and qemuSetupCgroupForIOThreads to mimic the existing Vcpu API's.

These will support having an 'iotrhreadpin' element in the 'cpuset' in
order to pin named IOThreads to specific CPU's. The IOThread pin names
will follow the IOThread naming scheme starting at 1 (eg "iothread1")
up through an including the def->iothreads value.

Libvirt documents that the default entropy source for the 'random'
backend of a RNG device is /dev/random. Instead of storing and
propagating NULL across our code and checking it in multiple places fill
the default in the post parse callback and use that in the other places.

qemu supports adding multiple RNG devices. This patch allows libvirt to
support this.

The "random" backend for virtio-rng can be started with no path
specified which equals to /dev/random. The cgroup code didn't consider
this and called few of the functions with NULL resulting into:

 $ virsh start rng-vm
 error: Failed to start domain rng-vm
 error: Path '(null)' is not accessible: Bad address

Problem introduced by commit c6320d34

Create the structures and API's to hold and manage the iSCSI host device.
This extends the 'scsi_host' definitions added in commit id '5c811dce'.
A future patch will add the XML parsing, but that code requires some
infrastructure to be in place first in order to handle the differences
between a 'scsi_host' and an 'iSCSI host' device.

Split virDomainHostdevSubsysSCSI further. In preparation for having
either SCSI or iSCSI data, create a union in virDomainHostdevSubsysSCSI
to contain just a virDomainHostdevSubsysSCSIHost to describe the
'scsi_host' host device

Create a separate typedef for the hostdev union data describing SCSI
Then adjust the code to use the new pointer