On Fri, Jul 26, 2013 at 02:31:24PM +0200, Andreas Färber wrote:
Am 25.07.2013 20:02, schrieb Eduardo Habkost:
On Thu, Jul 25, 2013 at 04:09:18PM +0200, Andreas Färber wrote:
Am 25.07.2013 16:00, schrieb Eduardo Habkost:
libvirt needs a way to find out how exactly "-machine foo-1.0 -cpu bar" looks different from "-machine foo-1.1 -cpu bar",
Why? (What's the actual use case?)
libvirt API allows individual CPU features to be configured, so libvirt needs to know what exactly will be the result of using a machine-type/CPU-model combination to make sure it will be exactly what was requested: http://libvirt.org/formatdomain.html#elementsCPU
That's exactly what you added properties for last minute in v1.5!
libvirt instantiates qemu-system-x86_64 -cpu foo,+x,+y and then checks that it got what it wanted - if not, die, otherwise continue with virtualization. One process.
I believe libvirt needs to know what are the results of the CPU model + machine-type combination at other moments, even before building the QEMU command-line. But I may be mistaken, so I hope the libvirt developers can clarify that.
Also, libvirt needs to be able to check if migration to a host is possible (i.e. if all features enabled by a machine-type/CPU-model combination are supported by the host) before actually starting the migration process.
That's one process on the destination with one -machine pc-i440-x.y. Is the problem possibly rather that -incoming and QMP exclude each other? Then we should fix that instead by starting incoming migration from QMP in the same process that we used to check that migration will be possible without guest-visible changes.
I don't know the answer for that, and I also don't know if it is acceptable for libvirt to be required to execute QEMU just to find out if migration to a host is possible. I am thinking of cases where there may be dozens or hundreds of hosts available, and some management system needs to find out quickly what are the best candidates to which a large set of VMs can be migrated. -- Eduardo