[libvirt] qemu: cpu model definition problem

Jiri Denemark jdenemar at redhat.com
Tue Jun 21 12:21:01 UTC 2016


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




More information about the libvir-list mailing list