On Tue, Aug 16, 2011 at 05:46:43PM -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. The goal of the XML is that it should always reflect the canonical configuration of the guest. So when the guest is running it should not show 'host' as the CPU model, but rather the real CPU model that the guest is using. Although libvirt has the info internally, we want that to be equally visible via the XML description to the app. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list