1. 09 4月, 2014 3 次提交
    • J
      Rename id, max_id to need_cpus, total_cpus · dd74ab4e
      Ján Tomko 提交于
      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)
      dd74ab4e
    • J
      Extend virCgroupGetPercpuStats to fill in vcputime too · 897808e7
      Ján Tomko 提交于
      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.
      897808e7
    • J
      Fix return value of virCgroupGetPercpuStats · 23d2d863
      Ján Tomko 提交于
      We need to return the number of successfully populated stats,
      not the nparams supplied by the user.
      23d2d863
  2. 31 3月, 2014 1 次提交
  3. 25 3月, 2014 1 次提交
  4. 21 3月, 2014 1 次提交
    • W
      cgroup: Fix start VMs coincidently failed · bfb29654
      Wang Yufei 提交于
      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>
      bfb29654
  5. 18 3月, 2014 2 次提交
  6. 26 2月, 2014 1 次提交
    • E
      build: fix cgroups on non-Linux · fa2e4dbf
      Eric Blake 提交于
      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>
      fa2e4dbf
  7. 24 2月, 2014 1 次提交
  8. 21 2月, 2014 1 次提交
  9. 20 2月, 2014 3 次提交
  10. 20 1月, 2014 1 次提交
  11. 10 12月, 2013 1 次提交
    • M
      cgroups: Redefine what "unlimited" means wrt memory limits · 231656bb
      Martin Kletzander 提交于
      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>
      231656bb
  12. 06 12月, 2013 1 次提交
  13. 15 10月, 2013 2 次提交
  14. 09 10月, 2013 1 次提交
  15. 16 9月, 2013 2 次提交
  16. 12 9月, 2013 1 次提交
  17. 11 9月, 2013 1 次提交
    • D
      Fix cgroups when all are mounted on /sys/fs/cgroup · f0b6d8d4
      Daniel P. Berrange 提交于
      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>
      f0b6d8d4
  18. 13 8月, 2013 8 次提交
  19. 01 8月, 2013 3 次提交
    • D
      Enable support for systemd-machined in cgroups creation · 2fe24701
      Daniel P. Berrange 提交于
      Make the virCgroupNewMachine method try to use systemd-machined
      first. If that fails, then fallback to using the traditional
      cgroup setup code path.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      2fe24701
    • D
      Cope with races while killing processes · 75304eaa
      Daniel P. Berrange 提交于
      When systemd is involved in managing processes, it may start
      killing off & tearing down croups associated with the process
      while we're still doing virCgroupKillPainfully. We must
      explicitly check for ENOENT and treat it as if we had finished
      killing processes
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      75304eaa
    • D
      Add support for systemd cgroup mount · aedd46e7
      Daniel P. Berrange 提交于
      Systemd uses a named cgroup mount for tracking processes. Add
      it as another type of controller, albeit one which we have to
      special case in a number of places. In particular we must
      never create/delete directories there, nor add tasks. Essentially
      the systemd mount is to be considered read-only for libvirt.
      
      With this change both the virCgroupDetectPlacement and
      virCgroupCopyPlacement methods must be invoked. The copy
      placement method will copy setup for resource controllers
      only. The detect placement method will probe for any
      named controllers, or resource controllers not already
      setup.
      Signed-off-by: NDaniel P. Berrange <berrange@redhat.com>
      aedd46e7
  20. 29 7月, 2013 2 次提交
  21. 26 7月, 2013 3 次提交