qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine


From: Marcel Apfelbaum
Subject: Re: [Qemu-devel] [PATCH RFC] hw/pc: set q35 as the default x86 machine
Date: Tue, 5 Jun 2018 18:56:09 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0



On 06/05/2018 04:29 PM, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 04:20:46PM +0300, Marcel Apfelbaum wrote:

On 06/05/2018 11:43 AM, Daniel P. Berrangé wrote:
On Tue, Jun 05, 2018 at 09:27:46AM +0200, Gerd Hoffmann wrote:
    Hi,

    Add to that shortcuts like -cdrom
stop working,
Maybe is fixable.
Already fixed for ages.

I see marking Q35 as the default machine a first step.
Maybe the better option is to go the arm route:  Just don't define a
default, so users have to specify pc or q35.  That will make them notice
there is a world beside 'pc', and we also avoid breaking things
silently.
It can work, sure. And we can add user hints: "Use q35 for ...., select pc
if..."

If QEMU removes the default, then libvirt will have to hardcode
'pc' as the default to maintain back compatibility, so I don't
think that ends up as a net win
Can't libvirt preserve 'pc' for existing domains, while defaulting to q35
the creation of new domains ? This way it aligns with Gerd's proposal of no
default x86 machine.
Existing domains wasn't the case I was concerned about. Consider you have
libvirt 4.4.0 intsalled and you deploy a *new* domain from a prebuilt
disk image "foo".

Using Laszlo idea (I think):
 1) disk image "foo"/no info -> use 'pc' machine.
 2) no prebuild image (clean install?) ->  use q35 and add this info to xml In the meantime find a way to embed the supported machine type(s) in the image. (I think the above idea was already discussed, not sure what was the conclusion )


Thanks,
Marcel

  Now update to a libvirt or QEMU which changes to q35
and try to deploy another new domain from the same prebuilt disk
image "foo". It may not work now if that disk image doesn't support
q35. That would be a regression from the user's POV, whether libvirt or
qemu has changed the default.

Regards,
Daniel




reply via email to

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