[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: Eduardo Habkost
Subject: Re: [Qemu-devel] [libvirt] [PATCH 4/7] qemu: Add monitor APIs to fetch CPUID data from QEMU
Date: Fri, 26 Jul 2013 10:51:05 -0300
User-agent: Mutt/1.5.21 (2010-09-15)

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.


reply via email to

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