Commit Graph

12 Commits

Author SHA1 Message Date
Ján Tomko
af1c98e406 Fix virCgroupGetPercpuStats with non-continuous present CPUs
Per-cpu stats are only shown for present CPUs in the cgroups,
but we were only parsing the largest CPU number from
/sys/devices/system/cpu/present and looking for stats even for
non-present CPUs.
This resulted in:
internal error: cpuacct parse error
2015-01-22 17:01:11 +01:00
Ján Tomko
2dcdb7f654 Indent top-level labels by one space in tests/ 2014-03-25 14:58:41 +01:00
Thorsten Behrens
35aebf1118 Fix misspelled cpuacct.usage_percpu in cgroup mock. 2014-02-20 16:20:10 +01:00
Thorsten Behrens
9ce8a7c5c5 Add unit test for virCgroupGetBlkioIo*Serviced 2014-02-20 16:20:09 +01:00
Eric Blake
57682aea36 maint: fix comma style issues: tests, tools
Most of our code base uses space after comma but not before;
fix the remaining uses before adding a syntax check.

* tests/sysinfotest.c: Consistently use commas.
* tests/viratomictest.c: Likewise.
* tests/vircgroupmock.c: Likewise.
* tools/virsh-domain.c: Likewise.
* tools/virsh-volume.c: Likewise.

Signed-off-by: Eric Blake <eblake@redhat.com>
2013-11-20 09:14:55 -07:00
Michal Privoznik
32799f1a9d vircgroupmock: Mock access() to some more files
Currently, if access(path, mode) is invoked, we check if @path has this
special prefix SYSFS_PREFIX. If it does, we modify the path a bit and
call realaccess. If it doesn't we act just like a wrapper and call
realaccess directly. However, we are mocking fopen() as well. And as one
can clearly see there, fopen("/proc/cgroups") will succeed. Hence, we
have an error in our mocked access(): We need to check whether @path is
not equal to /proc/cgroups as it may not exists on real system we're
running however we definitely know how to fopen() it.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2013-10-22 15:42:19 +01:00
Daniel P. Berrange
a48838ad2e Fix launching of VMs on when only logind part of systemd is present
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=721979

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-09-12 11:32:36 +01:00
Daniel P. Berrange
f0b6d8d472 Fix cgroups when all are mounted on /sys/fs/cgroup
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: Daniel P. Berrange <berrange@redhat.com>
2013-09-11 11:45:38 +01:00
Daniel P. Berrange
78cff68ca3 Workaround issue with clang and inline functions with static vars
Clang does not like it when you pass a static variable to an
inline function

 vircgroupmock.c:462:22: error: static variable 'fakesysfsdir' is
  used in an inline function with external linkage [-Werror,-Wstatic-in-inline]

Just make the var non-static to avoid this

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-05-14 15:00:22 +01:00
Daniel P. Berrange
f3662737b1 Do proper escaping of cgroup resource partitions
If a user cgroup name begins with "cgroup.", "_" or with any of
the controllers from /proc/cgroups followed by a dot, then they
need to be prefixed with a single underscore. eg if there is
an object "cpu.service", then this would end up as "_cpu.service"
in the cgroup filesystem tree, however, "waldo.service" would
stay "waldo.service", at least as long as nobody comes up with
a cgroup controller called "waldo".

Since we require a '.XXXX' suffix on all partitions, there is
no scope for clashing with the kernel 'tasks' and 'release_agent'
files.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-04-26 13:52:02 +01:00
Daniel P. Berrange
83336118db Track symlinks for co-mounted cgroup controllers
If a cgroup controller is co-mounted with another, eg

   /sys/fs/cgroup/cpu,cpuacct

Then it is a requirement that there exist symlinks at

   /sys/fs/cgroup/cpu
   /sys/fs/cgroup/cpuacct

pointing to the real mount point. Add support to virCgroupPtr
to detect and track these symlinks

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-04-15 17:35:32 +01:00
Daniel P. Berrange
d14524701a Add a test suite for cgroups functionality
Some aspects of the cgroups setup / detection code are quite subtle
and easy to break. It would greatly benefit from unit testing, but
this is difficult because the test suite won't have privileges to
play around with cgroups. The solution is to use monkey patching
via LD_PRELOAD to override the fopen, open, mkdir, access functions
to redirect access of cgroups files to some magic stubs in the
test suite.

Using this we provide custom content for the /proc/cgroup and
/proc/self/mounts files which report a fixed cgroup setup. We
then override open/mkdir/access so that access to the cgroups
filesystem gets redirected into files in a temporary directory
tree in the test suite build dir.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-04-15 17:35:31 +01:00