Currently I am evaluating/testing a KVM based virtualisation host solution (small installation) where I indent to run Clonezilla on the host itself in an maintenance window. Since I read a lot of hints of using LVM volumes instead of regular harddrive files for better performance and less SSD wearing, I made a LVM based host setup.
messages and as a result, only the /boot partition outside the LVM and the virtual hard drive (I setup a Windows 10 guest) inside the thin pool is backed up (Clonezilla used dd mode). All other volumes are missing.
It may be helpful to clarify how the current Clonezilla version handles LVM2 in general (supported and unsupported LVM setup scenarios), especially where there are some regular volumes as well as a thin pool inside the same volume group.
As a feature request, the following idea might be senseful for a future version: Consider LVMs as a container of sub hard drives. So a outer
foreach lv in lvdisplay
loop should run. On every LV try to detect for valid file systems first, then also check for a partition table (GPT and MBR). When neither nor can be found, use dd. In case of a valid partition table, a sub directory should be created and partclone should be run. In my example, Clonezilla then would detect the NTFS drives of my Windows 10 guest which then can be backed up like a physical Windows 10 installation.
The restore process should run in reverse direction: Create the PV/VG/LVs as saved in the backup set, then run the restore partclone operations on the LVs itself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the meantime, I setup a new variant: All KVM host OS parts inside classic ext4 partitions while the virtual hard disks use a VG containg a single thin pool only with all virtual hard drives attached (I set up two Windows guests inside Proxmox).
First done a backup with Clonezilla; at least, all virtual hard drives were also backuped but the verification process shows some error messages. After that, the whole SSD RAID-1 array wiped out / all sectors blkdiscard-ed and then running a restore (simulation a disaster recovery situation, i.e. bare metal Clonezilla restore process).
The classic paritions were not a problem; the host OS restarted fine as expected. But restoring the LVM2 causes a lot of troubles beginning with LV Status NOT available in the lvdisplay output. Trying out to fix them shows messages like
Also tried out commands like lvconvert --repair and vgck but no success.
The only passible way: Deleting the whole VG and recreating it, i.e. beginning with lvremove pve vm-100-disk-0 and ending with pvremove /dev/md126p10 then trimming all sectors on the SSDs using blkdiscard /dev/md126p10 in my case. After that, recreating the whole LVM structure manually, i.e.
in general but with customized partition/LVM layout as shown in the collected data. After setting up it's recommended to setup 2 guest systems at least so there is some material in the LVM for testing the backup and restore process.
The easier test case would be a LVM with thin pool for the virtual hard drives only. The more advanced test case would be when /boot is a regular partition only while /, /home, /var and so on are all LVs in combination with xfs which allow resizing without umount or reboot required.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mmm.. Actually Clonezilla does not support thin provisioning LVM, due to some tools do not have required functions.
So your issue is about thin provisioning LVM? If so, for the moment it's can not be done.
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In short: conventional LVs which means thick provisioning from the hypervisor perspective.
As you can see in the collected log files, this case works without error. The only big issue: On a virtualisation host, you typically don't use the whole disk space inside the volume group since the free space is needed for further VMs, creating snapshots and so on. The current implementation tries to resize all LVs proportionally which is not desired on a virtualisation host. So the behaviour to restore every LV to it's original size ist much mor useful.
Keeping the LV's original size should be the standard behaviour when using beginner mode for restoredisk. On the expert mode, an option like
[x] LVM2: resize LVs to use the whole disk space (unchecked=restore LVs in its original size)
would be the senseful way to support this option.
Thin pool support should be also placed as feature request for a future Clonezilla version.
Note: Snapshot on LVs and KVM is a separate topic (RAW instead of QCOW2) as I have tested today which does not affect Clonezilla.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the meantime, a full backup / wipe HD / restore process done: It works, when using conventional LVM, i.e. no thin pool.
During watching the restore process, I saw some lvresize commands. So the improvement for the next release is just leave away these commands which I currently have to undo using lvreduce to put it to the original LV size.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So the improvement for the next release is just leave away these commands which I currently have to undo using lvreduce to put it to the original LV size." -> Are you sure? I believe there is more.
Actually tried to support thin provisioning LVM in Clonezilla. However, we encountered this issue: https://github.com/jthornber/thin-provisioning-tools/issues/126
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the meantime I tested the latest 3.1.3-16 release with LVM. Used test scenario does not use thin pool, i.e. should be compatible with the current Clonezilla release. Result: Several red messages still appears. Details see
First I thought that something could be corrupted on the test LVM so I tested the following long way: Backed up all LVs, then delete everything and then recreating the whole LVM again. Result:
I still got the red messages. So I made some observations. Debian 12 (Bookworm) on my test system uses 2.03.16(2) (2022-05-18) while the Clonezilla live system uses 2.03.22(2) (2023-08-02) (see the lvm_version*.txt files). Another hint for you: lvdisplay/vgdisplay used in the Clonezilla live USB cmd environment shows a
which this does not appear when done on the Debian 12 host system. So I suppose a LVM version issue here.
Next test I will do: Backing up LVs and deleting LVM completely again but recreating it from the Clonezilla USB live environment because I suppose a version issue somewhere.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the meantime, LV recreation from Clonezilla's live environment is done and backup repeated. Result: The same error messages. So the LVM version is not the root cause. Details see
But I observed something very weird: When going to the shell (cmd) after the backup, lvdisplay shows warnings (lvdisplay_warnungen.txt) and one LV shows NOT available as status.
When I boot from the stick and go to the shell (cmd) directly instead of "Start_Clonezilla" and do the lvdisplay command, then all LVs show status availabe and now warning appears. See also the differences (lvdisplay_diff.txt).
Note: On Clonezilla version 3.1.2-22, these red messages didn't appear, i.e. I was able to backup my test system without errors, so this seems to be a new bug.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Mm... If you are able to reproduce this issue in a virtual machine, please share the files of the virtual machine so that we can try to reproduce this issue here. Otherwise it's not easy to debug and fix it here.
Thanks.
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the meantime, the puzzle about red message seems to be solved: In the current Clonezilla version, LVs must contain some content (partitions), i.e. empty LVs (all sectors zeroed) caused the errors as reported before (this happens witgh current 3.1.3-16 as well as 3.1.2-22 version).
Remark: The vboxhd-vboxnetw65 LV was from a failed VirtualBox NetWare installation test (CD boot aborded) so it was empty. So I applied the following steps before:
i.e. the current 3.1.3-16 release was able to backup my test system successfully, i.e. no red message at the end. Take care on lsblk.txt: All LVs contain partitions. Take also care on lvdisplay.txt: All LVs remain status available.
Next step will be the disk wipe and restore test where you will get feedback at given time.
You should able to reproduce the bug by just creating a new LV and leaving it empty.
Last edit: dreael 2024-08-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In the meantime, the restore test using 3.1.3-16 has also been done.
In general, it worked fine. The only still open issue: Alle LV sizes are increased to allocate the whole VG's space instead remaining the original LV's size so I have to lvreduce every LV manually to its original size first. I also checked teh expert mode for new options. Details see
In short: The current Clonezilla is usable for my projekt when taking care about known issues (no thin pool, all LVs must contain content like partitions and lvreduce must be applied after a full restore, so documenting the original LV sizes using lvdisplay before backup is recommended).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the hint about deactivating the -r option. I successfully tested it recently, i.e. all the LVs keep their size.
Suggestion for the next version: Why not set -r disabled as default option, i.e. default behaviour should be keep all sizes and partition positions to the original values. Another approach may be compare the disk size (savedisk documents it in the partition table file). When it is equal (same hardware as used for the backup or same model found) then -r should be disabled by default, otherwise the user can be asked.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"Suggestion for the next version: Why not set -r disabled as default option, i.e. default behaviour should be keep all sizes and partition positions to the original values. Another approach may be compare the disk size (savedisk documents it in the partition table file). When it is equal (same hardware as used for the backup or same model found) then -r should be disabled by default, otherwise the user can be asked." -> Thanks for your suggestion. We will think about how to make it better.
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please give testing Clonezilla live >= 3.2.0-22 or 20241201-* a try.
The way you mentioned has been implemented, i.e., by default "-r" option is not on.
When the option "-k1" is used, "-r" option will be added, too.
Please let us know the results. Thanks.
Steven
Last edit: Steven Shiau 2024-12-01
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I'm facing the same issue (TASK ERROR: activating LV 'pve/data' failed: Thin pool pve-data-tpool (252:4) transaction_id is 0, while expected 726.) after creating an image of a disk and trying to restore it on a different machine.
I've tried restoring the backup with Clonezilla live version 3.2.0-29 (the image was created with version 3.2.0-5, but I can create it again with a different version if needed), but unfortunally I´m still getting the same error after restoring the backup.
I have used option -k0 to keep the same partition size, and I double-checked and made sure the option "-r" in the advance options was not selected, is there any other option I can try to see if it fix the issue?
Last edit: Victor 2024-12-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Clonezilla developers
Currently I am evaluating/testing a KVM based virtualisation host solution (small installation) where I indent to run Clonezilla on the host itself in an maintenance window. Since I read a lot of hints of using LVM volumes instead of regular harddrive files for better performance and less SSD wearing, I made a LVM based host setup.
The issue: First I got
messages and as a result, only the /boot partition outside the LVM and the virtual hard drive (I setup a Windows 10 guest) inside the thin pool is backed up (Clonezilla used dd mode). All other volumes are missing.
I collected all important details at
https://beilagen.dreael.ch/Diverses/Clonezilla_LVM_Problem/
It may be helpful to clarify how the current Clonezilla version handles LVM2 in general (supported and unsupported LVM setup scenarios), especially where there are some regular volumes as well as a thin pool inside the same volume group.
As a feature request, the following idea might be senseful for a future version: Consider LVMs as a container of sub hard drives. So a outer
loop should run. On every LV try to detect for valid file systems first, then also check for a partition table (GPT and MBR). When neither nor can be found, use dd. In case of a valid partition table, a sub directory should be created and partclone should be run. In my example, Clonezilla then would detect the NTFS drives of my Windows 10 guest which then can be backed up like a physical Windows 10 installation.
The restore process should run in reverse direction: Create the PV/VG/LVs as saved in the backup set, then run the restore partclone operations on the LVs itself.
Thanks for your feedback. We will read that and try to improve that in the future.
Steven
In the meantime, I setup a new variant: All KVM host OS parts inside classic ext4 partitions while the virtual hard disks use a VG containg a single thin pool only with all virtual hard drives attached (I set up two Windows guests inside Proxmox).
First done a backup with Clonezilla; at least, all virtual hard drives were also backuped but the verification process shows some error messages. After that, the whole SSD RAID-1 array wiped out / all sectors blkdiscard-ed and then running a restore (simulation a disaster recovery situation, i.e. bare metal Clonezilla restore process).
The classic paritions were not a problem; the host OS restarted fine as expected. But restoring the LVM2 causes a lot of troubles beginning with
LV Status NOT availablein thelvdisplayoutput. Trying out to fix them shows messages likeAlso tried out commands like
lvconvert --repairandvgckbut no success.The only passible way: Deleting the whole VG and recreating it, i.e. beginning with
lvremove pve vm-100-disk-0and ending withpvremove /dev/md126p10then trimming all sectors on the SSDs usingblkdiscard /dev/md126p10in my case. After that, recreating the whole LVM structure manually, i.e.Restore process itself:
Note the
sparseoption to keep the thin pool LVs really thin.At least, both my Proxmox guest boot successfully.
All details are collected at
https://beilagen.dreael.ch/Diverses/KVM2_LVM_nurThinPool_Clonezilla/
Thanks for considering in a future Clonezilla release in advance.
Thanks for updating that. Is that possible you can share the VM with us? We'd like to reproduce this issue, and try to improve it.
Steven
I ran Clonezilla on a physical system which is set up as shown in
https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_12_Bookworm
in general but with customized partition/LVM layout as shown in the collected data. After setting up it's recommended to setup 2 guest systems at least so there is some material in the LVM for testing the backup and restore process.
The easier test case would be a LVM with thin pool for the virtual hard drives only. The more advanced test case would be when
/bootis a regular partition only while/,/home,/varand so on are all LVs in combination with xfs which allow resizing withoutumountor reboot required.Mmm.. Actually Clonezilla does not support thin provisioning LVM, due to some tools do not have required functions.
So your issue is about thin provisioning LVM? If so, for the moment it's can not be done.
Steven
In the meantime a new scenario tested for you:
https://beilagen.dreael.ch/Diverses/KVM1_Clonezilla_LVM_konventionell_ohne_ThinPool/
In short: conventional LVs which means thick provisioning from the hypervisor perspective.
As you can see in the collected log files, this case works without error. The only big issue: On a virtualisation host, you typically don't use the whole disk space inside the volume group since the free space is needed for further VMs, creating snapshots and so on. The current implementation tries to resize all LVs proportionally which is not desired on a virtualisation host. So the behaviour to restore every LV to it's original size ist much mor useful.
Keeping the LV's original size should be the standard behaviour when using beginner mode for restoredisk. On the expert mode, an option like
[x] LVM2: resize LVs to use the whole disk space (unchecked=restore LVs in its original size)
would be the senseful way to support this option.
Thin pool support should be also placed as feature request for a future Clonezilla version.
Note: Snapshot on LVs and KVM is a separate topic (RAW instead of QCOW2) as I have tested today which does not affect Clonezilla.
In the meantime, a full backup / wipe HD / restore process done: It works, when using conventional LVM, i.e. no thin pool.
During watching the restore process, I saw some
lvresizecommands. So the improvement for the next release is just leave away these commands which I currently have to undo usinglvreduceto put it to the original LV size.So the improvement for the next release is just leave away these commands which I currently have to undo using lvreduce to put it to the original LV size." -> Are you sure? I believe there is more.
Actually tried to support thin provisioning LVM in Clonezilla. However, we encountered this issue:
https://github.com/jthornber/thin-provisioning-tools/issues/126
Steven
In the meantime I tested the latest 3.1.3-16 release with LVM. Used test scenario does not use thin pool, i.e. should be compatible with the current Clonezilla release. Result: Several red messages still appears. Details see
https://beilagen.dreael.ch/Diverses/KVM2_LVM_ohneThinpool_Clonezilla_aktVers/
First I thought that something could be corrupted on the test LVM so I tested the following long way: Backed up all LVs, then delete everything and then recreating the whole LVM again. Result:
https://beilagen.dreael.ch/Diverses/KVM2_LVM_ohneThinpool_Clonezilla_LVM_neu/
I still got the red messages. So I made some observations. Debian 12 (Bookworm) on my test system uses 2.03.16(2) (2022-05-18) while the Clonezilla live system uses 2.03.22(2) (2023-08-02) (see the lvm_version*.txt files). Another hint for you: lvdisplay/vgdisplay used in the Clonezilla live USB cmd environment shows a
which this does not appear when done on the Debian 12 host system. So I suppose a LVM version issue here.
Next test I will do: Backing up LVs and deleting LVM completely again but recreating it from the Clonezilla USB live environment because I suppose a version issue somewhere.
In the meantime, LV recreation from Clonezilla's live environment is done and backup repeated. Result: The same error messages. So the LVM version is not the root cause. Details see
https://beilagen.dreael.ch/Diverses/KVM2_LVM_ohneThinpool_Clonezilla_LVM_LiveUmg/
But I observed something very weird: When going to the shell (cmd) after the backup,
lvdisplayshows warnings (lvdisplay_warnungen.txt) and one LV showsNOT availableas status.When I boot from the stick and go to the shell (cmd) directly instead of "Start_Clonezilla" and do the
lvdisplaycommand, then all LVs show statusavailabeand now warning appears. See also the differences (lvdisplay_diff.txt).Note: On Clonezilla version 3.1.2-22, these red messages didn't appear, i.e. I was able to backup my test system without errors, so this seems to be a new bug.
Mm... If you are able to reproduce this issue in a virtual machine, please share the files of the virtual machine so that we can try to reproduce this issue here. Otherwise it's not easy to debug and fix it here.
Thanks.
Steven
In the meantime, the puzzle about red message seems to be solved: In the current Clonezilla version, LVs must contain some content (partitions), i.e. empty LVs (all sectors zeroed) caused the errors as reported before (this happens witgh current 3.1.3-16 as well as 3.1.2-22 version).
Remark: The
vboxhd-vboxnetw65LV was from a failed VirtualBox NetWare installation test (CD boot aborded) so it was empty. So I applied the following steps before:(creating a FAT16 partition)
Result:
https://beilagen.dreael.ch/Diverses/KVM2_LVM_ohneTP_alleLVs_part/
i.e. the current 3.1.3-16 release was able to backup my test system successfully, i.e. no red message at the end. Take care on
lsblk.txt: All LVs contain partitions. Take also care onlvdisplay.txt: All LVs remain status available.Next step will be the disk wipe and restore test where you will get feedback at given time.
You should able to reproduce the bug by just creating a new LV and leaving it empty.
Last edit: dreael 2024-08-28
In the meantime, the restore test using 3.1.3-16 has also been done.
In general, it worked fine. The only still open issue: Alle LV sizes are increased to allocate the whole VG's space instead remaining the original LV's size so I have to
lvreduceevery LV manually to its original size first. I also checked teh expert mode for new options. Details seehttps://beilagen.dreael.ch/Diverses/KVM2_LVM_ohneTP_Restore3_1_3-16/
In short: The current Clonezilla is usable for my projekt when taking care about known issues (no thin pool, all LVs must contain content like partitions and
lvreducemust be applied after a full restore, so documenting the original LV sizes usinglvdisplaybefore backup is recommended).Thanks for your feedback.
"The only still open issue: Alle LV sizes are increased to allocate the whole VG's space instead remaining the original LV's size" ->
You can enter expert mode, and deselect the option "-r":
https://clonezilla.org//clonezilla-live/doc/02_Restore_disk_image/advanced/09-advanced-param.php
Steven
Thanks for the hint about deactivating the
-roption. I successfully tested it recently, i.e. all the LVs keep their size.Suggestion for the next version: Why not set
-rdisabled as default option, i.e. default behaviour should be keep all sizes and partition positions to the original values. Another approach may be compare the disk size (savediskdocuments it in the partition table file). When it is equal (same hardware as used for the backup or same model found) then -r should be disabled by default, otherwise the user can be asked."Suggestion for the next version: Why not set -r disabled as default option, i.e. default behaviour should be keep all sizes and partition positions to the original values. Another approach may be compare the disk size (savedisk documents it in the partition table file). When it is equal (same hardware as used for the backup or same model found) then -r should be disabled by default, otherwise the user can be asked." -> Thanks for your suggestion. We will think about how to make it better.
Steven
Please give testing Clonezilla live >= 3.2.0-22 or 20241201-* a try.
The way you mentioned has been implemented, i.e., by default "-r" option is not on.
When the option "-k1" is used, "-r" option will be added, too.
Please let us know the results. Thanks.
Steven
Last edit: Steven Shiau 2024-12-01
Hi, I'm facing the same issue (
TASK ERROR: activating LV 'pve/data' failed: Thin pool pve-data-tpool (252:4) transaction_id is 0, while expected 726.) after creating an image of a disk and trying to restore it on a different machine.I've tried restoring the backup with Clonezilla live version 3.2.0-29 (the image was created with version 3.2.0-5, but I can create it again with a different version if needed), but unfortunally I´m still getting the same error after restoring the backup.
I have used option -k0 to keep the same partition size, and I double-checked and made sure the option "-r" in the advance options was not selected, is there any other option I can try to see if it fix the issue?
Last edit: Victor 2024-12-28
LVM thin provisioning is not supported ATM, as mentioned here:
https://sourceforge.net/p/clonezilla/discussion/Open_discussion/thread/6a5322bf85/
"that's still an issue due to some tools are not available for Clonezilla to do that. For more info, please check:
https://github.com/jthornber/thin-provisioning-tools/issues/126
"
Steven