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

[Cole Robinson]

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

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

- Cole