Re: [libvirt] [Qemu-devel] change x86 default machine type to Q35?
(CCing libvir-list) On Mon, Jul 10, 2017 at 07:45:54PM +0300, Michael S. Tsirkin wrote:
On Mon, Jul 10, 2017 at 10:59:43AM -0300, Eduardo Habkost wrote:
On Mon, Jul 10, 2017 at 10:42:26AM +0300, Marcel Apfelbaum wrote:
On 07/07/2017 21:03, Eduardo Habkost wrote:
On Fri, Jul 07, 2017 at 06:17:57PM +0300, Michael S. Tsirkin wrote:
On Fri, Jul 07, 2017 at 10:39:49AM -0300, Eduardo Habkost wrote:
On Wed, Jul 05, 2017 at 12:32:10PM +0300, Marcel Apfelbaum wrote: [...] > > The upper layers should manage the defaults by themselves so > are not supposed to be affected.
But they would be. libvirt uses the default machine-type from QEMU.
How about extending the command for supported machines with a recommended machine type, and teaching libvirt to use that?
I don't think QEMU has enough information to decide if it should recommend "q35" or "pc".
We don't really need a complicated rule set, we would just recommend q35 by default. Libvirt will try to create the default machine and if fails for some reason (what would it be?) it can switch to PC.
The advanced logic would be "old systems should use PC", where old means Windows XP and before and so on. But this logic should appear in management layers above.
In this case, is there any difference between "changing the default to q35" and "recommending q35", for libvirt users?
-- Eduardo
No but libvirt users do not manage e.g. pci slots manually. They do not use the -cdrom flag. Etc. So changing the default is unlikely to break things for them.
I see. If this part is really true (can libvirt developers confirm that?), then the proposed end result makes sense (not having a default for running QEMU directly, but changing default to "q35" for people using libvirt). But I don't see why we would need a new mechanism to make QEMU recommend a machine-type for libvirt, if libvirt could simply choose its own default (or maybe also refuse to pick a default, if libvirt developers decide that's the best solution).
People not using libvirt use some or all of this and other such functionality, and changing the default might break things for them.
-- Eduardo
On 10.07.2017 19:47, Eduardo Habkost wrote:
(CCing libvir-list)
On Mon, Jul 10, 2017 at 07:45:54PM +0300, Michael S. Tsirkin wrote:
On Mon, Jul 10, 2017 at 10:59:43AM -0300, Eduardo Habkost wrote:
On Mon, Jul 10, 2017 at 10:42:26AM +0300, Marcel Apfelbaum wrote:
On 07/07/2017 21:03, Eduardo Habkost wrote:
On Fri, Jul 07, 2017 at 06:17:57PM +0300, Michael S. Tsirkin wrote:
On Fri, Jul 07, 2017 at 10:39:49AM -0300, Eduardo Habkost wrote: > On Wed, Jul 05, 2017 at 12:32:10PM +0300, Marcel Apfelbaum wrote: [...] >> >> The upper layers should manage the defaults by themselves so >> are not supposed to be affected. > > But they would be. libvirt uses the default machine-type from > QEMU.
How about extending the command for supported machines with a recommended machine type, and teaching libvirt to use that?
I don't think QEMU has enough information to decide if it should recommend "q35" or "pc".
We don't really need a complicated rule set, we would just recommend q35 by default. Libvirt will try to create the default machine and if fails for some reason (what would it be?) it can switch to PC.
The advanced logic would be "old systems should use PC", where old means Windows XP and before and so on. But this logic should appear in management layers above.
In this case, is there any difference between "changing the default to q35" and "recommending q35", for libvirt users?
-- Eduardo
No but libvirt users do not manage e.g. pci slots manually. They do not use the -cdrom flag. Etc. So changing the default is unlikely to break things for them.
I see. If this part is really true (can libvirt developers confirm that?), then the proposed end result makes sense (not having a default for running QEMU directly, but changing default to "q35" for people using libvirt).
But I don't see why we would need a new mechanism to make QEMU recommend a machine-type for libvirt, if libvirt could simply choose its own default (or maybe also refuse to pick a default, if libvirt developers decide that's the best solution).
Agreed, it does not make much sense to invent a new mechanism here. I guess the default should rather be switched in the the tools that create the XML for libvirt, i.e. virt-install and friends? Concerning QEMU, could we maybe simply emit a warning a la "you did not specify a machine type with the -M option, so you are currently running the the 'pc' machine type. Please note that future versions of QEMU might use the 'q35' machine type instead. If you require the 'pc' machine type for your setting, then please specify it with the -M option." for a couple of releases, so that other people have a chance to update their scripts, and then finally switch to q35 ? Thomas
On 11/07/2017 10:48, Thomas Huth wrote:
On 10.07.2017 19:47, Eduardo Habkost wrote:
(CCing libvir-list)
On Mon, Jul 10, 2017 at 07:45:54PM +0300, Michael S. Tsirkin wrote:
On Mon, Jul 10, 2017 at 10:59:43AM -0300, Eduardo Habkost wrote:
On Mon, Jul 10, 2017 at 10:42:26AM +0300, Marcel Apfelbaum wrote:
On 07/07/2017 21:03, Eduardo Habkost wrote:
On Fri, Jul 07, 2017 at 06:17:57PM +0300, Michael S. Tsirkin wrote: > On Fri, Jul 07, 2017 at 10:39:49AM -0300, Eduardo Habkost wrote: >> On Wed, Jul 05, 2017 at 12:32:10PM +0300, Marcel Apfelbaum wrote: [...] >>> >>> The upper layers should manage the defaults by themselves so >>> are not supposed to be affected. >> >> But they would be. libvirt uses the default machine-type from >> QEMU. > > How about extending the command for supported machines with a > recommended machine type, and teaching libvirt to use that?
I don't think QEMU has enough information to decide if it should recommend "q35" or "pc".
We don't really need a complicated rule set, we would just recommend q35 by default. Libvirt will try to create the default machine and if fails for some reason (what would it be?) it can switch to PC.
The advanced logic would be "old systems should use PC", where old means Windows XP and before and so on. But this logic should appear in management layers above.
In this case, is there any difference between "changing the default to q35" and "recommending q35", for libvirt users?
-- Eduardo
No but libvirt users do not manage e.g. pci slots manually. They do not use the -cdrom flag. Etc. So changing the default is unlikely to break things for them.
I see. If this part is really true (can libvirt developers confirm that?), then the proposed end result makes sense (not having a default for running QEMU directly, but changing default to "q35" for people using libvirt).
But I don't see why we would need a new mechanism to make QEMU recommend a machine-type for libvirt, if libvirt could simply choose its own default (or maybe also refuse to pick a default, if libvirt developers decide that's the best solution).
Hi Thomas,
Agreed, it does not make much sense to invent a new mechanism here. I guess the default should rather be switched in the the tools that create the XML for libvirt, i.e. virt-install and friends?
Concerning QEMU, could we maybe simply emit a warning a la
"you did not specify a machine type with the -M option, so you are currently running the the 'pc' machine type. Please note that future versions of QEMU might use the 'q35' machine type instead. If you require the 'pc' machine type for your setting, then please specify it with the -M option."
for a couple of releases, so that other people have a chance to update their scripts, and then finally switch to q35 ?
Sounds like a plan, adding Laine (libvirt) to confirm (or not) if makes sense. Is a pity to loose the "QEMU 3.0" release, but is nicer indeed to let people know in advance. Thanks, Marcel
Thomas
Hi,
Concerning QEMU, could we maybe simply emit a warning a la
"you did not specify a machine type with the -M option, so you are currently running the the 'pc' machine type. Please note that future versions of QEMU might use the 'q35' machine type instead. If you require the 'pc' machine type for your setting, then please specify it with the -M option."
Warnings tend to get ignored until things are actually break, so I don't think this helps much. I think simply not having a default machine type (as already suggested elsewhere in this thread) is the best way to deal with this. That way we don't silently change behavior. It also is in line with what we have on arm where we already require the user to explicitly pick a machine type. We probably want a more verbose error message on x86 though, suggesting to pick 'pc' for compatibility with old qemu versions and for old guests, and q35 otherwise. cheers, Gerd
Am 11.07.2017 um 10:13 hat Gerd Hoffmann geschrieben:
Hi,
Concerning QEMU, could we maybe simply emit a warning a la
"you did not specify a machine type with the -M option, so you are currently running the the 'pc' machine type. Please note that future versions of QEMU might use the 'q35' machine type instead. If you require the 'pc' machine type for your setting, then please specify it with the -M option."
Warnings tend to get ignored until things are actually break, so I don't think this helps much. I think simply not having a default machine type (as already suggested elsewhere in this thread) is the best way to deal with this.
I would absolutely hate this. One of the nice things about qemu has always been that 'qemu disk.img' is enough to start a simple VM. You only need to touch any other options for things you care about. I wouldn't want to give this up. Kevin
On 11/07/2017 16:42, Kevin Wolf wrote:
Concerning QEMU, could we maybe simply emit a warning a la
"you did not specify a machine type with the -M option, so you are currently running the the 'pc' machine type. Please note that future versions of QEMU might use the 'q35' machine type instead. If you require the 'pc' machine type for your setting, then please specify it with the -M option." Warnings tend to get ignored until things are actually break, so I don't think this helps much. I think simply not having a default machine type (as already suggested elsewhere in this thread) is the best way to deal with this. I would absolutely hate this. One of the nice things about qemu has always been that 'qemu disk.img' is enough to start a simple VM. You only need to touch any other options for things you care about. I wouldn't want to give this up.
I agree. Don't change anything, leave "-M pc" aside, and let libosinfo pick q35 for newer guests. Paolo
On 11/07/2017 17:47, Paolo Bonzini wrote:
On 11/07/2017 16:42, Kevin Wolf wrote:
Concerning QEMU, could we maybe simply emit a warning a la
"you did not specify a machine type with the -M option, so you are currently running the the 'pc' machine type. Please note that future versions of QEMU might use the 'q35' machine type instead. If you require the 'pc' machine type for your setting, then please specify it with the -M option." Warnings tend to get ignored until things are actually break, so I don't think this helps much. I think simply not having a default machine type (as already suggested elsewhere in this thread) is the best way to deal with this. I would absolutely hate this. One of the nice things about qemu has always been that 'qemu disk.img' is enough to start a simple VM. You only need to touch any other options for things you care about. I wouldn't want to give this up.
I agree. Don't change anything, leave "-M pc" aside, and let libosinfo pick q35 for newer guests.
Hi Paolo, While I do think it would be a good step moving forward, I am not convinced is "enough" to get more users using it. More so, a low level bug in upper layers (e.g. Open stack) will lead to difficulty to debug and result in the same "The machine is not steady enough, it doesn't worth the effort, let's move back to pc", or even frustration of the people that really need Q35. IMHO we need to find a way to let more users use Q35 by default and make an effort to fix the possible issues before. Thanks, Marcel
Paolo
On Wed, Jul 12, 2017 at 09:39:39AM +0300, Marcel Apfelbaum wrote:
On 11/07/2017 17:47, Paolo Bonzini wrote:
On 11/07/2017 16:42, Kevin Wolf wrote:
Concerning QEMU, could we maybe simply emit a warning a la
"you did not specify a machine type with the -M option, so you are currently running the the 'pc' machine type. Please note that future versions of QEMU might use the 'q35' machine type instead. If you require the 'pc' machine type for your setting, then please specify it with the -M option." Warnings tend to get ignored until things are actually break, so I don't think this helps much. I think simply not having a default machine type (as already suggested elsewhere in this thread) is the best way to deal with this. I would absolutely hate this. One of the nice things about qemu has always been that 'qemu disk.img' is enough to start a simple VM. You only need to touch any other options for things you care about. I wouldn't want to give this up.
I agree. Don't change anything, leave "-M pc" aside, and let libosinfo pick q35 for newer guests.
Hi Paolo,
While I do think it would be a good step moving forward, I am not convinced is "enough" to get more users using it. More so, a low level bug in upper layers (e.g. Open stack) will lead to difficulty to debug and result in the same "The machine is not steady enough, it doesn't worth the effort, let's move back to pc", or even frustration of the people that really need Q35.
I guess not being enough depends on which users we want to affect. People who run QEMU from the command-line don't get a virtio drive or a modern CPU model chosen by default, either. Is the choice of machine-type different? Why?
[...]
-- Eduardo
Hi,
I think simply not having a default machine type (as already suggested elsewhere in this thread) is the best way to deal with this.
I would absolutely hate this. One of the nice things about qemu has always been that 'qemu disk.img' is enough to start a simple VM.
Well, not really. There is no "qemu" any more, and there are other defaults like default memory size which need tweaks, so the minimum command line isn't that short any more and looks more like this: qemu-system-x86_64 -enable-kvm -m 1G disk.img cheers, Gerd
On 12/07/2017 8:51, Gerd Hoffmann wrote:
Hi,
Hi,
I think simply not having a default machine type (as already suggested elsewhere in this thread) is the best way to deal with this.
I would absolutely hate this. One of the nice things about qemu has always been that 'qemu disk.img' is enough to start a simple VM.
Well, not really. There is no "qemu" any more, and there are other defaults like default memory size which need tweaks, so the minimum command line isn't that short any more and looks more like this:
qemu-system-x86_64 -enable-kvm -m 1G disk.img
If the command line is the main concern, I don't think is enough to be the reason not to switch the default. We can work on achieving the same/close with Q35. Thanks, Marcel
cheers, Gerd
Am 12.07.2017 um 07:51 hat Gerd Hoffmann geschrieben:
I think simply not having a default machine type (as already suggested elsewhere in this thread) is the best way to deal with this.
I would absolutely hate this. One of the nice things about qemu has always been that 'qemu disk.img' is enough to start a simple VM.
Well, not really. There is no "qemu" any more, and there are other defaults like default memory size which need tweaks, so the minimum command line isn't that short any more and looks more like this:
qemu-system-x86_64 -enable-kvm -m 1G disk.img
Depends on what you want to do, but in the common case yes. So we have already moved in the wrong direction. Not a good reason to do more of it. Actually, I think changing the defaults to -m 1G and -machine accel=kvm:tcg would be much less problematic than -M q35, so maybe that should be our first step towards better defaults. (Or at least something to schedule for 3.0.) And even changing the default to -M q35, however problematic, would still be nicer than making -M non-optional. Kevin
On Tue, Jul 11, 2017 at 10:13:05AM +0200, Gerd Hoffmann wrote:
Hi,
Concerning QEMU, could we maybe simply emit a warning a la
"you did not specify a machine type with the -M option, so you are currently running the the 'pc' machine type. Please note that future versions of QEMU might use the 'q35' machine type instead. If you require the 'pc' machine type for your setting, then please specify it with the -M option."
Warnings tend to get ignored until things are actually break, so I don't think this helps much. I think simply not having a default machine type (as already suggested elsewhere in this thread) is the best way to deal with this. That way we don't silently change behavior. It also is in line with what we have on arm where we already require the user to explicitly pick a machine type.
If we do that, we probably should wait for libvirt to adapt and choose its own default. Current libvirt would pick an arbitrary machine-type (the first one in the query-machines list) as the default. -- Eduardo
participants (6)
-
Eduardo Habkost -
Gerd Hoffmann -
Kevin Wolf -
Marcel Apfelbaum -
Paolo Bonzini -
Thomas Huth