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
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
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?_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
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 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel