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

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(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/kimchi-devel > > _______________________________________________ > Kimchi-devel mailing list > Kimchi-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/kimchi-devel