[libvirt] [PATCH] storage: Deactive lv before remove it

Osier Yang jyang at redhat.com
Mon Jun 13 14:43:10 UTC 2011


On 06/09/2011 08:33 AM, Jun'ichi Nomura wrote:
> Hi
>
> On 06/08/11 17:01, Osier Yang wrote:
>> This is to address BZ# https://bugzilla.redhat.com/show_bug.cgi?id=702260,
>> though even if with this patch, the user might see error like
>> "Unable to deactivate logical volume",
>
> Can you try the attached patch?
> (in addition to the upstream lvm fix you mentioned below)
>
> Recent distributions generate udev events *after* the use of
> devices through "watch" rules.
> As a result, lvremove/lvchange can race with it and fail to
> remove/deactivate volume.
>
> I haven't tested the patch but I could fix the similar
> problem of lvremove by putting 'udevadm settle' before that.
> So I think it's worth trying.
>
>> it could fix the problem if the
>> lv is referred to by another existing LVs, allowing the user remove
>> the lv successfully without seeing error like "Can't remove open logical
>> volume".
>>
>> For the error "Unable to deactivate logical volume", libvirt can't do
>> more, it's problem of lvm, see BZ#:
>> https://bugzilla.redhat.com/show_bug.cgi?id=570359
>>
>> And the patch applied to upstream lvm to fix it:
>> https://www.redhat.com/archives/lvm-devel/2011-May/msg00025.html
>
> This lvm patch fixes only the case where lvremove itself generates udev events.
> You'll still see the problem as the udev events will be generated when
> a VM finishes using the volume, for example.
>

I'm worried about using "udevadm settle" will introduce some delays,
but it looks to me this is the only workable fix for the bug, as for
"lvchange -an $vol; lvremove $vol", it could encount the similiar
problem with "lvremove -f", as you can still get the udev processing
event when doing "lvchange -an".

Anybody has thoughts on this? if no, I'd think Jun'ichi's patch is
nice, and push it.

Thanks
Osier




More information about the libvir-list mailing list