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.

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

On 2013年05月21日 16:45, Peter Maydell wrote: > On 21 May 2013 09:39, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote: >> Libvirt has always had support for specifying what machine type to use.

> OK, that makes sense. So is the problem here just configuration > or is it the next layer above libvirt not being configurable? Currently, the next layer above libvirt is not configurable. It is dependent on this default setting. Users also expect to start one VM successfully by default.

On Tue, May 21, 2013 at 05:02:51PM +0800, Li Zhang wrote: > On 2013年05月21日 16:45, Peter Maydell wrote: >> On 21 May 2013 09:39, Daniel P. Berrange <berrange(a)redhat.com&gt; wrote: >>> 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. >>> >>> 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, >> Agreed; thanks for the clarification. >> >>> 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. >> OK, that makes sense. So is the problem here just configuration >> or is it the next layer above libvirt not being configurable? > Currently, the next layer above libvirt is not configurable. > It is dependent on this default setting. Users also expect > to start one VM successfully by default. What is the application above libvirt you are using ? It clearly needs to be fixed if it is to use non-x86 archs successfully.

Daniel

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 <zhlcindy(a)gmail.com&gt; 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?

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

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

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

"Daniel P. Berrange" <berrange(a)redhat.com&gt; writes: > 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: >>> 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. We've talked in the past about having an accelerator specific machine default. I think this is a perfectly reasonable thing to do and would solve the problem for ARM and for PPC.

Perhaps the right thing to do for OpenStack is to allow for a user specified configuration file to select things like the default hardware models/machine types? Then this could become node configuration instead of dynamic configuration. I think it could be useful for general users too. Every domain requires a lot of the same boiler plate bits. I think a lot of configurations would benefit from being able to set global domain options.

On Tue, May 21, 2013 at 11:12:26AM -0600, Eric Blake wrote: > I have also argued in the past that it would be useful for libvirt to > support the idea of a template, where you can specify a domain XML that > inherits defaults from the template. We've already done things like > this for networking, nwfilter, and even secret management (in domain > XML, you declare that you are using a named network object, and that > network object serves as the template instead of you having to hard-code > all the elements into your domain XML), so we have a design to base it > on. But until someone adds such a feature for libvirt, then OpenStack > should be passing explicit XML to libvirt, and tracking defaults at the > OpenStack layer. I don't think the idea of a template belongs in libvirt.

Creating basic XML structure with relevant defaults pre-filled for a particular usecase is something that the libvirt-designer library is aiming to take care of for applications. 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 :|

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 <zhlcindy(a)gmail.com&gt; 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? Why is the machine type in the <os> section rather than the <domain> section? > 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. Paul.