[libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt
Anthony Liguori
anthony at codemonkey.ws
Sun Mar 25 18:01:34 UTC 2012
On 03/25/2012 10:45 AM, Avi Kivity wrote:
> On 03/25/2012 05:30 PM, Anthony Liguori wrote:
>> On 03/25/2012 10:18 AM, Avi Kivity wrote:
>>> On 03/25/2012 05:07 PM, Anthony Liguori wrote:
>>>>> As log as qemu -nodefconfig -cpu westmere -M pc1.1
>>>>
>>>>
>>>> -nodefconfig is going to eventually mean that -cpu westmere and -M
>>>> pc-1.1 will not work.
>>>>
>>>> This is where QEMU is going. There is no reason that a normal user
>>>> should ever use -nodefconfig.
>>>
>>> I don't think anyone or anything can use it, since it's meaning is not
>>> well defined. "not read any configuration files" where parts of qemu
>>> are continually moved out to configuration files means its a moving
>>> target.
>>
>> I think you assume that all QEMU users care about forward and
>> backwards compatibility on the command line about all else.
>>
>> That's really not true. The libvirt folks have stated repeatedly that
>> command line backwards compatibility is not critical to them. They
>> are happy to require that a new version of QEMU requires a new version
>> of libvirt.
>
> I don't think this came out of happiness, but despair. Seriously,
> keeping compatibility is one of the things we work hardest to achieve,
> and we can't manage it for our command line?
I hate to burst your bubble, but we struggle and rarely maintain the level of
compatibility you're seeking to have.
I agree with you that we need to do a better job maintaining compatibility which
is why I'm trying to clearly separate the things that we will never break from
the things that will change over time.
-nodefconfig is a moving target. If you want stability, don't use it. If you
just want to prevent the user's /etc/qemu stuff from being loaded, use
-no-user-config.
>>
>> I'm not saying that backwards compat isn't important--it is. But
>> there are users who are happy to live on the bleeding edge.
>
> That's fine, but I don't see how -nodefconfig helps them. All it does
> is take away the building blocks (definitions) that they can use when
> setting up their configuration.
Yes, this is a feature.
>>> Suppose we define the southbridge via a configuration file. Does that
>>> mean we don't load it any more?
>>
>> Yes. If I want the leanest and meanest version of QEMU that will
>> start in the smallest number of milliseconds, then being able to tell
>> QEMU not to load configuration files and create a very specific
>> machine is a Good Thing. Why exclude users from being able to do this?
>
> So is this the point? Reducing startup time?
Yes, that's one reason. But maybe a user wants to have a whole different set of
machine types and doesn't care to have the ones we provide. Why prevent a user
from doing this?
Maybe they have a management tool that attempts to totally hide QEMU from the
end user and exposes a different set of machine types. It's certainly more
convenient for something like the Android emulator to only have to deal with
QEMU knowing about the 4 types of machines that it specifically supports.
Regards,
Anthony Liguori
More information about the libvir-list
mailing list