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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).