Re: [libvirt] [PATCH 12/12] food for thought
On 09/29/2010 06:09 PM, Eric Blake wrote:
Here's where I ran out of time for the day. I'm much less
familiar
with xen than with qemu, so I have no idea how to tell if xen's
documented domain/vcpu_avail (which is what we want for current vcpus)
is usable in contrast to domain/vcpus (the maximum amount). For that
matter, I'm not even sure if modifying the Sxpr parsing/generating
code is enough to make xen use the new attribute, or what else might
be involved. Hints on what I need to do from here are greatly
appreciated.
---
src/xen/xend_internal.c | 6 ++++++
src/xen/xm_internal.c | 6 ++++++
src/xenapi/xenapi_utils.c | 2 +-
3 files changed, 13 insertions(+), 1 deletions(-)
Xen is more complex than I first thought.
I'm debating whether to support xendConfigVersion <= 2 (xm_internal.h)
or just xendConfigVersion >= 3 (xend_internal.h).
Additional things I've discovered:
http://lists.xensource.com/archives/html/xen-devel/2009-11/msg01061.html
documents that the config file (xm_internal.h) has two parameters, vcpus
is the max, and vcpu_avail is a bitmask of which vcpus to enable at
boot. I'm assuming that xen cannot support more than 32 vcpus?
http://www.cl.cam.ac.uk/research/srg/netos/xen/readmes/interface/interfac...
documents that each /domain sexpr contains vcpus (maximum), online_vcpus
(current), and vcpu_avail (bitmask of online vcpus).
The xm vcpu-set command can only change the current vcpus of a running
domain, so I'm not sure how that interacts with persistent storage. I
can't figure out whether I have to modify xm_internal.h to set the
vcpu_avail bitmask to get this to happen, or whether changing the
/domain sexpr also affects the persistent configuration.
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library http://libvirt.org