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.
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list