Re: [Xen-devel] Red Hat Cluster and Xen

["Rami Rosen" <rosenrami@xxxxxxxxx>]

Hello David,

Yes, you can go one more step backwards, and use cluster-1.02.00.
But you must also apply two patches : see
http://www.redhat.com/archives/cluster-devel/2006-June/msg00162.html

These two patches are due to changes in libsysfs.

For me it worked like a charm.

Regards,
Rami Rosen


On 3/21/07, David Shwatrz <dshwatrz@xxxxxxxxx> wrote:
> Hello all,
>
> I had tried to build Red Hat Cluster (http://sourceware.org/cluster/)
> against
> a Xen tree in order to deploy a cluster with Xen VMs.
>
> Under the ftp repository,
> ftp://sources.redhat.com/pub/cluster/releases,
> there are some releases.
>
> I started by trying to build the latest, which is: cluster-2.00.00.tar.gz.
>
> I ran :
>     ./configure --kernel_src=/work/src/xen-3.0.4_1-src/linux-2.6.16.33-xen
>
> I get the following error :
>     /work/src/cluster-2.00.00/gnbd-kernel/src/gnbd.c: In function
> 'gnbd_init':
> /work/src/cluster- 2.00.00/gnbd-kernel/src/gnbd.c:888: error: 'struct
> request'
>   has no member named 'cmd_type'
>
> It turns out that the struct request in
>
> /work/src/xen-3.0.4_1-src/linux-2.6.16.33-xen/include/linux
> is missing
>     a member named 'cmd_type' ; this member DOES exists in linux kernel
> 2.6.20 for example.
>
> After probing a bit, I discovered that the problem is that this redhat
> cluster
>     version is for kernel 2.6.20 (and higher) , and Xen
>     (also unstable version, as far as I know) still does not work with this
> version.
>     see the following thread:
>
> https://www.redhat.com/archives/linux-cluster/2007-March/msg00175.html
>
>     So I went a step back and tried cluster-1.03.00.
>
>     (If you wonder why I skipped cluster-1.04 version, which does exists
>     in that repository: the reason is simple ; If you will look at that
> thread
>     mentioned above you will find out that also cluster-1.04 is intended for
> use with 2.6.20.)
>
>     after "make install" I got:
>     /work/src/cluster-1.03.00/gfs-kernel/src/nolock/main.c: In function
> 'nolock_plock_get':
> /work/src/cluster-1.03.00/gfs-kernel/src/nolock/main.c:250:
> error: too many arguments to function 'posix_test_lock'
>
>  It turned out that the posix_test_lock() prototype in the linux kernel that
> Xen
> uses is:
>  struct file_lock *posix_test_lock(struct file *, struct file_lock *);
>
> while the call to posix_test_lock() in gfs-kernel/src/nolock/main.c is with
> three
> parameters.
>
>                     What should I do ? should I go again one step back
> (until reaching a
> stop point for this recursion) ?
>
> Any ideas ?
>
> DS
>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel