On Fri, Nov 02, 2007 at 01:23:32PM -0400, beth kon wrote: > I tested with the latest code, and found a problem with specifying a > value in the cpuset in XML that is greater than maxcpu-1. The attached > patch corrects this behavior, but the issue remains that an out of range > cpu will prevent the domain from starting. This is the way xm create > works today. Okay, thanks, patch applied and commited ! > In talking with Daniel about this, he made the point that it is not > necessarily desirable for the failure of a tuning parameter (e.g., > config specifies cpu 5 and the domain is now being started on a 4 cpu > machine) to cause domain creation to fail. He mentioned phones ringing > in the middle of the night somewhere for support when the domain fails > to start. I think he has a point. Wouldn't it make more sense to start > the domain(s) at perhaps suboptimal performance, than to have everything > shut down until someone can come and figure out the problem? > > It would seem better if the domain started (with no cpu affinity) and a > warning was posted. This might also argue for separation of domain > config and tuning parameters. Or at least for 2 flavors of create? One > that fails if tuning parameters cannot be activated, and one that doesn't. Well that could be one of the flags passed to the Create (or CreateLinux) calls, but I'm afraid taht would lead the user to assume the behaviour will be consistent from hypervisor to hypervisor and also for all tuning parameters, and honnestly I'm not sure we will ever be able to garantee this. I think we need to discuss more globally tuning parameters, I will make another post today on the topic to start a clean thread :-) thanks a lot ! 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