Re: Support situation for nestedhvm

[Alejandro Vallejo <alejandro.vallejo@cloud.com>]

On Thu, Nov 09, 2023 at 10:36:21AM +0000, Andrew Cooper wrote:
> On 09/11/2023 9:50 am, Alejandro Vallejo wrote:
> > Hi,
> >
> > On Tue, Nov 07, 2023 at 08:15:32PM +0000, Andrew Cooper wrote:
> >> On 07/11/2023 7:53 pm, Elliott Mitchell wrote:
> >>> I ran into the nestedhvm via the following path.  I was considering the
> >>> feasibility of shedding tasks from a desktop onto a server running Xen.
> >>> I was looking at `man xl.cfg` and noticed "nestedhvm".
> >>>
> >>> Since one of the tasks the computer handled was running other OSes in
> >>> fully simulated environments, this seemed to be something I was looking
> >>> for.  No where did I ever see anything hinting "This configuration option
> >>> is completely unsupported and risky to use".
> >> This one is explicitly covered in SUPPORT.md, and has had XSAs out
> >> against it in the past for being unexpectedly active when it oughtn't to
> >> have been.
> >>
> >>> Things simply started exploding without any warnings.
> >> Things also explode if you try to create a VM with 10x more RAM than you
> >> have, or if you try `./xenwatchdogd --help`, or `xl debug-keys c`, or
> >> many other things. 
> >>
> >> The xl manpage probably ought to state explicitly that the option is
> >> experimental, but that the extent of what I'd consider reasonable here.
> >>
> >> You can't solve educational matters with technical measures.
> >>
> >> ~Andrew
> >>
> > No, but we can prevent users unexpectedly shooting themselves in the foot.
> 
> ... and break OSSTest and XenRT while you're at it.
> 
> Like it or not, this knob is behaved in this way for 15 years.  You will
> be doing harm for no benefit by trying to change it.
Improving UX is a distinctively good benefit. A lot of people on this
mailing list may be aware of its quirks, but a user shouldn't need to be
that aware in order to set up a stable system.

> 
> And if you need a cautionary tail on why this is a bad idea generally,
> as well as a background on why I will firmly object to technical
> countermeasures like this, read up on Xen's allow_unsafe command line
> parameter.
> 
> ~Andrew
This?
  https://bugzilla.redhat.com/show_bug.cgi?id=858724

If so, that's very different. allow_unsafe caused previously accesible
remote hosts to become unbootable after an update, leaving anyone with a
remote host without IPMI interface dead in the water. It's nothing like
preventing spinning up a VM with a set of features that with high
likelihood a user doesn't want.

Both OSSTest and XenRT can simply adjust their nestedhvm knobs based on a
simple probing script.

Cheers,
Alejandro