- Devel - oVirt List Archives

oVirt-4.4 on CetOS 8.2
by Dominik Holler 16 Jun '20

16 Jun '20

Hello, CentOS 8.2 was released before oVirt was prepared for CentOS 8.2 . Currently oVirt-4.4 fails to install on CentOS 8.2 . This will be fixed soon. Dominik

4 6

ovirt-engine has been tagged (ovirt-engine-4.4.1.4)
by Tal Nisan 16 Jun '20

16 Jun '20

1 0

/ovirt-engine/api/clusters takes over 2 minutes to responde
by marcel.hanke＠ionos.com 15 Jun '20

15 Jun '20

Hi, we currently have the problem that a call to /ovirt-engine/api/clusters takes over 2 minutes. I'd like to debug this, as this is new for the newer version (currently 4.3.9.4-1.el7). The issue only appears on larger setups, here as a example: costs: 188 clusters: 5 datacenter: 1 storage domains: 20 virtual machines: 3552 networks: 123 As I'm usually only a admin and not a developer for oVirt i don't know where to start debugging this issue. As this only appears in larger scales, our stage environment can't be used for debugging and getting into the code. Any advise on how to approach this? (to starting with smaller things, i don't have the time unfortunately) Thanks Marcel Hanke 1&1 IONOS SE

2 1

ovirt-engine has been tagged (ovirt-engine-4.4.1.3)
by Tal Nisan 10 Jun '20

10 Jun '20

1 0

ovirt-engine has been tagged (ovirt-engine-4.3.11)
by Tal Nisan 09 Jun '20

09 Jun '20

1 0

ovirt-engine has been tagged (ovirt-engine-4.4.1.2)
by Tal Nisan 03 Jun '20

03 Jun '20

1 0

OST on CentOS Stream
by Michal Skrivanek 02 Jun '20

02 Jun '20

Hi there, we have an issue with latest AdvancedVirt and our current CentOS 8.1 based OST. libguestfs seems to be always failing (tested by commented out virt-sparsify test, so it’s not visible normally) and we have no such issues when running same tests on RHEL 8.2. So I tried to move on and update to CentOS Stream and indeed it seems to be working ok. With CentOS 8.2 getting closer but not there yet maybe it’s best to use CentOS Stream for now. There is some interest from users as well, and we can’t really do anything to fix those 8.1 issues other than remove AV update and keep using old stuff with old bugs. To run on Stream we need two things. openvswitch compatible with 8.2/Stream. I used Dominik’s [1] and to fix apparently missing ansible-runner dependency on python3-pyutils (Martin, please address. I suppose it was a transient dep before and it was just dropped) I would suggest to move OST to CentOS Stream, and consider at least experimental support of CentOS Stream. It doesn’t seem like we’re missing much other than to point to the right repos. Thanks, michal [1] https://copr-be.cloud.fedoraproject.org/results/dominik/OpenvSwitch/epel-8-…

3 4

OST faiilures on he suites - missing `script` package
by Evgeny Slutsky 02 Jun '20

02 Jun '20

Hi, we 've started to get failures with our HE suits : *03:07:46* # /usr/bin/dnf --installroot /var/lib/mock/epel-7-x86_64-39127a08ee2e67d9ffa6f99a66a95b59-4799/root/ --releasever 7 --setopt=deltarpm=False --allowerasing --disableplugin=local --disableplugin=spacewalk install @buildsys-build python3 python3-pip python36-PyYAML python36-six python36-pyxdg python2 python2-pip python2-pyyaml python2-six python2-pyxdg ansible autoconf automake grubby lago lago-ovirt libselinux-python python-netaddr script virt-install wget docker python-pip python-virtualenv mkdocs fontawesome-fonts-web <https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-role-remote-suite…>*03:07:46* Failed to set locale, defaulting to C <https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-role-remote-suite…>*03:07:46* No match for argument: script <https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-role-remote-suite…>*03:07:46* Error: Unable to find a match: script https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-role-remote-suite… https://jenkins.ovirt.org/job/ovirt-system-tests_he-basic-role-remote-suite…

3 2

Add Evgheni Dereveanchin to ovirt quay owners group
by Nir Soffer 01 Jun '20

01 Jun '20

I suggest to add Evgheni to the owners group: https://quay.io/organization/ovirt/teams/owners So he managed groups and repos. Nir

2 1

Re: Problem with mixing all the changes
by Nir Soffer 28 May '20

28 May '20

On Wed, May 13, 2020 at 12:19 PM FMGarcia <francisco.garcia(a)wbsgo.com> wrote: Hi Fran, I'm moving the discussion to devel mailing list where it belongs. > In https://gerrit.ovirt.org/#/c/107082/ we have "several problems" to decide this patch: > > At the base (current version in github), the synergy ('download_disk_snapshot.py' and 'upload_disk_snapshot.py') does not working: > > 'Download_disk_snapshot.py' only download volumes of a disk. > 'Upload_disk_snapshot.py' requires: virtual machine configuration ('.ovf'), a only disk to upload in path './disks/xxxx', and manual action to attach disk to the vm. > > Then, I think that if you want a synergy with both scripts, we should change 'download_disk_snapshot.py' before that 'upload_disk_snapshot.py'. If not, you should edit 'upload_disk_snapshot.py' to add a variable 'vm_id'(as variable sd_name in this script) to attach the uploaded disk. I agree. It would be nice if we can do: $ mkdir -p backups/vm-id $ download_disk_snapshots.py --backup-dir backups/vm-id ... $ upload_disk_snapshots.py --backup-dir backups/vm-id ... download_disk_snapshots.py will download vm ovf and all disks. upload_disk_snaphsots.py would take the output of download_disk_snapshots.py and create a new vm. > I suppose that the best thing is to discard the gerrit, and to propose first what you want with 'download_disk_snapshot.py' and 'upload_disk_snapshot.py' and then act accordingly (several patch). Do you agree? This is a bigger change that can take more time. I think we better fix the issues in the current scripts - the first one is the missing attach disk that you fix in your patch. Since you posted this fix with a lot of other unrelated fixes (some wrong or unneeded), we cannot merge it. This is another reason to post minimal patches that do one fix. > I'm only truly interested in opened bug with block domain and volumes of > 1GB: https://bugzilla.redhat.com/show_bug.cgi?id=1707707. I make these changes to help a little since you would help me by solving the bug. I don't code in Python, I code in Java, using Java-sdk and the bug is a major limitation in my software, so I want resolve this bug (1 year old). =( I hope you understand. :) Sure, I understand. If you don't time to work on this, some other developer can take over this patch. The bug should be fixed by: https://gerrit.ovirt.org/c/108991/ It would be nice if you can test this. I started a build here: https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/5867/ When the build is ready, you will be able to install engine from this build by adidng a yum repo with the baseurl: https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/5867/artifa… Note that this requires CentOS 8.1. If you want to test on CentOS 7, you need to wait until the fix will be backported to 4.3, or since you like Java, maybe port it yourself? Note also that we have a much more advanced backup and restore options: https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/backup_v… Here is example run I did yesterday: I started with full backup of a running vm: $ ./backup_vm.py full --engine-url https://engine3/ --username admin@internal --password-file /home/nsoffer/.config/ovirt/engine3/password --cafile /home/nsoffer/Downloads/certs/engine3.pem --backup-dir /home/nsoffer/tmp/backups/test-nfs b5732b5c-37ee-4c66-b77e-bda5d37a10fe [ 0.0 ] Starting full backup for VM b5732b5c-37ee-4c66-b77e-bda5d37a10fe [ 1.5 ] Waiting until backup f73541c6-88d1-4dac-a551-da922cdb3f55 is ready [ 4.6 ] Created checkpoint '4754dc34-da4b-4e62-84ea-164c413b003c' (to use in --from-checkpoint-uuid for the next incremental backup) [ 4.6 ] Creating image transfer for disk 566e6aa6-575b-4f83-88c9-e5e5b54d9649 [ 5.9 ] Waiting until transfer 98e5aabc-fedb-4d2c-81c5-eed1a8b07790 will be ready [ 5.9 ] Image transfer 98e5aabc-fedb-4d2c-81c5-eed1a8b07790 is ready [ 5.9 ] Transfer url: https://host4:54322/images/13a0a396-5070-4b0f-a5cd-e2506c5abf0f Formatting '/home/nsoffer/tmp/backups/test-nfs/566e6aa6-575b-4f83-88c9-e5e5b54d9649.202005132336.full.qcow2', fmt=qcow2 size=6442450944 cluster_size=65536 lazy_refcounts=off refcount_bits=16 [ 100.00% ] 6.00 GiB, 18.34 seconds, 334.95 MiB/s [ 24.3 ] Finalizing transfer 98e5aabc-fedb-4d2c-81c5-eed1a8b07790 [ 24.5 ] Full backup completed successfully This downloads all vms disks to ~/tmp/backups/test-nfs/, creating 566e6aa6-575b-4f83-88c9-e5e5b54d9649.202005132336.full.qcow2 This file includes entire disk content at the time the backup was stated. This includes data from all snapshots. Then I run incremental backup of the same vm, recoding the data changes since the full backup: $ ./backup_vm.py incremental --engine-url https://engine3/ --username admin@internal --password-file /home/nsoffer/.config/ovirt/engine3/password --cafile /home/nsoffer/Downloads/certs/engine3.pem --backup-dir /home/nsoffer/tmp/backups/test-nfs --from-checkpoint-uuid 4754dc34-da4b-4e62-84ea-164c413b003c b5732b5c-37ee-4c66-b77e-bda5d37a10fe [ 0.0 ] Starting incremental backup for VM b5732b5c-37ee-4c66-b77e-bda5d37a10fe [ 1.3 ] Waiting until backup 01a88749-06eb-431a-81f2-b03db24b878e is ready [ 2.3 ] Created checkpoint '6f80d3c5-5b81-42ae-9700-2ccab37ad93b' (to use in --from-checkpoint-uuid for the next incremental backup) [ 2.3 ] Creating image transfer for disk 566e6aa6-575b-4f83-88c9-e5e5b54d9649 [ 3.4 ] Waiting until transfer 16c90052-9411-46f6-8dc6-b2f260206708 will be ready [ 3.4 ] Image transfer 16c90052-9411-46f6-8dc6-b2f260206708 is ready [ 3.4 ] Transfer url: https://host4:54322/images/b9a44902-46f1-43b3-a9ad-9d72735c53ad Formatting '/home/nsoffer/tmp/backups/test-nfs/566e6aa6-575b-4f83-88c9-e5e5b54d9649.202005132347.incremental.qcow2', fmt=qcow2 size=6442450944 cluster_size=65536 lazy_refcounts=off refcount_bits=16 [ 100.00% ] 6.00 GiB, 0.63 seconds, 9.52 GiB/s [ 4.0 ] Finalizing transfer 16c90052-9411-46f6-8dc6-b2f260206708 [ 4.1 ] Incremental backup completed successfully This backup is tiny since the only thing changed was new directory created on the vm, and some system logs modified since the full backup. Then I rebased the incremental backup on top of the full backup: cd home/nsoffer/tmp/backups/test-nfs qemu-img rebase -u -b 566e6aa6-575b-4f83-88c9-e5e5b54d9649.202005132336.full.qcow2 -F qcow2 566e6aa6-575b-4f83-88c9-e5e5b54d9649.202005132347.incremental.qcow2 This images are now a valid qcow2 chain that can be uploaded using upload_disk.py: $ python3 upload_disk.py --engine-url https://engine3/ --username admin@internal --password /home/nsoffer/.config/ovirt/engine3/password --cafile /home/nsoffer/Downloads/certs/engine3.pem --disk-format qcow2 --disk-sparse --sd-name iscsi2-1 /home/nsoffer/tmp/backups/test-nfs/566e6aa6-575b-4f83-88c9-e5e5b54d9649.202005132347.incremental.qcow2 Checking image... Image format: qcow2 Disk format: cow Disk content type: data Disk provisioned size: 6442450944 Disk initial size: 2755264512 Disk name: 566e6aa6-575b-4f83-88c9-e5e5b54d9649.202005132347.incremental.qcow2 Connecting... Creating disk... Disk id: a9785777-8aac-4515-a47a-2f5126e3af73 Creating image transfer... Transfer ID: 6e0384b6-730b-4416-a954-bf45e627d5cf Transfer host: host4 Uploading image... [ 100.00% ] 6.00 GiB, 20.50 seconds, 299.70 MiB/s Finalizing image transfer... Upload completed successfully The result is a single qcow2 disk on the domain iscs2-1. I created a new vm from this disk. This backup script is not complete yet, we don't download the VM OVF in each backup, and we don't create the VM from the OVF. These features should be added later. You may want to start testing and intergating this code instead of the snapshot based download. See https://www.ovirt.org/develop/release-management/features/storage/increment… Nir

3 5