Any idea on my assumed scenario? If this is really an issue, it's something we need fix it IMHO. Thanks --jyh > -----Original Message----- > From: Jiang, Yunhong > Sent: Friday, November 02, 2012 4:52 PM > To: Eric Blake > Cc: libvir-list@xxxxxxxxxx > Subject: RE: Is possible that cpu_maps.xml changed during different > releases? > > 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@xxxxxxxxxx > > Subject: RE: 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@xxxxxxxxxx] > > > Sent: Thursday, November 01, 2012 11:23 PM > > > To: Jiang, Yunhong > > > Cc: libvir-list@xxxxxxxxxx > > > Subject: Re: 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@xxxxxxxxxx +1-919-301-3266 > > > Libvirt virtualization library http://libvirt.org -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list