[libvirt] qemu: cpu model definition problem

[Maxim Nestratov]

21.06.2016 15:21, Jiri Denemark пишет:

> On Sat, Jun 18, 2016 at 23:24:56 +0300, Maxim Nestratov wrote:
>> Hi all,
>>
>> I've just encountered a problem with ability to live migrate a VM
>> between hosts using the following cpu section in VM's xml:
>>
>>     <cpu mode='custom' match='exact'>
>>       <model fallback='allow'>Haswell-noTSX</model>
>>       ...
>>       <feature policy='disable' name='rdrand'/>
>>     </cpu>
>>
>> The problem is that a VM with such a config crashes when it migrates
>> from a host where 'rdrand' presents to a host where it is absent.
>> This happens due to the fact that QEMU and libvirt have pretty different
>> view on what 'Haswell-noTSX' is. Libvirt's description lacks some
>> features, which present in QEMU description of this cpu model (e.g.
>> 'rdrand'). It is impossible to disable features present on the host and
>> different from QEMU's ones by current libvirt code, i.e. libvirt thinks
>> that no use to disable something that doesn't exist.
>> Of course, the problem in this case can be fixed just by adding missed
>> features to 'Haswell-noTSX' model in cpu_map.xml to match what QEMU has,
>> but it doesn't seem right because it will help just in this particular
>> case, and in general, it will not be a solution because QEMU can change
>> its cpu model definitions at any time and it does this from time to time.
>> What libvirt might have done is:
>>    - either ask QEMU for cpu model definition and work with it,
> We can't do this since QEMU is not able to provide us the data the way
> we need them. There were several attempts to change that, but it's not
> an easy task and the current consensus says it's not even necessary now.
>
>> - or construct a command line for QEMU with required and disabled
>> features without taking into account libvirt cpu_map.xml, i.e. always
>> add '+xx' and '-yy' for features mentioned explicitly in domain xml.
> Yes, we should do this. And we will do this once I finish my series so
> that I can (at least partially) send it to the list. Stay tuned :-)
>
> Jirka

Ok. Thank you.

Maxim