[virt-tools-list] [RFC] VM configuration templates

[Cedric Bosdonnat]

On Thu, 2017-08-03 at 11:23 -0400, Cole Robinson wrote:
> On 08/03/2017 10:47 AM, Cedric Bosdonnat wrote:
> > On Thu, 2017-08-03 at 10:05 -0400, Cole Robinson wrote:
> > > On 07/24/2017 04:04 AM, Cedric Bosdonnat wrote:
> > > > Hi all,
> > > > 
> > > > While working on a special VM setup here, I was wondering about introducing
> > > > some configuration templates in virt-manager.
> > > > 
> > > > We could have a drop down list somewhere in the UI to select a template. Here
> > > > is a list of possible templates we could propose:
> > > > 
> > > >   * 'Full host VM'
> > > >       expose as much as possible of the host to a single VM
> > > >       no migration possible
> > > >   * 'Easily migratable VM'
> > > >   * 'normal-sized VM, as fast as possible'
> > > >       no migration possible either
> > > > 
> > > > Obviously choosing one of these templates would be optional. That drop down
> > > > list could be in the final page of the new guest wizard.
> > > > 
> > > > Any opinion on such a feature?
> > > > 
> > > 
> > > Sorry for the late response.
> > > 
> > > Besides <cpu> setting, what types of features do you see tweaking for 'Full
> > > host' vs 'easily' vs 'normal'?
> > 
> > In the full host, we would have the cpu model passed through, but also cpu pinning,
> > vNUMA setup and IOThreads. We could also define the memory hugepage size if applicable
> > and disable THP.
> > 
> > Easily migratable VM for example would get basic cpu features. We could use cpu-baseline
> > and cpu-compare to get the user define (in the preferences) a set of minimal cpu features
> > among his hosts.
> > 
> > > If the main differentiator is 'how migratable is this VM' I don't like the
> > > idea of putting that into the New VM wizard, since I think 99% of virt-manager
> > > users don't care about that, and migration is a difficult concept with a lot
> > > of VM config caveats, plus it usually requires host configuration outside of
> > > virt-manager to get working so it's unlikely to be something that 'just works'.
> > 
> > Having it in the configuration doesn't help users discovering such a new feature.
> 
> Discoverability has a tradeoff though. If it's an obvious self describing
> feature that many people will want to use and can't live without, make it 100%
> discoverable. But anything that isn't relevant to many users, and/or has
> drawbacks for some users, or is difficult to explain? Putting it in the New VM
> wizard means ever user may have to ask themselves a question (migratable vs
> full host vs middle ground) they might not know the answer to. These are the
> things I try to consider when adjusting the New VM wizard and other highly
> visible parts of the UI

Agreed. My initial UI proposition was just to start the discussion.

> > And for people wanting a full-host VM, that would be more interesting in the VM setup,
> > since they may not want this for all their hosts managed by virt-manager...
> > Or we could have this defined in the connection (thinking out loud).
> > 
> > > However I'm more open to a kind of migration vs performance setting in the
> > > Preferences dialog that determines the default New VM setup. But to discuss
> > > that we should start with a list of features you see enabling/disabling
> > 
> > I'll try to come up with some precise profiles then.
> > 
> 
> Cool, thanks. The important thing with those performance features is to
> understand if they have tradeoffs. Migratability is the obvious one, but are
> there performance tradeoffs or are they always wins
> 
> A UI starting point might be to add an option to the details cpu or memory
> page to sync settings with host topology or something like that.

Yep, and that even offer the advantage to be changed before the real creation
of the VM. Or could it be in the 'Overview' page.

--
Cedric