[Pkg-xen-devel] XCP and OpenXenCenter

[Mike McClurg]

On Thu, Jul 7, 2011 at 8:48 PM, Ritesh Raj Sarraf <rrs at debian.org> wrote:
>
> Hello Mike,
>
>
> On this topic, I noticed that Thomas had started the discussion earlier
> in May 2011. http://www.gossamer-threads.com/lists/xen/api/205934
>

Yes, Thomas has offered to help us on the Debian packaging front.
We've just gotten our repositories to the state where we are ready for
external help for packaging. Thomas, Jon or I will email you next week
to show you what we have got so far.

> From what I read in that thread, if XCP is the combination of multiple
> items (dm-multipath, LVM, open-iscsi and others), it will be difficult
> to add those patches to respective base packages unless they are
> accepted upstream first.
>
> I have worked on XenServer and from my limited exploration I recall that
> there is quite some change in the dependent items. I recall multipath
> having many changes (a python monitoring layer on top of multipath -
> mpathcount).
>
> But from your email it looks like the separation of the dependencies has
> already been done. Please correct me here.
>

XenServer and XCP have made many ugly changes to all of those packages
you have mentioned, and those changes are basically un-upstreamable.
Fortunately, we don't need to upstream those packages for our Debian
port to work. So far, the only component that we'll have to modify
upstream is the Debian Xen package, and most of that work is exposing
the standard Xen OCaml libraries and backporting some changes from Xen
4.1.1 -- no major surgery.

> If XenAPI is the only item that needs packaging to get started, it would
> be much quicker.
>

There are four major components that will need to be turned into
Debian packages:

- blktap2, which is a combination kernel module and userland daemon
for managing storage

- xen-api, which contains a number of daemon and etc and init.d
scripts for starting and configuring the daemons

- xen-api-libs, which is a set of OCaml libraries used to build xapi,
the main xen-api daemon

- xen-api-sm, which contains a number of storage management backends,
typically written in Python

Depending what the the Debian packaging guidelines say, there may be a
one-to-one correlation between those components and the packages that
we create. I'm betting, though, that we may have to split them up into
sub-packages (forgive me if I'm abusing terminology here).

>
> Looks like waldi maintains the xen package building under the kernel
> build umbrella. I need to set that up and test. I'll keep you posted.
>

Thanks.

> Meanwhile, I'd suggest you file "wishlist" bug reports for all patches
> that touch the kernel and the Xen hypervisor package. Also, file an ITP
> for XenAPI. Please let me know if you need help with this. I can do it
> for you.
>

Jon Ludlam and I will start filling out the wishlist bug reports. I
have no idea what an ITP is, so I would appreciate it if you would
file one for me ;) Please let me know what information you need from
us and I will get it to you.

>
> Considering we don't include the dm-multipath .... and other changes to
> the base components now, will it still work? Will it provide the
> equivalent of libvirt?
>
> Ritesh

It works on our Sid/experimental test boxes, to the point where we've
installed both PV and HVM guests. There will be a limited number of
storage backends compared to XCP, but we will be able to provide
backends that will enable migration. While there isn't a one-to-one
correspondence between the features that XenAPI and libvirt provide,
our port of XenAPI will provide a fully functional management API for
Xen hosts. For the XenAPI documentation, see here:
http://docs.vmd.citrix.com/XenServer/5.6.0sp2/1.0/en_gb/api/

Mike