On Tue, Jun 29, 2021 at 9:09 AM Laurent Duparchy <duparchy(a)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/downl...
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/62c493e314f2d50db54079cd90c0d...
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...
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