Hi,
We are pleased to announce the open-sourcing of the ''xapi''
toolstack
-- as used in the Citrix XenServer product line. The xapi toolstack is
licensed under the LGPL v2.1 with a special static linking exception. The
toolstack:
* manages the lifecycle of VMs (installing from templates, running,
suspending, migrating, creating snapshots and checkpoints and import/export)
* binds hosts together into single "Resource Pools"
* interfaces with heterogeneous storage services through a plugin mechanism
* manages host and VM networking, including bonding and VLANs
* records multi-resolution persistent performance statistics
* generates alerts when performance thresholds are crossed or multipathed
storage degrades
* authenticates users through either PAM or Active Directory
* supports Role-based access control
* actively manages VM memory allocations through ballooning
* supports host software upgrade without VM downtime
("rolling-upgrade")
* plans for host failure, performs admission control and automatic VM
restart
* exposes the XenAPI over HTTP/S
* provides secure tunnelling for VM console traffic
* includes a Java applet for viewing consoles and a Javascript XenAPI
client demo
* supports a simple plugin mechanism for extension
* when used with the open-source CIM provider
[http://community.citrix.com/display/xs/Kensho]
provides a full DMTF CIM API with OVF support
The released code is the current development version ("trunk") and is
under
active development. The repositories are here:
http://xenbits.xen.org/xapi/xen-dist-ocaml.hg
-- scripts and Makefiles to build some external library dependencies
http://xenbits.xen.org/xapi/xen-api-libs.hg
-- internal libraries (e.g. for talking to xenstore)
http://xenbits.xen.org/xapi/xen-api.hg
-- the toolstack itself
The easiest way to build the code is in a specially-prepared VM,
instructions are here:
http://xenbits.xen.org/xapi/install.html
>From now on, all development will take place on the
xen-api@lists.xensource.com
mailing list. In the future we plan to move relevant content such as
documentation, designs, roadmaps etc. onto the main xen.org wiki.
Comments, criticism and contributions are welcome!
The xapi toolstack team.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On Tue, Nov 3, 2009 at 10:30 AM, Dave Scott <Dave.Scott@eu.citrix.com> wrote:> Hi, > > We are pleased to announce the open-sourcing of the ''xapi'' toolstack > -- as used in the Citrix XenServer product line. The xapi toolstack is > licensed under the LGPL v2.1 with a special static linking exception. The > toolstack:This is great that Citrix is open sourcing this code... Thanks for that! Some questions... o Are there any high level READMEs for what is in what directories for the two repos? o What has not been open sourced? i.e. after a brief look, I didn''t see the VHD code... But I could have missed it... o Now that there are two tool stacks, are there any short term and long term thoughts, plans, roadmaps, etc... o I noticed there are a fair amount of Xen and qemu patches.. I see that some are toolset specific and some are not.. Are there any plans to start rolling these into unstable and a a few of them into 3.4? (I realize this takes a lot of work and time). Thanks, MRJ _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, Mark Johnson wrote:> This is great that Citrix is open sourcing this code... Thanks for that! > > Some questions... > o Are there any high level READMEs for what is in what directories > for the two repos?The best we''ve got at the moment is some generated module/function-level docs: http://www.xen.org/files/XenCloud/ocamldoc/ Here''s a quick inline summary: xen-dist-ocaml.hg: a bunch of Makefiles (in the style of BSD ports I think) for downloading and building external tools and libs. At some point we should probably switch to using RPMS. xen-api-libs.hg: utility libraries, some xen-specific some more general: eg camldm: interface to device-mapper cdrom: wrappers around CDROM-specific ioctls eventchn: xen event channel stubs fake: used as part of a hypercall simulator (for testing) log: logging library (with syslog bindings) mmap: interface to mmap rpc-light: a simple RPC framework capable of using XMLRPC and JSON sha1: stubs for generating sha1sums stdext: helper functions to augment standard libraries uuid: generates uuids xb: stuff for talking xenbus xs: stuff for talking to xenstore xc: hypercalls xen-api.hg: most of the stuff is here java: contains the example Java VM console viewer javascript: contains the example Javascript UI ocaml/auth: stuff for PAM, AD ocaml/client_records: utility stuff for the CLI ocaml/console: console forwarding ocaml/database: manages the VM, host metadata ocaml/idl/datamodel.ml: defines the API ocaml/xenops: low-level domain, qemu management ocaml/xapi/xapi_*: high-level API entrypoints ocaml/xapi/vmops: higher-level domain, qemu management ocaml/xenstored: ocaml xenstore> o What has not been open sourced? i.e. after a brief look, I didn''t > see the VHD code... But I could have missed it...My understanding is that the VHD code was OSSed a while back. Although we''re still on blktap1, we''re intending to explicitly switch to the new blktap2 stuff as soon as practical.> o Now that there are two tool stacks, are there any short term > and long term thoughts, plans, roadmaps, etc... > > o I noticed there are a fair amount of Xen and qemu patches.. I > see that some are toolset specific and some are not.. Are there any > plans to start rolling these into unstable and a a few of them into 3.4? > (I realize this takes a lot of work and time).I''m compiling a xapi toolstack architecture document which contains some of our thoughts on how the toolstack could evolve. It''s partially complete (perhaps such things are always partially complete) but I''ll check it into the xen-api.hg repo anyway. We also have a draft of a toolstack roadmap which I''ll try to get on the wiki. We''re keen to reduce the size of the patch queues. I believe bugfixes are all upstream but there''s still stuff like the occasional backport... or an interface change that was never upstreamed. For example I think there''s a change to the block device shutdown protocol which makes toolstack error handling easier. Hopefully we can start discussing those changes and either drop them or upstream them :) Cheers, Dave _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api
Mark Johnson
2009-Nov-03 17:56 UTC
[Xen-API] Re: [Xen-devel] release of ''xapi'' toolstack
On Tue, Nov 3, 2009 at 11:51 AM, Dave Scott <Dave.Scott@eu.citrix.com> wrote:> > Hi, > > Mark Johnson wrote: >> This is great that Citrix is open sourcing this code... Thanks for that! >> >> Some questions... >> o Are there any high level READMEs for what is in what directories >> for the two repos? > > The best we''ve got at the moment is some generated module/function-level docs: > > http://www.xen.org/files/XenCloud/ocamldoc/ > > Here''s a quick inline summary: > > xen-dist-ocaml.hg: a bunch of Makefiles (in the style of BSD ports I think) for downloading and building external tools and libs. At some point we should probably switch to using RPMS. > > xen-api-libs.hg: utility libraries, some xen-specific some more general: eg > camldm: interface to device-mapper > cdrom: wrappers around CDROM-specific ioctls > eventchn: xen event channel stubs > fake: used as part of a hypercall simulator (for testing) > log: logging library (with syslog bindings) > mmap: interface to mmap > rpc-light: a simple RPC framework capable of using XMLRPC and JSON > sha1: stubs for generating sha1sums > stdext: helper functions to augment standard libraries > uuid: generates uuids > xb: stuff for talking xenbus > xs: stuff for talking to xenstore > xc: hypercalls > > xen-api.hg: most of the stuff is here > java: contains the example Java VM console viewer > javascript: contains the example Javascript UI > ocaml/auth: stuff for PAM, AD > ocaml/client_records: utility stuff for the CLI > ocaml/console: console forwarding > ocaml/database: manages the VM, host metadata > ocaml/idl/datamodel.ml: defines the API > ocaml/xenops: low-level domain, qemu management > ocaml/xapi/xapi_*: high-level API entrypoints > ocaml/xapi/vmops: higher-level domain, qemu management > ocaml/xenstored: ocaml xenstoreThanks, that''s exactly what I was looking for.> >> o What has not been open sourced? i.e. after a brief look, I didn''t >> see the VHD code... But I could have missed it... > > My understanding is that the VHD code was OSSed a while back. Although we''re still > on blktap1, we''re intending to explicitly switch to the new blktap2 stuff as soon as practical.Oh, that''s right... Thanks. Other than the GUI, what will remained closed source in the XenServer product? i.e. are there any extensions to the cli, xapi? Any additional libs not present in xen-api-libs.hg? Any extensions to blktap? I assume things like the p2v and v2v tools will remain closed source... I''m just trying to get a feel for what functionality is being opened up. And what functionality, if any, Citrix doesn''t want to open up at this time.>> o Now that there are two tool stacks, are there any short term >> and long term thoughts, plans, roadmaps, etc... >> >> o I noticed there are a fair amount of Xen and qemu patches.. I >> see that some are toolset specific and some are not.. Are there any >> plans to start rolling these into unstable and a a few of them into 3.4? >> (I realize this takes a lot of work and time). > > I''m compiling a xapi toolstack architecture document which contains some of our thoughts on how the toolstack could evolve. It''s partially complete (perhaps such things are always partially complete) but I''ll check it into the xen-api.hg repo anyway. We also have a draft of a toolstack roadmap which I''ll try to get on the wiki. > > We''re keen to reduce the size of the patch queues. I believe bugfixes are all upstream but there''s still stuff like the occasional backport... or an interface change that was never upstreamed. For example I think there''s a change to the block device shutdown protocol which makes toolstack error handling easier. Hopefully we can start discussing those changes and either drop them or upstream them :)Great, thanks Dave! MRJ _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api
Mark Johnson wrote:> Other than the GUI, what will remained closed source in the > XenServer product? i.e. are there any extensions to the cli, > xapi? Any additional libs not present in xen-api-libs.hg? > Any extensions to blktap?At present a few server-side pieces are not open-source. These are (from memory): 1. the heartbeat/liveset management daemon which is needed for HA (xapi talks to this via a simple interface) 2. some 3rd party FC tools 3. a few storage backends (NetApp, EQL and StorageLink) Some pieces of the XenServer product (eg ''Workload Balancing'') are actually off-box windows services which talk to xapi via the API. These are closed.> I assume things like the p2v and v2v tools will remain > closed source...Actually there is some basic linux P2V stuff in there: the install CD doubles as a P2V client, which uploads to a special ''P2V'' VM (xen-api.hg/ocaml/p2v/p2v.ml) Cheers, Dave _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api
On Tue, Nov 03, 2009 at 06:35:16PM +0000, Dave Scott wrote:> > Mark Johnson wrote: > > Other than the GUI, what will remained closed source in the > > XenServer product? i.e. are there any extensions to the cli, > > xapi? Any additional libs not present in xen-api-libs.hg? > > Any extensions to blktap? > > At present a few server-side pieces are not open-source. These are (from memory): > 1. the heartbeat/liveset management daemon which is needed for HA (xapi talks to this via a simple interface) > 2. some 3rd party FC tools > 3. a few storage backends (NetApp, EQL and StorageLink) >Hmm.. Citrix XenServer doesn''t currently support iSCSI multipathing with EQL storage. I''ve understood the EQL storage backend is mostly for other features (snapshots, cloning etc), so now I could actually help fix the multipathing stuff.. Any pointers where to look for the iSCSI multipathing stuff? -- Pasi _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Thanks a lot. One quick question, is it likely the Windows things(XenCenter, pvdrivers, and others) open source someday as well? I just don''t want to be surprised again. :) Utter On Wed, Nov 4, 2009 at 2:35 AM, Dave Scott <Dave.Scott@eu.citrix.com> wrote:> > Mark Johnson wrote: > > Other than the GUI, what will remained closed source in the > > XenServer product? i.e. are there any extensions to the cli, > > xapi? Any additional libs not present in xen-api-libs.hg? > > Any extensions to blktap? > > At present a few server-side pieces are not open-source. These are (from > memory): > 1. the heartbeat/liveset management daemon which is needed for HA (xapi > talks to this via a simple interface) > 2. some 3rd party FC tools > 3. a few storage backends (NetApp, EQL and StorageLink) > > Some pieces of the XenServer product (eg ''Workload Balancing'') are actually > off-box windows services which talk to xapi via the API. These are closed. > > > I assume things like the p2v and v2v tools will remain > > closed source... > > Actually there is some basic linux P2V stuff in there: the install CD > doubles as a P2V client, which uploads to a special ''P2V'' VM > (xen-api.hg/ocaml/p2v/p2v.ml) > > Cheers, > Dave > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Hi, The windows drivers are freely distributable, but not open source. It''s not clear that various MSFT libraries used permit them to be open-source. Regarding XenCenter: a cloud platform probably doesn''t need a windows GUI. Hopefully 3rd party clients will be able to manage xapi via its API (or, at some point, libvirt: http://www.xen.org/products/cloud_roadmap.html). We''ve included a simple prototype/proof-of-concept Javascript UI which shows how to talk to xapi via XMLRPC (with a JSON server-side shim for unmarshalling convenience). It''s capable of viewing consoles, powercycling VMs etc as well as automatically picking up metadata changes from the server via the event mechanism. We use it quite a lot internally when debugging stuff. Hope this helps, Dave From: Dirk Utterback [mailto:dirk.utterback@gmail.com] Sent: 04 November 2009 02:59 To: Dave Scott Cc: Mark Johnson; xen-devel@lists.xensource.com; xen-api@lists.xensource.com Subject: Re: [Xen-devel] release of ''xapi'' toolstack Thanks a lot. One quick question, is it likely the Windows things(XenCenter, pvdrivers, and others) open source someday as well? I just don''t want to be surprised again. :) Utter On Wed, Nov 4, 2009 at 2:35 AM, Dave Scott <Dave.Scott@eu.citrix.com<mailto:Dave.Scott@eu.citrix.com>> wrote: Mark Johnson wrote:> Other than the GUI, what will remained closed source in the > XenServer product? i.e. are there any extensions to the cli, > xapi? Any additional libs not present in xen-api-libs.hg? > Any extensions to blktap?At present a few server-side pieces are not open-source. These are (from memory): 1. the heartbeat/liveset management daemon which is needed for HA (xapi talks to this via a simple interface) 2. some 3rd party FC tools 3. a few storage backends (NetApp, EQL and StorageLink) Some pieces of the XenServer product (eg ''Workload Balancing'') are actually off-box windows services which talk to xapi via the API. These are closed.> I assume things like the p2v and v2v tools will remain > closed source...Actually there is some basic linux P2V stuff in there: the install CD doubles as a P2V client, which uploads to a special ''P2V'' VM (xen-api.hg/ocaml/p2v/p2v.ml<http://p2v.ml>) Cheers, Dave _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com> http://lists.xensource.com/xen-devel _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jonathan Ludlam
2009-Nov-04 15:23 UTC
RE: [Xen-API] Re: [Xen-devel] release of ''xapi'' toolstack
Hi Pasi, Julian Chesterfield (cc''d) is the person responsible for the storage backends - I''m sure he''ll point you in the right direction. Anyway, if you''re planning on hacking on the multipathing code, there are a couple of things you should probably be aware of - the version of multipathd that we ship differs in some important ways from the stock CentOS one. There are a couple of incidental patches that do things like alert when paths go up/down, but the most important one is the patch that stops multipathd from listening for uevents. The CentOS version has both multipathd listening for uevents and multipath invoked from the udev scripts, which was racy and we found that it was difficult to decide when the process of adding a LUN had completed. What we''ve done is ensure that everything is done synchronously, so the backends explicitly tell multipathd (through the multipathd cli interface -- which is *not* the same as the command ''multipath''!) when paths arrive and disappear. So when a path appears, we effectively do: # echo "add path sd<x>" | multipathd -k When this command returns, we know that multipathd has finished processing the device, and the devmapper node has appeared. The only thing that is done automatically from udev is a failsafe rule that''s executed when a device is removed from the system. This rule tells multipathd to forget about the particular path, which prevents a possible condition where LVM waits indefinitely trying to access a multipathed device where all the paths have vanished. This is probably the most important aspect of how multipath works currently - obviously there''s some more detail, and we''ll have to write this up on the xen.org wiki at some point. Cheers, Jon -----Original Message----- From: xen-api-bounces@lists.xensource.com [mailto:xen-api-bounces@lists.xensource.com] On Behalf Of Pasi Kärkkäinen Sent: 03 November 2009 19:51 To: Dave Scott Cc: ''Mark Johnson''; xen-devel@lists.xensource.com; xen-api@lists.xensource.com Subject: [Xen-API] Re: [Xen-devel] release of ''xapi'' toolstack On Tue, Nov 03, 2009 at 06:35:16PM +0000, Dave Scott wrote:> > Mark Johnson wrote: > > Other than the GUI, what will remained closed source in the > > XenServer product? i.e. are there any extensions to the cli, > > xapi? Any additional libs not present in xen-api-libs.hg? > > Any extensions to blktap? > > At present a few server-side pieces are not open-source. These are (from memory): > 1. the heartbeat/liveset management daemon which is needed for HA (xapi talks to this via a simple interface) > 2. some 3rd party FC tools > 3. a few storage backends (NetApp, EQL and StorageLink) >Hmm.. Citrix XenServer doesn''t currently support iSCSI multipathing with EQL storage. I''ve understood the EQL storage backend is mostly for other features (snapshots, cloning etc), so now I could actually help fix the multipathing stuff.. Any pointers where to look for the iSCSI multipathing stuff? -- Pasi _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api _______________________________________________ xen-api mailing list xen-api@lists.xensource.com http://lists.xensource.com/mailman/listinfo/xen-api
Pasi Kärkkäinen
2009-Nov-06 09:54 UTC
Re: [Xen-API] Re: [Xen-devel] release of ''xapi'' toolstack
On Wed, Nov 04, 2009 at 03:23:53PM +0000, Jonathan Ludlam wrote:> Hi Pasi, > > Julian Chesterfield (cc''d) is the person responsible for the storage > backends - I''m sure he''ll point you in the right direction. >Ok.> Anyway, if you''re planning on hacking on the multipathing code, > there are a couple of things you should probably be aware of - > the version of multipathd that we ship differs in some important > ways from the stock CentOS one. There are a couple of incidental > patches that do things like alert when paths go up/down, but the > most important one is the patch that stops multipathd from listening > for uevents. The CentOS version has both multipathd listening for > uevents and multipath invoked from the udev scripts, which was racy > and we found that it was difficult to decide when the process of > adding a LUN had completed. What we''ve done is ensure that everything > is done synchronously, so the backends explicitly tell multipathd > (through the multipathd cli interface -- which is *not* the same as > the command ''multipath''!) when paths arrive and disappear. > So when a path appears, we effectively do: > > # echo "add path sd<x>" | multipathd -k > > When this command returns, we know that multipathd has finished > processing the device, and the devmapper node has appeared. >Are these patches available from somewhere?> The only thing that is done automatically from udev is a failsafe > rule that''s executed when a device is removed from the system. > This rule tells multipathd to forget about the particular path, > which prevents a possible condition where LVM waits indefinitely > trying to access a multipathed device where all the paths have vanished. > > This is probably the most important aspect of how multipath works > currently - obviously there''s some more detail, and we''ll have to > write this up on the xen.org wiki at some point. >Thanks for the info. This is indeed good to know beforehands :) -- Pasi> Cheers, > > Jon > > > -----Original Message----- > From: xen-api-bounces@lists.xensource.com [mailto:xen-api-bounces@lists.xensource.com] On Behalf Of Pasi Kärkkäinen > Sent: 03 November 2009 19:51 > To: Dave Scott > Cc: ''Mark Johnson''; xen-devel@lists.xensource.com; xen-api@lists.xensource.com > Subject: [Xen-API] Re: [Xen-devel] release of ''xapi'' toolstack > > On Tue, Nov 03, 2009 at 06:35:16PM +0000, Dave Scott wrote: > > > > Mark Johnson wrote: > > > Other than the GUI, what will remained closed source in the > > > XenServer product? i.e. are there any extensions to the cli, > > > xapi? Any additional libs not present in xen-api-libs.hg? > > > Any extensions to blktap? > > > > At present a few server-side pieces are not open-source. These are (from memory): > > 1. the heartbeat/liveset management daemon which is needed for HA (xapi talks to this via a simple interface) > > 2. some 3rd party FC tools > > 3. a few storage backends (NetApp, EQL and StorageLink) > > > > Hmm.. Citrix XenServer doesn''t currently support iSCSI multipathing with > EQL storage. I''ve understood the EQL storage backend is mostly for other > features (snapshots, cloning etc), so now I could actually help fix the > multipathing stuff.. > > Any pointers where to look for the iSCSI multipathing stuff? > > -- Pasi > > > _______________________________________________ > xen-api mailing list > xen-api@lists.xensource.com > http://lists.xensource.com/mailman/listinfo/xen-api_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jonathan Ludlam
2009-Nov-06 10:51 UTC
Re: [Xen-API] Re: [Xen-devel] release of ''xapi'' toolstack
Unfortunately, the src rpms are only available in the source isos, in this case, source-1.iso. You can download that here: http://www.xen.org/products/cloud_source.html Obviously this is a less-than-ideal distribution mechanism, and we''re going to have to fix this! For now, I''ll send you out-of-band the src rpm for dm-multipath that contains the patches I mentioned. Hope this helps! Jon On 6 Nov 2009, at 09:54, Pasi Kärkkäinen wrote:> On Wed, Nov 04, 2009 at 03:23:53PM +0000, Jonathan Ludlam wrote: >> Hi Pasi, >> >> Julian Chesterfield (cc''d) is the person responsible for the storage >> backends - I''m sure he''ll point you in the right direction. >> > > Ok. > >> Anyway, if you''re planning on hacking on the multipathing code, >> there are a couple of things you should probably be aware of - >> the version of multipathd that we ship differs in some important >> ways from the stock CentOS one. There are a couple of incidental >> patches that do things like alert when paths go up/down, but the >> most important one is the patch that stops multipathd from listening >> for uevents. The CentOS version has both multipathd listening for >> uevents and multipath invoked from the udev scripts, which was racy >> and we found that it was difficult to decide when the process of >> adding a LUN had completed. What we''ve done is ensure that everything >> is done synchronously, so the backends explicitly tell multipathd >> (through the multipathd cli interface -- which is *not* the same as >> the command ''multipath''!) when paths arrive and disappear. >> So when a path appears, we effectively do: >> >> # echo "add path sd<x>" | multipathd -k >> >> When this command returns, we know that multipathd has finished >> processing the device, and the devmapper node has appeared. >> > > Are these patches available from somewhere? > >> The only thing that is done automatically from udev is a failsafe >> rule that''s executed when a device is removed from the system. >> This rule tells multipathd to forget about the particular path, >> which prevents a possible condition where LVM waits indefinitely >> trying to access a multipathed device where all the paths have >> vanished. >> >> This is probably the most important aspect of how multipath works >> currently - obviously there''s some more detail, and we''ll have to >> write this up on the xen.org wiki at some point. >> > > Thanks for the info. This is indeed good to know beforehands :) > > -- Pasi > >> Cheers, >> >> Jon >> >> >> -----Original Message----- >> From: xen-api-bounces@lists.xensource.com [mailto:xen-api- >> bounces@lists.xensource.com] On Behalf Of Pasi Kärkkäinen >> Sent: 03 November 2009 19:51 >> To: Dave Scott >> Cc: ''Mark Johnson''; xen-devel@lists.xensource.com; xen-api@lists.xensource.com >> Subject: [Xen-API] Re: [Xen-devel] release of ''xapi'' toolstack >> >> On Tue, Nov 03, 2009 at 06:35:16PM +0000, Dave Scott wrote: >>> >>> Mark Johnson wrote: >>>> Other than the GUI, what will remained closed source in the >>>> XenServer product? i.e. are there any extensions to the cli, >>>> xapi? Any additional libs not present in xen-api-libs.hg? >>>> Any extensions to blktap? >>> >>> At present a few server-side pieces are not open-source. These are >>> (from memory): >>> 1. the heartbeat/liveset management daemon which is needed for HA >>> (xapi talks to this via a simple interface) >>> 2. some 3rd party FC tools >>> 3. a few storage backends (NetApp, EQL and StorageLink) >>> >> >> Hmm.. Citrix XenServer doesn''t currently support iSCSI multipathing >> with >> EQL storage. I''ve understood the EQL storage backend is mostly for >> other >> features (snapshots, cloning etc), so now I could actually help fix >> the >> multipathing stuff.. >> >> Any pointers where to look for the iSCSI multipathing stuff? >> >> -- Pasi >> >> >> _______________________________________________ >> xen-api mailing list >> xen-api@lists.xensource.com >> http://lists.xensource.com/mailman/listinfo/xen-api_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel