On Mon, Jun 28, 2021 at 11:07 AM Laurent Duparchy <duparchy@esrf.fr> wrote:

Hi,

Thanks you for your response.

I'm new to ovirt / LVM (Oracle flavor). I'm wondering why LVM snapshots don't have the "s" attribute. ..

We don't use LVM snapshots for VM disks. oVirt snapshots are using qcow2 logical volumes per VM snapshots. For example VM can start with one logical volume: /dev/vgname/lv-1 When you create a snapshot in engine, ovirt creates new logical volume: /dev/vgname/lv-2 And creates a qcow2 image using /dev/vgname/lv-1 as the backing file: /dev/vgname/lv-1 <- /dev/vgname/lv-2 (top)

( I noticed it while looking for the best way to backup the VMs to tape.

The best way with oVirt 4.4 is to use incremental backup, but you are likely using 4.3. There are several backup solutions that use snapshots to create incremental backup. This is more complex and less efficient but it should be available for your version.

We must have an offline & out-of-band backup to tape which is part of our "Disaster Recovery Plan". At the moment a (most simple) "dd" of the entire Volume Group seems OK. Nevertheless checking if more granular is possible... Keeping things simple being a goal. )

Keeping things simple backup at the storage side at the LUN level is probably the simplest way. It may also be the most efficient way depending on the storage capabilities, for example if your storage supports thin provisioning. But note that backup in storage level can create inconsistent backup, so starting a VM after restore may require running fsck. Using snapshots or incremental backup should generally avoid this issue if the VMs have qemu-guest-agent. Nir

Laurent Duparchy ESRF - The European Synchrotron MIS Group 04 76 88 22 56 / 06 71 10 38 40

Nir Soffer wrote on 21/06/2021 21:35:

On Mon, Jun 21, 2021 at 10:29 PM <duparchy@esrf.fr> wrote:

Hi, What are the internal commands used to clone LVM partitions ?

Are you sure this is the right mailing list?

(you can simply indicate me the source code where this is done)

If you mean how we copy disks lvm based disks (e.g. on FC/iSCSI storage domain), we use this: https://github.com/oVirt/vdsm/blob/4f728377f6cd6950035a7739014737789a4d6f14/...

Most flows uses this API for copying disks: https://github.com/oVirt/vdsm/blob/master/lib/vdsm/storage/sdm/api/copy_data...

Nir

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