Re: [Xen-API] Xen Management API draft - portability

[Hollis Blanchard <hollisb@xxxxxxxxxx>]

On Sun, 2006-06-25 at 10:48 +0100, Ewan Mellor wrote:
> On Thu, Jun 22, 2006 at 01:34:12PM -0500, Hollis Blanchard wrote:
> 
> > On Thu, 2006-06-22 at 18:01 +0100, Ewan Mellor wrote:
> > > Attached is a draft Xen Management API.  This document presents our ideas 
> > > in
> > > terms of a data model, with an implied binding to XML-RPC calls.  There 
> > > are a
> > > few examples in there too -- hopefully it's clear how the mapping between 
> > > the
> > > document and the wire protocol.
> > 
> > Hi, I'm concerned about some of the x86 assumptions in this document. In
> > particular:
> > 
> > enum bios_boot_option:
> >     Is this relevant outside of HVM? Perhaps both those "bios" fields in
> > class VM could be replaced with a "boot device" string? Many non-x86
> > systems specify boot devices with free text; they are not limited by
> > legacy x86 BIOS. I believe that's even true for Intel's EFI.
> 
> IIRC, people have spoke in the past about using a "BIOS" even with paravirt
> guests, as opposed to using pygrub for example, so I think that this is
> potentially relevant outside of HVM.

Sorry, this still isn't clear to me.

> I wouldn't have a problem with making
> these free-form strings instead, or providing a different field, if you think
> you need extra flexibility.

I think a free-form string would be best.

> > enum cpu_feature:
> >     Very concerned about this one. How is this supposed to be used? If
> > higher-level code uses constants like "PAE", that software will need
> > modification for every non-x86 architecture, and I think that should be
> > an anti-goal. What makes sense to me is if Xen passes up an *opaque*
> > bitmask specifying required features (hcall: "what features does domain
> > 7 require?"), and that bitmask could be passed back down to Xen e.g.
> > when migrating a VM (hcall: "do you support these features?").
> >     I see that IA64 has its own "feature" bit. When thinking about managing
> > a heterogeneous cluster of Xen systems, it would probably make more
> > sense to have an "architecture" field in class VM. Then we could add a
> > "compatible architectures" field to class host_cpu, i.e. a list of
> > architectures that CPU can support. For an x86-64 CPU, that would be
> > "x86, x86-64". That way, when looking for a system on which to start an
> > x86 VM, the user could be presented with a list of all x86 and x86-64
> > systems being managed.
> >     Each architecture needs its own "optional feature" values, but there's
> > no sense in putting them all into the same namespace. For example,
> > PowerPC would have an FPU bit, but also Altivec, and of course almost
> > none of the x86 bits listed would be relevant for us, so it's a waste of
> > bits. I'm sure IA64 has the same situation.
> >     Of course, there are already a lot of bits in this list; it's
> > conceivable we could run out of bits in an int/long/whatever in the
> > future. Would it be better to communicate required features as strings
> > instead of an enum? Or am I misunderstanding, and the "enums" in this
> > document do not mean the same as "enum" in C, instead meaning "list of
> > acceptable string values"?
> 
> The constants in cpu_feature are taken from Linux's
> include/asm-i386/cpufeature.h. It's obviously x86-specific at the moment, and
> if that's a problem, then we can work on it.
> 
> If there are fields that only make sense on x86, I don't have a problem with
> that -- they can just be ignored on other, more sensible, platforms, as long
> as we've got the capacity to manage x86's idiosyncrasies.  On the other hand,
> if the problem needs to be solved on other arches too, then we should put
> together a platform-agnostic API.
>
> I can see the appeal of using opaque bitstrings, but I'm worried that these
> will be unmanagable by non-specialist users.  We can't very well say to people
> "look up the CPU features for your particular platforms, AND them together,
> and then type the resultant bitmask here".

(I don't understand your bitmask example...)

I didn't realize these features will be exposed in the user interface at
all. How do you expect that to work? (I explained the only scenario that
I could see: "I created a domain here, and now I want to know if I can
move it over there.")

Also, do you expect non-specialist users to manage terms like "CX8",
"PSE36", ...?

> We need to be able to provide a
> meaningful mapping at the API level, which is why it would be nice to use an
> enum. Perhaps a list of strings would be the best compromise -- we could
> define the strings that make sense on any particular platform, and the API
> would remain flexible for the future.

OK.

Now how about my other questions?
- Do you expect higher-level software to hardcode a list of these
features for the UI? That's a problem both for portability and for
future x86 architectures (with currently undefined feature bits). How
can we avoid that?
- Is an "enum" here a list of strings? If not, there is danger of
running out of bit numbers in a fixed-size bitmask. It's worth pointing
out that you've already listed 63 enum items.
- Do you agree that it makes sense to add "architecture" and "compatible
architectures" fields to class VM and host_cpu, respectively?

-- 
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api