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

[Guannan Ren]

On 04/24/2013 11:39 AM, Guannan Ren wrote:
> On 04/23/2013 11:20 PM, Jiri Denemark wrote:
>> On Tue, Apr 23, 2013 at 10:47:58 -0400, 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...
>>>
>>> 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.
>> I agree that currently copying host CPU XML into guest CPU is safest
>> than using host-model (which is just a shortcut for it but the config is
>> not preserved after domain shutdown). However, host-model will be
>> improved (hopefully soon) to provide more. And I think we (libvirt)
>> should come up with something that would preserve the configuration,
>> too.
>>
>
>    Actually,  virt-manager cached the cpu model and features via 
> VIR_DOMAIN_XML_UPDATE_CPU
>    after toggling host-model checkbox.
>    We can give a hint to user if host cpu changed after 
> destroy/start/migration: one is to keep guest
>    OS running safely with cached host-model cpu (convert to custom 
> mode automatically), the other
>    is to use newest host-model cpu.

       Hi Cole,

          What's your ideas? If you decide to restore the 'copy' button, 
I will do it.

       Guannan