Bug #1521
LVM transfer driver remove persistent LV when onevm shutdown
| Status: | Closed | Start date: | 10/01/2012 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Jaime Melis | % Done: | 0% | |
| Category: | Drivers - Auth | |||
| Target version: | Release 4.0 | |||
| Resolution: | fixed | Pull request: | ||
| Affected Versions: | OpenNebula 3.6 |
Description
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)
fix-removing-persistent-lvm-volumes.diff 
(1.61 KB)
fix-removing-persistent-lvm-volumes-2.diff
(980 Bytes)
Associated revisions
bug #1521: LVM transfer driver remove persistent LV when onevm shutdown
Issue and patch provided by Bastien Cadiot
Bug #1521: Remove debug message
Bug #1521: LVM transfer driver remove persistent LV when onevm shutdown
The code in this commit is based on Milos Kozak's patch
Bug #1521: Clone LVM instead of doing snapshot
Bug #1521: Use the original image size for cloning, instead of the default image size
History
#1
Updated by Ruben S. Montero almost 9 years ago
- Assignee set to Jaime Melis
- Target version set to Release 3.8
Hi
Thanks for this one. We'll look into this ASAP for 3.8
#2
Updated by Jan Horacek almost 9 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 almost 9 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 almost 9 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 almost 9 years ago
- File fix-removing-persistent-lvm-volumes.diff added
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 almost 9 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 almost 9 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 over 8 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 over 8 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 over 8 years ago
bastien, the syncing of remote scripts could be invoked by "onehost sync" no manual syncing needed.
#11
Updated by Miloš Kozák over 8 years ago
- File fix-removing-persistent-lvm-volumes-2.diff added
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 over 8 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 over 8 years ago
Hi Milos,
you're right bug confirmed. Thanks for the patch, we will fix this ASAP.
#14
Updated by Ruben S. Montero over 8 years ago
- Status changed from Assigned to Closed
- Resolution set to fixed