Bug #1521

LVM transfer driver remove persistent LV when onevm shutdown

Added by Bastien Cadiot over 7 years ago. Updated almost 7 years ago.

Status:ClosedStart date:10/01/2012
Priority:NormalDue date:
Assignee:Jaime Melis% Done:


Category:Drivers - Auth
Target version:Release 4.0
Resolution:fixed Pull request:
Affected Versions:OpenNebula 3.6


I have found an already fixed issue for this bug ( http://dev.opennebula.org/issues/1463 ) but the provided patch do not solve the problem.
LV are still deleted when we shutdown a VM based on a persistent LVM image.

I made a patch for this bug (import from lvm delete script), it check if the LV is a snapshot or a base LV before deleting it.

lvm_transfer_patch (711 Bytes) Bastien Cadiot, 10/01/2012 03:32 PM

fix-removing-persistent-lvm-volumes.diff Magnifier (1.61 KB) Jan Horacek, 10/04/2012 05:53 PM

fix-removing-persistent-lvm-volumes-2.diff Magnifier (980 Bytes) Miloš Kozák, 01/29/2013 02:57 PM

Associated revisions

Revision 603ac069
Added by Jaime Melis over 7 years ago

bug #1521: LVM transfer driver remove persistent LV when onevm shutdown

Issue and patch provided by Bastien Cadiot

Revision 1d842d34
Added by Jaime Melis over 7 years ago

Bug #1521: Remove debug message

Revision a59c899e
Added by Jaime Melis about 7 years ago

Bug #1521: LVM transfer driver remove persistent LV when onevm shutdown

The code in this commit is based on Milos Kozak's patch

Revision eb612e6c
Added by Jaime Melis about 7 years ago

Bug #1521: Clone LVM instead of doing snapshot

Revision 4bc92ec6
Added by Jaime Melis about 7 years ago

Bug #1521: Use the original image size for cloning, instead of the default image size


#1 Updated by Ruben S. Montero over 7 years ago

  • Assignee set to Jaime Melis
  • Target version set to Release 3.8


Thanks for this one. We'll look into this ASAP for 3.8

#2 Updated by Jan Horacek over 7 years ago

it looks, that this is not complete fix. i have volume, not a base of any lvm snapshot and not snapshot itself. just a volume marked as persistent. removing the VM still deletes the persistent volume. i'm lucky i found this in non-production environment. i'm searching a "final sollution" currently.

#3 Updated by Bastien Cadiot over 7 years ago

The patch (in combination with this one http://dev.opennebula.org/issues/1395) works in my environment. I'm talking about snapshot because it's the method to create non persistent VM based on LV.

Maybe we are not in the same configuration. It was tested with LVM datastore, with LVM transfer driver. $ONE_LOCATION/remote/tm/lvm/mvds
Try to locate the bug by commenting LVREMOVE command in both mvds et delete script, and see if this stop to remove persistent volume.

#4 Updated by Jan Horacek over 7 years ago

yes, it definitely depends on the environment and usecase. what basicaly is not good, is that de LV is removed on the LVM level, but is not removed as a volume in opennebula - so feature or bug, it causes inconsystency betwen storage subsystem and opennebula database.

#5 Updated by Jan Horacek over 7 years ago

bastien, your fix is almost OK, thank, i encountered another bug http://dev.opennebula.org/issues/1395 not fixed in the rpm i used. the two issues complicated the issue more and caused removing of devices even when it could only cause leaking of volumes.

i prepared a patch which is more verbosely coded, but i think it is more readable, based on bastien's fix.

on the other side, i thing, that using xpath and querying PERSISTENT parametr would be the best sollution, independent on the current lvm naming layout (recognizing that the volume is persistent or it is only one of the nonpersistent cases.) i had prepared the rewrite, but returned to the original form from 3.6.0, with bastiens patch and with small rewrite on top.

#6 Updated by Jaime Melis over 7 years ago

  • Status changed from New to Closed
  • Resolution set to fixed

We have studied the issued and applied the patch Bastien provided (a slightly modified version). There are a couple of thigns to take into account:

1) For PERSISTENT=YES images, or SAVE_AS images, MVDS is called, but DELETE isn't. This leaves MVDS with the task of knowing if its a SAVE_AS image in which case it has to remove the original DEV.

2) For PERSISTENT=NO images, MVDS is never called, but DELETE is. There use to be a pointless check, an if confition that always evaluated to true.

That's one of the reasons we did not apply Jan Horacek's patch. Additionally we couldn't figure out:

    #   lv-one-{VMID}-{DISKID}         ... nonpersistnet volume initialized at vm creation

When is that LV name format generated?

Closing this ticket, but feel free to reopen it if this doesn't clarify / solve the problem adequately for you.

#7 Updated by Jan Horacek over 7 years ago

than for detailed info. it's interresting, that mvds was not taken into account on my installation where i'm using tm lvm and ds lvm.

lv-one-{VMID}-{DISKID} is caused by mkimage not yet commited as issue - it's missing in tm_lvm driver. sorry for that, i forgot to inform about it.

#8 Updated by Miloš Kozák about 7 years ago

Hello, I am experiencing same issue in OpenNebula 3.8.1. I am going to upgrade to 3.8.3, but according to task list it should have been already in 3.8?

#9 Updated by Bastien Cadiot about 7 years ago

I'm currently on ONE 3.8.1 and there is no problem for me.
Did you update from 3.6 to 3.8 ? I noticed that these scripts are executed by the host and not by the front-end. And for me theses scripts are not updated automatically when I upgrade to the newer version. I have to copy manually all drivers from Opennebula:/var/lib/one/remotes to Host:/var/tmp/one

Maybe you are in the same case.

Otherwise try to set debug flag to 3 and provide a log from oned.log

#10 Updated by Jan Horacek about 7 years ago

bastien, the syncing of remote scripts could be invoked by "onehost sync" no manual syncing needed.

#11 Updated by Miloš Kozák about 7 years ago

Hi, maybe it was my fault I didnt get it I must to patch it first. But as I installed ONE 3.8.3 even persistent LV got deleted upon VM delete. I am attaching improved patch which should work against ONE 3.8.3. Can I ask anybody to check it out and verify if is it fine like that or more work should be done on it? As it is it works to me..

#12 Updated by Ruben S. Montero about 7 years ago

  • Status changed from Closed to Assigned
  • Target version changed from Release 3.8 to Release 4.0
  • Resolution deleted (fixed)

Reopening this to verify the issue and patch...

Thanks for the feedback!

#13 Updated by Jaime Melis about 7 years ago

Hi Milos,

you're right bug confirmed. Thanks for the patch, we will fix this ASAP.

#14 Updated by Ruben S. Montero almost 7 years ago

  • Status changed from Assigned to Closed
  • Resolution set to fixed

Also available in: Atom PDF