[Ocfs2-users] OCFS2 and Xen interoperability issue

[Sunil Mushran]

So this is a known issue on OCFS2 1.4/(RH)EL5 combination. As in, this
will _work_ on OCFS2 1.2 on the same kernel and _should_ work with OCFS2
bundled with the mainline kernels. But not on the specific combination you
are using.

In short, the xm save/dump-core implementation in 2.6.18 is hacky. And that
hack conflicts with the code we've had to add to backport the fs to (RH)EL5.
To get this to work, we will need some kernel symbols exported.

But it is too late for that and we will not be addressing this issue. The
issue should be resolved by OCFS2 1.6.

Sunil

Gonçalo Borges wrote:
> Hi...
>> ocfs2 and kernel versions?
>>
> [root at core19 ~]# uname -a
> Linux core19.ncg.ingrid.pt 2.6.18-128.1.16.el5xen #1 SMP Tue Jun 30 
> 07:06:24 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
>
> [root at core19 ~]# rpm -qa | grep ocfs2
> ocfs2-tools-1.4.2-1.el5
> ocfs2-2.6.18-128.1.16.el5xen-1.4.2-1.el5
> ocfs2console-1.4.2-1.el5
>
> Cheers
> Goncalo
>
>> Gonçalo Borges wrote:
>>> Hi All...
>>>
>>> I'm testing a Xen solution on an OCFS2 SAN to store VM images,
>>> and I'm observing an interoperability issue between two kinds of
>>> softwares.
>>>
>>> I've already tried to obtain some feedback from Xen experts without
>>> any success. Maybe I'm more lucky on this list, and someone knows
>>> a workaround to the problem.
>>>
>>> The problem is the following: If I try to save a Virtual Machine (VM)
>>> asking to store the checkpoint file in any local dir of the physical
>>> host where the VM is running (ex: /tmp), everything works fine, and
>>> I can properly restore the VM afterwards. Nevertheless, if I try to 
>>> save
>>> a VM asking to store the saved file inside the OCFS2 SAN, it fails with
>>> the following messages in (xend) log:
>>>
>>> ---*---
>>>
>>> [2009-08-21 14:45:25 xend 9720] INFO (XendCheckpoint:351) Saving memory
>>> pages: iter 1   0%ERROR Internal error: Error when writing to state 
>>> file
>>> (5) (errno 14)
>>> [2009-08-21 14:45:25 xend 9720] INFO (XendCheckpoint:351) Save exit 
>>> rc=1
>>> [2009-08-21 14:45:25 xend 9720] ERROR (XendCheckpoint:133) Save failed
>>> on domain one-0 (9).
>>> Traceback (most recent call last):
>>>     File 
>>> "/usr/lib64/python2.4/site-packages/xen/xend/XendCheckpoint.py",
>>> line 110, in save
>>>       forkHelper(cmd, fd, saveInputHandler, False)
>>>     File 
>>> "/usr/lib64/python2.4/site-packages/xen/xend/XendCheckpoint.py",
>>> line 339, in forkHelper
>>>       raise XendError("%s failed" % string.join(cmd))
>>> XendError: /usr/lib64/xen/bin/xc_save 26 9 0 0 0 failed
>>>
>>> ---*---
>>>
>>> It seems this is related to the fact that Xen is unable to "lock" 
>>> the remote
>>> block device, which in our case is an ocfs2 one. I'm not the only 
>>> one complaining
>>> about this issue, according to the following threads:
>>>
>>> http://lists.xensource.com/archives/html/xen-users/2009-04/msg00670.html 
>>>
>>> http://lists.xensource.com/archives/html/xen-users/2008-09/msg00948.html 
>>>
>>>
>>> I wonder if anyone can provide additional info, or if there is some 
>>> workaround
>>> for the problem?
>>>
>>> Cheers
>>> Goncalo
>>>
>>> _______________________________________________
>>> Ocfs2-users mailing list
>>> Ocfs2-users at oss.oracle.com
>>> http://oss.oracle.com/mailman/listinfo/ocfs2-users
>>
>