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
