[Kimchi-devel] [RFC] Do not block operations due to ref_cnt

[Aline Manera]

On 31/03/2015 22:57, Royce Lv wrote:
> On 03/31/2015 07:03 AM, Crístian Viana wrote:
>> Hi,
>>
>> I'd like to propose a change to how Kimchi uses the resource field 
>> "ref_cnt".
>>
>> Currently, "ref_cnt" - which stands for "reference count" - is one of 
>> the fields returned when looking up a storage volume. Its purpose is 
>> to indicate how many times that resource is being used at the moment. 
>> For example, if the resource /storagepools/pool/storagevolumes/vol 
>> has ref_cnt=1, it means that the disk is attached to 1 VM right now 
>> and thus it cannot be attached to another VM. I believe the original 
>> idea of this feature is to prevent the same resource from being 
>> attached more than once at the same time. However, IMO, that might 
>> not always be the desired behavior and there's no way to enforce it 
>> completely as those resources can be used outside of Kimchi, where 
>> "ref_cnt" doesn't exist. For example, if I have one VM which uses the 
>> disk "vol", I'm not able to attach it to another VM via Kimchi; but 
>> if I use another libvirt-based VM manager (e.g. virsh), I am able to 
>> attach that disk to a different VM. This becomes even trickier when 
>> we consider other operations, like snapshots, which can attach/detach 
>> disks while they're being reverted to. Also, suppose I might want to 
>> inspect one VM's disk from another VM, and then I'd need to attach 
>> one disk twice; Kimchi wouldn't allow that by stating that the disk 
>> is already in use.
>>
>> I propose Kimchi should stop using "ref_cnt" as a blocking method. 
>> The field may still exist for information/warning messages (e.g. "are 
>> you sure you want to attach this disk? it's already being used by 
>> another VM.") but no operation should be blocked because of it, as it 
>> is the case now. As inconsistencies with that value may happen and we 
>> have no way to make sure it will always work, we shouldn't annoy the 
>> user by stopping them from doing something that may be perfectly valid.
> Let me explain the context of this design:
>     As kimchi always create a disk internally with VM, we do not want 
> these disks we know belong to given VM to be attached to others at the 
> same time, because it can easily cause corruption. And openstack nova 
> also has this logic to prevent cinder volumes to be attached to 
> multiple VMs.
>
> I agree that are some use cases we need shared disk:
>     clustered application can deal with concurrent access of disk 
> (concurrent filesystem, databases with shared table-space). I think 
> for these cases we need to label these disks as "shared", let users 
> aware that these disks have concurrent access control on these disks, 
> we can refer to ovirt's shared raw disk if we want: 
> http://www.ovirt.org/Features/SharedRawDisk.
>
> What I do not agree is we lay the burdern of preventing corruption to 
> user by chopping away ref_cnt just because we think handle it bothers 
> us. For the use case you mentioned:
> 1. virsh/virt-manager allows attach twice: right, but it will not 
> handle the corruption disk of concurrent access. Two vms writing the 
> disk meta-data will surely course corruption.
> 2. snapshots: because a disk ref_cnt is neither 0 or 1 for now. we can 
> scan the xml to decide its ref_cnt after snapshots revert is done.
> 3. inspect one VM's disk from another VM: if from two running VM, the 
> disk may corrupt, if one is down and another is running (e.g. for 
> emergency recovery) I would suggest to detach it from the paniced VM 
> first like what we do to physical machine.

Royce,

I don't think Cristian is proposing to discard the ref_cnt parameter.
 From my understanding, he is proposing we don't consider the ref_cnt 
value as a blocking method.
We will keep the ref_cnt parameter and do our best to have the right 
value set there, but when the user wants to attach a disk with ref_cnt 
!= 0 we will warn he that some disk corruption may happen as other VM is 
using the same disk.

Based on that proposal, I want also to suggest to change the ref_cnt to 
used_by and list the VM names. So we can properly inform the user which 
VMs are using which disks.

>>
>> Any feedback will be very welcome.
>>
>> Best regards,
>> Crístian.
>>
>> _______________________________________________
>> Kimchi-devel mailing list
>> Kimchi-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/kimchi-devel
>
> _______________________________________________
> Kimchi-devel mailing list
> Kimchi-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/kimchi-devel