release of 'xapi' toolstack

release of 'xapi' toolstack

[Dave Scott]

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.

Re: release of 'xapi' toolstack

[Mark Johnson]

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

RE: release of 'xapi' toolstack

[Dave Scott]

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

Re: release of 'xapi' toolstack

[Mark Johnson]

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 xenstore

Thanks, 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

RE: [Xen-devel] release of 'xapi' toolstack

[Dave Scott]

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

Re: release of 'xapi' toolstack

[Pasi Kärkkäinen]

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

Re: release of 'xapi' toolstack

[Dirk Utterback]

[-- Attachment #1.1: Type: text/plain, Size: 1375 bytes --]

  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
>

[-- Attachment #1.2: Type: text/html, Size: 2045 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: release of 'xapi' toolstack

[Dave Scott]

[-- Attachment #1.1: Type: text/plain, Size: 2448 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 7044 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

RE: Re: [Xen-devel] release of 'xapi' toolstack

[Jonathan Ludlam]

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-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org [mailto:xen-api-bounces-GuqFBffKawv/PtFMR13I2A@public.gmane.orgsource.com] On Behalf Of Pasi Kärkkäinen
Sent: 03 November 2009 19:51
To: Dave Scott
Cc: 'Mark Johnson'; xen-devel-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org; xen-api-GuqFBffKawuULHF6PoxzQA@public.gmane.orgcom
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-GuqFBffKawuULHF6PoxzQEEOCMrvLtNR@public.gmane.org
http://lists.xensource.com/mailman/listinfo/xen-api

Re: [Xen-API] Re: release of 'xapi' toolstack

[Pasi Kärkkäinen]

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

Re: [Xen-API] Re: release of 'xapi' toolstack

[Jonathan Ludlam]

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