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

Crístian Viana vianac at linux.vnet.ibm.com
Mon Mar 30 23:03:28 UTC 2015


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.

Any feedback will be very welcome.

Best regards,
Crístian.




More information about the Kimchi-devel mailing list