[libvirt] [PATCH] Fix virsh sched-credit for xend
# HG changeset patch # User john.levon@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.) Signed-off-by: John Levon <john.levon@sun.com> diff --git a/src/xend_internal.c b/src/xend_internal.c --- a/src/xend_internal.c +++ b/src/xend_internal.c @@ -4665,7 +4665,7 @@ xenDaemonSetSchedulerParameters(virDomai ret = xend_op(domain->conn, domain->name, "op", "domain_sched_credit_set", "weight", buf_weight, - "cap", buf_cap, NULL); + "cap", buf_cap, "dom", domain->name, NULL); break; } default:
On Thu, Jan 22, 2009 at 05:49:00PM -0800, john.levon@sun.com wrote:
# HG changeset patch # User john.levon@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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
On Fri, Jan 23, 2009 at 10:34:14AM +0000, Daniel P. Berrange wrote:
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 ?
Sure. Indeed, that's how libvirt implements the get version - from the sexpr.
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.
Seems like an odd decision? regards john
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@sun.com wrote:
# HG changeset patch # User john.levon@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? Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
On Mon, Jan 26, 2009 at 10:55:37AM +0000, Richard W.M. Jones wrote:
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?
And obviously, this seems like a missing feature! regards john
On Mon, Jan 26, 2009 at 10:55:37AM +0000, Richard W.M. Jones wrote:
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@sun.com wrote:
# HG changeset patch # User john.levon@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?
It isn't that simple. Tunables are not represented as part of the XML, and if Xen is now persisting them in its config file, then any statement we make about virDomainSetSchedularParams persisting the settings would be unreliable. The very next call to virDomainDefineXML/CreateXML will blow away the tunable settings that were not part of the XML. 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. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
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...) regards john
On Mon, Jan 26, 2009 at 11:48:42AM +0000, John Levon wrote:
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.
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). Is this still a real distinction we can/need to make? Maybe time to revisit this and allow administrative things to be added.
(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...)
Yeah me too. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora
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. regards john
On Mon, Jan 26, 2009 at 01:21:46PM +0000, John Levon wrote:
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.
Yup, I totally agree with you. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top
participants (4)
-
Daniel P. Berrange -
John Levon -
john.levon＠sun.com
-
Richard W.M. Jones