[Libvir] CPU pinning of domains at creation time
There are a few things I gathered on this issue. This affects NUMA setups, where basically if a domain must be placed on a given cell it is not good to let the hypervisor place it first with its own heuristics and then later migrate it to a different set of CPU, but better to instruct the hypervisor to start said domain on the given set. - For Xen it is possible to instruct the hypervisor by passing (cpus '2,3') in the SExpr where the argument is a list of the physical processors allowed - For KVM I think the standard way would be to select the cpuset using sched_setaffinity() between the fork of the current process and the exec of the qemu process - there is no need (from a NUMA perspective) to do fine grained allocation at that point, as long as the domain can be restricted to a given cell at startup, then if needed virDomainPinVcpu() can be used later to do more precise pinning in order to try to optimize placement - to be able to instruct the hypervisor at creation time adding the information in the domain XML description looks the more natural way (another option would be to force to use virDomainDefineXML, add a call using the resulting virDomainPtr to define the set, and then virDomainCreate would be used to do the actual start) + the good point of having this embedded in the XML is that we still have all informations about the domain settings in the XML, if we want to restart it later + the bad point is that we need to fetch and carry this extra information when doing XML dumps to not loose it for example when manipulating the domain to add or remove devices - extracting a cpuset can still be an heavy operation, for example if using xend on need one RPC per vcpu in the domain, the cpuset being constructed by OR'ing logically all cpumaps used by the vcpus of the domain (though in most case this will be the full map after the first CPU and can be stopped immediately) - for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added). Internally implementing this should not be too hard, I would probably refactor some of the existing parsing code, provide functions to get the cpuset and the number of physical processors. Does this sounds okay ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Thu, Oct 11, 2007 at 09:00:14AM -0400, Daniel Veillard wrote:
There are a few things I gathered on this issue. This affects NUMA setups, where basically if a domain must be placed on a given cell it is not good to let the hypervisor place it first with its own heuristics and then later migrate it to a different set of CPU, but better to instruct the hypervisor to start said domain on the given set. - For Xen it is possible to instruct the hypervisor by passing (cpus '2,3') in the SExpr where the argument is a list of the physical processors allowed - For KVM I think the standard way would be to select the cpuset using sched_setaffinity() between the fork of the current process and the exec of the qemu process
Yep, as with Xen, this will only let you specify coarse mapping at time of creating the VM. ie you can say 'this VM is allow to run on pCPUs 1 & 3', but you can't say 'this VM's vCPU 1 is allow on pCPU 1 and vCPU 2 is allowed on pCPU 3'. This is because KVM has one thread per vCPU, and at the time of creating the VM the, vCPU threads don't yet exist & so there's nothing to pin. Not a huge problem really, just something we should document. Basically we are setting VM affinity at time of creationg. VCPU affinity can be set once a VM is running to fine-tune.
- there is no need (from a NUMA perspective) to do fine grained allocation at that point, as long as the domain can be restricted to a given cell at startup, then if needed virDomainPinVcpu() can be used later to do more precise pinning in order to try to optimize placement
Yep, from a NUMA pov we're only concerned with the VM memory allocation, so it is sufficient to consider VM affinity and not vCPU affinity.
- to be able to instruct the hypervisor at creation time adding the information in the domain XML description looks the more natural way (another option would be to force to use virDomainDefineXML, add a call using the resulting virDomainPtr to define the set, and then virDomainCreate would be used to do the actual start) + the good point of having this embedded in the XML is that we still have all informations about the domain settings in the XML, if we want to restart it later + the bad point is that we need to fetch and carry this extra information when doing XML dumps to not loose it for example when manipulating the domain to add or remove devices - extracting a cpuset can still be an heavy operation, for example if using xend on need one RPC per vcpu in the domain, the cpuset being constructed by OR'ing logically all cpumaps used by the vcpus of the domain (though in most case this will be the full map after the first CPU and can be stopped immediately)
Fetching /xend/domain/%s?op=vcpuinfo lets us get info for all vCPUs in a domain in a single RPC doesn't it ? In any case we should first just try the hypercall - in all normal scenarios that'll work fine.
- for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added).
It doesn't make sense to me to include the info at a vCPU level in the XML, since our granularity at time of creation is only at a VM level. When dumping XML, the VM's affinity is basically the union of the affinity of all of its pCPUs. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
* Daniel Veillard <veillard@redhat.com> [2007-10-11 08:01]:
There are a few things I gathered on this issue. This affects NUMA setups, where basically if a domain must be placed on a given cell it is not good to let the hypervisor place it first with its own heuristics and then later migrate it to a different set of CPU, but better to instruct the hypervisor to start said domain on the given set. - For Xen it is possible to instruct the hypervisor by passing (cpus '2,3') in the SExpr where the argument is a list of the physical processors allowed
A bit more detail here just FYI: Xen takes the cpu list and converts that into an affinity bitmap that is then applied to each vcpu allocated to the guest.
- For KVM I think the standard way would be to select the cpuset using sched_setaffinity() between the fork of the current process and the exec of the qemu process
Yep.
- there is no need (from a NUMA perspective) to do fine grained allocation at that point, as long as the domain can be restricted to a given cell at startup, then if needed virDomainPinVcpu() can be used later to do more precise pinning in order to try to optimize placement
kvm-46 added user-space allocated memory which means that we can use libnuma/numactl to set the approriate node.
- to be able to instruct the hypervisor at creation time adding the information in the domain XML description looks the more natural way (another option would be to force to use virDomainDefineXML, add a call using the resulting virDomainPtr to define the set, and then virDomainCreate would be used to do the actual start) + the good point of having this embedded in the XML is that we still have all informations about the domain settings in the XML, if we want to restart it later + the bad point is that we need to fetch and carry this extra information when doing XML dumps to not loose it for example when manipulating the domain to add or remove devices - extracting a cpuset can still be an heavy operation, for example if using xend on need one RPC per vcpu in the domain, the cpuset being constructed by OR'ing logically all cpumaps used by the vcpus of the domain (though in most case this will be the full map after the first CPU and can be stopped immediately)
Yeah, that might be a decent patch to xend - build up an array of affinity masks for each vcpu.
- for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added).
I think we should support the same cpuset notation that Xen supports, which means including ranges (1-4) and negation (^1). These two features make describing large ranges much more compact.
Internally implementing this should not be too hard, I would probably refactor some of the existing parsing code, provide functions to get the cpuset and the number of physical processors.
Does this sounds okay ?
Yeah, I think this covers everything we'd need. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx (512) 838-9253 T/L: 678-9253 ryanh@us.ibm.com
On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
* Daniel Veillard <veillard@redhat.com> [2007-10-11 08:01]:
- for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added).
I think we should support the same cpuset notation that Xen supports, which means including ranges (1-4) and negation (^1). These two features make describing large ranges much more compact.
on input I guess it makes sense. But we can't garantee to have such a compact representation on output. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
* Daniel Veillard <veillard@redhat.com> [2007-10-11 08:01]:
- for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added).
I think we should support the same cpuset notation that Xen supports, which means including ranges (1-4) and negation (^1). These two features make describing large ranges much more compact.
Enclosed is a rewrite of the cpuset notations, which can plug as a replacement for the current code in xend_internals, it should support the existing syntax currently used to parse xend topology strings, and also alllow ranges and negation. It's not as a patch but as a standlone replacement program which can be used to test (in spirit of the old topology.c one from Beth). I guess that's okay, check the test output (and possibly extend the test cases in tests array), It tried to think of everything including the weird \\n python xend bug and the 'no cpus' in cell cases. Just dump tst.c in libvirt/src, add $(INCLUDES) to the $(CC) $(CFLAGS) -I../include -o tst tst.c .... line and run make tst ./tst and check the output (also enclosed), The parsing is done in a slightly different way, but that should not change the output, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, 17 Oct 2007 10:53:17 -0400 Daniel Veillard wrote:
On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
I think we should support the same cpuset notation that Xen supports, which means including ranges (1-4) and negation (^1). These two features make describing large ranges much more compact.
Enclosed is a rewrite of the cpuset notations, which can plug as a replacement for the current code in xend_internals, it should support the existing syntax currently used to parse xend topology strings, and also alllow ranges and negation. It's not as a patch but as a standlone replacement program which can be used to test (in spirit of the old topology.c one from Beth). I guess that's okay, check the test output (and possibly extend the test cases in tests array), It tried to think of everything including the weird \\n python xend bug and the 'no cpus' in cell cases. Just dump tst.c in libvirt/src, add $(INCLUDES) to the $(CC) $(CFLAGS) -I../include -o tst tst.c .... line and run make tst ./tst and check the output (also enclosed), The parsing is done in a slightly different way, but that should not change the output,
I checked the test output. It seems work fine to me ! And also, how about this one for specifying "all" as an input ? --- tst.c_org 2007-10-17 20:52:10.000000000 -0400 +++ tst.c 2007-10-17 20:52:57.000000000 -0400 @@ -25,6 +25,7 @@ virXendError(void *conn, virErrorNumber #ifdef STANDALONE const char *tests[] = { + "node0:all", "node0:0-3,7,9-10\n node1:11-14\n", "node0:4,7\n", "node0:8-9,11\n", @@ -166,11 +167,19 @@ parseCpuSet(virConnectPtr conn, const ch while ((*cur != 0) && (*cur != sep)) { /* - * 3 constructs are allowed: + * 4 constructs are allowed: * - N : a single CPU number * - N-M : a range of CPU numbers with N < M * - ^N : remove a single CPU number from the set + * - all : apply the cpumap to all vcpus */ + if ( !strcmp(cur, "all") ) { + char buf[256]; + memset(&buf, 0, sizeof(buf)); + sprintf(buf, "0-%d", maxcpu); + cur = buf; + } + if (*cur == '^') { cur++; neg = 1; Thanks, Saori Fukuta
On Thu, Oct 18, 2007 at 10:10:59AM +0900, Saori Fukuta wrote:
On Wed, 17 Oct 2007 10:53:17 -0400 Daniel Veillard wrote:
On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
I think we should support the same cpuset notation that Xen supports, which means including ranges (1-4) and negation (^1). These two features make describing large ranges much more compact.
Enclosed is a rewrite of the cpuset notations, which can plug as a replacement for the current code in xend_internals, it should support the existing syntax currently used to parse xend topology strings, and also alllow ranges and negation. It's not as a patch but as a standlone replacement program which can be used to test (in spirit of the old topology.c one from Beth). I guess that's okay, check the test output (and possibly extend the test cases in tests array), It tried to think of everything including the weird \\n python xend bug and the 'no cpus' in cell cases. Just dump tst.c in libvirt/src, add $(INCLUDES) to the $(CC) $(CFLAGS) -I../include -o tst tst.c .... line and run make tst ./tst and check the output (also enclosed), The parsing is done in a slightly different way, but that should not change the output,
I checked the test output. It seems work fine to me ! And also, how about this one for specifying "all" as an input ?
All is the default, i.e. you don't specify a cpumap in the XML format. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Daniel Veillard wrote:
On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
* Daniel Veillard <veillard@redhat.com> [2007-10-11 08:01]:
- for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added).
I think we should support the same cpuset notation that Xen supports, which means including ranges (1-4) and negation (^1). These two features make describing large ranges much more compact.
Enclosed is a rewrite of the cpuset notations, which can plug as a replacement for the current code in xend_internals, it should support the existing syntax currently used to parse xend topology strings, and also alllow ranges and negation. It's not as a patch but as a standlone replacement program which can be used to test (in spirit of the old topology.c one from Beth). I guess that's okay, check the test output (and possibly extend the test cases in tests array), It tried to think of everything including the weird \\n python xend bug and the 'no cpus' in cell cases. Just dump tst.c in libvirt/src, add $(INCLUDES) to the $(CC) $(CFLAGS) -I../include -o tst tst.c .... line and run make tst ./tst and check the output (also enclosed), The parsing is done in a slightly different way, but that should not change the output,
Daniel
...
------------------------------------------------------------------------ cur = str; while (*cur != 0) { /* * Find the next NUMA cell described in the xend output */ cur = strstr(cur, "node"); if (cur == NULL) break; cur += 4; cell = parseCpuNumber(&cur, maxcpu);
This is certainly a nit, but I might change parseCpuNumber to parseNumber, since it looks a little odd that you are getting the cell id from the cpu number. A nit to be sure!
if (cell < 0) goto parse_error; skipSpaces(&cur); if (*cur != ':') goto parse_error; cur++; skipSpaces(&cur); if (!strncmp (cur, "no cpus", 7)) { nb_cpus = 0; for (cpu = 0;cpu < maxcpu;cpu++) cpuset[cpu] = 0; } else { nb_cpus = parseCpuSet(conn, &cur, 'n', cpuset, maxcpu);
Other than our discussion on #virt about handling of ^N specifications in parseCpuSet, looks good!
------------------------------------------------------------------------
-- Elizabeth Kon (Beth) IBM Linux Technology Center Open Hypervisor Team email: eak@us.ibm.com
On Wed, Oct 17, 2007 at 10:14:56PM -0400, beth kon wrote:
Daniel Veillard wrote:
On Thu, Oct 11, 2007 at 10:45:44AM -0500, Ryan Harper wrote:
* Daniel Veillard <veillard@redhat.com> [2007-10-11 08:01]:
- for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added).
I think we should support the same cpuset notation that Xen supports, which means including ranges (1-4) and negation (^1). These two features make describing large ranges much more compact.
Enclosed is a rewrite of the cpuset notations, which can plug as a replacement for the current code in xend_internals, it should support the existing syntax currently used to parse xend topology strings, and also alllow ranges and negation. It's not as a patch but as a standlone replacement program which can be used to test (in spirit of the old topology.c one from Beth). I guess that's okay, check the test output (and possibly extend the test cases in tests array), It tried to think of everything including the weird \\n python xend bug and the 'no cpus' in cell cases. Just dump tst.c in libvirt/src, add $(INCLUDES) to the $(CC) $(CFLAGS) -I../include -o tst tst.c .... line and run make tst ./tst and check the output (also enclosed), The parsing is done in a slightly different way, but that should not change the output,
Daniel
...
------------------------------------------------------------------------ cur = str; while (*cur != 0) { /* * Find the next NUMA cell described in the xend output */ cur = strstr(cur, "node"); if (cur == NULL) break; cur += 4; cell = parseCpuNumber(&cur, maxcpu);
This is certainly a nit, but I might change parseCpuNumber to parseNumber, since it looks a little odd that you are getting the cell id from the cpu number. A nit to be sure!
well, the only problem is if you have more cells than maxcpu, which doesn't make that much sense. Since we are testing against maxcpu I really think we should keep the function name, I can duplicate code and make a simpler function just for parsing the cell no.
if (cell < 0) goto parse_error; skipSpaces(&cur); if (*cur != ':') goto parse_error; cur++; skipSpaces(&cur); if (!strncmp (cur, "no cpus", 7)) { nb_cpus = 0; for (cpu = 0;cpu < maxcpu;cpu++) cpuset[cpu] = 0; } else { nb_cpus = parseCpuSet(conn, &cur, 'n', cpuset, maxcpu);
Other than our discussion on #virt about handling of ^N specifications in parseCpuSet, looks good!
Which is done in my version, will propagate. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Thu, Oct 18, 2007 at 04:53:15AM -0400, Daniel Veillard wrote:
On Wed, Oct 17, 2007 at 10:14:56PM -0400, beth kon wrote:
This is certainly a nit, but I might change parseCpuNumber to parseNumber, since it looks a little odd that you are getting the cell id from the cpu number. A nit to be sure!
well, the only problem is if you have more cells than maxcpu, which doesn't make that much sense. Since we are testing against maxcpu I really think we should keep the function name, I can duplicate code and make a simpler function just for parsing the cell no.
Other than our discussion on #virt about handling of ^N specifications in parseCpuSet, looks good!
Which is done in my version, will propagate.
New version with the changes suggested. Also the dump exercize the serialization code ifor CPUset (see the new <dump> elements which won't be used in the final code but useful to check correctness of output) Valgrind tst allowed me to found a bug in virBufferContentAndFree() Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Thu, 11 Oct 2007 09:00:14 -0400 Daniel Veillard wrote:
There are a few things I gathered on this issue. This affects NUMA setups, where basically if a domain must be placed on a given cell it is not good to let the hypervisor place it first with its own heuristics and then later migrate it to a different set of CPU, but better to instruct the hypervisor to start said domain on the given set.
That sounds good to me !
- For Xen it is possible to instruct the hypervisor by passing (cpus '2,3') in the SExpr where the argument is a list of the physical processors allowed
Yeah, we can set CPUs to the domain by passing that and the physical CPUs will be pinned to VCPUs.
- for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added).
How about adding <cpus>2,3</cpus> to the XML simply ? And we may set 64 CPUs, it is hard to set all of them by each number. (i.e. we have to set cpuset='1,2,3,4,5,6,7,8,9,10,....,64') So I hope to use - (range) and ^ (negation) to set cpuset as Ryan said. Regards, Saori Fukuta
On Fri, Oct 12, 2007 at 05:02:11PM +0900, Saori Fukuta wrote:
On Thu, 11 Oct 2007 09:00:14 -0400 Daniel Veillard wrote:
- for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added).
How about adding <cpus>2,3</cpus> to the XML simply ?
it's not any simpler. It's more complex because it adds a new element node in the XML. Moreover I don't expect taht information to be any more structured so it does not make sense to me to expose it as element content, plus <cpus> could be used in the future to describe fully structured informations so I don't think it makes sense to use it for just the cpuset.
And we may set 64 CPUs, it is hard to set all of them by each number. (i.e. we have to set cpuset='1,2,3,4,5,6,7,8,9,10,....,64') So I hope to use - (range) and ^ (negation) to set cpuset as Ryan said.
On input why not. Do you have a complete description of the syntax you want to allow ? Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Fri, 12 Oct 2007 05:12:13 -0400 Daniel Veillard wrote:
On Fri, Oct 12, 2007 at 05:02:11PM +0900, Saori Fukuta wrote:
On Thu, 11 Oct 2007 09:00:14 -0400 Daniel Veillard wrote:
- for the mapping at the XML level I suggest to use a simple extension to the <vcpu>n</vcpu> and extend it to <vcpu cpuset='2,3'>n</vcpu> with a limited syntax which is just the comma separated list of allowed CPU numbers (if the code actually detects such a cpuset is in effect i.e. in general this won't be added).
How about adding <cpus>2,3</cpus> to the XML simply ?
it's not any simpler. It's more complex because it adds a new element node in the XML. Moreover I don't expect taht information to be any more structured so it does not make sense to me to expose it as element content, plus <cpus> could be used in the future to describe fully structured informations so I don't think it makes sense to use it for just the cpuset.
Thanks for the explanation, I quoted the Xen-configuration (like cpus = ""). And that make sense to me !
And we may set 64 CPUs, it is hard to set all of them by each number. (i.e. we have to set cpuset='1,2,3,4,5,6,7,8,9,10,....,64') So I hope to use - (range) and ^ (negation) to set cpuset as Ryan said.
On input why not. Do you have a complete description of the syntax you want to allow ?
Yeah, I was thinking about input. For output, your suggestion sounds good. For input, I want to allow the following description of syntax. (e.g.) input : output 0 : 0 0-5 : 0,1,2,3,4,5 0-5,^1 : 0,2,3,4,5 0-3,5,^1 : 0,2,3,5 Regards, Saori Fukuta
On Fri, Oct 12, 2007 at 05:02:11PM +0900, Saori Fukuta wrote:
How about adding <cpus>2,3</cpus> to the XML simply ?
Just because the backends don't support strict binding of VCPUs to particular CPUs I really don't think this should be encoded in the XML. A strict binding is often the only sensible way to set things up. regards john
participants (6)
-
beth kon -
Daniel P. Berrange -
Daniel Veillard -
John Levon -
Ryan Harper -
Saori Fukuta