<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel P. Berrange a écrit :
<blockquote cite="mid20060804175517.GH23276@redhat.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">TODO: These vcpus functions permits to dynamically change the vcpu/cpu
relation after the domain has been started but nothing has been done
regarding static cpus attribution in the XML configuration file of a domain.
</pre>
</blockquote>
<pre wrap=""> Yes there is a few things left:
- as you said the impact on XML format (I'm not sure how much should be
extracted though)
</pre>
</blockquote>
<pre wrap=""><!---->
Whether we need the vcpu mapping in the XML really depends on whether its
useful to persist this stuff, or whether its something you can just define
at runtime as required. VCPU mappings really get into the realm of runtime
policy which I'm not convinced really wants/needs to be part of the basic
XML document data.
For example, when talking in terms of policy I don't think you'd directly
store info in terms of 'map vcpu-1 to host cpu 3'. Instead you'd probably
want to express it as 'give domain X a dedicated fixed CPU', or 'let domain
X share/float 3 cpus' with other domains. The policy/management app would then
decide which particular VCPU<->Host CPU mappings to implement when starting
up the domain. Such a decision would have to take into account existing VCPU
pinning from other domains already running.
So really IMHO we don't need to rush into adding VCPU mapping to the XML.
Better to wait and see if there are apps being created which explicitly
need this info persisted in the XML.
</pre>
</blockquote>
Yes, I'm agree. It's better to wait and see the next Xen release with
NUMA support and the new "Credit" scheduler because the cpu mapping
policy depend narrowly on these features.<br>
<br>
</body>
</html>