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.
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"?
Those are the first issues that stand out for me. In general I'd like to
remind everybody that computer networks are not homogeneous, so let's
not box ourselves into a corner in the future by designing an
x86-specific API today... :)
--
Hollis Blanchard
IBM Linux Technology Center
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api
|
Home