Late this year, early next year.
Gonçalo Borges wrote:
> Hi Sunil
>
> Thanks for the reply. What's the time frame to release OCFS2 1.6?
>
> Cheers
> Goncalo
>
>
> On 08/25/2009 05:13 PM, Sunil Mushran wrote:
>> 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?
>>>>
>>> [r...@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
>>>
>>> [r...@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@oss.oracle.com
>>>>> http://oss.oracle.com/mailman/listinfo/ocfs2-users
>>>>
>>>
>>
>
_______________________________________________
Ocfs2-users mailing list
Ocfs2-users@oss.oracle.com
http://oss.oracle.com/mailman/listinfo/ocfs2-users
