Re: qemu-kvm: remove "boot=on|off" drive parameter compatibility (fwd)

Re: qemu-kvm: remove "boot=on|off" drive parameter compatibility (fwd)

[Serge Hallyn]

We (Ubuntu) plan to switch to qemu in the next release which opens in
November.  I suppose there's likely to be a hiccough or two, but I can't
think of any offhand.

-serge

Quoting Scott Moser (smoser@ubuntu.com):
> you should have been added here.
> 
> 
> ---------- Forwarded message ----------
> Date: Mon, 1 Oct 2012 09:19:29
> From: Anthony Liguori <anthony@codemonkey.ws>
> To: Jan Kiszka <jan.kiszka@siemens.com>, Marcelo Tosatti <mtosatti@redhat.com>
> Cc: kvm <kvm@vger.kernel.org>, qemu-devel <qemu-devel@nongnu.org>,
>     Cole Robinson <crobinso@redhat.com>, Scott Moser <smoser@ubuntu.com>,
>     Andreas Färber <afaerber@suse.de>, Michael Tokarev <mjt@tls.msk.ru>
> Subject: Re: qemu-kvm: remove "boot=on|off" drive parameter compatibility
> 
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
> > On 2012-10-01 11:31, Marcelo Tosatti wrote:
> >
> > It's not just about default configs. We need to validate if the
> > migration formats are truly compatible (qemu-kvm -> QEMU, the other way
> > around definitely not). For the command line switches, we could provide
> > a wrapper script that translates them into upstream format or simply
> > ignores them. That should be harmless to carry upstream.
> 
> qemu-kvm has:
> 
>  -no-kvm
>  -no-kvm-irqchip
>  -no-kvm-pit
>  -no-kvm-pit-reinjection
>  -tdf <- does nothing
> 
> There are replacements for all of the above.  If we need to add them to
> qemu.git, it's not big deal to add them.
> 
>  -drive ...,boot= <- this is ignored
> 
> cpu_set command for CPU hotplug which is known broken in qemu-kvm.
> 
> testdev which is nice but only used for development
> 
> Default nic is rtl8139 vs. e1000.
> 
> Some logic to move change the default VGA ram size to 16mb for pc-1.2
> (QEMU uses 16mb by default now too).
> 
> I think at this point, none of this matters but I added the various
> distro maintainers to the thread.
> 
> I think it's time for the distros to drop qemu-kvm and just ship
> qemu.git.  Is there anything else that needs to happen to make that
> switch?
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> > But I would really stop worrying about the qemu-kvm code base.
> >
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> > Corporate Competence Center Embedded Linux
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] qemu-kvm: remove "boot=on|off" drive parameter compatibility (fwd)

[Serge Hallyn]

We (Ubuntu) plan to switch to qemu in the next release which opens in
November.  I suppose there's likely to be a hiccough or two, but I can't
think of any offhand.

-serge

Quoting Scott Moser (smoser@ubuntu.com):
> you should have been added here.
> 
> 
> ---------- Forwarded message ----------
> Date: Mon, 1 Oct 2012 09:19:29
> From: Anthony Liguori <anthony@codemonkey.ws>
> To: Jan Kiszka <jan.kiszka@siemens.com>, Marcelo Tosatti <mtosatti@redhat.com>
> Cc: kvm <kvm@vger.kernel.org>, qemu-devel <qemu-devel@nongnu.org>,
>     Cole Robinson <crobinso@redhat.com>, Scott Moser <smoser@ubuntu.com>,
>     Andreas Färber <afaerber@suse.de>, Michael Tokarev <mjt@tls.msk.ru>
> Subject: Re: qemu-kvm: remove "boot=on|off" drive parameter compatibility
> 
> Jan Kiszka <jan.kiszka@siemens.com> writes:
> 
> > On 2012-10-01 11:31, Marcelo Tosatti wrote:
> >
> > It's not just about default configs. We need to validate if the
> > migration formats are truly compatible (qemu-kvm -> QEMU, the other way
> > around definitely not). For the command line switches, we could provide
> > a wrapper script that translates them into upstream format or simply
> > ignores them. That should be harmless to carry upstream.
> 
> qemu-kvm has:
> 
>  -no-kvm
>  -no-kvm-irqchip
>  -no-kvm-pit
>  -no-kvm-pit-reinjection
>  -tdf <- does nothing
> 
> There are replacements for all of the above.  If we need to add them to
> qemu.git, it's not big deal to add them.
> 
>  -drive ...,boot= <- this is ignored
> 
> cpu_set command for CPU hotplug which is known broken in qemu-kvm.
> 
> testdev which is nice but only used for development
> 
> Default nic is rtl8139 vs. e1000.
> 
> Some logic to move change the default VGA ram size to 16mb for pc-1.2
> (QEMU uses 16mb by default now too).
> 
> I think at this point, none of this matters but I added the various
> distro maintainers to the thread.
> 
> I think it's time for the distros to drop qemu-kvm and just ship
> qemu.git.  Is there anything else that needs to happen to make that
> switch?
> 
> Regards,
> 
> Anthony Liguori
> 
> >
> > But I would really stop worrying about the qemu-kvm code base.
> >
> > Jan
> >
> > --
> > Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
> > Corporate Competence Center Embedded Linux
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Qemu-devel] qemu-kvm: remove "boot=on|off" drive parameter compatibility (fwd)

[Peter Maydell]

On 1 October 2012 15:15, Serge Hallyn <serge.hallyn@canonical.com> wrote:
> We (Ubuntu) plan to switch to qemu in the next release which opens in
> November.  I suppose there's likely to be a hiccough or two, but I can't
> think of any offhand.

Are you planning to do that for all CPU target architectures, or
to maintain the current split between x86 and everything-else ?

-- PMM

Re: [Qemu-devel] qemu-kvm: remove "boot=on|off" drive parameter compatibility (fwd)

[Peter Maydell]

On 1 October 2012 15:15, Serge Hallyn <serge.hallyn@canonical.com> wrote:
> We (Ubuntu) plan to switch to qemu in the next release which opens in
> November.  I suppose there's likely to be a hiccough or two, but I can't
> think of any offhand.

Are you planning to do that for all CPU target architectures, or
to maintain the current split between x86 and everything-else ?

-- PMM

Re: [Qemu-devel] qemu-kvm: remove "boot=on|off" drive parameter compatibility (fwd)

[Serge Hallyn]

Quoting Peter Maydell (peter.maydell@linaro.org):
> On 1 October 2012 15:15, Serge Hallyn <serge.hallyn@canonical.com> wrote:
> > We (Ubuntu) plan to switch to qemu in the next release which opens in
> > November.  I suppose there's likely to be a hiccough or two, but I can't
> > think of any offhand.
> 
> Are you planning to do that for all CPU target architectures, or
> to maintain the current split between x86 and everything-else ?
> 
> -- PMM

I'll have to talk to qemu-linaro folks about that.  I don't mind carrying
patchsets (that are headed upstream) to enable some chipsets if that's
what's needed to consolidate the source trees.  The bigger question
relates to main vs universe.  For instance qemu-system is built against
vde2, and qemu-kvm-spice against spice, both of which are in universe.
I understand the distinction may change or disappear soon, so this may
not be an issue.

I intend to schedule a session on this at UDS.

-serge

Re: [Qemu-devel] qemu-kvm: remove "boot=on|off" drive parameter compatibility (fwd)

[Serge Hallyn]

Quoting Peter Maydell (peter.maydell@linaro.org):
> On 1 October 2012 15:15, Serge Hallyn <serge.hallyn@canonical.com> wrote:
> > We (Ubuntu) plan to switch to qemu in the next release which opens in
> > November.  I suppose there's likely to be a hiccough or two, but I can't
> > think of any offhand.
> 
> Are you planning to do that for all CPU target architectures, or
> to maintain the current split between x86 and everything-else ?
> 
> -- PMM

I'll have to talk to qemu-linaro folks about that.  I don't mind carrying
patchsets (that are headed upstream) to enable some chipsets if that's
what's needed to consolidate the source trees.  The bigger question
relates to main vs universe.  For instance qemu-system is built against
vde2, and qemu-kvm-spice against spice, both of which are in universe.
I understand the distinction may change or disappear soon, so this may
not be an issue.

I intend to schedule a session on this at UDS.

-serge