I do not want to be offensive to current XCP developers, but right now I
see few really important problems:
1) Some parts of XCP is still closed source (HA, WLB) and XCP heavy
depends on them. Most worst is that WLB from Citrix created for windows
and depends on MSSQL (I think, we shall not expect Microsoft to publish
MSSQL source code under GPL within next 5 months).
2) Ocaml. May be cool academic language, but I think, there is a very
few ocaml programmers and intersection of sets of ocaml programmers and
xen specialists tends to single numbers.
3) Not very cute internal architecture of xapi. Database are kept in
plaintext format (just ocaml serialisation), intensive cross-syncing
(lot of empty pool updates via XenAPI notification system), not very
cute architecture (master and slave, all slaves are kept database, but
only master will reply to requests).
4) Lack of full access to domain internals (XS, XC interfaces). Domains
have pool-wide options and 'local' options (from xc point of view). We
have no method to set up some XS values to keep them between migration.
5) Scrapyard within other-config field (it contains some critical for VM
values to run (install-repository), but it all joined in some kind of
blob "dig it out yourself").
6) Very delicate and troublefull xapi toolstack build process.
7) Lack of 'change startup config while VM running' (i'm about values,
which one have meaning while vm is starting: VCPUs-at-startup,
memory-static-*, etc - you can change them only while VM is offline;
more reasonably implementation must allow to change those values while
VM is online, but accept them to work at reboot/shutdown/start).
8) Heavy limitation on pool size (I still not test it myself, but I
hear, limitation is 16 hosts per pool - that is not good for normal
cloud with many hosts).
9) Unavailability for using external kernels for PV.
10) Heavy depends on guest tools.
Last four is problem of XCP, not xapi, but firsts are problems of xapi.
One more problem is XenAPI by itself: one connection per one operation
is TOO heavy to use as fast basis for future development. (I think, it
needs for some kind of interaction without connectivity lost after each
command).
(But I personally think, ocaml is main difficulty for community
development - threshold of entry is too high for most intersted in
development).
(F.e. I glad to write few more classes for vm_metrics - I know C and
Python, but I can not even read ocaml code).
В Чтв, 26/08/2010 в 14:17 -0700, yueyu.lin пишет:
> Thanks a lot. It helps me a lot.
> Yes indeed, we need to make the documentations better to attract more
> developers to develop platforms and applications based on Xen-Cloud.
>
>
> Actually I'm a little bit curious how the host side implemented, in
> user space or kernel space, although it's beyond my current
> understanding over Xen and XCP
>
> On Aug 26, 2010, at 05:06 AM, Rob Hoes <Rob.Hoes@xxxxxxxxxx> wrote:
>
>
> > Hi Yueyu,
> >
> > There is a PDF document containing more details of the XML-RPC
> > protocol. Unfortunately I cannot find an XCP-specific version
> > online, but it is more or less the same as the XenServer API
> > reference, which you can find at
> >
http://support.citrix.com/servlet/KbServlet/download/23833-102-646000/xenenterpriseapi.pdf. See Chapter 1 for the details of how to use the XML-RPC protocol.
> >
> > Then, you can use
http://www.xenorg/files/XenCloud/ocamldoc/ as a
> > reference for the API's classes, calls etc. This is totally
> > independent of any programming language.
> >
> > We should probably integrate the information of Chapter 1 of the PDF
> > in the HTML docs, and also put the PDF online...
> >
> > Regards,
> > Rob
> >
> > -----Original Message-----
> > From: xen-api-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:xen-api-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of George
> > Shuklin
> > Sent: 26 August 2010 12:57
> > To: xen-api@xxxxxxxxxxxxxxxxxxx
> > Subject: Re: [Xen-API] Xen-API: XMLRPC Documentation
> >
> > Yes, you can ignore ocaml existence in first iteration (see below)
> > and
> > use (for example) python with XenAPI.py interface. Main difference
> > in
> > xapi and xend implementation of XenAPI is pool-related classed (xend
> > have no conception of pool).
> >
> > About ocaml.. In first XenAPI is language-neutral interface, but
> > xapi
> > implementation is poor: they store some values in ocaml format (f.e.
> > last_boot_record for vm). But management part and main data are
> > available for use without ocaml concern
> >
> > Documentation published on
xen.org site:
> >
http://www.xen.org/files/XenCloud/ocamldoc/
> >
> > Yes, this is only reference. No guideline or tutorial available.
> >
> > В Чтв, 26/08/2010 в 04:29 -0700, Yueyu Lin пишет:
> > > Hi, all
> > > I have done some research over the interfaces of Xen(XCP). I found
> > this page to introduce the history of API:
> >
http://wiki.xensource.com/xenwiki/API_History
> > > If I understand correctly, both xend and xapi have implemented the
> > server side(host side) service. The client side(management tools)
> > just sends the XML-RPC requests to either xend or xapi.
> > > My question is : I can only find xapi documentation describes the
> > API in Ocaml way. I have no clue how to compose the XML-RPC and get
> > the response. If my understanding is correct, I don't
> > > need to learn ocaml to use xapi since I only need to send XML-RPC
> > requests to host that means I can use every language I like.
> > > I think if the xend and xapi need to implement the service, they
> > should have the XML-RPC documentation first. Can someone point me
> > the location of the whole XML-RPC documentation so that
> > > I can write my own client program to access and manage the XCP
> > hosts.
> > > Thanks a lot!
> > >
> > > _______________________________________________
> > > xen-api mailing list
> > > xen-api@xxxxxxxxxxxxxxxxxx
> > >
http://lists.xensource.com/mailman/listinfo/xen-api
> >
> >
> >
> > _______________________________________________
> > xen-api mailing list
> > xen-api@xxxxxxxxxxxxxxxxxxx
> >
http://lists.xensource.com/mailman/listinfo/xen-api
> >
> > _______________________________________________
> > xen-api mailing list
> > xen-api@xxxxxxxxxxxxxxxxxxx
> >
http://lists.xensource.com/mailman/listinfo/xen-api
> >
_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api
Home