kladderadeng commented on issue #10487: URL: https://github.com/apache/cloudstack/issues/10487#issuecomment-2727237547
Thanks everyone and sorry for the delay. I had to reinstall the whole environment because the system used is undergoing tests with various Hypervisors. But I am back to ACS now and am able to replicate the issue. @rajujith Thank you. I understand now that the process is different. I also read that this feature is probably not the right one to prepare for a disaster recovery, so we will have to look for other solutions. @abh1sar Thank you for the detailed step by step explanation. That helps a lot. Regarding your question about the qcow2 file in the /tmp folder: There is none created. The folder and in it a backup.xml is created, though. The auto-created backup.xml looks like this: ```xml <domainbackup mode='push'><disks> <disk name='sda' backup='yes' type='file' backupmode='full'><driver type='qcow2'/><target file='/tmp/csbackup.jlJQw/i-2-16-VM/2025.03.16.07.05.01/root.1b677e62-95d0-43b2-be8d-d7d1919c950f.qcow2' /></disk> </disks></domainbackup> ``` Permissions are this: ``` 7 -rw-r--r-- 1 nobody root 263 Mar 16 07:05 /tmp/csbackup.jlJQw/i-2-16-VM/2025.03.16.07.05.01/backup.xml ``` About manual testing: Since the structure of your sample.xml gave me an error that it does not fit to the schema, I tried to create my own with the help of https://libvirt.org/formatbackup.html, but failed too (skill issue, I am pretty sure ;-) ). I tried to use the one that ACS / virsh auto-created in the /tmp folder and as expected, this replicates the error I found in the logs: ``` root:~# virsh backup-begin i-2-16-VM --backupxml /tmp/csbackup.jlJQw/i-2-16-VM/2025.03.16.07.05.01/backup.xml error: internal error: unable to execute QEMU command 'blockdev-add': Could not open '/tmp/csbackup.jlJQw/i-2-16-VM/2025.03.16.07.05.01/root.1b677e62-95d0-43b2-be8d-d7d1919c950f.qcow2': Permission denied ``` I ruled out "true" permission issues when I created this issue, but after @rajujith pointed out that the backup procedure of turned on / off instances is different, I wonder if changing something on the permission side would help. I did not add any mount options when mounting the NFS share while creating the Backup Repository in ACS, though. So I went back to my NAS NFS share and added a maproot --> root to see what it does. And now the Live backup started. It seems I was able to fix it by adjusting the default permissions for the NFS share on the NAS side. What I do not get is, why is the offline backup working and the online backup now. There is a different way how the NFS share is mounted, right? -- 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]
