From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Novotny Subject: Re: Question about vcpu_avail Date: Tue, 24 Nov 2009 16:27:08 +0100 Message-ID: <4B0BFB4C.50102@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On 11/24/2009 04:20 PM, Keir Fraser wrote: > On 24/11/2009 15:08, "Michal Novotny" 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 >