qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [qemu-devel][libvirt] Default machine type setting for


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [qemu-devel][libvirt] Default machine type setting for ppc64
Date: Tue, 21 May 2013 11:01:36 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, May 21, 2013 at 07:55:27PM +1000, Paul Mackerras wrote:
> On Tue, May 21, 2013 at 09:39:53AM +0100, Daniel P. Berrange wrote:
> > On Tue, May 21, 2013 at 09:31:26AM +0100, Peter Maydell wrote:
> > > On 21 May 2013 09:19, Li Zhang <address@hidden> wrote:
> > > > We encounter this problem in openstack which always use
> > > > default machine type. Currently, QEMU sets mac99 as default
> > > > setting for ppc64 but it doesn't work on our platform at all.
> > > >
> > > > I tried to fix this in libvirt which it is not acceptable because
> > > > libvirt only considers to get default setting from QEMU.
> > > 
> > > This will need to be fixed for ARM -- the whole idea of there
> > > being a sensible "default machine type" and it being the one
> > > QEMU starts by default is pretty x86-centric. libvirt needs
> > > to have support for specifying which machine to use.
> > 
> > Libvirt has always had support for specifying what machine type to use.
> > This discussion is simply about what machine type to default to, if the
> > user hasn't explicitly asked for one.
> 
> So, the situation is that the XML in question has <type>hvm</type>,
> in the <os> section.  Does that say anything about what type of
> machine is being requested?

Obviously not, since you've not specified any machine type and
thus you'll get the default. If you don't like that, change your
app to request a specific machine type.

>                              Why is the machine type in the <os>
> section rather than the <domain> section?

That's just the way it was chosen to be represented when first
implemented. In hindsight that may be sub-optimal, but libvirt
will not change existing XML schema design since that breaks
back compatibilty which is worse.

> > QEMU has the notion of a default machine for each target, and that is
> > what libvirt uses if the user hasn't specified a machine.  It is not
> > libvirt's job to override QEMU's notion of the default machine here,
> > so if the 'mac99' machine type isn't suitable as the default either
> > QEMU needs to change that for the ppc target, or the user needs to
> > explicitly specify their desired machine type.
> 
> We are getting the default changed to 'pseries', at least for cases
> where pseries support is compiled in, which isn't necessarily
> always.  That will of course not satisfy the Freescale guys.
> 
> I think libvirt needs some more sensible way to ask qemu what its
> capabilities are.  Currently it has no way to ask qemu "what machines
> can you emulate with kvm acceleration?"  If the user has asked for a
> KVM domain then the default machine should be one that can be provided
> by KVM.  At present it isn't, on PowerPC.

If QEMU can provide more intelligent info in this respect, then
libvirt can use it. We're doing the best we can with picking
defaults given the info QEMU currently provides us.


Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

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