On Fri, 23 May 2014, Fabio Fantoni wrote:
One issue is that -M pc didn't always work with Xen. Now it does and we
are already relying on it in libxl since
2bc047635b51abd41c917aa2b813211ee0de2c38. It is safe because all QEMU
releases from 1.6 onward work well with Xen and -M pc. Older QEMU
releases are considered ancient and unmaintained. This is what I was
referring to in my last reply. I really meant "we should move away from
xenfv and use a pc.* machine that does not create xen-platform by
default".
As you say the other issue is the version of the pc machine, especially
in relation to save/restore. However since:
commit 2bc047635b51abd41c917aa2b813211ee0de2c38
Author: Anthony PERARD <address@hidden>
Date: Wed Nov 27 18:21:34 2013 +0000
libxl: Handle xen_platform_pci=0 case with qemu-xen.
we are simply calling QEMU with -M pc if xen_platform_pci=0. I think we
should change that too and backport the patch to 4.4. pc-i440fx-1.6
seems like a good choice to me.
Use "-M pc" as default seems a good idea.
Use specific version maybe too.
This way the base hardware should stay the same even if updating qemu, is
right?
Yep
If yes, this should also solve possible problem like windows
reactivation request for different hardware, right?
Right
How about create also xl parameter to select the "pc" model?
Having a VM config parameter for it is OK. In the past I argued against
relying on such a parameter to solve all compatibility issues with QEMU
because I would like libxl to be able to select the right QEMU machine
automatically, without user intervention. But the option could still be
useful for debugging.
