# HG changeset patch # User john.levon(a)sun.com # Date 1232675291 28800 # Node ID 415bfd87e0ecd7751ed6df372e82da0e3991d617 # Parent 68e14fe50dfa88a4694bc4c7a68d2f73f41c6171 Fix virsh sched-credit for xend Need to pass domain in the xend op for shut-down domains. (This also requires xend fixes, but this patch doesn't make things worse.)

On Thu, Jan 22, 2009 at 05:49:00PM -0800, john.levon(a)sun.com wrote: > # HG changeset patch > # User john.levon(a)sun.com > # Date 1232675291 28800 > # Node ID 415bfd87e0ecd7751ed6df372e82da0e3991d617 > # Parent 68e14fe50dfa88a4694bc4c7a68d2f73f41c6171 > Fix virsh sched-credit for xend > > Need to pass domain in the xend op for shut-down domains. > (This also requires xend fixes, but this patch doesn't make things > worse.) Does XenD actaully persist the schedinfo changes for inactive domains ? Historically we've only considered the sched tunables API to be relevant to active guests, and none of the drivers make any attempt to persist the settings for inactive domains.

On Fri, Jan 23, 2009 at 10:34:14AM +0000, Daniel P. Berrange wrote: > On Thu, Jan 22, 2009 at 05:49:00PM -0800, john.levon(a)sun.com wrote: > > # HG changeset patch > > # User john.levon(a)sun.com > > # Date 1232675291 28800 > > # Node ID 415bfd87e0ecd7751ed6df372e82da0e3991d617 > > # Parent 68e14fe50dfa88a4694bc4c7a68d2f73f41c6171 > > Fix virsh sched-credit for xend > > > > Need to pass domain in the xend op for shut-down domains. > > (This also requires xend fixes, but this patch doesn't make things > > worse.) > > Does XenD actaully persist the schedinfo changes for inactive domains ? > Historically we've only considered the sched tunables API to be > relevant to active guests, and none of the drivers make any attempt > to persist the settings for inactive domains. I'm not sure if we make any explicit guarantees about this though, so perhaps we should leave the decision to the drivers themselves? Or document how it should work in the API?

On Mon, Jan 26, 2009 at 11:29:01AM +0000, Daniel P. Berrange wrote: > It isn't that simple. Tunables are not represented as part of the XML, Good point, that would need to be fixed. I'd missed this. > So if we want to be able to set tunables on inactive domains, the > virDomainSetSchedularParams() is not the right place todo it - we > can only guarentee that is is reliably usable on live domains. No, surely we should fix the XML to represent it, and then it /would/ work. Must be better than another identical API.

(BTW I find that the API providing a bunch of unknown name/value pairs with no indication of what they might be a little icky...)

On Mon, Jan 26, 2009 at 12:28:47PM +0000, Richard W.M. Jones wrote: > > No, surely we should fix the XML to represent it, and then it /would/ > > work. Must be better than another identical API. > > Historically there has been a bit of a debate about this. It's not > clear if the XML is meant to represent static configuration about the > domain (eg. what disks it has), versus administration of the domain > (how vCPUs are pinned for example). I think it's become evident that the XML represents the dynamic state of the domain - for example, the whole code is structured around things like the console pty being available. This would include administrative actions, especially ones that should be persisted. Put another way, there's nowhere else for it to go! Yes, it would have been nice for a clear separation between the three things (hypervisor-agnostic description of a guest 'profile', i.e. image.rng, configuration of a domain, and runtime state of a domain), but it cannot be changed now. Furthermore, the API does not include the notion of persistence, sadly.