Xen devel - Jun 2013 - Re: [Qemu-devel] [PATCH] Remove hardcoded xen-platform device initialization

Il 19/06/2013 10:29, Ian Campbell ha scritto:
>> > You could check for existence of the pc-i440fx-1.6 machine and
infer
>> > that it is at least v1.6 (might break in some distant future of
course
>> > and for current git commits until your changes get merged).
> Actually, this raises an interesting point. AIUI "pc" is simply
and
> alias for the most recent "pc-X.Y" and "pc-X.Y" is
present to allow for
> qemu "upgrading" the set of emulated hardware, as in it
represents
> changing the set of emulated peripherals, not just fixing bugs in the
> emulation etc, is that right?
Usually it represents adding _features_ to the emulation.  There are
some cases where the set of emulated peripherals change (e.g. pvpanic
added in 1.5), but it''s the exception rather than the rule.  There are
also some cases of bug-compatibility, but again they''re not the most
common use of versioned machine types.

You do not know how older guests react to those new features, and you
want to prevent moving guests to older versions that lack some features.
 For these reasons, libvirt always sticks to the alias target that was
found at creation time.

Example 1: you defined a machine last year with machine type "pc".
libvirt actually stored it with machine type "pc-1.2".  Today you run
it
and hardware/features do not change.

Example 2: you defined a machine today with machine type "pc". 
libvirt
actually stored it with machine type "pc-1.6".  You run it on a
machine
with an old QEMU, the machine doesn''t start.

Example 3: you ask libvirt to edit the definition of the machine of
example 1.  You change the machine type back to "pc".  libvirt stores
it
with machine type "pc-1.6".  Hardware may change compared to the
previous runs of the VM, but it will otherwise remain stable.

Example 4: you use vi to edit the definition of the machine of example
1/3.  You change the machine type to "pc".  You lose any guarantee
that
hardware does not change.  You should not do this.

Example 5: you use "virsh create" to start a VM based on an XML file,
rather than "virsh define"+"virsh start" as in examples 1-2.
You lose
any guarantee that hardware does not change.  Not frowned upon as much
as example 4, since the VM is supposed to be transient.
> I think it would be preferable for us to request a specific platform
> (pc-i440fx-1.6 if that''s the one) and a conscious decision to
support
> newer platforms (and can test it etc).
That can be a good idea, since Xen support is a bit less tested than KVM
with bleeding-edge QEMU.  You can query the machine types from the Xen
toolchain, and auto-remap "pc" to a machine type that is never newer
than what you consider to be well-tested.

It would require two QEMU invocations per "xl create".  However, most
of
the startup time of QEMU is loading dynamic libraries.  A good deal of
that time amortizes well over two invocations of QEMU.  Hence, you can
use the first invocation to query the machine type (using "-nodefaults
-nographic" etc. and a QMP connection), and the second to actually start
the VM.

Paolo