7:24 p.m.
I tested the latest CVS libvirt on a 128-way x3950 and create, define,
and start appear to work well with various cpusets specified. The only
thing I noticed was that dumpxml does not grab the cpuset info. I have
not looked at the code to verify, but is this expected? Maybe you
discussed this Daniel, but I can't remember at the moment.
--
Elizabeth Kon (Beth)
IBM Linux Technology Center
Open Hypervisor Team
email: eak(a)us.ibm.com
3:33 a.m.
On Tue, Nov 13, 2007 at 08:24:53PM -0500, beth kon wrote:
I tested the latest CVS libvirt on a 128-way x3950 and create,
define,
and start appear to work well with various cpusets specified. The only
thing I noticed was that dumpxml does not grab the cpuset info. I have
not looked at the code to verify, but is this expected? Maybe you
discussed this Daniel, but I can't remember at the moment.
Hum, no, that's not normal, I commited this on
Wed Oct 31 10:36:00 CET 2007 Daniel Veillard <veillard(a)redhat.com>
* proxy/libvirt_proxy.c src/proxy_internal.[ch] src/xen_internal.c
src/xen_unified.[ch] src/xend_internal.[ch] src/xml.[ch]: last
patch for the library NUMA support, allow to serialize CPU pinning
to domain configs (but won't work though proxy access), includes
many patches from Saori Fukuta.
and we applied later another patch from you :
Mon Nov 5 11:11:45 CET 2007 Daniel Veillard <veillard(a)redhat.com>
* src/xml.c: patch from Beth Kon to fix a problem when the
cpuset parameter for numa uses cpu maxcpu-1
But I was hoping it was a solved problem ... I guess we need to debug this !
The string should be given to xend_parse_sexp_desc as the cpus last argument.
That argument should be computed in xenUnifiedDomainDumpXML() where it calls
xenDomainUsedCpus() to get that string.
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/
7:59 p.m.
On Wed, 14 Nov 2007 04:33:47 -0500 Daniel Veillard wrote:
On Tue, Nov 13, 2007 at 08:24:53PM -0500, beth kon wrote:
> I tested the latest CVS libvirt on a 128-way x3950 and create, define,
> and start appear to work well with various cpusets specified. The only
> thing I noticed was that dumpxml does not grab the cpuset info. I have
> not looked at the code to verify, but is this expected? Maybe you
> discussed this Daniel, but I can't remember at the moment.
Hum, no, that's not normal, I commited this on
But I was hoping it was a solved problem ... I guess we need to debug this !
The string should be given to xend_parse_sexp_desc as the cpus last argument.
That argument should be computed in xenUnifiedDomainDumpXML() where it calls
xenDomainUsedCpus() to get that string.
I belive that the dumpxml grab the cpuset information.
For the active domain, we compute the cpuset information that we get
from Xen.
If all CPU are used, dumpxml does not show the cpuset information,
because no setting of cpuset is the same meaning with all CPU.
If some CPU is pined, dumpxml shows the pined cpuset information.
(just a example)
When pining "1" of PCPU for each VCPU, dumpxml will show the following
cpuset information.
# virsh vcpuinfo 2
VCPU: 0
CPU: 1
State: blocked
CPU time: 5.1s
CPU Affinity: -y
VCPU: 1
CPU: 1
State: blocked
CPU time: 6.7s
CPU Affinity: -y
# virsh dumpxml 2
...
<vcpu cpuset='1'>2</vcpu>
...
For the inactive domain, there are two case for dumpxml.
In case of the xendConfigVersion < 3, we get the cpuset information
from configuration file (i.e. cpus parameter of /etc/xen/config).
In other case, we try to get the cpuset information from Xen.
But we cannot get the information from Xen, so the dumpxml cannot show
the cpuset information for the inactive domain.
Don't you think so ?
Regards,
Saori
6216
days inactive
6217
days old
2 comments
3 participants
participants (3)
-
beth kon -
Daniel Veillard -
Saori Fukuta