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

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Mon, Jun 26, 2006 at 05:02:40PM -0500, Hollis Blanchard wrote:

> On Mon, 2006-06-26 at 20:28 +0100, Ewan Mellor wrote:
> > On Mon, Jun 26, 2006 at 01:31:24PM -0500, Hollis Blanchard wrote:
> > 
> > > [Snip: Re: CPU feature flags]
> > >
> > > 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.")
> > 
> > The other use case is "Please don't expose these features to my VM, because 
> > I
> > will need to be able to move it over there later".
> 
> That would be pretty easy with opaque types if the later host exists as
> part of the managed cluster already: at creation time, you could
> indicate the set of hosts you will ever want to run the domain on.
> 
> If you want to specify hypothetical hosts though, I guess you'd want
> some sort of checkbox system, i.e. "Pick the following CPU types you
> want to be able to run this domain on." The UI would translate e.g. "AMD
> Elan SC520" into a particular set of feature bits.

Yes, that latter case is the one that I had in mind.

> > > - 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.
> > 
> > On the wire, a particular value of an enum is a string, yes.
> 
> So we're clear: do you mean "0x1234" will be the string "on the wire",
> or do you mean "CX8,PSE36,FPU"?

The latter.

> Actually, that may not matter (assuming the protocol can handle
> arbitrarily-sized integers). I just checked, and it looks like there is
> a lot of room for capability bits (I'm looking at DOM0_PHYSINFO and
> __HYPERVISOR_xen_version [the distinction there is not obvious to me]).
> However, I still don't think it makes sense to include bits from all
> possible architectures in the same namespace, but rather reuse bit
> positions for each architecture. In other words, capability bit 0 on x86
> could mean something different from capability bit 0 on ia64.

Would you be happier if we named the constants "X86_FPU" etc, leaving room for
"PPC_xyz", etc?

> > > - Do you agree that it makes sense to add "architecture" and "compatible
> > > architectures" fields to class VM and host_cpu, respectively?
> > 
> > I certainly agree that we need to handle non-x86 platforms, but I'm not sure
> > what that entails.
> > 
> > I don't have a problem adding "architecture" to VM, that sounds like 
> > something
> > you'd want to know anyway.  Does having "compatible architectures" on the
> > Host_cpu class make sense, as opposed to having it on Host?  Do we want to
> > model a machine with different CPU architectures?
> 
> Ah, I'd missed Host. Yes, it makes more sense there than on Host_cpu.
> 
> > If we fix these things, are these fields sufficient for PPC support?
> 
> I don't want to officially sign off on anything, but I think so. :) I'd
> particularly like to see higher-level software using this API. (I think
> in general it's hard to get an API right without seeing a couple users
> first.)

Certainly, we'd love to get people trying out this API before we declare
"Version 1.0".  We could discuss how we might go about that on the call today.

Ewan.

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