On Wed, Sep 09, 2015 at 10:17:34AM +0200, Andrea Bolognani wrote:
> On Tue, 2015-09-08 at 16:47 +0100, Daniel P. Berrange wrote:
> > > Or we could just query everything that looks like a QEMU
> > > binary and then lookup the correct one for the guest based
> > > on the query results, couldn't we? A
On Tue, 2015-09-08 at 16:47 +0100, Daniel P. Berrange wrote:
> > Or we could just query everything that looks like a QEMU
> > binary and then lookup the correct one for the guest based
> > on the query results, couldn't we? Again, assuming such
> > interface even exists.
>
> I'd prefer libvirt to
On Tue, 2015-09-08 at 15:37 +0100, Daniel P. Berrange wrote:
> > at the moment, libvirt is using some ad-hoc logic to allow
> > i686 guests to run on qemu-system-x86_64 (by using the CPU
> > model qemu32); in all other cases, it's assumed that a $arch
> > guest needs qemu-system-$arch to run.
> >
On Tue, Sep 08, 2015 at 03:27:38PM +0200, Andrea Bolognani wrote:
> Hi,
>
> at the moment, libvirt is using some ad-hoc logic to allow
> i686 guests to run on qemu-system-x86_64 (by using the CPU
> model qemu32); in all other cases, it's assumed that a $arch
> guest needs qemu-system-$arch to run.
On Tue, Sep 08, 2015 at 05:34:42PM +0200, Andrea Bolognani wrote:
> On Tue, 2015-09-08 at 15:37 +0100, Daniel P. Berrange wrote:
> > > at the moment, libvirt is using some ad-hoc logic to allow
> > > i686 guests to run on qemu-system-x86_64 (by using the CPU
> > > model qemu32); in all other cases,
Hi,
at the moment, libvirt is using some ad-hoc logic to allow
i686 guests to run on qemu-system-x86_64 (by using the CPU
model qemu32); in all other cases, it's assumed that a $arch
guest needs qemu-system-$arch to run.
This is causing a problem right now with ppc64le guests
because, even though
