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

Re: [libvirt] [Qemu-devel] [PATCH v3 2/2] Add configure option --enable-pc-1-0-qemu-kvm



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


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