On Sun, Mar 09, 2025 at 23:40:30 +0100, Michael Niehren wrote:
> Hi,
>
> i just playing around with the "new" backup API for switching from the old way and simply want
> to do full backup's in push mode. If i do so,
>
> virsh backup-begin <domain>
>
> the backup-Image files are always created in the image directory
>
>
>
> As the place on the fast nvme's, where the images are lying is very limited, i want to place the
>
> backup-image files to be on another harddisk on an mounted dir whithout temporary save them
>
> in the image directory.
This is already possible but you need to configure the backup by passing
the '--backupxml' argument to 'virsh backup-begin' such as:
<domainbackup mode='push'>
<disks>
<disk name='vda' type='file'>
<driver type='qcow2'/>
<target file='/path/to/backup-vda.qcow2'/>
</disk>
</disks>
</domainbackup>
> To do so, an --targetdir option on backup-begin would be very useful.
The philosophy of the 'virDomainBackupBegin()' API and any API that
creates images on user's behalf is to allow configuring the path in the
XML. We do provide a default but that is deliberately limited because
any form of flexibility increases the corner cases that the algorithm
can hit. The algorithm to create the default paths is deliberately
simple and non-flexible as the users can override it via XML.
The 'virsh backup-begin' similarly to other commands such as 'virsh
snapshot-create' are meant as raw argument passtrhough to the underlying
API thus also doesn't offer any form of syntax sugar.
What would be possible and in line with existing design is to have
'virsh backup-begin-as' taking commandline parameters to create the XMLs
on your behalf. For backup target we could model it similarly to
'--diskspec' for snapshot-create-as. The argument namign would need to
change as the backup API takes actually two XML documents, both of which
can specify a list of disks.
Thus while extending the default path generator is out of scope, the
syntax-sugar enhanced virsh command is definitely in line what virsh
provides.
Feature requests are tracked in the upstream gitlab issue tracker:
https://gitlab.com/libvirt/libvirt/-/issues/new
Make sure to select the 'Enhancement' template for RFEs.
