LVM Snapshot script for shared storage LVM over iSCSI only

rustine22

New Member
Jun 9, 2024
6
0
1
Hi,

i have made a script to permit PVE users to do snapshots by SSH on VM node only for VM located on on shared storage LVM over iSCSI Storage (Tests on TrueNas).

What do you think of it ?

Usage: ./pve_iscsi_lvm_snapshot.sh <action> <vmid> [<snapshotname>]
action : Action à effectuer (list, create, delete, revert)
vmid : ID de la machine virtuelle
snapshotname : Nom du snapshot (obligatoire pour action create,delete,revert)


#list snapshot of VM 100
./pve_iscsi_lvm_snapshot.sh list 100

#create snapshot snap1 on VM100
./pve_iscsi_lvm_snapshot.sh create 100 snap1

#delete snapshot snap1 on VM 100 (forget it)
./pve_iscsi_lvm_snapshot.sh delete 100 snap1

#revert to snapshot snap1 on VM 100
./pve_iscsi_lvm_snapshot.sh revert 100 snap1

Best regards
 

Attachments

  • pve_iscsi_lvm_snapshot.zip
    2.7 KB · Views: 23
Looks interesting - I'm not sure it will be found easily here... Maybe I'll link this in some other discussions.

Perhaps you could translate the comments and prompts in the script to English, that might help some people to understand your script better.

Also, please think about hosting the script on github etc. because you need to log in to download attachments and it's not very accessible inside a .zip file. This would also allow people to report issues or suggest changes to the script.

Personally, in the code, I would have liked an overview like "the following functions are defined, this one does that and calls the next one" etc. as a description, but I was able to figure out what it did in general.

There was some commented out stuff there, looks like preparation for Version 2 with LVM-Snapshot autoextension or something? Currently it'll probably need the same amount of space allocated for VM disks as unallocated space in the LVM VG...

Did you try it with multiple hosts? Like moving a VM after you did a Snapshot? Will the script find the snapshot on the new host?

Can the script freeze the VM before taking the snapshot? Maybe leverage something like "qemu snapshot" as with backup until you've created the LVM snap? Maybe not needed, but I don't know if it could help with a VM having multiple disks, so that it achieves a "crash consistent" snapshot state with all disks snapshotted at the same point in time or something.
 
Looks interesting - I'm not sure it will be found easily here... Maybe I'll link this in some other discussions.
Thanks
Perhaps you could translate the comments and prompts in the script to English, that might help some people to understand your script better.
Yes i will dot that asap
Also, please think about hosting the script on github etc. because you need to log in to download attachments and it's not very accessible inside a .zip file. This would also allow people to report issues or suggest changes to the script.
exact, il will do that
Personally, in the code, I would have liked an overview like "the following functions are defined, this one does that and calls the next one" etc. as a description, but I was able to figure out what it did in general.

There was some commented out stuff there, looks like preparation for Version 2 with LVM-Snapshot autoextension or something? Currently it'll probably need the same amount of space allocated for VM disks as unallocated space in the LVM VG...
The script allocate 50% of original disk as snapshot, but it could be less for example 1% or 5% then autoextend would do extend if write io rate remain not too high. It depend of VM activity and if big modifications on disk will occur.
Did you try it with multiple hosts? Like moving a VM after you did a Snapshot? Will the script find the snapshot on the new host?
Not tested on several hosts, but with shared LVM iscsi, the script will probably execute right on server that hosts the VM.
Can the script freeze the VM before taking the snapshot? Maybe leverage something like "qemu snapshot" as with backup until you've created the LVM snap? Maybe not needed, but I don't know if it could help with a VM having multiple disks, so that it achieves a "crash consistent" snapshot state with all disks snapshotted at the same point in time or something.
No, no freeze implemented on script sorry. Script make lvm snapshot on all disk of the vm.
 
Great - I just thought that some more background information would be nice, like:

Script will find LVM volume for each Disk of given VM
It will then create a LVM snapshot with half the size of original disk - this is the amount of free space required in LVM.

The LVM snapshot tracks changes to original Volume, so when a snapshot is no longer needed, it can just be discarded (no additional I/O load).

Should a VM be very active writing changes to disk, the snapshot might fill up (What happens then?)

When a VM needs to be rolled back to a snapshot, it needs to be shut down first. To start the rollback, that is for some reason called "merge" in LVM, the VMs disk volumes will be deactivated and activated again. This will instantly allow the VM to boot with the previous state of the disks, but in the background LVM will move blocks around to revert the changes in original volume. (Additional space requirements?)

Edge cases: What about moving a VM to another host while a merge is underway? Is there a way to prevent that? But then you'd need to undo whatever you did to prevent the move after "LVM merge" is completed. Hmm.
 
Great - I just thought that some more background information would be nice, like:

Script will find LVM volume for each Disk of given VM
It will then create a LVM snapshot with half the size of original disk - this is the amount of free space required in LVM.
yes
The LVM snapshot tracks changes to original Volume, so when a snapshot is no longer needed, it can just be discarded (no additional I/O load).

Should a VM be very active writing changes to disk, the snapshot might fill up (What happens then?)
As i understand of LVM Snapshot, max size of snaphot size is the original disk size. So i think, the LVM snapshot track every change on every byte of the original disk, so if all disk is changed, max size of snapshot will be the original size. But it's a my theory.
When a VM needs to be rolled back to a snapshot, it needs to be shut down first. To start the rollback, that is for some reason called "merge" in LVM, the VMs disk volumes will be deactivated and activated again. This will instantly allow the VM to boot with the previous state of the disks, but in the background LVM will move blocks around to revert the changes in original volume. (Additional space requirements?)
Yes it is. I hav added an ehancement on that script that verify the status of lv just after deleting snapshot, to wait for end of merging task before end the script
Edge cases: What about moving a VM to another host while a merge is underway? Is there a way to prevent that? But then you'd need to undo whatever you did to prevent the move after "LVM merge" is completed. Hmm.
there are some tests to do for this. in my memories, the vm is shutdown and lvm is merging so perhaps the lv status prevent the vm to be moved
 
last version with lvm configuration directives on top, and wait for merging task before end the script
 

Attachments

  • pve_iscsi_lvm_snapshot.zip
    2.9 KB · Views: 11
Here is somethink to sync just the snapshot incrementals between hosts but never tested so if any has interests and time to understand what happens there (like zfs send/recv) take a look into and perhaps find useful inside or as whole : https://github.com/mpalmer/lvmsync .
 
I think the sync of snapshots isn't needed, because it's LVM on a shared iSCSI LUN - the other hosts also should be able to see the snapshots.
 
Yes I know not used in this case directly but if you want a DR storage of that shared storage that lvmsync go further for solution :)
 
Just found this thread ... is this not just the almost the same as the ZFS-over-iSCSI plugin, yet instead LVM-over-iSCSI? Have you tried to copy and adapt the plugin?
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!