On Tue, Jun 29, 2021 at 9:09 AM Laurent Duparchy <duparchy@esrf.fr> wrote: ...
This is valuable information. I didn't read it anywhere so far. We'll have to evaluate what impact this way of snapshoting has on performances.
Sure, keeping many snapshots is not recommended. You should not treat snapshots as long term backup, only as a temporary state to make it easy to revert changes in the vm. It makes sense to always keep one snapshot for backup purposes. Backup applications using snapshots use this algorithm: Day 1: 1. Create temporary snapshot (e.g. backup-1) 2. Backup snapshot backup-1 (e.g. using image transfer API) Day 2: 1. Create temporary snapshot (e.g. backup-2) 2. Backup snapshot backup-2 3. Delete snapshot backup-1 Day N: 1. Create temporary snapshot (e.g. backup-N) 2. Backup snapshot backup-N 3. Delete snapshot backup-(N-1) To download snapshot you can use this example: https://github.com/oVirt/ovirt-engine-sdk/blob/sdk_4.3/sdk/examples/download... The example is not very good, and it downloads all snapshots instead of one but you can use it as an example how to create a transfer for disk snapshot.
Thanks a lot.
Allow me one last question before I stop spamming you...
Using virt-v2v for migration from Oracle VM ("raw" files) to KVM, it seems that the "preallocated" option for (iSCSI) LVM volumes is mandatory.
virt-v2v supports converting to format="qcow2" sparse=True. This should work with ovirt 4.3, but there is no way to use these options from the UI. If you convert in two steps: - from oracle vm to local file - from local file to ovirt and if you have recent enough virt-v2v, you should be able to choose the image format "qcow2" and allocation "sparse". -oa <sparse|preallocated> Set output allocation mode -of <raw|qcow2> Set output format One issue with virt-v2v is that it always allocates entire disk, even when using sparse disk, since it does not how to estimate the size of the disk: https://github.com/libguestfs/virt-v2v/blob/62c493e314f2d50db54079cd90c0d5a4... To shrink the disk size to optimal size, you can reduce the disk after the import: https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/reduce_di...
We may have to change some currently large volumes to thin-provisionning. What would be the fastest way to do that ? (maybe directly, not in a two phases migrations)
I think the simplest way to do this on 4.3 is to create a template from the vm, and choose qcow2 disk format. When the template is ready, you can create the vm back from the template, and delete the template. This requires downtime during the conversion. In 4.4. you can create a template from a snapshot to avoid the downtime. We are working on a disk conversion feature for 4.4.9, @Benny Zlotnik can add more info. Nir