On Tue, Aug 16, 2011 at 17:46:43 -0400, Dave Allan wrote: > On Tue, Aug 16, 2011 at 10:55:32PM +0200, Jiri Denemark wrote: > > On Mon, Aug 08, 2011 at 13:48:59 +0200, Jiri Denemark wrote: > > > Hi, > > > > > > AFAIK this topic is not new but I think we still do not have a good solution > > > for it. Libvirt already supports specifying what CPU and its features a guest > > > should see but imagine one wants to run a guest on the best possible CPU. The > > > current way is to copy the <cpu> element from capabilities XML into domain > > > XML. This approach is fine since it provides reproducible environment and such > > > domain can even be migrated to a different host. But the CPU shown provided to > > > a guest is not the same as the real host CPU. It's based on a model which > > > doesn't reflect all aspects of real CPUs. Ideally, we would model everything > > > but that's quite complicated and may need updating anytime a new CPU is > > > introduced. > > > > There have been no comments on this so far. Perhaps the topic is not so > > controversial as I thought it was. But more likely it's just that people are > > busy with other things. IIRC, Daniel used to have a strong opinion on this > > matter, is that right? > > I'm thinking that this boils down essentially to syntactic sugar. > > Would it not be possible to create a <cpu>host</cpu> that simply > automates the process of copying the host capabilities into the > running guest XML? That would allow libvirt to do pre-migration > validation that the destination host was suitable, but also permit > users to specify one value of <cpu> that should in theory run with the > maximum capabilities of the particular host where the domain was > started and not have to go through the work of copying the host > capabilities every time before booting the guest. Dave and I agreed privately on IRC that in fact both use cases are valid and it would be nice if the XML configuration could allow both of them. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list