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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list