On Tue, Nov 13, 2007 at 11:51:09AM -0500, beth kon wrote:
beth kon wrote:
>When a domain is started, the caller can specify a minimal start (XML
>only) or a tuned start (XML plus tuning). Lower level libvirt code
>would understand the specifics of the hypervisor well enough to know
>whether it had to include some of the tuning information at domain
>creation time.
Daniel and I have been discussing this a bit on IRC, so I will dump that
information on the list... (correct me if I misstate something here,
Daniel :-)
Daniel wants to have the xml contain all parameters that must be
specified at domain creation in order to achieve proper function, and
cannot be tuned later. I agree this is a reasonable definition. In this
case, cpuset would need to be in the xml.
Yup, that's what I tried to express :-)
My concern is that currently Xen will fail a domain create request if
the cpu is out of range with the error "invalid argument", so the user
will not have enough information to correct the problem in the xml and
try again. We can pursue getting a more explicit error message from
Xen. Or Xen could ignore the cpuset and start the domain, perhaps with
a warning message.
My thinking was that ideally it might be good to have libvirt provide 2
start methods - minimal and tuned, but Daniel thinks it is not worth the
complexity. It should be up to the user to correct issues in the xml and
try again.
We really need to get some reporting. Usually 'invalid argument' arise
for example if you try to start an x86_64 guest on an i686 host, i.e.
something as broken as a wrong architecture.
One thing we can do in libvirt is check the input parameters, we know
how many physical CPUs are on the box, and we do parse the cpuset attribute
so we coudl either:
- drop the informations about cpuset and give an error
- abort the create operation and also give the error
unfortunately we can't do anything about predefined domains, already in
the xen database. But I think this should cope with most case in libvirt.
Oh and of course ideally we should get a xend patch upstream to give
back a correct error message, but that's not something we can control.
thanks !
Daniel
--
Red Hat Virtualization group
http://redhat.com/virtualization/
Daniel Veillard | virtualization library
http://libvirt.org/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/