WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-api

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

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