Re: [linux-lvm] How to implement live migration of VMs in thinlv after using lvmlockd

Zhiyong Ye <[email protected]>
Newsgroups dev.linux.lists.linux-lvm
Message-ID <[email protected]>

在 11/2/22 1:57 AM, David Teigland 写道:
> On Wed, Nov 02, 2022 at 01:02:27AM +0800, Zhiyong Ye wrote:
>> Hi Dave,
>>
>> Thank you for your reply!
>>
>> Does this mean that there is no way to live migrate VMs when using lvmlockd?
> 
> You could by using linear LVs, ovirt does this using sanlock directly,
> since lvmlockd arrived later.
> 

Yes, standard LV is theoretically capable of live migration because it 
supports multiple hosts using the same LV concurrently with a shared 
lock (lvchange -asy). But I want to support the live migration feature 
for both LVs (thin LV and standard LV).

>> As you describe, the granularity of thinlv's sharing/unsharing is per
>> read/write IO, except that lvmlockd reinforces this limitation for the lvm
>> activation command.
>>
>> Is it possible to modify the code of lvmlockd to break this limitation and
>> let libvirt/qemu guarantee the mutual exclusivity of each read/write IO
>> across hosts when live migration?
> 
> lvmlockd locking does not apply to the dm i/o layers.  The kind of
> multi-host locking that you seem to be talking about would need to be
> implemented inside dm-thin to protect on-disk data structures that it
> modifies.  In reality you would need to write a new dm target with locking
> and data structures designed for that kind of sharing.

I can try to write a new dm thin target or make some modifications based 
on the existing dm-thin target to support this feature, if it is 
technically feasible. But I'm curious why the current dm-thin doesn't 
support multi-host shared access, just like dm-linear does.

Regards!

Zhiyong

_______________________________________________
linux-lvm mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.