Hello Nir,
Sorry for delay in my reply to you.
$ git log --onelinedd2d7d391fa (HEAD -> master, origin/master, origin/HEAD) core: CreateSnapshotDisk - validate specified disk
d2af151b9ca engine: add warning message for low space for re attached storage domain
d068d4da10c core: prevent exporting a VM to a data domain with illegal disks
945afdc5b13 core: rephrase backup audit log messages
ae1c762858a core: Add VM_INCREMENTAL_BACKUP_FAILED_FULL_VM_BACKUP_NEEDED audit log
3cd2766ae15 core: set image initial size on CreateSnapshot
fd19d1cc73f packaging: backup: Handle grafana
4c5a5305843 build: post ovirt-engine-4.4.1
1997cba811f (tag: ovirt-engine-4.4.1) build: ovirt-engine-4.4.1
If you want to test it now, you can use install the ovirt-release-master.rpm:
It installs me version ovirt-release-master-4.4.0-0.3.master.20200527011524.gitbb3bf5a.el8.noarch. Are correct? In this version is fixed the problem?
Would there be a way to install this on an AMD Ryzen 7?It is to test environment. I have a problem with compatibility of cluster CPU =(. Would there be some way to bypass this restriction? Otherwise I would have to try it on another pc.
You can test now if you want. If you don't like to test a development version wait until the fixis released (check the related bug).
Yes, I'm interested to test. All the help you can give will be good.
However, why do you try to restore the snapshots ? We discussed this with several backupfolks and they were not interested in restoring snapshots, but restoring complete disk.
Assuming you backup using snapshots, and you have:
backup-day-3.qcow2backup-day-2.qcow2backup-day-1.qcow2
To restore a disk to the state in backup-day-3.qcow2 you don't need to upload the snapshotto storage. You can create a chain from these images:
qemu-img rebase -u -b backup-day-1.qcow2 -F qcow2 backup-day-2.qcow2qemu-img rebase -u -b backup-day-2.qcow2 -F qcow2 backup-day-3.qcow2
Note that you don't need to use disk uuids for the rebase, your qcow2 are not uploadedto ovirt so the backing chain is relevant only locally. upload_disk.py read the guestdata from the chain and upload the raw data to imageio server in ovirt.
Now you have this chain:
backup-day-1.qcow2 <- backup-day-2.qcow2 <- backup-day-3.qcow2 (top)
You an upload all the data in this chain to a new disk using:
upload_disk.py ... --disk-sparse --disk-format raw --sd-name my-domain backup-day-3.qcow2
This is basically like.
qemu-img convert -f qcow2 -O raw my-domain backup-day-3.qcow2 new-disk.raw
So you can continue to use snapshot for backup, but restore to a disk with a single layer.
It is a good suggestion. I think it is safer and faster than the solution I have (which is to upload all the snapshots and merge them).
Why block domain is a problem?
Because in iSCSI domains was this problem (Disks or volumes with
size > 1Gb couldn't upload). I only tested
with iSCSI domains and I extrapolated to all block domains.
Why do you need a snapshot clone? You can download a snapshot from any storagewithout cloning the snapshot.
I before Ovirt 4.0, I cloned the VM from a snapshot, and I
download full disk of cloned VM. Now, (Before of I will apply this
fix) I can download a snapshot, but the problem is that I couldn't
upload these downloaded snapshots.
You may be interested in this talk:
They are very interesting and very clear. Congratulations!!
However, I have questions:
- Can I apply several simultaneous connections while upload image(I don't know if it makes a lot of sense, or if performance would be affected)? A example:
A process do(Takes 10ms, for example):
PUT /images/xxx-yyy?flush=n HTTP/1.1
Content-Range: bytes 0 - 123456/*
Content-Length: 123457
And other process(Takes also 10ms, for example):
PUT /images/xxx-yyy?flush=n HTTP1.1
Content-Range: 1234567 - 246913
Content-Length: 123457
Could it improve performance x2 (Approx) ?
- Is Zero feature available in JAVA SDK? Or would I have to implement it?
Best regards,
Fran