[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [libvirt] [PATCH 4/7] qemu: Add monitor APIs to fetch C

From: Andreas Färber
Subject: Re: [Qemu-devel] [libvirt] [PATCH 4/7] qemu: Add monitor APIs to fetch CPUID data from QEMU
Date: Fri, 26 Jul 2013 14:31:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7

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.

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


SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

reply via email to

[Prev in Thread] Current Thread [Next in Thread]