Mailing List Archive

On Mon, Jun 26, 2006 at 04:12:39PM +0100, Ewan Mellor wrote:
> On Sun, Jun 25, 2006 at 04:49:03PM +0100, Daniel P. Berrange wrote:
> > * What is the motivation for implementing an explicit login_with_password
> > method rather than utilizing the existing HTTP authentication protocols ?
>
> We discussed this on xen-devel last week -- HTTP auth doesn't seem to be
> widely supported, so we didn't want to rely upon it. Also, this way we can
> use the XML-RPC over something other than HTTP (such as a raw unix domain
> socket).
>
> > The proposed login API utilizing a simple username/password pair is quite
> > limiting, preventing the use of any of the more advanced authentication
> > protocols such as challenge/response, public / private key, kerberos
> > ticket passing.
> >
> > The latter would be particuarly important if the apps using this API want
> > to integrate with any kind of single sign on system. Perhaps it would be
> > possible to define a more advanced login process which could be backed by
> > something like SASL
> >
> > http://www.ietf.org/rfc/rfc2222.txt
> > http://asg.web.cmu.edu/sasl/
>
> What would be involved in making this work? The username / password is
> already a step up for Xen -- how complicated is SASL or similar?

I'm not familiar enough with it to give any estimates on work involved, but
it would definitely be more complex than user/password, however, this is to
be expected given the much broader capabilities. There's fairly comprehensive
docs in the Cyrus SASL source distribution, for example,

http://www.indelible.org/php/sasl/cyrus-sasl/programming.html

Another possibility would be to integrate with PAM, fully supporting the
conversation function callbacks

Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

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

On Fri, Jun 23, 2006 at 09:36:33AM -0400, Mike D. Day wrote:

> 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.
>
> Ewan, I like the API a lot. The storage repository class needs some
> additional thought. It really requires some dbms-like attributes. I will
> try to get some more specific feedback on the storage repository class
> to you in a different note.
>
> here is some cursory feedback:
>
> 1.4.1 transport layer
>
> We should also support bare xml which would enable file redirection
> (stdin and stdout) and the use of ssh.

Sure, OK.

> 1.4.2
>
> session -
>
> We should allow optional delegation of authentication to the transport
> layer. For example, use ssh public key authentication instead of a
> userid/password login.

So what does that entail? You configure your server to allow you to have a
null session object if the connection is received through a UDP socket, or
something like that?

> 1.6 (to do)
>
> Authorization schema that maps uids to operations on objects.

Of course, Xend has no concept of fine-grained access control at all at the
moment. That could be quite a lot of work.

> notification - need a notification class and a notification listener
> on the client.

Yes, I think we do (Daniel Berrange raised the same point).

> 2.6.1 VM class
>
>
> Need an addition field "profile" that allows the user to classify VMs
> for particular purposes. For example, "web server," "sendmail switch,"
> "dbms host," "devel workstation," etc.
>
> This should be a list attribute. Might be good to supply some
> enumerated values but also allow values that are not enumerated.

What would you do with this "profile"?

> Clone method needs to have a customization parameter. Simply cloning a
> VM is not sufficient - the clone at minimum needs a different host
> name, network configuration, and changes to various config files.
>
> One way to customize a cloned image is to patch the
> filesystem. Another is to replace specific files with new versions
> (usually works best for binary files).

Is this something we need to specify at the API level? Obviously we can
specify that it gets renamed and gets new MAC addresses, but stooging into the
filesystem sounds quite complex. How would we specify these operations?

> VM needs a migrate method:
>
> Bool migrate(session id s, vm ref vm, host ref current, host ref
> destination, Bool test)

D'oh! We probably want a migrate command in there ;-)

> 2.8 Host class
>
> Host needs additional attributes that will allow automated
> determination that a given host is capable of hosting a given VM.
>
> For example, a VM may need specific host characteristics beyond CPU: a
> minimum amount of memory, TPM, network bandwidth, and so on.

Do you think that we can fill out the "and so on"? It would be good to get
something like an exhaustive list here, I guess.

> If the host class has these attributes we can create an addition
> method that automatically determines if a host can host a particular
> vm.
>
> Bool qualify(session id s, vm ref vm, host ref host)
>
>
> 2.9 Class Network
>
> Network needs additional attributes that provide media
> characteristics of the NIC.
>
> RO bandwidth integer Bandwidth in mbps
>
> RO latency integer time in ms for an icmp roundtrip to a host on the
> same subnet.

Do you mean that the node should be continually measuring these things, or
that they get measured at startup, or what? Isn't measuring bandwidth quite
expensive?

Ewan.

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

On Sun, Jun 25, 2006 at 04:49:03PM +0100, Daniel P. Berrange wrote:

> Finally, a higher level question - the API is still basically unidirectional,
> poll based model. By this I mean, if I want to detect changes in a guest VMs
> lifecycle state (eg, from running -> paused), then I have no choice but to
> poll the 'power_state' field on every VM i'm interested in. If the app using
> the API is a GUI app, then this polling is going to have to be done pretty
> frequently (once per second or more) to provide an acceptable refresh in the
> UI. I'm concerned that polling so frequently over an HTTP / XML-RPC protocol
> is going to impose a very significant performance hit on the host machine.
> It would be very desriable if there was a formal API for getting asynchronous
> callbacks notifying the client of changes in a VM's lifecycle state. I know
> this is not really possible with XML-RPC, but I wanted to bring it up as a
> use-case none-the-less in case there are alternate ways to provide such a
> capability.
>
> The same issue is true of the proposed mechanism for asynchronous invocation
> invocation of APIs - it also requires the client to make requests polling
> for completion of the API which is not really buying any performance benefit.
> Unless the client actually wanted the 'estimated time of completion' data,
> they might as well just send a regular synchronous request & use select()
> or poll() system calls on the HTTP socket to do a non-blocking wait for
> completion client side.

Here's a thought -- how about we provide a call with the semantics of "please
give me the next event", which blocks at the server until an event becomes
available. The client would call the server with registration for events, and
then make this synchronous call in another thread or in a select() loop, which
would block until an event arrives. If the connection gets broken without an
event, just reconnect and block again.

Would this work?

Ewan.

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

On Mon, Jun 26, 2006 at 04:54:33PM +0100, Ewan Mellor wrote:
> On Sun, Jun 25, 2006 at 04:49:03PM +0100, Daniel P. Berrange wrote:
>
> > Finally, a higher level question - the API is still basically unidirectional,
> > poll based model. By this I mean, if I want to detect changes in a guest VMs
> > lifecycle state (eg, from running -> paused), then I have no choice but to
> > poll the 'power_state' field on every VM i'm interested in. If the app using
> > the API is a GUI app, then this polling is going to have to be done pretty
> > frequently (once per second or more) to provide an acceptable refresh in the
> > UI. I'm concerned that polling so frequently over an HTTP / XML-RPC protocol
> > is going to impose a very significant performance hit on the host machine.
> > It would be very desriable if there was a formal API for getting asynchronous
> > callbacks notifying the client of changes in a VM's lifecycle state. I know
> > this is not really possible with XML-RPC, but I wanted to bring it up as a
> > use-case none-the-less in case there are alternate ways to provide such a
> > capability.
> >
> > The same issue is true of the proposed mechanism for asynchronous invocation
> > invocation of APIs - it also requires the client to make requests polling
> > for completion of the API which is not really buying any performance benefit.
> > Unless the client actually wanted the 'estimated time of completion' data,
> > they might as well just send a regular synchronous request & use select()
> > or poll() system calls on the HTTP socket to do a non-blocking wait for
> > completion client side.
>
> Here's a thought -- how about we provide a call with the semantics of "please
> give me the next event", which blocks at the server until an event becomes
> available. The client would call the server with registration for events, and
> then make this synchronous call in another thread or in a select() loop, which
> would block until an event arrives. If the connection gets broken without an
> event, just reconnect and block again.
>
> Would this work?

That's an interesting idea, avoiding polling since the client can just watch
the socket in a select() / poll() call. It would obviously require keeping
a 2nd connection open to the hypervisor, however, that's not too onerous so
it's certainly a plausible solution even if it is a bit of a nasty hack.

Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

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

On Mon, Jun 26, 2006 at 04:46:43PM +0100, Ewan Mellor wrote:
> On Fri, Jun 23, 2006 at 09:36:33AM -0400, Mike D. Day wrote:
>
> > 2.6.1 VM class
> >
> >
> > Need an addition field "profile" that allows the user to classify VMs
> > for particular purposes. For example, "web server," "sendmail switch,"
> > "dbms host," "devel workstation," etc.
> >
> > This should be a list attribute. Might be good to supply some
> > enumerated values but also allow values that are not enumerated.
>
> What would you do with this "profile"?

This sounds like its getting into area of arbitrary metadata - rather
than denoting a bunch of explicit metadata fields, it might be useful
to consider a general purpose metadata field - for example a string
containing an XML doc following Dublin Core metadata schema, which would
allow either the administrator, or management tools to define these kind
of tags &/ categorization as required

> > VM needs a migrate method:
> >
> > Bool migrate(session id s, vm ref vm, host ref current, host ref
> > destination, Bool test)
>
> D'oh! We probably want a migrate command in there ;-)

How would authentication operate - the destination host must have some
kind of authentication process before accepting migration of a VM from
another host. So would this API assume that authentication credentials
have been previoously set up behind the scenes ? If not then the migrate
API would need some way to request / receive authenitcation credentials.

Regards,
Dan.
--
|=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=|
|=- Perl modules: http://search.cpan.org/~danberr/ -=|
|=- Projects: http://freshmeat.net/~danielpb/ -=|
|=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|

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

On Mon, Jun 26, 2006 at 06:36:22PM +0100, Daniel P. Berrange wrote:

> > > VM needs a migrate method:
> > >
> > > Bool migrate(session id s, vm ref vm, host ref current, host ref
> > > destination, Bool test)
> >
> > D'oh! We probably want a migrate command in there ;-)
>
> How would authentication operate - the destination host must have some
> kind of authentication process before accepting migration of a VM from
> another host. So would this API assume that authentication credentials
> have been previoously set up behind the scenes ? If not then the migrate
> API would need some way to request / receive authenitcation credentials.

How about this?

/**
* @returns authToken
*/
String vm_migrate_authorise(String session, String uuid)

void vm_migrate(String session, String uuid, String destination,
String authToken)

So you log in to the destination and source as normal, and then issue a
"migrate_authorise" to the destination, receive a token which the destination
has generated randomly, give that to the source, and then the source passes
that authToken to the destination as part of the handshake on the migration
channel (the connection that the actual memory contents go down).

Does that sound OK? This restricts the authentication exchange to the login
messages (however we want to do that) and then relies upon session tokens from
then on.

Ewan.

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

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

Daniel P. Berrange wrote:
> On Mon, Jun 26, 2006 at 04:12:39PM +0100, Ewan Mellor wrote:
>
>> On Sun, Jun 25, 2006 at 04:49:03PM +0100, Daniel P. Berrange wrote:
>>
>>> * What is the motivation for implementing an explicit login_with_password
>>> method rather than utilizing the existing HTTP authentication protocols ?
>>>
>> We discussed this on xen-devel last week -- HTTP auth doesn't seem to be
>> widely supported, so we didn't want to rely upon it. Also, this way we can
>> use the XML-RPC over something other than HTTP (such as a raw unix domain
>> socket).
>>

Nothing about our XML-RPC interfaces is widely supported. We're talking
about requiring per-call wrappers because of implicit typing? We're
talking about lots of code in the bindings. A little more isn't going
to hurt.

>> What would be involved in making this work? The username / password is
>> already a step up for Xen -- how complicated is SASL or similar?
>>
>
> I'm not familiar enough with it to give any estimates on work involved, but
> it would definitely be more complex than user/password, however, this is to
> be expected given the much broader capabilities. There's fairly comprehensive
> docs in the Cyrus SASL source distribution, for example,
>

I can speak from experience dealing with SASL. It's quite a nightmare
to get right. What complicates matters is the fact that the two
difference kerberos libraries out there provide differing interfaces and
I believe it is still the case that SuSE/RedHat ship different kerberoses.

XML-RPC over SSH would solve this general problem as PAM integrates
quite nicely with any existing single sign-on.

BTW: I'm just getting to this mail from last week so I'll be responding
a bit out of order. Sorry.

Regards,

Anthony Liguori

> http://www.indelible.org/php/sasl/cyrus-sasl/programming.html
>
> Another possibility would be to integrate with PAM, fully supporting the
> conversation function callbacks
>
> Regards,
> Dan.
>


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

Ewan Mellor wrote:
> On Sun, Jun 25, 2006 at 04:49:03PM +0100, Daniel P. Berrange wrote:
>
>
>> The same issue is true of the proposed mechanism for asynchronous invocation
>> invocation of APIs - it also requires the client to make requests polling
>> for completion of the API which is not really buying any performance benefit.
>> Unless the client actually wanted the 'estimated time of completion' data,
>> they might as well just send a regular synchronous request & use select()
>> or poll() system calls on the HTTP socket to do a non-blocking wait for
>> completion client side.
>>
>
> Here's a thought -- how about we provide a call with the semantics of "please
> give me the next event", which blocks at the server until an event becomes
> available. The client would call the server with registration for events, and
> then make this synchronous call in another thread or in a select() loop, which
> would block until an event arrives. If the connection gets broken without an
> event, just reconnect and block again.
>
> Would this work?
>

I've got code that does this (for a different project). As long as your
XML-RPC server is threaded, you can block the call however long you
want. It's a little tricky not leaking threads when you block (if you
block merely on a condition, if the client closes the connection you'll
potentially block indefinitely).

I've been told that proxies are a real PITA with these sort of tricks
though. Many enforce very support keep-alive timeouts. Certainly is
better than nothing though.

Regards,

Anthony Liguori

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


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

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".

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

That's a good question, but one I hope to solve at the UI, not the API. Maybe
your cluster manager knows what machines you have in your hetrogenous cluster,
and so can manage these flags for you?

> - 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?

I expect us to define a set of strings that are known and understood to have
particular semantics, so that higher level software can manage them. I don't
think that we can manage these flags correctly otherwise. I don't see this as
a problem for portability -- I hope to be able to define the appropriate
strings for PPC as well as for x86. For flags that we don't yet know about,
for platforms that we're not working with at the moment, say, or new flags on
existing platforms, we would add these to the set of known strings. New
clients would be fine -- old clients would have to say to the user "I've no
idea what this value 'PSE79' is, should I leave it alone?" (or the client
software could just leave it alone silently).

> - 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.

> - 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?

If we fix these things, are these fields sufficient for PPC support?

Cheers,

Ewan.

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

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.

> > Also, do you expect non-specialist users to manage terms like "CX8",
> > "PSE36", ...?
>
> That's a good question, but one I hope to solve at the UI, not the API. Maybe
> your cluster manager knows what machines you have in your hetrogenous cluster,
> and so can manage these flags for you?
>
> > - 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?
>
> I expect us to define a set of strings that are known and understood to have
> particular semantics, so that higher level software can manage them. I don't
> think that we can manage these flags correctly otherwise. I don't see this as
> a problem for portability -- I hope to be able to define the appropriate
> strings for PPC as well as for x86. For flags that we don't yet know about,
> for platforms that we're not working with at the moment, say, or new flags on
> existing platforms, we would add these to the set of known strings. New
> clients would be fine -- old clients would have to say to the user "I've no
> idea what this value 'PSE79' is, should I leave it alone?" (or the client
> software could just leave it alone silently).

My concern is that the API users (i.e. the management software) will
need to know intimate details about processors, and I don't trust them
to think about portability. :) I'd prefer to have an API that you simply
can't misuse.

> > - 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"?

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.

> > - 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.)

--
Hollis Blanchard
IBM Linux Technology Center


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

Ewan Mellor wrote:

> Here's a thought -- how about we provide a call with the semantics of "please
> give me the next event", which blocks at the server until an event becomes
> available. The client would call the server with registration for events, and
> then make this synchronous call in another thread or in a select() loop, which
> would block until an event arrives. If the connection gets broken without an
> event, just reconnect and block again.

Yes, this would work. The advantage of a blocking poll is simplicity.
And we could use this method for all asynchronous methods.

I still believe we need an asynchronous notification. The blocking poll
is pretty heavy. If you imagine a management application that is
monitoring one hundred machines, it would need to have 100 sessions
blocked on the event method.

Mike

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

Ewan Mellor wrote:
> On Mon, Jun 26, 2006 at 06:36:22PM +0100, Daniel P. Berrange wrote:
>
>
>>>> VM needs a migrate method:
>>>>
>>>> Bool migrate(session id s, vm ref vm, host ref current, host ref
>>>> destination, Bool test)
>>>>
>>> D'oh! We probably want a migrate command in there ;-)
>>>
>> How would authentication operate - the destination host must have some
>> kind of authentication process before accepting migration of a VM from
>> another host. So would this API assume that authentication credentials
>> have been previoously set up behind the scenes ? If not then the migrate
>> API would need some way to request / receive authenitcation credentials.
>>
>
> How about this?
>
> /**
> * @returns authToken
> */
> String vm_migrate_authorise(String session, String uuid)
>
> void vm_migrate(String session, String uuid, String destination,
> String authToken)
>
> So you log in to the destination and source as normal, and then issue a
> "migrate_authorise" to the destination, receive a token which the destination
> has generated randomly, give that to the source, and then the source passes
> that authToken to the destination as part of the handshake on the migration
> channel (the connection that the actual memory contents go down).
>
> Does that sound OK? This restricts the authentication exchange to the login
> messages (however we want to do that) and then relies upon session tokens from
> then on.
>

It seems there should be a mechanism for ensuring the target host is
capable of hosting the VM as well. Does the target host have compatible
architecture, cpu flags (if that matters), hypervisor version, etc.? I
guess one could argue that clients should be responsible for ensuring
the target is acceptable prior to performing the migration, particularly
when one considers all of the things that could go wrong - e.g. some
disk on the SAN that the VM requires is not available at the target. At
a minimum though the implementation should handle migration failures
gracefully and not "lose" the VM, i.e. we start shoveling pages over to
the target host and for whatever reason we are unable to bring the thing
up there *and* it is no longer running on the source host.

Also, should we be concerned about migrating VMs across untrusted
networks? Should there be mechanisms to support encrypting the memory?

Regards,
Jim

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

Ewan Mellor wrote:
> On Sun, Jun 25, 2006 at 04:49:03PM +0100, Daniel P. Berrange wrote:
>
>
>> Finally, a higher level question - the API is still basically unidirectional,
>> poll based model. By this I mean, if I want to detect changes in a guest VMs
>> lifecycle state (eg, from running -> paused), then I have no choice but to
>> poll the 'power_state' field on every VM i'm interested in. If the app using
>> the API is a GUI app, then this polling is going to have to be done pretty
>> frequently (once per second or more) to provide an acceptable refresh in the
>> UI. I'm concerned that polling so frequently over an HTTP / XML-RPC protocol
>> is going to impose a very significant performance hit on the host machine.
>> It would be very desriable if there was a formal API for getting asynchronous
>> callbacks notifying the client of changes in a VM's lifecycle state. I know
>> this is not really possible with XML-RPC, but I wanted to bring it up as a
>> use-case none-the-less in case there are alternate ways to provide such a
>> capability.
>>
>> The same issue is true of the proposed mechanism for asynchronous invocation
>> invocation of APIs - it also requires the client to make requests polling
>> for completion of the API which is not really buying any performance benefit.
>> Unless the client actually wanted the 'estimated time of completion' data,
>> they might as well just send a regular synchronous request & use select()
>> or poll() system calls on the HTTP socket to do a non-blocking wait for
>> completion client side.
>>
>
> Here's a thought -- how about we provide a call with the semantics of "please
> give me the next event", which blocks at the server until an event becomes
> available. The client would call the server with registration for events, and
> then make this synchronous call in another thread or in a select() loop, which
> would block until an event arrives. If the connection gets broken without an
> event, just reconnect and block again.
>
> Would this work?
>

Don't think this would scale. Seems a little nasty with a few hundred
clients (with open connections / sessions) waiting on events.

Regards,
Jim

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

xen-api-bounces@lists.xensource.com wrote on 06/26/2006 07:09:02 PM:

> Ewan Mellor wrote:
> > On Mon, Jun 26, 2006 at 06:36:22PM +0100, Daniel P. Berrange wrote:
> >
> >
> >>>> VM needs a migrate method:
> >>>>
> >>>> Bool migrate(session id s, vm ref vm, host ref current, host ref
> >>>> destination, Bool test)
> >>>>
> >>> D'oh! We probably want a migrate command in there ;-)
> >>>
> >> How would authentication operate - the destination host must have
some
> >> kind of authentication process before accepting migration of a VM
from
> >> another host. So would this API assume that authentication
credentials
> >> have been previoously set up behind the scenes ? If not then the
migrate
> >> API would need some way to request / receive authenitcation
credentials.
> >>
> >
> > How about this?
> >
> > /**
> > * @returns authToken
> > */
> > String vm_migrate_authorise(String session, String uuid)
> >
> > void vm_migrate(String session, String uuid, String destination,
> > String authToken)
> >
> > So you log in to the destination and source as normal, and then issue
a
> > "migrate_authorise" to the destination, receive a token which the
> destination
> > has generated randomly, give that to the source, and then the source
passes
> > that authToken to the destination as part of the handshake on the
migration
> > channel (the connection that the actual memory contents go down).
> >
> > Does that sound OK? This restricts the authentication exchange tothe
login
> > messages (however we want to do that) and then relies upon session
> tokens from
> > then on.
> >
>
> It seems there should be a mechanism for ensuring the target host is
> capable of hosting the VM as well. Does the target host have compatible

> architecture, cpu flags (if that matters), hypervisor version, etc.? I
> guess one could argue that clients should be responsible for ensuring
> the target is acceptable prior to performing the migration, particularly

> when one considers all of the things that could go wrong - e.g. some
> disk on the SAN that the VM requires is not available at the target. At


The whole migration procedure should in the optimal case be 'atomic'. One
could allocate resources on the target system and lock the allocation to
ensure that no other system migrates a VM there that makes your system
perform worse on the target system than where it's being migrated from.

> a minimum though the implementation should handle migration failures
> gracefully and not "lose" the VM, i.e. we start shoveling pages over to
> the target host and for whatever reason we are unable to bring the thing

> up there *and* it is no longer running on the source host.

I think Xend actually handles that case already.

>
> Also, should we be concerned about migrating VMs across untrusted
> networks? Should there be mechanisms to support encrypting the memory?
>
It would certainly be interesting to have this as an option. You could use
the passed-around authentication token from your suggestion above to
establish a shared key between the source and destination system.

Stefan

> Regards,
> Jim
>
> _______________________________________________
> xen-api mailing list
> xen-api@lists.xensource.com
> http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

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@lists.xensource.com
http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-api

On Wed, Jun 28, 2006 at 11:36:39AM +0100, Ewan Mellor wrote:

> > > > - 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.

Just in case that wasn't clear, the actual on-the-wire format for a
cpu_feature Set would be

<array><data>
<value><string>CX8</string></value>
<value><string>PSE36</string></value>
<value><string>FPU</string></value>
</data></array>

Cheers,

Ewan.

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

[oops, resending to list]

On Wed, 2006-06-28 at 11:36 +0100, Ewan Mellor wrote:
>
> > 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?

I'm not sure. I was thinking in terms of C bit numbers, because we
hadn't clarified what we really meant by "enum". But now I know
better...

Thinking this through: so when the remote end (xend?) sees "FPU
required", it will need to translate that to a bit number and make an
hcall to query the hypervisor. It can perform that translation because
we're adding an "architecture" field to class VM. Sounds fine.

So no, we don't need to rename any of the bits.

--
Hollis Blanchard
IBM Linux Technology Center


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

On Mon, 2006-06-26 at 13:31 -0500, Hollis Blanchard wrote:
>
> > 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.

To clarify, I'd like to remove bios/* from class VM, and replace them
with a "boot device" string.

(Pretty much everywhere the word "BIOS" appears is a problem.)

--
Hollis Blanchard
IBM Linux Technology Center


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