Re: [Xen-devel] Xen Platform QoS design discussion

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 02/05/14 13:30, Xu, Dongxiao wrote:
>> -----Original Message-----
>> From: Jan Beulich [mailto:JBeulich@xxxxxxxx]
>> Sent: Friday, May 02, 2014 5:24 PM
>> To: Xu, Dongxiao
>> Cc: Andrew Cooper(andrew.cooper3@xxxxxxxxxx); Ian Campbell;
>> xen-devel@xxxxxxxxxxxxx
>> Subject: RE: Xen Platform QoS design discussion
>>
>>>>> On 01.05.14 at 02:56, <dongxiao.xu@xxxxxxxxx> wrote:
>>>> From: Ian Campbell [mailto:Ian.Campbell@xxxxxxxxxx]
>>>> Have you asked yourself whether this information even needs to be
>>>> exposed all the way up to libxl? Who are the expected consumers of this
>>>> interface? Are they low-level CLI tools (i.e. like xenpm is) or are you
>>>> expecting toolstacks to plumb this information all the way up to their
>>>> GUI or CLI (e.g. xl or virsh)?
>>> The information returned to libxl users is the cache utilization for a
>>> certain domain in certain socket, and the main consumers are cloud users 
>>> like
>>> openstack, etc. Of course, we will also provide an xl command to present 
>>> such
>>> information.
>> To me this doesn't really address the question Ian asked, yet knowing
>> who's going to be the consumer of the data is also quite relevant for
>> answering your original question on the method to obtain that data.
>> Obviously, if the main use of it is per-domain, a domctl would seem like
>> a suitable approach despite the data being more of sysctl kind. But if
>> a global view would be more important, that model would seem to make
>> life needlessly hard for the consumers. In turn, if using a domctl, I tend
>> to agree that not using shared pages would be preferable; iirc their use
>> was mainly suggested because of the size of the data.
> From the discussion with openstack developers, on certain cloud host, all 
> running VM's information (e.g., domain ID) will be stored in a database, and 
> openstack software will use libvirt/XenAPI to query specific domain 
> information. That libvirt/XenAPI API interface basically accepts the domain 
> ID as input parameter and get the domain information, including the platform 
> QoS one.
>
> Based on above information, I think we'd better design the QoS hypercall 
> per-domain.

The design of the hypercall has nothing to do with the design of the
libxl/XenAPI interface.

It is clear from this statement that cloudstack want all information for
all domains.  Therefore, at one level at least there will be a big set
of nested loops like:

every $TIMEPERIOD
  for each domain
    for each type of information
      get-$TYPE-information-for-$DOMAIN

As far as a XenAPI inteface would go, this would be information coming
from the rrdd-daemon.  This daemon most certainly wont want to be using
a hypercall designed like this.

Does anyone know how libvirt/libxl would go about
collecting/storing/passing this information?

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel