On 08/04/2016 11:11 AM, Andrea Bolognani wrote:
On Mon, 2016-08-01 at 10:02 -0400, Laine Stump wrote:
> 2) To assure that the actual device presented to the guest doesn't
> change in the future when defaults are changed, we may want to autofill
> "version" even when none is specified. (We would of course be stuck with
> the unfortunate problem of what to do with existing configs)
I don't think we should worry too much about this: since we
lock on a versioned machine type on guest creation, and we can
assume the default virtio version will only change along with
a bump in machine type version[1], we'll always present the
same hardware to the guest.
Hmm, and anyway, lack of a version means "be compatible with *all* the
versions", so there isn't any single value of version that could be
filled in.
<EmilyLitella>nevermind</EmilyLitella>
It does somehow bother me that a single attribute is being used to
control two separate options in qemu. I suppose, though, that this is
okay, because those two options have a possibility of 4 different
combinations, with one of those combinations being nonsensical
(disable_modern and disable_legacy both set to yes), so the remaining
three combinations map to version = (nothing), "0.9", and "1.0".
[1] What would be the point in versioned machine types
otherwise? :)
Oh, there are plenty of other things aside from device default option
settings that are preserved by versioned machinetypes.