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

[Cole Robinson]

On 04/23/2013 11:04 AM, Martin Kletzander wrote:
> 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.
> 

The previous 'button' method could have a HW upgrade problem as well, but the
failure scenario is better, libvirt will refuse to start the VM. People having
to reactivate their windows guests is the scarier thing to me. And I don't
think people would be too surprised if after upgrading their HW their existing
VMs said 'the hw has changed' or whatever.

The libvirt upgrade case is scarier to me TBH, people keep VMs around for a
long time and I know from experience that the CPU reported by <capabilities>
can change over libvirt versions, at least gaining new flags.

>> 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 :)
> 

Of course it _can_ be explained in the UI, the problem is will it actually
inform an ignorant user about which option they should choose, and in a
reasonable manner? Since the implications here are subtle enough that even us
libvirt guys overlooked corner cases, user's are going to have no chance of
getting it 'right'.

Jiri probably has better ideas, but maybe there can be a host-model-static or
something like that: it just does a one time copy of the capabilities cpu into
the domain XML, but will update to the new CPU when the guest is migrated. But
I don't know, it's a pretty tricky problem.

- Cole