Open Stack

I'm afraid what you are trying is completely wrong.
In case you need a shared file system then you should use a different
technology like Manila.

Multiattach in cinder allows multiple VMS to access the same block device
data but it does
NEVER provide any mechanism to guarantee consistency at file system level.
Popular filesystems
such as xfs never protect concurrent IO from multiple machines and If you
mount the filesystem
on the shared disk by multiple vms and write on it concurrently then you'd
end up with a corrupted filesystem.

Usually when you have multiattach-ed block devices then you need to
implement a mechanism
to prevent concurrent access (eg. Pacemaker)



On Tue, Aug 30, 2022 at 1:06 AM Lokendra Rathour <lokendrarathour at gmail.com>
wrote:

> Hi Team,
> It worked if I redo the VM creation with creation one more volume of
> multi-attach type.
> Thanks once again for the same.
>
> we can mark this thread as closed.
>
>
> On Mon, Aug 29, 2022 at 11:18 AM Lokendra Rathour <
> lokendrarathour at gmail.com> wrote:
>
>> Hi Team,
>> On TripleO Wallaby deployment, I have tried creating multi-attach type
>> volume, which if I am attaching this volume to two VM, it is getting
>> attached.
>> After mounting the same in each VM, if I am creating the folders in one
>> VM at the mount path,
>> I am not seeing the same on the other VM at the mount path
>> [image: image.png]
>>
>> Ideally if the backend volume is same and if I am understanding the idea
>> correctly, then the content should be same in both the location, as the
>> back is same.
>> Checking at horizon I also see that Volume is showing attached to both
>> the VMs.
>>
>>
>> [image: image.png]
>>
>> Document followed to create this:
>> https://docs.openstack.org/cinder/latest/admin/volume-multiattach.html
>>
>> Please advice
>>
>> --
>> ~ Lokendra
>> skype: lokendrarathour
>>
>>
>>
>
> --
> ~ Lokendra
> skype: lokendrarathour
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220830/80034b19/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 80246 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220830/80034b19/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 64122 bytes
Desc: not available
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20220830/80034b19/attachment-0003.png>