Hi,
AFAIK this topic is not new but I think we still do not have a good solution
for it. Libvirt already supports specifying what CPU and its features a guest
should see but imagine one wants to run a guest on the best possible CPU. The
current way is to copy the <cpu> element from capabilities XML into domain
XML. This approach is fine since it provides reproducible environment and such
domain can even be migrated to a different host. But the CPU shown provided to
a guest is not the same as the real host CPU. It's based on a model which
doesn't reflect all aspects of real CPUs. Ideally, we would model everything
but that's quite complicated and may need updating anytime a new CPU is
introduced.
I think we should add a possibility to passthrough host CPU into a domain no
matter what the CPU looks like. Domains configured in such a way will not be
allowed to be migrated since we cannot guarantee the same CPU on destination
host but they would be able to see the real CPU. Another benefit is that a
single XML configuration would work on any CPU without modifications. Since
possible issues with such domains will be harder to debug we can mark them as
tainted just like we do if someone calls qemu monitor commands directly.
I'm not sure what XML representation makes the most sense so I'll mention
several options which I'm thinking about:
- "host" ("native", "passthrough", whatever) special model; same name space as
real CPU models, I don't like this too much:
<cpu match='exact'>
<model>host</model>
</cpu>
- "host" match policy; has nice first-look semantics that the guest CPU
matches host's but doesn't play very nice with the defined semantics of
"match" attribute:
<cpu match='host'/>
- new "mode" attribute; IMHO the best one, similar to what we have for SMBIOS:
<cpu mode='host'/>
vs.
<cpu mode='custom' match='...'>
<model>...</model.
...
</cpu>
What do you think?
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list