[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[Libvir] [RFC] The idea of 'policy manager'



Hello,

I summarized the idea about 'policy manager'. The purpose of 'policy manager'
is to manage and to operate 'runtime policy' such as cpu pin/weight/cap.

Please refer to the following thread about earlier argument about
'policy manager'.

https://www.redhat.com/archives/libvir-list/2007-February/msg00211.html

To implement the above mentioned features, I think that 'policy manager'
need to be constructed by CLI and API. Is it all right in the following ideas?


- About CLI

  At first, I think the following commands are necessary.
  ('xxx' means temporary command name)

  (1) xxx vcpupin <domain> <vcpu> <cpulist>
       : Same as virsh vcpupin <domain> <vcpu> <cpulist> command

  (2) xxx schedweight <domain> <weight>
       : Same as xm sched-credit -d <domain> -w <weight> command

  (3) xxx schedcap <domain> <cap>
       : Same as xm sched-credit -d <domain> -c <cap> command

  (4) xxx cpuoccupy <pcpu> <domains>
       : The domains specified by <domains> can use the <pcpu> in occupancy,
         and the other domains can't use it. (*)

  (5) xxx cpupolicy <domain>
       : Show the CPU runtime policy of <domain>.

    (*) When a running domain has vcpu pinned to only single pcpu,
        the other domains can't occupy the pcpu.

  In above mentioned (1)-(4), policy informations of not only running domains
  but also inactive domains are managed in the following API.

- About API

  The main function which is necessary for API are as follows. 

  o When CLI command is executed, the demanded processing is done
    by calling libvirt from API.
  o API preserves the specified by CLI command to a specific file.
  o When start/reboot domain command is executed by libvirt,
    API is called from libvirt and the domain is set the runtime policy.

- TODO list

  o It is necessary to add new function into libvirt to change scheduler
    parameters (cpu weight/cap) previously.


Any other thoughts from anyone?

Regards,
Yuzuru Asano.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]