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

[Ian Campbell]

On Wed, 2013-06-19 at 10:41 +0200, Paolo Bonzini wrote:
> 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.

I had a grep around libvirt wondering how it handled this and didn't
find it. The approach you describe makes perfect sense when you have a
persistent config. The case with xl is more like your example 5:

> 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.

For something like xapi we'd likely want to support some sort of model
similar to libvirt, so whatever we do at the libxl layer needs to
consider both approaches.

> 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.

Not to mention that on a system already running a domain or two there is
a good chance that at least the relevant bits of QEMU are already in
RAM.

In fact, I wonder if we could just query the qemu which is running to
provide dom0 itself with qdisk services, at least in the case where the
guest is configured to use the same version of qemu.

Ian.