Re: [libvirt] [Qemu-devel] Qemu, libvirt, and CPU models
On Wed, Mar 07, 2012 at 19:26:25 -0300, Eduardo Habkost wrote:
Awesome. So, if Qemu and libvirt disagrees, libvirt will know that
and
add the necessary flags? That was my main worry. If disagreement between
Qemu and libvirt is not a problem, it would make things much easier.
...but:
Is that really implemented? I simply don't see libvirt doing that. I see
code that calls "-cpu ?" to list the available CPU models, but no code
calling "-cpu ?dump", or parsing the Qemu CPU definition config file. I
even removed some random flags from the Nehalem model on my machine
(running Fedora 16), and no additional flags were added.
Right, currently we only detect if Qemu knows requested CPU model and use
another one if not. We should really start using something like -cpu ?dump.
However, since qemu may decide to change parts of the model according to,
e.g., machine type, we would need something more dynamic. Something like, "hey
Qemu, this is the machine type and CPU model we want to use, these are the
features we want in this model, and we also want few additional features,
please, tell us what the resulting CPU configuration is (if it is even
possible to deliver such CPU on current host)". And the result would be
complete CPU model, which may of course be different from what the qemu's
configuration file says. We could then use the result to update domain XML (in
a way similar to how we handle machine types) so that we can guarantee the
guest will always see the same CPU. Once CPU is updated, we could just check
with Qemu if it can provide such CPU and start (or refuse to start) the
domain. Does it seem reasonable?
> We could go one step further and just write
> out a cpu.conf file that we load in QEMU with -loadconfig.
Sounds good. Anyway, I want to make everything configurable on the
cpudef config file configurable on the command-line too, so both options
(command-line or config file) would work.
I'd be afraid of hitting the command line length limit if we specified all CPU
details in it :-)
So, it looks like either I am missing something on my tests or
libvirt
is _not_ probing the Qemu CPU model definitions to make sure libvirt
gets all the features it expects.
Also, I would like to ask if you have suggestions to implement
the equivalent of "-cpu ?dump" in a more friendly and extensible way.
Would a QMP command be a good alternative? Would a command-line option
with json output be good enough?
I quite like the possible solution Anthony (or perhaps someone else) suggested
some time ago (it may however be biased by my memory): qemu could provide a
command line option that would take QMP command(s) and the result would be QMP
response on stdout. We could use this interface for all kinds of probes with
easily parsed output.
(Do we have any case of capability-querying being made using QMP
before
starting any actual VM, today?)
Not really. We only query QMP while for available QMP commands that we can
used further on when the domain is running.
So, about the above: the cases where libvirt thinks a feature is
available but Qemu knows it is not available are sort-of OK today,
because Qemu would simply refuse to start and an error message would be
returned to the user.
Really? In my experience qemu just ignored the feature it didn't know about
without any error message and started the domain happily. It might be because
libvirt doesn't use anything like -cpu ...,check or whatever is needed to make
it fail. However, I think we should fix it.
But what about the features that are not available on the host CPU,
libvirt will think it can't be enabled, but that _can_ be enabled?
x2apic seems to be the only case today, but we may have others in the
future.
I think qemu could tell us about those features during the probe phase (my
first paragraph) and we would either use them with policy='force' or something
similar.
Jirka