[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

  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:


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?


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 redhat com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]