We had some problems with restoring VMs in the last time.
After some research we found that the Proxy on Linux has a problem with the assignments of physical volumes. It seems that there are PVs of target machines are preserved in the LVM archive files of the proxy… This is causing problems at restore time – leaving the restored VMs unbootable.
I have double checked the Veeam documentation about prerequisites (https://helpcenter.veeam.com/docs/backup/vsphere/backup_proxy_requirements.html?ver=110) and found no hint that LVM is a problem with Linux proxy.
The problem occurred with Suse Linux only, we are in the process to check if there is the same problem with RedHat Linux.
To visualize the problem, I will show it from the Veeam Proxy perspective and from the target VMs perspective.
Veeam Proxy
List the physical volumes with pvs. One device is not found…
Grep for the UUID of the missing volume in the directory /etc/lvm/archive
In this case the UUID is found in three files. At these three occasions this volume was seen as a local physical volume of the proxy and saved into the LVM archive…
![](https://uploads-eu-west-1.insided.com/veeam-en/attachment/9a734314-09ae-4edd-85f5-5baeb906f554.png)
To which target VM belongs this device originally?
Our Linux administration team has a central index of the PVs of all VMs. So, they can search for the UUID.
![](https://uploads-eu-west-1.insided.com/veeam-en/attachment/e175b670-ceb9-431f-8d41-3e5c779e0276.jpg)
Now we know that the target VM with the number 121 is the one who owns the original PV.
Target VM
On the target VM a physical volume with the offending UUID can be found (this is the intended location of this PV ).
![](https://uploads-eu-west-1.insided.com/veeam-en/attachment/24d3e9b4-6b62-4ca7-9f14-2d2b6d6bafe6.png)
Conclusion
So, it seems that the usage of LVM on the Veeam proxy can damage the management of the PVs on the proxy. In this case the target VM was not bootable after restoring, because the described PV was not correctly assigned to the VM.
There is no error in Veeam at backup or restore, all is looking good. But the restored VM is not bootable. So, this is very good argument to use Sure backup and Data Labs to make sure your backups are restorable and functional.
We had this problem on Suse Linux only up to now. But we will setup all our Linux proxy VMs with LVM now, regardless if they are running on Suse or RedHat Linux.
In the meantime, Veeam support has answered and confirmed that LVM should not be used on Linux Proxys. Unfortunately, this is not reflected in the documentation. I hope this will be updated shortly.
Don’t use LVM on any Linux proxy. Deactivate it, or better, don’t install it on the proxy VM.