Fix the build on FreeBSD, broken by commit 4882618e.
Signed-off-by: NJán Tomko <jtomko@redhat.com>
(cherry picked from commit 99b2b457)

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.

(cherry picked from commit 4882618e)

I missed adding virCgroupNewIOThread to the !VIR_CGROUP_SUPPORTED

Pushing as build breaker

Add virCgroupNewIOThread() to mimic virCgroupNewVcpu() except the naming
scheme with use "iothread" rather than "vcpu".

Need to free 'root' and 'opts' before 'return -1' if symlink fails.
Signed-off-by: NWang Rui <moon.wangrui@huawei.com>

Added <capabilities> in the <features> section of LXC domains
configuration. This section can contain elements named after the
capabilities like:

  <mknod state="on"/>, keep CAP_MKNOD capability
  <sys_chroot state="off"/> drop CAP_SYS_CHROOT capability

Users can restrict or give more capabilities than the default using
this mechanism.

Commit a48f4451 introduced a helper
function to convert cgroup device mode to string. The function was only
conditionally compiled on platforms that support cgroup. This broke the
build when attempting to export the symbol:

  CCLD     libvirt.la
  Cannot export virCgroupGetDevicePermsString: symbol not defined

Move the function out of the ifdef, as it doesn't really depend on the
cgroup code being present.

Cgroups code uses VIR_CGROUP_DEVICE_* flags to specify the mode but in
the end it needs to be converted to a string. Add a helper to do it and
use it in the cgroup code before introducing it into the rest of the
code.

Don't leak keypath when we fail to kill a process
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

In making the conversion to the new API, I fixed a couple bugs:
virSCSIDeviceGetSgName would leak memory if a directory
unexpectedly contained multiple entries;
virNetDevTapGetRealDeviceName could report a spurious error
from a stale errno inherited before starting the readdir search.

The decision on whether to store the result of virDirRead into
a variable is based on whether the end of the loop falls through
to cleanup code automatically.  In some cases, we have loops that
are documented to return NULL on failure, and which raise an
error on most failure paths but not in the case where the directory
was unexpectedly empty; it may be worth a followup patch to
explicitly report an error if readdir was successful but the
directory was empty, so that a NULL return always has an error set.

* src/util/vircgroup.c (virCgroupRemoveRecursively): Use new
interface.
(virCgroupKillRecursiveInternal, virCgroupSetOwner): Report
readdir failures.
* src/util/virfile.c (virFileLoopDeviceOpenSearch)
(virFileNBDDeviceFindUnused, virFileDeleteTree): Use new
interface.
* src/util/virnetdevtap.c (virNetDevTapGetRealDeviceName):
Properly check readdir errors.
* src/util/virpci.c (virPCIDeviceIterDevices)
(virPCIDeviceFileIterate, virPCIGetNetName): Report readdir
failures.
(virPCIDeviceAddressIOMMUGroupIterate): Use new interface.
* src/util/virscsi.c (virSCSIDeviceGetSgName): Report readdir
failures, and avoid memory leak.
(virSCSIDeviceGetDevName): Report readdir failures.
* src/util/virusb.c (virUSBDeviceSearch): Report readdir
failures.
* src/util/virutil.c (virGetFCHostNameByWWN)
(virFindFCHostCapableVport): Report readdir failures.
Signed-off-by: NEric Blake <eblake@redhat.com>

My commit 897808e7 added a parameter to virCgroupGetPercpuStats,
but didn't change the stub for systems where cgroups are not supported.

The iterator is checked for being less than or equal to need_cpus.
The 'n' variable is incremented need_cpus + 1 times.

Simplify the computation of need_cpus and make its value one larger,
to let it be used instead of 'n' and compared without the equal sign
in loop conditions.

Just index the sum_cpu_time array instead of using a helper variable.

Start the loop at start_cpu instead of continuing for all lower values.

The cpus are indexed from 0, so a startcpu value equal
to the number of CPUs is invalid.

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

total_cpus is the total number of CPUs on the host
need_cpus is the number of CPUs we need to look at

(need_cpus can be larger than ncpus, because we need to look
 at CPUs before the startcpu too, even if we aren't reporting
 their stats)

Currently, virCgroupGetPercpuStats is only used by the LXC driver,
filling out the CPUTIME stats. qemuDomainGetPercpuStats does this
and also filles out VCPUTIME stats.

Extend virCgroupGetPercpuStats to also report VCPUTIME stats if
nvcpupids is non-zero. In the LXC driver, we don't have cpupids.
In the QEMU driver, there is at least one cpupid for a running domain,
so the behavior shouldn't change for QEMU either.

Also rename getSumVcpuPercpuStats to virCgroupGetPercpuVcpuSum.

We need to return the number of successfully populated stats,
not the nparams supplied by the user.

Signed-off-by: NHongwei Bi <hwbi2008@gmail.com>

When I start multi VMs coincidently and any of the cgroup directories
named machine doesn't exist. There's a chance that VM start failed because
of creating directory failed:
Unable to initialize /machine cgroup: File exists
When the errno returned by mkdir in virCgroupMakeGroup is EEXIST,
we should pass it through and continue to start the VM.
Signed-off-by: NWang Yufei <james.wangyufei@huawei.com>

Any source file which calls the logging APIs now needs
to have a VIR_LOG_INIT("source.name") declaration at
the start of the file. This provides a static variable
of the virLogSource type.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Commit a1cbe4b5 added a check for spaces around assignments and this
patch extends it to checks for spaces around '=='.  One exception is
virAssertCmpInt where comma after '==' is acceptable (since it is a
macro and '==' is its argument).
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Running ./autobuild.sh detected a mingw failure:

  CCLD     libvirt.la
Cannot export virCgroupGetPercpuStats: symbol not defined
Cannot export virCgroupSetOwner: symbol not defined

* src/util/vircgroup.c (virCgroupGetPercpuStats)
(virCgroupSetOwner): Implement stubs.
Signed-off-by: NEric Blake <eblake@redhat.com>

This function is needed for user namespaces, where we need to chmod()
the cgroup to the initial uid/gid such that systemd is allowed to
use the cgroup.
Signed-off-by: NRichard Weinberger <richard@nod.at>
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Commit 65158899 broke the build on FreeBSD:
In function `qemuDomainGetCPUStats':
/../../src/qemu/qemu_driver.c:16102:
undefined reference to `virCgroupGetDomainTotalCpuStats'

To reuse this from other drivers, like lxc.

This reads blkio stats from blkio.throttle.io_service_bytes and
blkio.throttle.io_serviced.

This patch introduces virCgroupSetBlkioDeviceReadIops,
virCgroupSetBlkioDeviceWriteIops,
virCgroupSetBlkioDeviceReadBps and
virCgroupSetBlkioDeviceWriteBps,

we can use these interfaces to set up throttle
blkio cgroup for domain.

This patch also adds the new throttle blkio cgroup
elements to the test xml.
Signed-off-by: NGuan Qiang <hzguanqiang@corp.netease.com>
Signed-off-by: NGao feng <gaofeng@cn.fujitsu.com>

Since kernel 3.12 (commit 34ff8dc08956098563989d8599840b130be81252 in
linux-stable.git in particular) the value for 'unlimited' in cgroup
memory limits changed from LLONG_MAX to ULLONG_MAX.  Due to rather
unfortunate choice of our VIR_DOMAIN_MEMORY_PARAM_UNLIMITED constant
(which we transfer as an unsigned long long in Kibibytes), we ended up
with the situation described below (applies to x86_64):

 - 2^64-1 (ULLONG_MAX) -- "unlimited" in kernel = 3.12

 - 2^63-1 (LLONG_MAX) -- "unlimited" in kernel < 3.12
 - 2^63-1024 -- our PARAM_UNLIMITED scaled to Bytes

 - 2^53-1 -- our PARAM_UNLIMITED unscaled (in Kibibytes)

This means that when any number within (2^63-1, 2^64-1] is read from
memory cgroup, we are transferring that number instead of "unlimited".
Unfortunately, changing VIR_DOMAIN_MEMORY_PARAM_UNLIMITED would break
ABI compatibility and thus we have to resort to a different solution.

With this patch every value greater than PARAM_UNLIMITED means
"unlimited".  Even though this may seem misleading, we are already in
such unclear situation when running 3.12 kernel with memory limits set
to 2^63.

One example showing most of the problems at once (with kernel 3.12.2):
 # virsh memtune asdf --hard-limit 9007199254740991 --swap-hard-limit -1
 # echo 12345678901234567890 >\
/sys/fs/cgroup/memory/machine/asdf.libvirt-qemu/memory.soft_limit_in_bytes
 # virsh memtune asdf
 hard_limit     : 18014398509481983
 soft_limit     : 12056327051986884
 swap_hard_limit: 18014398509481983
Signed-off-by: NMartin Kletzander <mkletzan@redhat.com>

Unifying codding style, replace 'newpath' with 'newPath'.

From: Zhou Yimin <zhouyimin@huawei.com>

The range of valid values for cgroup tunables has
changed in the past and may change again in future
kernels. Avoid hardcoding range checks in libvirt
code, delegating range checking to the kernel itself.
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

When EINVAL is returned while changing a cgroups value, tell
user that what values are invalid for the field.
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

s/shoule/should
Signed-off-by: NChen Hanxiao <chenhanxiao@cn.fujitsu.com>

The function existed in two identical instances in lxc and qemu. Move it
to vircgroup.c and simplify it. Refactor the callers too.

Semantics of the libvirt helper are more clear. This change also allows
to clean up some pieces of code.

Debian systems may run the 'systemd-logind' daemon, which causes the
/sys/fs/cgroup/systemd  mount to be setup, but no other cgroup
controllers are created. While the LXC driver considers cgroups to
be mandatory, the QEMU driver is supposed to accept them as optional.

We detect whether they are present by looking in /proc/mounts for
any mounts of type 'cgroups', but this is not sufficient. We need to
skip any named mounts (as seen by a name=XXX string in the mount
options), so that we only detect actual resource controllers.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721979Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Some users in Ubuntu/Debian seem to have a setup where all the
cgroup controllers are mounted on /sys/fs/cgroup rather than
any /sys/fs/cgroup/<controller> name. In the loop which detects
which controllers are present for a mount point we were modifying
'mnt_dir' field in the 'struct mntent' var, but not always restoring
the original value. This caused detection to break in the all-in-one
mount setup.

Fix that logic bug and add test case coverage for this mount
setup.
Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>

Complete the refactoring by adding missing stubs so it compiles on
platform without cgroup support.
Signed-off-by: NEric Blake <eblake@redhat.com>

Complete moving to VIR_CGROUP_SUPPORTED
Signed-off-by: NEric Blake <eblake@redhat.com>

Continue converting to VIR_CGROUP_SUPPORTED
Signed-off-by: NEric Blake <eblake@redhat.com>