akoskuczi-bw opened a new issue, #14291:
URL: https://github.com/apache/cloudstack/issues/14291
### problem
When restoring a KVM virtual machine using the CloudStack Veeam integration,
the restore fails if the original template from which the VM was deployed has
already been deleted from CloudStack.
The VM backup contains the complete root disk and the VM configuration, so
the original template image should not be required to restore the VM.
However, the exported/restored VM metadata still references the original
CloudStack template ID.
Example from the restore metadata:
```
<TemplateId>9c12bd7a-3a78-42dc-9bc2-20939014640f</TemplateId>
<TemplateName>9c12bd7a-3a78-42dc-9bc2-20939014640f</TemplateName>
<OriginalTemplateId>9c12bd7a-3a78-42dc-9bc2-20939014640f</OriginalTemplateId>
<OriginalTemplateName>9c12bd7a-3a78-42dc-9bc2-20939014640f</OriginalTemplateName>
The root disk section also contains the same template reference:
<rasd:Template>9c12bd7a-3a78-42dc-9bc2-20939014640f</rasd:Template>
```
If this template no longer exists in CloudStack, the VM cannot be restored.
### versions
Ubuntu 24.04 KVM Hypervisors
Ubuntu 24.04 Management server
Cloudstack: 4.23.0.0
### The steps to reproduce the bug
1. Create a template in CloudStack.
2. Deploy a VM from that template.
3. Back up the VM using the CloudStack/Veeam integration.
4. Verify that the VM backup is successful.
5. Delete the original template from CloudStack.
6. Attempt to restore the previously backed-up VM.
7. The restore fails because the original template referenced by the VM
metadata is no longer available.
### What to do about it?
The restore process requires the original template referenced by TemplateId
/ OriginalTemplateId to still exist.
If the template has been deleted, the VM restore fails even though the
backup contains the VM root disk.
A VM backup should be independently restorable even if the original template
has been deleted.
During restore, the template reference should preferably be treated as
provenance/metadata rather than as a mandatory dependency.
Possible behavior could be:
if original template exists:
restore VM and preserve the template relationship
if original template does not exist:
restore VM from the backed-up root disk
mark original template as unavailable / null / deleted
The existence of the original template should not prevent restoration of a
VM whose root disk is fully contained in the backup. Deleting the original
template does not normally make an already deployed VM unusable.
Therefore, a VM-level backup should ideally not introduce a stronger
dependency on the original template than the running CloudStack VM itself has.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
