From: "Andreas Färber" <afaerber@suse.de>
To: Alex Bligh <alex@alex.org.uk>, "Michael S. Tsirkin" <mst@redhat.com>
Cc: Ryan Harper <ryan.harper@canonical.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
"quintela@redhat.com" <quintela@redhat.com>,
Libvirt <libvir-list@redhat.com>,
Serge Hallyn <serge.hallyn@ubuntu.com>,
"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
Alexander Graf <agraf@suse.de>,
Cole Robinson <crobinso@redhat.com>,
Amit Shah <amit.shah@redhat.com>, Bruce Rogers <brogers@suse.com>,
"Serge E. Hallyn" <serge@hallyn.com>
Subject: Re: [Qemu-devel] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm
Date: Mon, 22 Sep 2014 17:45:28 +0200 [thread overview]
Message-ID: <54204418.7080500@suse.de> (raw)
In-Reply-To: <C3ABED49-2AB0-4BD5-8071-947195FF1CF0@alex.org.uk>
Am 22.09.2014 um 15:05 schrieb Alex Bligh:
>>> Sadly that is not true. For instance on Ubuntu Precise
>>> it's invoked as qemu-system-x86_64 by at least one
>>> management application known to me.
>>
>> Well change it to call qemu-kvm then :)
>> Also what happens if you install qemu as well?
>> Does it conflict?
>
> I'm not an Ubuntu maintainer but AFAIK qemu-kvm is deprecated.
> It may only be there to support upgrades.
>
> We still need to support migration from qemu running on Precise
> to qemu running on Trusty. The trusty instance may not have
> qemu-kvm installed. If we were looking at argv[0], we'd
> really want to look at it on the /sending/ machine.
>
> Forcing qemu to be involved as qemu-kvm solely on the basis
> some users might want to migrate a VM in from a previous
> version does not sound practical.
>
>>> I'm not quite sure why you say "legacy management
>>> applications".
>>
>> Because any non legacy one can be patched.
>
> Well this is where we diverge. I think the distro needs
> a way to change the default behaviour, i.e. so the existing
> command line will do something different.
>
>>> This applies to /any/ management application.
>>> Unless we're going to burden every management application
>>> with this problem, we need to fix it.
>>>
>>> Just as a reminder, the ./configure value defaults to
>>> off, which means there is no change in current behaviour.
>>
>> Yes but this still perpetuates the mess.
>>
>> If you prefer using -M pc-1.0, add a new property
>> and teach management to set it.
>>
>> But no silent compile-time behind the scenes changes please.
>
> OK, how about we keep the aliases, and make pc-1.0
> default to the pc-1.0-qemu-git. We then add a command
> line option to make pc-1.0 mean pc-1.0-qemu-kvm, with
> that obviously defaulting to off.
>
> Then distros can then put the option in
> /etc/qemu/target-x86_64.conf or whatever.
What about adding a bool property "qemu-kvm-compat" to the MachineClass?
Then a qemu-kvm shell script (like SUSE uses) can pass -global
machine.qemu-kvm-compat=on whereas qemu-system-x86_64 would run in the
default non-qemu-kvm mode (config on disk would affect both). It would
also allow running -machine pc-0.15,qemu-kvm-compat=on, ditching lots of
new machine names and avoiding the name bikeshedding.
Regards,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
next prev parent reply other threads:[~2014-09-22 15:45 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-21 14:38 [Qemu-devel] [PATCH v3 0/2] Add machine type pc-1.0-qemu-kvm for live migrate compatibility with qemu-kvm Alex Bligh
2014-09-21 14:38 ` [Qemu-devel] [PATCH v3 1/2] " Alex Bligh
2014-09-22 11:50 ` Michael S. Tsirkin
2014-09-22 12:28 ` Alex Bligh
2014-09-22 12:38 ` Michael S. Tsirkin
2014-09-21 14:38 ` [Qemu-devel] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm Alex Bligh
2014-09-22 11:36 ` Michael S. Tsirkin
2014-09-22 11:42 ` [Qemu-devel] [libvirt] " Daniel P. Berrange
2014-09-22 11:53 ` Michael S. Tsirkin
2014-09-22 15:24 ` Markus Armbruster
2014-09-22 15:36 ` Michael S. Tsirkin
2014-09-22 15:47 ` Serge Hallyn
2014-09-22 15:44 ` Paolo Bonzini
2014-09-22 17:30 ` Alex Bligh
2014-09-22 19:10 ` Paolo Bonzini
2014-09-22 19:36 ` Alex Bligh
2014-09-23 0:12 ` Serge Hallyn
2014-09-22 11:50 ` [Qemu-devel] " Alex Bligh
2014-09-22 12:10 ` Michael S. Tsirkin
2014-09-22 13:05 ` Alex Bligh
2014-09-22 15:45 ` Andreas Färber [this message]
2014-09-22 16:54 ` Alex Bligh
2014-09-22 17:26 ` Markus Armbruster
2014-09-23 3:46 ` Michael S. Tsirkin
2014-09-23 3:44 ` Michael S. Tsirkin
2014-09-22 15:32 ` Markus Armbruster
2014-09-22 17:21 ` Michael S. Tsirkin
2014-09-23 7:59 ` Markus Armbruster
2014-09-23 8:24 ` Michael S. Tsirkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54204418.7080500@suse.de \
--to=afaerber@suse.de \
--cc=agraf@suse.de \
--cc=alex@alex.org.uk \
--cc=amit.shah@redhat.com \
--cc=brogers@suse.com \
--cc=crobinso@redhat.com \
--cc=libvir-list@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=ryan.harper@canonical.com \
--cc=serge.hallyn@canonical.com \
--cc=serge.hallyn@ubuntu.com \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.