On Thu, Nov 08, 2007 at 02:34:05PM -0500, beth kon wrote: > Daniel Veillard wrote: > > <snip> > > > > > > >My opinion: > >----------- > > > >We need better tools, even for simple use case to be able to save > >an existing tuning for a domain or a full machine, and reload it > >when needed. This is IMHO better done on top of the existing API > >which already have the entry points to implement them. My idea is > >to provide tuning commands in virsh [5]. If you implement tuning both > >at creation time and in the tool, this mean you either make them > >different in which case you have no coherency between what you say > >when you create a domain or save its config and what you do at the > >virsh level. If you don't make it different (for example trying to > >use the same kind of XML syntax), then you need code for doing this > >both in the tool and in the library itself, or you export as a > >new API the tuning load and save. Exporting as a parallel API what > >we have already for scheduling and VCPU affinity makes the API > >more complex, and less coherent. > > > > > > > Daniel, > > Just to be sure I understand, are you suggesting removing tuning > information from any configuration file and making it a runtime exercise > to set it up? (That is, after the domain has been started) It would not be removing, as I don't think we have any at this point, the only exception would be the 'currentMemory' parameter, and the cpuset informations, both are optional obviously, but may be absolutely necessary at creation time, to avoid a broken or failed setup of the domain. And yes tuning would be a runtime exercise (which application can activate immediately after the completion of the Create command), Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list