qemu-devel
[Top][All Lists]
Advanced

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

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


From: Michael Tokarev
Subject: [Qemu-devel] qemu-kvm command-line compat
Date: Fri, 18 Jan 2013 09:28:04 +0400
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/17.0 Icedove/17.0

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 
"$@"

(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



reply via email to

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