[virt-tools-list] [PATCH v2 0/3] add cpu mode 'host-model' support

[Martin Kletzander]

On 04/23/2013 04:47 PM, Cole Robinson wrote:
> On 04/23/2013 08:06 AM, Martin Kletzander wrote:
>> On 04/23/2013 01:56 PM, Guannan Ren wrote:
>>> On 04/23/2013 07:37 PM, Martin Kletzander wrote:
>>>> On 04/20/2013 10:09 PM, Cole Robinson wrote:
>>>>> On 04/18/2013 03:47 AM, Guannan Ren wrote:
>>>>>> v1 to v2:
>>>>>>    removed UPDATE_CPU flag checking
>>>>>>    renamed helper function name from reset() to clear_attrs()
>>>>>>    change the check box to be labeled 'Use host CPU model'
>>>>>>    remove the lightbulb icon, use tooltip instead
>>>>>>    reword the tooltip from Cole's
>>>>>>    remove the WARN image icon from UI
>>>>>>
>>>>>> Add a checkbox for 'host-model' mode and removed 'Copy host CPU
>>>>>> configuration'
>>>>>> button.
>>>>>>
>>>> Sorry for not catching this thread earlier, but IIUC, the 'host-model'
>>>> doesn't make up for the button.  XML is saved with 'host-model' then,
>>>> right?
>>>>
>>>> Unfortunately, I can't see that easily right now as git virt-manager
>>>> consistently crashes for me on all VMs and bare metal as well and I made
>>>> that one of my priorities in order to speed up the bug hunt on it.
>>>>
>>>
>>>     Martin, I am using virt-manager git head now, it seems fine for me.
>>>     Is there anything wrong about 'host-model', I can't quite follow you
>>> here.
>>>
>>>     Guannan
>>>
>>
>> I was just wondering if dropping the button isn't a bad idea, some guest
>> OS might have problems when it is ran on different CPU, which is what
>> might happen with host-model after destroy/start, but would be avoided
>> with 'Copy host configuration'.  I'm not saying 'host-model' is wrong,
>> we definitely want the support for that.
>>
> 
> Hmm, how would host-model change CPU between destroy/start... like a libvirt
> update supporting more flags? I didn't think about that, and it is
> problematic. Libvirt goes to great lengths to try and preserve hardware config
> for a VM across libvirt updates, host-model potentially throws that out the
> window...
> 

I could only think of some HW upgrade, which is the admin's problem in
this case, I guess.  Migrations etc. shouldn't be vulnerable to this as
the current used specification is used to transfer the machine.

> Unless there's some clever way of getting around that it makes me think
> host-model just doesn't fit in the UI. Trying to explain all the nuances of
> this stuff in the current UI is impossible, so until we come up with something
> different we should go with the safest bet, which is only providing the old
> button press behavior.
> 

How about getting off the hook by tool-tipping the user on host-model
with something like "Use host configuration for each start." or
something similar with added "for details on 'host-model', see libvirt
documentation".

This wouldn't just get us off the hook but also avoid duplicating
documentation.  I'd just like to see both options in the UI, so I'm
thinking more towards unified result, but feel free to convert me with
your opinions :)

Martin