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

Guannan Ren gren at redhat.com
Fri Apr 26 04:42:28 UTC 2013


On 04/26/2013 01:53 AM, Cole Robinson wrote:
> On 04/25/2013 03:41 AM, Guannan Ren wrote:
>> 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
> Yeah I think we should restore the button behavior, sorry I know its a pain.
> I'd rather see what host-model improvements Jiri plans hit a libvirt release
> and then we can re-evaluate.

     Okay, the revert patch sent:
https://www.redhat.com/archives/virt-tools-list/2013-April/msg00258.html

     Guannan




More information about the virt-tools-list mailing list