I promised that mail for the beginning of the week but I still have
a very hard time to try to formulate a good plan of action, I'm still
stuck in a dilemna, see below.
What is it?
-----------
I think tuning informations are that set of parameters associated
to a domain or a host, which are not stricly needed to get the
domain(s) working but improve their runtime behaviour.
To me this includes:
- scheduling parameters the scope may be host/hypervisor/domain
- vcpu affinity i.e. to which set of physical CPU each of the
vcpu may be bound
- and possibly others ...
The problem:
------------
People would like to associate those to the XML domain informations,
the goal being to be able to restore those informations when a domain
(re-)starts.
I have been objecting it so far because, I think those informations
don't have the same lifetime and scope as the other domain informations
saved in the XML. Since they are not needed to start the domain, and
that once the domain is started the existing domain API can be used
to change those informations, it is better to keep them separate.
However I got objections from David Lutterkort [1], Jim Fehlig [2],
and John Levon [3] plus of course the initial request for it from
Tatsuro Enokura (and the Fujistu people in general) [4]
The problem to me comes from 2 things:
1/ storing tuning informations in domains descriptions is not sufficient
2/ if we store them there we also need to always save them when exporting
the XML domain file
2/ is fairly important to avoid a lot of problems as we have experienced
before for example with console informations. If the input for virsh create
gets different from the output of dumpxml, a lot of rather annoying things
happen in practice, it certainly generate confusion. So we really need
to output those tuning data if we put them in.
Also I strongly believe in 1/, i.e. tuning informations are cross domain
and they are vey likely to change fast as soon as the management applications
will get deployed, but even in relatively small deployment the tuning is
rather a per host informations, which may depend on the current workload
of the machine. I don't believe in tuning being loaded at create time
and never changing later. Even in my own very basic usage that doesn't match
my use which lead me to load and stop domain on demand for short period
of time.
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.
I don't want to force the decision one way or another, it is
probable I missed something, but I don't think adding tuning informations
to the domain configuration file to be really that convenient,
I could be done better, and with less associated problems by
keeping those separate.
Daniel
[1] https://www.redhat.com/archives/libvir-list/2007-October/msg00250.html
[2] https://www.redhat.com/archives/libvir-list/2007-November/msg00003.html
[3] https://www.redhat.com/archives/libvir-list/2007-October/msg00046.html
[4] https://www.redhat.com/archives/libvir-list/2007-October/msg00221.html
[5] https://www.redhat.com/archives/libvir-list/2007-October/msg00245.html
--
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