qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] qemu-kvm command-line compat


From: Doug Goldstein
Subject: Re: [Qemu-devel] qemu-kvm command-line compat
Date: Fri, 18 Jan 2013 19:52:13 -0600

On Thu, Jan 17, 2013 at 11:28 PM, Michael Tokarev <address@hidden> wrote:
> Hello.
>
> I was thinking about switching users from (old) qemu-kvm to (new) qemu,
> and am trying to understand the difference and how to compensate for
> them.
>
> So far we had several discussions about this topic, first of all
> touching live migration ([1]), which is about different side,
> and some mentioning the topic I'm trying to discuss as well,
> for example [2].
>
> But there were no discussions (iirc) about other ingredients.
>
> As far as I remember, qemu-kvm had quite some differences compared
> with qemu, at least:
>
>  -accel kvm,tcg
>  -cpu kvm64 (or kvm32?)
>  -kernel_irqchip (machine option)
>
> So, my question is, -- what to suggest to use when a user switches
> from qemu-kvm to qemu now?
>
> I can try to come up with a compat script of some sort which will
> try to translate old qemu-kvm command line to new qemu command line,
> something like:
>
>  exec qemu-system-x86_64 -machine accel=kvm:tcg,kernel_irqchip=on -cpu kvm64
> "$@"

This is what exactly what I planned on shipping as Gentoo's
/usr/bin/qemu-kvm. Let me know what you decide to change and I'll
match suit.

>
> (I'm not sure yet how to handle default_machine_options but that's
> minor, the above is enough to demonstrate what I'm talking about).
> This is assuming that later definitions will override earlier of
> the same name.
>
> Is that enough or is there something else needed?
>
> Is explicit kernel_irqchip necessary?
>
> How to choose between -cpu kvm64 vs kvm32?
>
> Is this expected to work with libvirt, which tries to specify
> everything explicitly?
>
> I can also try to check other options to see whenever things
> like -enable-kvm (or -disable), -machine accel=, -cpu are
> specified and omit corresponding parts, again, I'm not yet
> sure if that's necessary.
>
> And as mentioned in [2], I'm not sure such a wrapper is
> welcome generally, due to different reception of defaults
> by different people.
>
> Comments?
>
> [1] http://patchwork.ozlabs.org/patch/205676/
> [2] https://patchwork.kernel.org/patch/1531761/
>
> Thanks,
>
> /mjt
>

--
Doug Goldstein



reply via email to

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