Question about vcpu_avail

Question about vcpu_avail

[Michal Novotny]

Hi,
I would like to ask about vcpu_avail variable in XendDomainInfo.py. Is 
that variable working and what is it used for ? I think it's a bitmask 
showing what VCPUs are used and what are not, am I correct? Also, I'm 
thinking of adding some variable of `maxvcpus` to define maximum number 
of vcpus for PV guests. This way we could define a config file like:

vcpus = 2
maxvcpus = 4

and by setting `xm vcpu-set {domain} {numberOfVCPUs}` we can set up to 4 
vcpus. Current behavior is to set to 1 vcpu and back to 2 vcpus but 
never to cross the number defined in of vcpus. Now we could be able to 
allocate up to 4 vcpus to the guest and not just 2... What do you think 
about that idea?

Thanks,
Michal

Re: Question about vcpu_avail

[Keir Fraser]

On 23/11/2009 15:02, "Michal Novotny" <minovotn@redhat.com> wrote:

> I would like to ask about vcpu_avail variable in XendDomainInfo.py. Is
> that variable working and what is it used for ? I think it's a bitmask
> showing what VCPUs are used and what are not, am I correct?

Yes, it allows you to configure which VCPUs are brought online by default on
guest bootup. If you do add a maxvcpus config item, it can be parsed out
into vcpus and vcpu_avail entirely within xm's create.py (excuse dodgy
pseudocode):
 if defined(maxvcpus):
     vcpu_avail = (1 << vcpus) - 1
     vcpus = maxvcpus

i.e., no need for xend itself to know about the new config item.

 -- Keir

> Also, I'm 
> thinking of adding some variable of `maxvcpus` to define maximum number
> of vcpus for PV guests. This way we could define a config file like:
> 
> vcpus = 2
> maxvcpus = 4
> 
> and by setting `xm vcpu-set {domain} {numberOfVCPUs}` we can set up to 4
> vcpus. Current behavior is to set to 1 vcpu and back to 2 vcpus but
> never to cross the number defined in of vcpus. Now we could be able to
> allocate up to 4 vcpus to the guest and not just 2... What do you think
> about that idea?

Re: Question about vcpu_avail

[Michal Novotny]

On 11/23/2009 04:28 PM, Keir Fraser wrote:
> On 23/11/2009 15:02, "Michal Novotny"<minovotn@redhat.com>  wrote:
>
>    
>> I would like to ask about vcpu_avail variable in XendDomainInfo.py. Is
>> that variable working and what is it used for ? I think it's a bitmask
>> showing what VCPUs are used and what are not, am I correct?
>>      
> Yes, it allows you to configure which VCPUs are brought online by default on
> guest bootup. If you do add a maxvcpus config item, it can be parsed out
> into vcpus and vcpu_avail entirely within xm's create.py (excuse dodgy
> pseudocode):
>   if defined(maxvcpus):
>       vcpu_avail = (1<<  vcpus) - 1
>       vcpus = maxvcpus
>
> i.e., no need for xend itself to know about the new config item.
>
>   -- Keir
>
>    

Well, I don't know Keir since the main use scenario for maxvcpus is to 
set number of vcpus for the guest so a new definition in Xend should be 
required.

Then you just issue `xm vcpu-set {domainName} {numberOfVcpus}` command 
to change number of VCPUs used by the guest, method `setVCpuCount(self, 
vcpus)` from XendDomainInfo.py is called to set number of VCpus so check 
should be implemented here as:

      def setVCpuCount(self, vcpus):
         if vcpus > self.info['maxvcpus']:
             log.debug("Cannot set %d vcpu(s) for domain %s (domid %d)."
                       "Maximum number of vcpu(s) is set to %d" %
                                 (vcpus, self.info['name'], self.domid,
                                  self.info['maxvcpus']))
             raise VmError("Cannot set %d vcpu(s). Maximum number of 
vcpus for "
                           "this domain is %d" % (vcpus, 
self.info['maxvcpus']) )

          self.info['vcpu_avail'] = (1 << vcpus) - 1
          self.storeVm('vcpu_avail', self.info['vcpu_avail'])

And domain_max_vcpus() call should be changed from 
`xc.domain_max_vcpus(self.domid, int(self.info['vcpus']))` to 
`xc.domain_max_vcpus(self.domid, int(self.info['maxvcpus']))`.

The only change that should be done to xm/create.py is to add `maxvcpus` 
to add_conf mapping to allow it to be read/parsed out from the config file.

Well, I've been looking to the code and there is self.info['VCPUs_max'] 
in XendDomainInfo.py. What is it used for? Could it be used for the same 
purpose like `maxvcpus` from example above?

Michal

>> Also, I'm
>> thinking of adding some variable of `maxvcpus` to define maximum number
>> of vcpus for PV guests. This way we could define a config file like:
>>
>> vcpus = 2
>> maxvcpus = 4
>>
>> and by setting `xm vcpu-set {domain} {numberOfVCPUs}` we can set up to 4
>> vcpus. Current behavior is to set to 1 vcpu and back to 2 vcpus but
>> never to cross the number defined in of vcpus. Now we could be able to
>> allocate up to 4 vcpus to the guest and not just 2... What do you think
>> about that idea?
>>      
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

Re: Question about vcpu_avail

[Keir Fraser]

On 24/11/2009 11:27, "Michal Novotny" <minovotn@redhat.com> wrote:

>> i.e., no need for xend itself to know about the new config item.
>> 
>>   -- Keir
>> 
>>    
> 
> Well, I don't know Keir since the main use scenario for maxvcpus is to
> set number of vcpus for the guest so a new definition in Xend should be
> required.

We already have a config option for that, called 'vcpus'. 'vcpu_avail' can
then be used to limit the number of those which are brought online during
initial boot. Any new config-file options can be sugar on top of those.

 -- Keir

Re: Question about vcpu_avail

[Michal Novotny]

On 11/24/2009 03:24 PM, Keir Fraser wrote:
> On 24/11/2009 11:27, "Michal Novotny"<minovotn@redhat.com>  wrote:
>
>    
>>> i.e., no need for xend itself to know about the new config item.
>>>
>>>    -- Keir
>>>
>>>
>>>        
>> Well, I don't know Keir since the main use scenario for maxvcpus is to
>> set number of vcpus for the guest so a new definition in Xend should be
>> required.
>>      
> We already have a config option for that, called 'vcpus'. 'vcpu_avail' can
> then be used to limit the number of those which are brought online during
> initial boot. Any new config-file options can be sugar on top of those.
>
>   -- Keir
>
>
>    
Well, imagine scenario you need to allocate 4 vcpus to the guest but you 
need to use only 2 vcpus at startup. So you suggest having `vcpus` and 
`maxvcpus` options in the config file and allocating all the `maxvcpus` 
and setting number of `vcpus` by setting appropriate mask using 
`vcpu_avail` ?

Thanks,
-- Michal

Re: Question about vcpu_avail

[Keir Fraser]

On 24/11/2009 14:51, "Michal Novotny" <minovotn@redhat.com> wrote:

>> We already have a config option for that, called 'vcpus'. 'vcpu_avail' can
>> then be used to limit the number of those which are brought online during
>> initial boot. Any new config-file options can be sugar on top of those.
>>    
> Well, imagine scenario you need to allocate 4 vcpus to the guest but you
> need to use only 2 vcpus at startup. So you suggest having `vcpus` and
> `maxvcpus` options in the config file and allocating all the `maxvcpus`
> and setting number of `vcpus` by setting appropriate mask using
> `vcpu_avail` ?

Yeah, I think you get it. In your example: if the user specifies maxvcpus=4,
vcpus=2 then xm turns that into vcpus=4, vcpu_avail=3 before sending it to
xend.

 -- Keir

Re: Question about vcpu_avail

[Michal Novotny]

On 11/24/2009 04:05 PM, Keir Fraser wrote:
> On 24/11/2009 14:51, "Michal Novotny"<minovotn@redhat.com>  wrote:
>
>    
>>> We already have a config option for that, called 'vcpus'. 'vcpu_avail' can
>>> then be used to limit the number of those which are brought online during
>>> initial boot. Any new config-file options can be sugar on top of those.
>>>
>>>        
>> Well, imagine scenario you need to allocate 4 vcpus to the guest but you
>> need to use only 2 vcpus at startup. So you suggest having `vcpus` and
>> `maxvcpus` options in the config file and allocating all the `maxvcpus`
>> and setting number of `vcpus` by setting appropriate mask using
>> `vcpu_avail` ?
>>      
> Yeah, I think you get it. In your example: if the user specifies maxvcpus=4,
> vcpus=2 then xm turns that into vcpus=4, vcpu_avail=3 before sending it to
> xend.
>
>   -- Keir
>
>    
Right, so, you mean that I should implement it into `xm` command itself 
and not XenD ? Well, what about people using eg. libvirt with upstream 
Xen? This way it should not be working since XM is not used... right?

Thanks,
-- Michal
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

Re: Question about vcpu_avail

[Keir Fraser]

On 24/11/2009 15:08, "Michal Novotny" <minovotn@redhat.com> wrote:

>> Yeah, I think you get it. In your example: if the user specifies maxvcpus=4,
>> vcpus=2 then xm turns that into vcpus=4, vcpu_avail=3 before sending it to
>> xend.
>>    
> Right, so, you mean that I should implement it into `xm` command itself
> and not XenD ? Well, what about people using eg. libvirt with upstream
> Xen? This way it should not be working since XM is not used... right?

If you add new config fields to xend, then libvirt callers are going to need
to be modified to expose them to users, aren't they (e.g., in a GUI or
whatever)? If the callers need modifying anyway, then they can just be
modified in a similar way to what I propose for xm, and deconstruct into the
config primitives that xend already understands.

 -- Keir

Re: Question about vcpu_avail

[Michal Novotny]

On 11/24/2009 04:20 PM, Keir Fraser wrote:
> On 24/11/2009 15:08, "Michal Novotny"<minovotn@redhat.com>  wrote:
>
>    
>>> Yeah, I think you get it. In your example: if the user specifies maxvcpus=4,
>>> vcpus=2 then xm turns that into vcpus=4, vcpu_avail=3 before sending it to
>>> xend.
>>>
>>>        
>> Right, so, you mean that I should implement it into `xm` command itself
>> and not XenD ? Well, what about people using eg. libvirt with upstream
>> Xen? This way it should not be working since XM is not used... right?
>>      
> If you add new config fields to xend, then libvirt callers are going to need
> to be modified to expose them to users, aren't they (e.g., in a GUI or
> whatever)? If the callers need modifying anyway, then they can just be
> modified in a similar way to what I propose for xm, and deconstruct into the
> config primitives that xend already understands.
>
>   -- Keir
>    

Well, the thing is whether it isn't better to be added to Xend itself 
instead of xm ? This could avoid further modifications. Maybe the 
callers have to be modified a little but I am not sure.

-- Michal

>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>    

Re: Question about vcpu_avail

[Keir Fraser]

On 24/11/2009 15:27, "Michal Novotny" <minovotn@redhat.com> wrote:

>> If you add new config fields to xend, then libvirt callers are going to need
>> to be modified to expose them to users, aren't they (e.g., in a GUI or
>> whatever)? If the callers need modifying anyway, then they can just be
>> modified in a similar way to what I propose for xm, and deconstruct into the
>> config primitives that xend already understands.
> 
> Well, the thing is whether it isn't better to be added to Xend itself
> instead of xm ? This could avoid further modifications. Maybe the
> callers have to be modified a little but I am not sure.

Let me put it this way then: xend already allows you to express what you
want to be able to do, through vcpus/vcpu_avail. Prettifying that for end
users is an issue of UI design.

 -- Keir