One question come to my mind for "but such changes will only be additive",
which may be an issue in cloud environment:
Considering following assumed situation:
In release 1.0's cpu_maps.xml, core2duo include feature "a, b, c"
In release 1.1's cpu_maps.xml, core2duo include "a, b, c, d"
Two hosts, with different CPU features:
Host A with feature "a, b, c, d, e" and 1.1 release, capabilities will be:
Model: Core2duo (assume core2duo is the only match one)
Features: e
Host B with feature "a, b, c, e", and 1.0 release, capabilities will be:
Models: Core2Duo (again, assume core2duo is the only match one)
Features: e
When we compare the capabilities in Host A, I think comparCPU will pass,
because host A will use 1.1 release definition to check Host B's capabilities, this
is sure to be wrong, since host B does not have feature 'd'.
I think the key point is, capabilities describe features with information from
cpu_maps.xml, which is a per-host file.
Thanks
--jyh
Will depends on
-----Original Message-----
From: Jiang, Yunhong
Sent: Friday, November 02, 2012 9:39 AM
To: Eric Blake
Cc: libvir-list(a)redhat.com
Subject: RE: [libvirt] Is possible that cpu_maps.xml changed during different
releases?
Eric, thanks for the answer very .much, that's really helpful.
Sorry for the wrong format, I'm using outlook and possibly some setting wrong.
Thanks
--jyh
> -----Original Message-----
> From: Eric Blake [mailto:eblake@redhat.com]
> Sent: Thursday, November 01, 2012 11:23 PM
> To: Jiang, Yunhong
> Cc: libvir-list(a)redhat.com
> Subject: Re: [libvirt] Is possible that cpu_maps.xml changed during
> different releases?
>
> On 10/31/2012 02:20 AM, Jiang, Yunhong wrote:
> > Hi, all
>
> [your mailer doesn't know how to wrap long lines, which makes it
> awkward to read your message]
>
> > I have two questions to the cpu_maps.xml in different releases,
> > hope
> someone can give me some hints:
> >
> > a) Will it be possible that the features defined in cpu_maps.xml
> > for one
> specific CPU model (like Nehalem) will be different? For example, one
> feature is not listed for Nehalem in release x.y, and added in release x.y+1?
>
> XML does have the possibility to change between releases, but such
> changes will only be additive (we will never remove support for a
> feature once it is listed).
>
> >
> > 2) Is the format of the cpu_maps.xml fine defined or will be it
> > changed
> during releases? I asked this because currently the features defined
> in the capabilities only list features not included in the definition
> in cpu_maps.xml for the corresponding model. So if I want to get the
> full features supported by the host, I have to parse the capabilities
> and the cpu_maps.xml. I didn't find the definition for cpu_maps.xml
> format, although the capabilities format is well defined in
>
http://libvirt.org/guide/html/Application_Development_Guide-Connection
> s-Ca
> pability_Info.html.
>
> The format should be well-defined; again, our requirement is that
> upgrades might add new xml attributes or elements, but will never
> remove elements that have been valid in previous releases. To some
> extent, docs/schemas/capability.rng in libvirt.git gives an RNG
> grammar for what capabilities will look like, although someone else
> may be able to point to a better documentation of what will be in
cpu_maps.xml.
>
> --
> Eric Blake eblake(a)redhat.com +1-919-301-3266
> Libvirt virtualization library
http://libvirt.org