[libvirt] [qemu-devel] Default machine type setting for ppc64
Hi all, Sorry to bring this problem up again. 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. Maybe I need to cc openstack mailing list, if it is one solution to add one option for machine types it supports. Any suggestion is appreciated. Thanks. :) --Li
Oops, correct libvirt mailing list address. :) Thanks. On 2013年05月21日 16:19, Li Zhang wrote:
Hi all,
Sorry to bring this problem up again.
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.
Maybe I need to cc openstack mailing list, if it is one solution to add one option for machine types it supports.
Any suggestion is appreciated.
Thanks. :) --Li
On 21 May 2013 09:19, Li Zhang <zhlcindy@gmail.com> 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. (There is consideration of changing the default ppc64 machine, as it happens; but in general you can't rely on QEMU doing what you want if you don't tell it specifically which board you wanted.) thanks -- PMM
On Tue, May 21, 2013 at 09:31:26AM +0100, Peter Maydell wrote:
On 21 May 2013 09:19, Li Zhang <zhlcindy@gmail.com> 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. 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. Regards, 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 21 May 2013 09:39, Daniel P. Berrange <berrange@redhat.com> 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? (the thing about changing the default is that it obviously breaks command line compatibility for anybody who was relying on the old default. So for ARM we're a bit locked in to a default which is pretty useless for most people.) thanks -- PMM
On 2013年05月21日 16:45, Peter Maydell wrote:
On 21 May 2013 09:39, Daniel P. Berrange <berrange@redhat.com> 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. Thanks. -- Li
(the thing about changing the default is that it obviously breaks command line compatibility for anybody who was relying on the old default. So for ARM we're a bit locked in to a default which is pretty useless for most people.)
thanks -- PMM
On 21 May 2013 10:02, Li Zhang <zhlcindy@gmail.com> wrote:
On 2013年05月21日 16:45, Peter Maydell wrote:
On 21 May 2013 09:39, Daniel P. Berrange <berrange@redhat.com> 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.
Right. I think we've now identified the bit of software whose x86-centric assumptions need fixing :-) thanks -- PMM
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@redhat.com> 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 -- |: 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 2013年05月21日 17:25, Daniel P. Berrange wrote:
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@redhat.com> 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.
Sorry for replying late. The applications are openstack and ovirt. Thanks. -- Li
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@gmail.com> 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.
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 <zhlcindy@gmail.com> 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 :|
On 21 May 2013 11:01, Daniel P. Berrange <berrange@redhat.com> wrote:
On Tue, May 21, 2013 at 07:55:27PM +1000, Paul Mackerras wrote:
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.
I think this would make sense. Currently for ARM to get KVM acceleration you have to use a specific guest CPU (A15), and so you have to use a machine which supports that CPU (currently just vexpress-a15). But we don't expose any way for libvirt to tell that it needs an A15 or which machine models support which CPUs. In fact we don't even give a sensible error message if you try to use a wrong CPU, we'll just blithely push ahead and behave very weirdly. thanks -- PMM
"Daniel P. Berrange" <berrange@redhat.com> 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. That said, why is mac99 the default? It doesn't seem to work at all for me. Even with TCG, I've had more luck with -M pseries. While adding an accelerator specific default, if mac99 is the wrong default for TCG, then we should change it. Regards, Anthony Liguori
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 21 May 2013 13:04, Anthony Liguori <anthony@codemonkey.ws> wrote:
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.
For ARM I would prefer not to have a default at all, and make the next level up specify it. It's reasonable to have a default machine choice for when you create a VM configuration; it's not so sensible to have a default that's picked every time you run the VM. The thing I think is most likely to be the useful choice for KVM/ARM isn't even in the tree yet... There's no user level difference between "pick whether you wanted a model of a versatile-PB or a zaurus" and "pick whether you wanted a model of an x86-PC or an ARM zaurus". At the moment we require the user to specify the latter choice (by having them in separate executables) but try to guess the former.
That said, why is mac99 the default?
Presumably because it was a sensible choice when it was originally put in, and once you have a default you can't change it without breaking peoples' command lines. thanks -- PMM
On 21/05/13 14:04, Anthony Liguori wrote:
"Daniel P. Berrange" <berrange@redhat.com> 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.
If we get such thing, then virtio-ccw might also be the right default for kvm on s390. Christian
"Daniel P. Berrange" <berrange@redhat.com> 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: 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.
Thinking about this a little more. OpenStack pushes a lot of configuration to the nodes themselves instead of making things dynamic and exposing APIs (think host network configuration). QEMU actually does allow a user to change the default machine type via the global config file so in theory you could do this with OpenStack. However, since libvirt uses -nouserconfig, this doesn't work in practice. 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. Regards, Anthony Liguori
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 05/21/2013 10:42 AM, Anthony Liguori wrote:
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.
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. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On Tue, May 21, 2013 at 11:12:26AM -0600, Eric Blake wrote:
On 05/21/2013 10:42 AM, Anthony Liguori wrote:
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.
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 :|
"Daniel P. Berrange" <berrange@redhat.com> writes:
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.
This is fine. But the conversation started with a statement that it's QEMU's job to define reasonable defaults and libvirt just exposes those. But in QEMU, we punt this problem by letting a user globally override this default. libvirt hides this ability from the end user. So either it's libvirt's problem to solve, or you should expose the ability to set the global setting within QEMU. We can't just point our fingers at each other and hope the problem goes away :-) Regards, Anthony Liguori
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 2013年05月22日 04:01, Anthony Liguori wrote:
"Daniel P. Berrange" <berrange@redhat.com> writes:
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. This is fine. But the conversation started with a statement that it's QEMU's job to define reasonable defaults and libvirt just exposes
On Tue, May 21, 2013 at 11:12:26AM -0600, Eric Blake wrote: those.
But in QEMU, we punt this problem by letting a user globally override this default. libvirt hides this ability from the end user.
So either it's libvirt's problem to solve, or you should expose the ability to set the global setting within QEMU. We can't just point our fingers at each other and hope the problem goes away :-)
Hi Anthony, Currently, to resolve this problem, can we set 'pseries' as default? Because mac99 doesn't work at all on our platform. Thanks. :) -- Li
Regards,
Anthony Liguori
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 2013年05月21日 17:55, Paul Mackerras wrote:
On Tue, May 21, 2013 at 09:31:26AM +0100, Peter Maydell wrote:
On 21 May 2013 09:19, Li Zhang <zhlcindy@gmail.com> 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>
On Tue, May 21, 2013 at 09:39:53AM +0100, Daniel P. Berrange wrote: 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.
You are right. This default setting can't satisfy every platform. So it will needs management tool to add one machine type option, if it wants to support different machine types for ppc64. Thanks. :)
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.
On 2013年05月21日 16:31, Peter Maydell wrote:
On 21 May 2013 09:19, Li Zhang <zhlcindy@gmail.com> 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. Ah, libvirt does have support for specifying one machine type.
I mean that libvirt set default according to QEMU's default setting, and management tools are dependent on this default setting without users' specified setting. I tried to change the default setting according to ppc64 platform in libvirt, but it is not accepted.
(There is consideration of changing the default ppc64 machine, as it happens; but in general you can't rely on QEMU doing what you want if you don't tell it specifically which board you wanted.) I see. Thanks for your suggestion. :)
thanks -- PMM
participants (7)
-
Anthony Liguori -
Christian Borntraeger -
Daniel P. Berrange -
Eric Blake -
Li Zhang -
Paul Mackerras -
Peter Maydell