On Thu, 2017-11-23 at 18:05 +0100, Pavel Hrdina wrote:
On Wed, Nov 22, 2017 at 04:24:07PM +0100, Andrea Bolognani wrote:
> + <p>
> + Some of the values listed above are not compatible with all
> + architecture and machine types, and if the value is missing altogether,
s/architecture/architectures/
> + libvirt will try to pick an appropriate default. In general, it's a
> + good idea to specify neither the target type nor the target model,
> + leave the task of choosing values up to libvirt, and don't change the
> + values afterward.
I would probably rephrase that to something like this:
Some of the values listed above are not compatible with all
architectures and machine types. If neither the target type nor
the target model is specified, libvirt will choose default values,
which are in general the best choice.
The original wording kind of feels strictly limiting and like you
shouldn't try to configure it at all.
Well, you kinda shouldn't :)
When I was writing that paragraph, I had this piece of existing
documentation in mind:
PCI controllers also have an optional subelement <model> with an
attribute name. [...] In almost all cases, you should not manually
add a <model> subelement to a controller, nor should you modify
one that is automatically generated by libvirt.
I believe the same applies here. There's exactly one situation where
you'll want to change the model for a PCI controller (using ioh3420
even though pcie-root-port is available) and exactly one situation
where you'll want to change the model for a serial device (using
sclplmconsole instead of sclpconsole on s390x).
In both cases, there's an excape route for the very few people who
actually need to make that sort of choice, but everyone else is
better off not touching the defaults at all, and the wording IMHO
clearly expresses that ("in almost all cases", "in general").
--
Andrea Bolognani / Red Hat / Virtualization