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

[Cedric Bosdonnat]

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.
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.

--
Cedric