From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: George Dunlap <george.dunlap@eu.citrix.com>
Cc: xen-devel@lists.xensource.com, Ian.Jackson@eu.citrix.com,
Ian Campbell <Ian.Campbell@citrix.com>
Subject: Re: [PATCH 1/2] xl: neuter vcpu-set --ignore-host.
Date: Thu, 26 Sep 2013 21:44:57 -0400 [thread overview]
Message-ID: <20130927014456.GC7952@konrad-lan.dumpdata.com> (raw)
In-Reply-To: <52445FED.1020604@eu.citrix.com>
On Thu, Sep 26, 2013 at 05:25:17PM +0100, George Dunlap wrote:
> On 26/09/13 13:48, Konrad Rzeszutek Wilk wrote:
> >On Thu, Sep 26, 2013 at 10:06:31AM +0100, Ian Campbell wrote:
> >>On Wed, 2013-09-25 at 16:40 -0400, Konrad Rzeszutek Wilk wrote:
> >>>When Xen 4.3 was released we had a discussion whether we should
> >>>allow the vcpu-set command to allow the user to set more than
> >>>physical CPUs for a guest (it didn't). The author brought up:
> >>> - Xend used to do it,
> >>IMHO xend is buggy here. If it were being maintained I encourage a patch
> >>to file this particular sharp edge off.
> >>
> >>> - If a user wants to do it, let them do it,
> >>We do, we have an option for those who know what they are doing to use
> >>in the tiny minority of cases where they need to do this.
> >>
> >>> - The original author of the change did not realize the
> >>> side-effect his patch caused this and had no intention of changing it.
> >>a happy accident then.
> >>
> >>> - The user can already boot a massively overcommitted guest by
> >>> having a large 'vcpus=' value in the guest config and we allow
> >>> that.
> >>IMHO this is an xl bug, I'd be happy to see a patch to fix this and
> >>require and override here too.
> >I think I posted one some time ago, but I don't recall anybody
> >commenting on it. Will repost it.
> >>>Since we were close to the release we added --ignore-host parameter
> >>>as a mechanism for a user to still set more vCPUs that the physical
> >>>machine as a stop-gate.
> >>>
> >>>This patch keeps said option but neuters the check so that we
> >>>can overcommit. In other words - by default the user is
> >>>allowed to set as many vCPUs as they would like.
> >>and why would a naive user want to do this? non-naive users can use the
> >>option if this is what they really want, and are probably grateful for
> >>the catch if they didn't intend to overcommit, which is almost always
> >>even for expert users.
> >>
> >>This change need far better rationalisation than "because xend did it"
> >>and "because we can". IMHO.
> >I am going to defer to George here. His viewpoint (I am going to
> >probably mangle it up) was that - if the user wants to do, let him/her
> >do it without us putting obstacles.
> >
> >And I think Ian Jackson was ambivalent here and was deferring to George.
>
> So I've gone back and read the original thread, and what I actually
> said was:
>
> "So I think the right thing to do long-term is to make it possible
> to do in xl. Having a "seatbelt" restriction by default that can be
> overridden would be OK with me, but I think a warning message when
> vcpus > pcpus would suffice."
>
> And my summary of mine and IanC's positions at the time (which IanC
> did not dispute) was:
>
> "We both agree that "vcpus > pcpus" is a bad configuration. I think
> ideally we should support it (because administrators should be
> allowed to shoot themselves in the foot) and Ian[C] seems to be
> making the case that we shouldn't support it."
>
> IanJ, as I understood him, agreed with me that it should be *possible*.
>
> As IanC points out, it is possible -- you just have to add "--ignore-host".
>
> So given what all of us think, keeping the "seatbelt" is probably
> the best compromise. IanC is happy that a hapless user will not
> accidentally shoot his own foot, and IanJ and I are happy that a
> skilled user can shoot her own foot if she really wants to.
Excellent. Let me prep a patch with said seatbelt option.
next prev parent reply other threads:[~2013-09-27 1:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-25 20:40 [RFC] Make xl vcpu-set work in overcommit and with PV guests. (v2) Konrad Rzeszutek Wilk
2013-09-25 20:40 ` [PATCH 1/2] xl: neuter vcpu-set --ignore-host Konrad Rzeszutek Wilk
2013-09-26 7:23 ` Dario Faggioli
2013-09-26 12:45 ` Konrad Rzeszutek Wilk
2013-09-26 9:06 ` Ian Campbell
2013-09-26 12:48 ` Konrad Rzeszutek Wilk
2013-09-26 16:25 ` George Dunlap
2013-09-27 1:44 ` Konrad Rzeszutek Wilk [this message]
2013-09-26 15:28 ` Konrad Rzeszutek Wilk
2013-09-26 15:47 ` Ian Campbell
2013-09-26 16:01 ` Andrew Cooper
2013-09-26 16:05 ` Ian Campbell
2013-09-27 1:52 ` Konrad Rzeszutek Wilk
2013-09-27 8:41 ` Ian Campbell
2013-09-30 18:40 ` Konrad Rzeszutek Wilk
2013-09-25 20:40 ` [PATCH 2/2] xl/vcpuset: Make it work for PV guests Konrad Rzeszutek Wilk
2013-09-26 9:10 ` Ian Campbell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130927014456.GC7952@konrad-lan.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=Ian.Campbell@citrix.com \
--cc=Ian.Jackson@eu.citrix.com \
--cc=george.dunlap@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.