On 06/05/18 15:29, 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". 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.
How about: - "create new domain with empty disk" --> i440fx now, q35 later - "create new domain from domain XML and disk image" --> whatever the domain definition dictates - "create new domain from disk image and no domain XML" --> assume i440fx forever (with a detailed board / device config that's used for all legacy (definition-less) disk images) - convince disk image distributors to provide their domain definitions with their disks (need not be libvirt domain XML, other definitions might work) - write converters from those other definition formats to libvirt XML, or QEMU cfg file? (I'm with Markus: <http://mid.mail-archive.com/87o9h6hb59.fsf@dusky.pond.sub.org>. Not specifically about OVF, but disk image providers need to start exposing their QEMU configs. And I think they should do that in whatever format their management stack supports.) Just my two cents, feel free to ignore. Thanks Laszlo
