Hello Nir,
Sorry for delay in my reply to you.
$ git log --oneline
dd2d7d391fa (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:
dnf install
http://resources.ovirt.org/pub/yum-repo/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 fix
is 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 backup
folks and they were not interested in restoring snapshots, but
restoring complete disk.
Assuming you backup using snapshots, and you have:
backup-day-3.qcow2
backup-day-2.qcow2
backup-day-1.qcow2
To restore a disk to the state in backup-day-3.qcow2 you don't need to
upload the snapshot
to storage. You can create a chain from these images:
qemu-img rebase -u -b backup-day-1.qcow2 -F qcow2 backup-day-2.qcow2
qemu-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 uploaded
to ovirt so the backing chain is relevant only locally. upload_disk.py
read the guest
data 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).
On 5/25/20 12:42 AM, Nir Soffer wrote:
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
storage
without 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.
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