September 2020 - Devel - oVirt List Archives

[VDSM] Started getting virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired
by Edward Haas 11 Jan '24

11 Jan '24

Hi, I have a VM which acts as an oVirt host with VDSM installed. I use it for testing without connecting it to Engine. Recently VDSM fails to come up and I see this error: Sep 26 17:58:18 localhost libvirtd: 2018-09-26 14:58:18.978+0000: 12176: error : virNetTLSContextCheckCertTimes:154 : The server certificate /etc/pki/vdsm/certs/vdsmcert.pem has expired Any hint on how to generate or fetch a new certificate without the help of Engine? Thanks, Edy.

3 5

Error: Adding new Host to ovirt-engine
by Ahmad Khiet 14 Aug '23

14 Aug '23

Hi, Can't add new host to ovirt engine, because the following error: 2019-06-12 12:23:09,664 p=4134 u=engine | TASK [ovirt-host-deploy-facts : Set facts] ************************************* 2019-06-12 12:23:09,684 p=4134 u=engine | ok: [10.35.1.17] => { "ansible_facts": { "ansible_python_interpreter": "/usr/bin/python2", "host_deploy_vdsm_version": "4.40.0" }, "changed": false } 2019-06-12 12:23:09,697 p=4134 u=engine | TASK [ovirt-provider-ovn-driver : Install ovs] ********************************* 2019-06-12 12:23:09,726 p=4134 u=engine | fatal: [10.35.1.17]: FAILED! => {} MSG: The conditional check 'cluster_switch == "ovs" or (ovn_central is defined and ovn_central | ipaddr and ovn_engine_cluster_version is version_compare('4.2', '>='))' failed. The error was: The ipaddr filter requires python's netaddr be installed on the ansible controller The error appears to be in '/home/engine/apps/engine/share/ovirt-engine/playbooks/roles/ovirt-provider-ovn-driver/tasks/configure.yml': line 3, column 5, but may be elsewhere in the file depending on the exact syntax problem. The offending line appears to be: - block: - name: Install ovs ^ here 2019-06-12 12:23:09,728 p=4134 u=engine | PLAY RECAP ********************************************************************* 2019-06-12 12:23:09,728 p=4134 u=engine | 10.35.1.17 : ok=3 changed=0 unreachable=0 failed=1 skipped=0 rescued=0 ignored=0 whats missing!? Thanks -- Ahmad Khiet Red Hat <https://www.redhat.com/> akhiet(a)redhat.com M: +972-54-6225629 <https://red.ht/sig>

7 10

Purging inactive maintainers from vdsm-master-maintainers
by Nir Soffer 21 Jun '21

21 Jun '21

I want to remove inactive contributors from vdsm-master-maintainers. I suggest the simple rule of 2 years of inactivity for removing from this group, based on git log. See the list below for current status: https://gerrit.ovirt.org/#/admin/groups/106,members Thoughts? Nir

6 11

Merge rights changes in the oVirt Engine project
by Tal Nisan 09 Apr '21

09 Apr '21

Hi everyone, As you probably know we are now in a mode in which we develop our next zstream version on the master branch as opposed to how we worked before where the master version was dedicated for the next major version. This makes the rapid changes in master to be delivered to customers in a much higher cadence thus affecting stability. Due to that we think it's best that from now on merges in the master branch will be done only by stable branch maintainers after inspecting those closely. What you need to do in order to get your patch merged: - Have it pass Jenkins - Have it get code review +2 - Have it mark verified +1 - It's always encourage to have it tested by OST, for bigger changes it's a must Once you have all those covered, please add me as a reviewer and I'll examine it and merge if everything seems right, if I haven't done it in a timely manner feel free to ping me.

3 4

Error Java SDK Issue??
by Geschwentner, Patrick 02 Apr '21

02 Apr '21

Dear Ladies and Gentlemen! I am currently working with the java-sdk and I encountered a problem. If I would like to retrieve the disk details, I get the following error: Disk currDisk = ovirtConnection.followLink(diskAttachment.disk()); The Error is occurring in this line: [cid:image001.png@01D44537.AF127FD0] The getResponst looks quiet ok. (I inspected: [cid:image002.png@01D44537.AF127FD0] and it looks ok). Error: wrong number of arguments The code is quiet similar to what you published on github (https://github.com/oVirt/ovirt-engine-sdk-java/blob/master/sdk/src/test/jav… ). Can you confirm the defect? Best regards Patrick

6 11

CentOS Stream support
by Michal Skrivanek 01 Feb '21

01 Feb '21

Hi all, we would like to ask about interest in community about oVirt moving to CentOS Stream. There were some requests before but it’s hard to see how many people would really like to see that. With CentOS releases lagging behind RHEL for months it’s interesting to consider moving to CentOS Stream as it is much more up to date and allows us to fix bugs faster, with less workarounds and overhead for maintaining old code. E.g. our current integration tests do not really pass on CentOS 8.1 and we can’t really do much about that other than wait for more up to date packages. It would also bring us closer to make oVirt run smoothly on RHEL as that is also much closer to Stream than it is to outdated CentOS. So..would you like us to support CentOS Stream? We don’t really have capacity to run 3 different platforms, would you still want oVirt to support CentOS Stream if it means “less support” for regular CentOS? There are some concerns about Stream being a bit less stable, do you share those concerns? Thank you for your comments, michal

6 12

planned Jenkins restart
by Evgheni Dereveanchin 02 Dec '20

02 Dec '20

Hi everyone, I'll be performing a planned Jenkins restart within the next hour. No new CI jobs will be scheduled during this maintenance period. I will inform you once it is back online. -- Regards, Evgheni Dereveanchin

2 2

Re: Need help in handling catch block in vdsm
by Michal Skrivanek 05 Oct '20

05 Oct '20

[adding devel list] > On 29 Sep 2020, at 09:51, Ritesh Chikatwar <rchikatw(a)redhat.com> wrote: > > Hello, > > i am new to VDSM codebase. > > There is one minor bug in gluster and they don't have any near plan to fix this. So i need to fix this in vdsm. > > The bug is when i run command > [root@dhcp35-237 ~]# gluster v geo-replication status > No active geo-replication sessions > geo-replication command failed > [root@dhcp35-237 ~]# > > So this engine is piling up with error. i need handle this in vdsm the code at this place > > https://github.com/oVirt/vdsm/blob/master/lib/vdsm/gluster/cli.py#L1231 <https://github.com/oVirt/vdsm/blob/master/lib/vdsm/gluster/cli.py#L1231> > > If i run the above command with xml then i will get > > [root@dhcp35-237 ~]# gluster v geo-replication status --xml > geo-replication command failed > [root@dhcp35-237 ~]# > > so i have to run one more command before executing this and check in exception that it contains No active geo-replication sessions this string. for that i did like this maybe it goes to stderr? other than that, no idea, sorry Thanks, michal > > try: > xmltree = _execGluster(command) > except ge.GlusterCmdFailedException as e: > if str(e).find("No active geo-replication sessions") != -1: > return [] > Seems like this is not working can you help me here > > > Any help will be appreciated > Ritesh >

4 6

Disk sizes not updated on unmap/discard
by Tomáš Golembiovský 02 Oct '20

02 Oct '20

Hi, currently, when we run virt-sparsify on VM or user runs VM with discard enabled and when the disk is on block storage in qcow, the results are not reflected in oVirt. The blocks get discarded, storage can reuse them and reports correct allocation statistics, but oVirt does not. In oVirt one can still see the original allocation for disk and storage domain as it was before blocks were discarded. This is super-confusing to the users because when they check after running virt-sparsify and see the same values they think sparsification is not working. Which is not true. It all seems to be because of our LVM layout that we have on storage domain. The feature page for discard [1] suggests it could be solved by running lvreduce. But this does not seem to be true. When blocks are discarded the QCOW does not necessarily change its apparent size, the blocks don't have to be removed from the end of the disk. So running lvreduce is likely to remove valuable data. At the moment I don't see how we could achieve the correct values. If anyone has any idea feel free to entertain me. The only option seems to be to switch to LVM thin pools. Do we have any plans on doing that? Tomas [1] https://www.ovirt.org/develop/release-management/features/storage/pass-disc… -- Tomáš Golembiovský <tgolembi(a)redhat.com>

5 4

ovirt-engine has been tagged (ovirt-engine-4.4.3.5)
by Tal Nisan 30 Sep '20

30 Sep '20

1 0

Incremental Backup | oVirt
by luwen.zhang＠vinchin.com 30 Sep '20

30 Sep '20

Dear team, My name is Luwen Zhang from Vinchin Backup & Recovery. I'm sending you this Email because our developers encountered some problems while developing incremental backup feature following the oVirt documentations. https://www.ovirt.org/documentation/incremental-backup-guide/incremental-ba… We downloaded oVirt 4.4.1 from oVirt website, and is now developing based on this version, as per the documentation when we perform the first time full backup, we should obtain a "checkpoint id", so when we perform incremental backup using this ID we should know what's have changed on the VM. But now the problem is that we cannot get the checkpoint ID. The components and versions of oVirt are as follows: Could you please kindly check on this issue and point out what should be wrong and what we should do? Looking forward to your reply. Thanks & regards! Luwen Zhang | Product Manager Tel: +86-28-8553-0156 Mob: +86-138-8042-4687 Skype: luwen.zhang_cn E-mail: luwen.zhang(a)vinchin.com F5, Block 8, National Information Security Industry Park, No.333 YunHua Road, Hi-Tech Zone, Chengdu, China | P.C.610015

1 0

Propose Eitan Raviv as a ovirt-system-tests network-suite maintainer
by Dominik Holler 28 Sep '20

28 Sep '20

Hi all, Eitan Raviv has been working on the oVirt project for more than 3 years. He contributed more than 40 patches to ovirt-system-tests, including more than 35 patches to the network-suite. He is already recognized as a relevant reviewer for the network-suite, so it time to give him the official role for the work he is already doing. I would like to propose Eitan as a virt-system-tests network-suite maintainer. Thanks Dominik

5 5

OST fails during 002_bootstrap_pytest
by Vojtech Juranek 24 Sep '20

24 Sep '20

Hi, can anybody look on OST, it fails constantly with error bellow. See e.g. [1, 2] for full logs. Thanks Vojta [1] https://jenkins.ovirt.org/job/ovirt-system-tests_manual/7381/ [2] https://jenkins.ovirt.org/job/ovirt-system-tests_manual/7382/ 13:07:16 ../basic-suite-master/test-scenarios/ 002_bootstrap_pytest.py::test_verify_engine_backup [WARNING]: Invalid characters were found in group names but not replaced, use 13:07:22 -vvvv to see details 13:07:22 /usr/lib/python2.7/site-packages/requests/__init__.py:91: RequestsDependencyWarning: urllib3 (1.25.10) or chardet (3.0.4) doesn't match a supported version! 13:07:22 RequestsDependencyWarning) 13:07:22 lago-basic-suite-master-engine | CHANGED => { 13:07:22 "changed": true, 13:07:22 "gid": 0, 13:07:22 "group": "root", 13:07:22 "mode": "0755", 13:07:22 "owner": "root", 13:07:22 "path": "/var/log/ost-engine-backup", 13:07:22 "secontext": "unconfined_u:object_r:var_log_t:s0", 13:07:22 "size": 6, 13:07:22 "state": "directory", 13:07:22 "uid": 0 13:07:22 } 13:07:44 [WARNING]: Invalid characters were found in group names but not replaced, use 13:07:44 -vvvv to see details 13:07:44 /usr/lib/python2.7/site-packages/requests/__init__.py:91: RequestsDependencyWarning: urllib3 (1.25.10) or chardet (3.0.4) doesn't match a supported version! 13:07:44 RequestsDependencyWarning) 13:07:44 lago-basic-suite-master-engine | FAILED | rc=1 >> 13:07:44 Start of engine-backup with mode 'backup' 13:07:44 scope: all 13:07:44 archive file: /var/log/ost-engine-backup/backup.tgz 13:07:44 log file: /var/log/ost-engine-backup/log.txt 13:07:44 Backing up: 13:07:44 Notifying engine 13:07:44 - Files 13:07:44 - Engine database 'engine' 13:07:44 - DWH database 'ovirt_engine_history' 13:07:44 - Grafana database '/var/lib/grafana/grafana.db' 13:07:44 Notifying engineFATAL: failed to backup /var/lib/grafana/grafana.db with sqlite3non-zero return code 13:17:47 FAILED

5 6

Engine build fails: "found duplicate key "when" with value "collectd_default_files|d(true)"
by Nir Soffer 23 Sep '20

23 Sep '20

I'm trying to build engine on new VM, installed based on README and it fails in ansible-lint on: /usr/share/ansible/roles/oVirt.metrics/roles/oVirt.logging/tasks/main.yml Is this a known issue? any workaround? Nir --- $ make clean install-dev PREFIX="$HOME/ovirt-engine" ... + /usr/bin/ansible-lint -c build/ansible-lint.conf packaging/playbooks/install-skydive.yml packaging/playbooks/ovirt-provider-ovn-driver.yml packaging/ansible-runner-service-project/project/create-brick.yml packaging/ansible-runner-service-project/project/ovirt-fetch-he-config.yml packaging/ansible-runner-service-project/project/ovirt-host-check-upgrade.yml packaging/ansible-runner-service-project/project/ovirt-host-deploy.yml packaging/ansible-runner-service-project/project/ovirt-host-enroll-certificate.yml packaging/ansible-runner-service-project/project/ovirt-host-remove.yml packaging/ansible-runner-service-project/project/ovirt-host-upgrade.yml packaging/ansible-runner-service-project/project/ovirt-image-measure.yml packaging/ansible-runner-service-project/project/ovirt-ova-export.yml packaging/ansible-runner-service-project/project/ovirt-ova-import.yml packaging/ansible-runner-service-project/project/ovirt-ova-query.yml packaging/ansible-runner-service-project/project/ovirt-vnc-sasl.yml packaging/ansible-runner-service-project/project/ovirt_host_upgrade_vars.yml packaging/ansible-runner-service-project/project/replace-gluster.yml packaging/ansible-runner-service-project/project/roles packaging/ansible-runner-service-project/project/roles/gluster-brick-create packaging/ansible-runner-service-project/project/roles/gluster-replace-peers packaging/ansible-runner-service-project/project/roles/hc-gluster-cgroups packaging/ansible-runner-service-project/project/roles/ovirt-host-check-upgrade packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-facts packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-firewalld packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-hosted-engine packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-iptables packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-kdump packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-kernel packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-libvirt-guests packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-misc packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-spice-encryption packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-vdsm-certificates packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-vdsm packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-vm-console-certificates packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-vm-console packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy-vnc-certificates packaging/ansible-runner-service-project/project/roles/ovirt-host-deploy packaging/ansible-runner-service-project/project/roles/ovirt-host-enroll-certificate packaging/ansible-runner-service-project/project/roles/ovirt-host-setup-vnc-sasl packaging/ansible-runner-service-project/project/roles/ovirt-host-upgrade packaging/ansible-runner-service-project/project/roles/ovirt-image-measure packaging/ansible-runner-service-project/project/roles/ovirt-ova-export-post-pack packaging/ansible-runner-service-project/project/roles/ovirt-ova-export-pre-pack packaging/ansible-runner-service-project/project/roles/ovirt-ova-extract packaging/ansible-runner-service-project/project/roles/ovirt-ova-pack packaging/ansible-runner-service-project/project/roles/ovirt-ova-query packaging/ansible-runner-service-project/project/roles/ovirt-provider-ovn-driver packaging/ansible-runner-service-project/project/roles/ovirt-to-vdsm-network packaging/ansible-runner-service-project/project/roles/python-ver-detect [WARNING]: While constructing a mapping from /usr/share/ansible/roles/oVirt.metrics/roles/oVirt.logging/tasks/main.yml, line 118, column 7, found a duplicate dict key (when). Using last defined value only. [WARNING]: While constructing a mapping from <unicode string>, line 118, column 7, found a duplicate dict key (when). Using last defined value only. Traceback (most recent call last): File "/usr/bin/ansible-lint", line 11, in <module> load_entry_point('ansible-lint==4.1.0', 'console_scripts', 'ansible-lint')() File "/usr/lib/python3.6/site-packages/ansiblelint/__main__.py", line 187, in main matches.extend(runner.run()) File "/usr/lib/python3.6/site-packages/ansiblelint/__init__.py", line 282, in run skip_list=self.skip_list)) File "/usr/lib/python3.6/site-packages/ansiblelint/__init__.py", line 174, in run matches.extend(rule.matchtasks(playbookfile, text)) File "/usr/lib/python3.6/site-packages/ansiblelint/__init__.py", line 84, in matchtasks yaml = ansiblelint.utils.append_skipped_rules(yaml, text, file['type']) File "/usr/lib/python3.6/site-packages/ansiblelint/utils.py", line 604, in append_skipped_rules ruamel_data = yaml.load(file_text) File "/usr/lib64/python3.6/site-packages/ruamel/yaml/main.py", line 266, in load return constructor.get_single_data() File "/usr/lib64/python3.6/site-packages/ruamel/yaml/constructor.py", line 105, in get_single_data return self.construct_document(node) File "/usr/lib64/python3.6/site-packages/ruamel/yaml/constructor.py", line 115, in construct_document for dummy in generator: File "/usr/lib64/python3.6/site-packages/ruamel/yaml/constructor.py", line 1357, in construct_yaml_map self.construct_mapping(node, data) File "/usr/lib64/python3.6/site-packages/ruamel/yaml/constructor.py", line 1266, in construct_mapping self.check_mapping_key(node, key_node, maptyp, key, value) File "/usr/lib64/python3.6/site-packages/ruamel/yaml/constructor.py", line 265, in check_mapping_key raise DuplicateKeyError(*args) ruamel.yaml.constructor.DuplicateKeyError: while constructing a mapping in "<unicode string>", line 118, column 7: - name: Populate logging_outputs d ... ^ (line: 118) " (original value: "collect_ovirt_engine_log or collect_ovirt_vdsm_log") in "<unicode string>", line 135, column 7: when: collectd_default_files|d(true) ^ (line: 135) To suppress this check see: http://yaml.readthedocs.io/en/latest/api.html#duplicate-keys Duplicate keys will become and error in future releases, and are errors by default when using the new API. make[1]: *** [Makefile:366: validations] Error 1 make[1]: Leaving directory '/home/nsoffer/src/ovirt-engine' make: *** [Makefile:545: all-dev] Error 2

2 4

Upgrade to 4.4 does not describe how to handle Gluster brick migration
by Sandro Bonazzola 23 Sep '20

23 Sep '20

Hi, it has been reported to oVirt website on https://github.com/oVirt/ovirt-site/issues/2287 that we may improve upgrade documentation covering (or linking to existing documentation) the gluster brick migration from el7 to el8 while upgrading from 4.3 to 4.4. Have we already got something we can provide there? Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

2 1

Very slow push/pull to/from gerrit
by Nir Soffer 23 Sep '20

23 Sep '20

Recently pushing changes to gerrit is very slow. It seems that the issue is pulling changes during rebase in "git review". Sometimes "git review" is very slow, but "git review -R" is very quick. This show that the issue was getting changes from gerrit during when git-review try to rebase the current branch on master. I noticed that origin/master and gerrit/master do not show the same commit: $ git log origin/master | head -1 commit 6e6e93cb1d237f9b6fdd533d5afdc1b9ba1c197a $ git log gerrit/master | head -1 commit 353e7b1e322aa02d4767b6617ed094be0643b094 $ git remote -v gerrit http://gerrit.ovirt.org/p/vdsm.git (fetch) gerrit ssh://nsoffer@gerrit.ovirt.org:29418/vdsm.git (push) origin http://gerrit.ovirt.org/p/vdsm.git (fetch) origin http://gerrit.ovirt.org/p/vdsm.git (push) I've been using this configuration for several years, and the slowness started only recently, so I guess the issue is not on my side. Same issues also on ovirt-engine, using similar configuration: $ git remote -v gerrit http://gerrit.ovirt.org/ovirt-engine (fetch) gerrit ssh://nsoffer@gerrit.ovirt.org:29418/ovirt-engine.git (push) origin git://gerrit.ovirt.org/ovirt-engine (fetch) origin git://gerrit.ovirt.org/ovirt-engine (push) Anyone experienced this? I guess that restarting the gerrit server will "fix" this issue. Nir

1 1

Possible i18n for cockpit-ovirt ?
by Juliette Tux 23 Sep '20

23 Sep '20

Hello, Localizator/translator here :) I have a small question regarding the cockpit-ovirt utility[1]. Are there any plans of adding the i18n into the code to facilitate proper translation of cockpit-ovirt? Thank you! [1] https://resources.ovirt.org/pub/ovirt-4.3/src/cockpit-ovirt/ -- С уважением, Дронова Юлия

3 5

ovirt-engine has been tagged (ovirt-engine-4.4.3.4)
by Tal Nisan 22 Sep '20

22 Sep '20

1 0

ioprocess 1.4.2 not tagged
by Sandro Bonazzola 21 Sep '20

21 Sep '20

Hi, last commit on ioprocess says: * ae379c8 - (HEAD -> master, origin/master, origin/HEAD) release: Bump version to 1.4.2 (12 giorni fa) <Eyal Shenitzky> But it's missing a tag and it has not been added to releng-tools for being included in oVirt 4.4.3 release candidate. Anything missing there or can we release it? Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

2 3

ovirt-engine-api-model master fail to build on Fedora 32 (Fatal error compiling: invalid flag: --release)
by Nir Soffer 21 Sep '20

21 Sep '20

I'm trying to build master on Fedora 32. This worked last week with: commit cbb664f1b5b87e05fec535461cfa09c758b033c2 (gerrit/master) Author: Martin Perina <mperina(a)redhat.com> Date: Mon Sep 14 12:49:33 2020 +0200 Make check-patch.packages a link to build-artifacts.packages But is broken now with: commit e821632e04626f72957177e49f03ca90bcbb5b77 (HEAD -> master, origin/master, origin/HEAD) Author: Ori_Liel <oliel(a)redhat.com> Date: Sat Sep 19 13:18:55 2020 +0300 [maven-release-plugin] prepare for next development iteration Here is example build: $ mvn clean install [INFO] Scanning for projects... [INFO] [INFO] ---------------------< org.ovirt.engine.api:model >--------------------- [INFO] Building oVirt API Model 4.4.19-SNAPSHOT [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ model --- [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ model --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /home/nsoffer/src/ovirt-engine-api-model/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:3.8.0:compile (default-compile) @ model --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 601 source files to /home/nsoffer/src/ovirt-engine-api-model/target/classes [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 0.694 s [INFO] Finished at: 2020-09-21T12:50:16+03:00 [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project model: Fatal error compiling: invalid flag: --release -> [Help 1] Do we have any way to fix this? Nir

2 2

Bug 1880171 - Upgrading host (or checking for updates) fails after 4.4.2 ovirt-engine upgrade
by Sandro Bonazzola 21 Sep '20

21 Sep '20

Hi, I'd like to propose to go with async fix for *Bug 1880171* <https://bugzilla.redhat.com/show_bug.cgi?id=1880171> - Upgrading host (or checking for updates) fails after 4.4.2 ovirt-engine upgrade and release it async for 4.4.2 as soon as possible. If you agree, I'll add ovirt-4.4.2-1 target milestone to oVirt classification. Thanks, -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*

1 0

Error building ovirt-engine-api-model on Fedora 32
by Nir Soffer 17 Sep '20

17 Sep '20

I'm trying to build with this change: https://gerrit.ovirt.org/c/111312/ And it fails to build. Same error on master (commit 2e3c836e4c2fd50258e96bc6966b5d9680b5332e). Anyone has a clue what is the reason for this? any workaround? $ mvn clean install [INFO] Scanning for projects... [INFO] [INFO] ---------------------< org.ovirt.engine.api:model >--------------------- [INFO] Building oVirt API Model 4.4.18-SNAPSHOT [INFO] --------------------------------[ jar ]--------------------------------- [INFO] [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ model --- [INFO] Deleting /home/nsoffer/src/ovirt-engine-api-model/target [INFO] [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ model --- [INFO] Using 'UTF-8' encoding to copy filtered resources. [INFO] skip non existing resourceDirectory /home/nsoffer/src/ovirt-engine-api-model/src/main/resources [INFO] [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ model --- [INFO] Changes detected - recompiling the module! [INFO] Compiling 601 source files to /home/nsoffer/src/ovirt-engine-api-model/target/classes [WARNING] /home/nsoffer/src/ovirt-engine-api-model/src/main/java/services/DisksService.java: Some input files use or override a deprecated API. [WARNING] /home/nsoffer/src/ovirt-engine-api-model/src/main/java/services/DisksService.java: Recompile with -Xlint:deprecation for details. [INFO] [INFO] --- exec-maven-plugin:1.4.0:java (generate-doc) @ model --- SLF4J: Class path contains multiple SLF4J bindings. SLF4J: Found binding in [jar:file:/home/nsoffer/.m2/repository/org/slf4j/slf4j-log4j12/1.7.7/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: Found binding in [jar:file:/home/nsoffer/.m2/repository/org/slf4j/slf4j-jdk14/1.5.6/slf4j-jdk14-1.5.6.jar!/org/slf4j/impl/StaticLoggerBinder.class] SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation. SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory] WARNING: An illegal reflective access operation has occurred WARNING: Illegal reflective access by org.jboss.classfilewriter.ClassFile$1 (file:/home/nsoffer/.m2/repository/org/jboss/weld/se/weld-se/2.3.0.Final/weld-se-2.3.0.Final.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int) WARNING: Please consider reporting this to the maintainers of org.jboss.classfilewriter.ClassFile$1 WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations WARNING: All illegal access operations will be denied in a future release ERROR org.ovirt.api.metamodel.tool.Main - Error while executing the "run" method of tool class "org.ovirt.api.metamodel.tool.Tool". java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.ovirt.api.metamodel.tool.Main.main(Main.java:74) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.codehaus.mojo.exec.ExecJavaMojo$1.run(ExecJavaMojo.java:293) at java.base/java.lang.Thread.run(Thread.java:834) Caused by: org.jboss.weld.exceptions.WeldException: WELD-000049: Unable to invoke public void org.ovirt.api.metamodel.tool.AsciiDocHtmlGenerator.init() on org.ovirt.api.metamodel.tool.AsciiDocHtmlGenerator@6ef4091 at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:100) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.postConstruct(DefaultLifecycleCallbackInvoker.java:81) at org.jboss.weld.injection.producer.BasicInjectionTarget.postConstruct(BasicInjectionTarget.java:126) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:171) at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742) at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842) at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92) at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378) at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389) at org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:70) at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:159) at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96) at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101) at org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:141) at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50) at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99) at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125) at org.ovirt.api.metamodel.tool.XmlDescriptionGenerator$Proxy$_$$_WeldClientProxy.generate(Unknown Source) at org.ovirt.api.metamodel.tool.Tool.run(Tool.java:383) at org.ovirt.api.metamodel.tool.Tool$Proxy$_$$_WeldClientProxy.run(Unknown Source) ... 11 more Caused by: java.lang.reflect.InvocationTargetException at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:98) ... 36 more Caused by: java.lang.ExceptionInInitializerError at org.asciidoctor.internal.JRubyAsciidoctor.createOptimizedConfiguration(JRubyAsciidoctor.java:151) at org.asciidoctor.internal.JRubyAsciidoctor.createJRubyAsciidoctorInstance(JRubyAsciidoctor.java:114) at org.asciidoctor.internal.JRubyAsciidoctor.create(JRubyAsciidoctor.java:62) at org.asciidoctor.Asciidoctor$Factory.create(Asciidoctor.java:647) at org.ovirt.api.metamodel.tool.AsciiDocHtmlGenerator.init(AsciiDocHtmlGenerator.java:39) ... 41 more Caused by: java.lang.RuntimeException: unsupported Java version: 11 at org.jruby.RubyInstanceConfig.initGlobalJavaVersion(RubyInstanceConfig.java:1858) at org.jruby.RubyInstanceConfig.<clinit>(RubyInstanceConfig.java:1608) ... 46 more Weld SE container STATIC_INSTANCE shut down by shutdown hook

3 8

Removal of deprecated init-scripts (network-scripts)
by Ales Musil 16 Sep '20

16 Sep '20

Hello, network-scripts for host networking were deprecated since oVirt 4.4. It will be removed completely in the 4.4.3 release. There is no action required for setups that did not change the configuration to use network-scripts backend (net_nmstate_enabled = false). Users that did disable nmstate should redeploy all affected hosts before 4.4.3. Also can you please tell us what was the reason to use network-scripts, if that is the case? Thank you. Best regards, Ales Musil -- Ales Musil Software Engineer - RHV Network Red Hat EMEA <https://www.redhat.com> amusil(a)redhat.com IM: amusil <https://red.ht/sig>

1 0

ovirt-engine has been tagged (ovirt-engine-4.4.3.3)
by Tal Nisan 15 Sep '20

15 Sep '20

1 0

device compatibility interface for live migration with assigned devices
by Yan Zhao 15 Sep '20

15 Sep '20

hi folks, we are defining a device migration compatibility interface that helps upper layer stack like openstack/ovirt/libvirt to check if two devices are live migration compatible. The "devices" here could be MDEVs, physical devices, or hybrid of the two. e.g. we could use it to check whether - a src MDEV can migrate to a target MDEV, - a src VF in SRIOV can migrate to a target VF in SRIOV, - a src MDEV can migration to a target VF in SRIOV. (e.g. SIOV/SRIOV backward compatibility case) The upper layer stack could use this interface as the last step to check if one device is able to migrate to another device before triggering a real live migration procedure. we are not sure if this interface is of value or help to you. please don't hesitate to drop your valuable comments. (1) interface definition The interface is defined in below way: __ userspace /\ \ / \write / read \ ________/__________ ___\|/_____________ | migration_version | | migration_version |-->check migration --------------------- --------------------- compatibility device A device B a device attribute named migration_version is defined under each device's sysfs node. e.g. (/sys/bus/pci/devices/0000\:00\:02.0/$mdev_UUID/migration_version). userspace tools read the migration_version as a string from the source device, and write it to the migration_version sysfs attribute in the target device. The userspace should treat ANY of below conditions as two devices not compatible: - any one of the two devices does not have a migration_version attribute - error when reading from migration_version attribute of one device - error when writing migration_version string of one device to migration_version attribute of the other device The string read from migration_version attribute is defined by device vendor driver and is completely opaque to the userspace. for a Intel vGPU, string format can be defined like "parent device PCI ID" + "version of gvt driver" + "mdev type" + "aggregator count". for an NVMe VF connecting to a remote storage. it could be "PCI ID" + "driver version" + "configured remote storage URL" for a QAT VF, it may be "PCI ID" + "driver version" + "supported encryption set". (to avoid namespace confliction from each vendor, we may prefix a driver name to each migration_version string. e.g. i915-v1-8086-591d-i915-GVTg_V5_8-1) (2) backgrounds The reason we hope the migration_version string is opaque to the userspace is that it is hard to generalize standard comparing fields and comparing methods for different devices from different vendors. Though userspace now could still do a simple string compare to check if two devices are compatible, and result should also be right, it's still too limited as it excludes the possible candidate whose migration_version string fails to be equal. e.g. an MDEV with mdev_type_1, aggregator count 3 is probably compatible with another MDEV with mdev_type_3, aggregator count 1, even their migration_version strings are not equal. (assumed mdev_type_3 is of 3 times equal resources of mdev_type_1). besides that, driver version + configured resources are all elements demanding to take into account. So, we hope leaving the freedom to vendor driver and let it make the final decision in a simple reading from source side and writing for test in the target side way. we then think the device compatibility issues for live migration with assigned devices can be divided into two steps: a. management tools filter out possible migration target devices. Tags could be created according to info from product specification. we think openstack/ovirt may have vendor proprietary components to create those customized tags for each product from each vendor. e.g. for Intel vGPU, with a vGPU(a MDEV device) in source side, the tags to search target vGPU are like: a tag for compatible parent PCI IDs, a tag for a range of gvt driver versions, a tag for a range of mdev type + aggregator count for NVMe VF, the tags to search target VF may be like: a tag for compatible PCI IDs, a tag for a range of driver versions, a tag for URL of configured remote storage. b. with the output from step a, openstack/ovirt/libvirt could use our proposed device migration compatibility interface to make sure the two devices are indeed live migration compatible before launching the real live migration process to start stream copying, src device stopping and target device resuming. It is supposed that this step would not bring any performance penalty as -in kernel it's just a simple string decoding and comparing -in openstack/ovirt, it could be done by extending current function check_can_live_migrate_destination, along side claiming target resources.[1] [1] https://specs.openstack.org/openstack/nova-specs/specs/stein/approved/libvi… Thanks Yan

14 117

ovirt-engine has been tagged (ovirt-engine-4.4.2.6)
by Tal Nisan 14 Sep '20

14 Sep '20

1 0

Re: oVirt Terraform Provider
by Sandro Bonazzola 14 Sep '20

14 Sep '20

Il giorno gio 3 set 2020 alle ore 12:29 Jake Reynolds < jake.reynolds(a)bidfx.com> ha scritto: > Hi, > > A number of PRs (bug fixes & feature additions) are outstanding on the > oVirt Terraform Provider https://github.com/oVirt/terraform-provider-ovirt. > There seems to have been no activity on the master branch of the repo for > months. > > 1. How can I promote/request that PRs are reviewed in a timely manner? > > Hi, +Roy Golan <rgolan(a)redhat.com> , +Roberto Ciatti <rciatti(a)redhat.com> , +Gal Zaidman <gzaidman(a)redhat.com> , +Evgeny Slutsky <eslutsky(a)redhat.com> can you please review pull requests in https://github.com/oVirt/terraform-provider-ovirt/pulls ? Thanks, > > 1. > 2. I am using this to deploy a global infrastructure over the next > year and expect to be doing further extensions/improvements over that time > (done 5 PRs in the past few weeks alone). How do I go about becoming part > of the community and getting write access to this repo if there is no > active maintainer? > > Welcome aboard :-) you're now part of the community! For getting merge rights into the repo, current maintainer should accept you as co-maintainer there. You can discuss here further extensions/improvements you'd like to work on or open bugs/rfe on https://bugzilla.redhat.com/enter_bug.cgi?product=ovirt-distribution&compon… for starting the discussion. If you prefer to work on github only I would recommend to ping here as well, to be sure people will be aware of the issue / pull request has been opened. > > 1. > > Thanks, > > > Jake > > > _______________________________________________ > Devel mailing list -- devel(a)ovirt.org > To unsubscribe send an email to devel-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/privacy-policy.html > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/devel@ovirt.org/message/QCECG5CP4XO7M… > -- Sandro Bonazzola MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://www.redhat.com/> *Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours. <https://mojo.redhat.com/docs/DOC-1199578>*

2 1

[ARM64] Possiblity to support oVirt on ARM64
by Zhenyu Zheng 11 Sep '20

11 Sep '20

Hi oVirt, We are currently trying to make oVirt work on ARM64 platform, since I'm quite new to oVirt community, I'm wondering what is the current status about ARM64 support in the oVirt upstream, as I saw the oVirt Wikipedia page mentioned there is an ongoing efforts to support ARM platform. We have a small team here and we are willing to also help to make this work. Thanks alot, Zhenyu Zheng

6 8

ovirt-engine has been tagged (ovirt-engine-4.4.2.5)
by Tal Nisan 11 Sep '20

11 Sep '20

1 0

CI cannot find ioprocess package
by Vojtech Juranek 09 Sep '20

09 Sep '20

Hi, CI fails quite often with Error: Unable to find a match: python3-ioprocess-1.4.1 see e.g. [1, 2]. Can someone please take a look? Thanks Vojta [1] https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23502 [2] https://jenkins.ovirt.org/job/vdsm_standard-check-patch/23503

2 1

isort errors while make install
by Prajith Kesava Prasad 09 Sep '20

09 Sep '20

Hi, everytime i clone and run make install i get this error, as a workaround i remove them and re-run which works fine, but i wanted to know the root cause, i thought it was because i pulled a wrong head ref?, or is it a common issue? ``` packaging/setup/plugins/ovirt-engine-setup/ovirt-engine/config/aaajdbc.py:249:21 '...'.format(...) has unused named argument(s): profile packaging/setup/plugins/ovirt-engine-setup/ovirt-engine/upgrade/auth_url_validation.py:75:13 '...'.format(...) has unused named argument(s): ownConnection + echo ERROR: The following check failed: ERROR: The following check failed: ``` Regards, Prajith

3 2

ovirt-engine has been tagged (ovirt-engine-4.4.3.2)
by Tal Nisan 09 Sep '20

09 Sep '20

1 0

[CI] Builds broken by "Status code: 403 for http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm"
by Nir Soffer 08 Sep '20

08 Sep '20

This is the second time, last time there was an issue during a nightly job that left the master snapshot repo broken. I have 3 failure builds: https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7744/ https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7751/ https://jenkins.ovirt.org/job/ovirt-engine_standard-check-patch/7755/ All seems to fail in: [2020-09-07T10:00:56.163Z] + dnf install -y http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm [2020-09-07T10:01:08.524Z] Status code: 403 for http://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm (IP: 66.187.230.40) Checking manually show: $ curl https://resources.ovirt.org/pub/yum-repo/ovirt-release-master.rpm <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access /pub/yum-repo/ovirt-release-master.rpm on this server.</p> </body></html> Looking at: https://resources.ovirt.org/pub/yum-repo/ ovirt-elease-master.rpm does not exist. So we have 2 issues: - The file does not exist - We return "403 Forbidden" instead of "404 Not Found"

3 6

gerrit pull/clone timeout
by Prajith Kesava Prasad 07 Sep '20

07 Sep '20

Is anyone else facing an issue of timeout (forever) while cloning/pulling ovirt-engine at times in gerrit, i followed the required procedures like adding ssh keys etc, did anything change or am I missing something? I have pasted the vv output for the same ``` $ git clone git://gerrit.ovirt.org/ovirt-engine -vvv Cloning into 'ovirt-engine'... Looking up gerrit.ovirt.org ... done. Connecting to gerrit.ovirt.org (port 9418) ... 107.22.212.69 done. and then hangs ``` ``` git clone ssh://pkesavap@gerrit.ovirt.org:29418/ovirt-engine.git Cloning into 'ovirt-engine'... ``` Regards, Prajith

2 1

Gerrit patch 110596
by Shubha Kulkarni 04 Sep '20

04 Sep '20

Hello, I have posted patch on gerrit for few weeks now and looking forward to get this completed. HYPERLINK "https://urldefense.com/v3/__https:/gerrit.ovirt.org/*/c/110596/__;Iw!!GqivP…"https://gerrit.ovirt.org/#/c/110596/ So far I got some feedback that I have already incorporated. Can you please review the patch so that I can wrap up this work? Thanks, Shubha

2 1

Re: [ovirt-users] [ovirt 4.2]The snapshot is deleted after restoring the snapshot
by Strahil Nikolov 03 Sep '20

03 Sep '20

If you have snapshots like A -> B -> C and you restore A , it is normal to loose B & C. After all when you restore A , B & C never happened. Otherwise , ovirt should clone the snapshots in separate images and that is not the requested, right ? Best Regards, Strahil Nikolov В четвъртък, 3 септември 2020 г., 10:03:30 Гринуич+3, liuweijie(a)sunyainfo.com <liuweijie(a)sunyainfo.com> написа: Dear All: I used ovirt api (POST /ovirt-engine/api/vms/{vm:id}/snapshots) to create several snapshots. When I call the snapshot recovery api (POST /ovirt-engine/api/vms/{vm:id }/snapshots/{snapshot:id}/restore) to restoe the first snapshot, I found that the next few snapshots were deleted, and it was normal when I restored the last snapshot. Why does the snapshot with the earlier recovery time delete the subsequent snapshot? The vm's os is centos. Hope get help from you soon, Thank you. Yours sincerely， Evelyn _______________________________________________ Users mailing list -- users(a)ovirt.org To unsubscribe send an email to users-leave(a)ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/LJL6NUYBPGJAF…

1 0

oVirt Terraform Provider
by Jake Reynolds 03 Sep '20

03 Sep '20

Hi, A number of PRs (bug fixes & feature additions) are outstanding on the oVirt Terraform Provider https://github.com/oVirt/terraform-provider-ovirt. There seems to have been no activity on the master branch of the repo for months. 1. How can I promote/request that PRs are reviewed in a timely manner? 2. I am using this to deploy a global infrastructure over the next year and expect to be doing further extensions/improvements over that time (done 5 PRs in the past few weeks alone). How do I go about becoming part of the community and getting write access to this repo if there is no active maintainer? Thanks, Jake

1 0

ovirt-engine has been tagged (ovirt-engine-4.4.2.4)
by Tal Nisan 03 Sep '20

03 Sep '20

1 0

Host installation is broken across OST suites
by Marcin Sobczyk 02 Sep '20

02 Sep '20

Hi, OST suites seem to be broken, example runs [1][2]. In 'engine.log' [3] there is a problem reported: 2020-08-31 10:54:50,875+02 ERROR [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-2) [568e87b9] Host installation failed for host '0524ee6a-815b-4f7c-8ac1-a085b9870325', 'lago-basic-suite-master-host-1': null 2020-08-31 10:54:50,875+02 DEBUG [org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand] (EE-ManagedThreadFactory-engine-Thread-2) [568e87b9] Exception: java.lang.NullPointerException at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand.executeCommand(InstallVdsInternalCommand.java:190) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.executeWithoutTransaction(CommandBase.java:1169) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.executeActionInTransactionScope(CommandBase.java:1327) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.runInTransaction(CommandBase.java:2003) at org.ovirt.engine.core.utils//org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInSuppressed(TransactionSupport.java:140) at org.ovirt.engine.core.utils//org.ovirt.engine.core.utils.transaction.TransactionSupport.executeInScope(TransactionSupport.java:79) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.execute(CommandBase.java:1387) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.executeAction(CommandBase.java:419) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.executor.DefaultBackendActionExecutor.execute(DefaultBackendActionExecutor.java:13) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.Backend.runAction(Backend.java:442) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.Backend.runActionImpl(Backend.java:424) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.Backend.runInternalAction(Backend.java:630) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.as.weld.common@19.1.0.Final//org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.delegateInterception(Jsr299BindingsInterceptor.java:79) at org.jboss.as.weld.common@19.1.0.Final//org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:89) at org.jboss.as.weld.common@19.1.0.Final//org.jboss.as.weld.interceptors.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:102) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:40) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:228) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.supports(CMTTxInterceptor.java:430) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:160) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81) at org.jboss.as.weld.common@19.1.0.Final//org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ejb3@19.1.0.Final//org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) at org.wildfly.security.elytron-private@1.11.4.Final//org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:627) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) at org.jboss.invocation@1.5.2.Final//org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185) at org.jboss.as.ee@19.1.0.Final//org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:81) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.interfaces.BackendInternal$$$view2.runInternalAction(Unknown Source) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:410) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.module.ejb.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:134) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.module.ejb.InjectionPointPropagatingEnterpriseTargetBeanInstance.invoke(InjectionPointPropagatingEnterpriseTargetBeanInstance.java:68) at org.jboss.weld.core@3.1.3.Final//org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:106) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.BackendCommandObjectsHandler$BackendInternal$BackendLocal$2049259618$Proxy$_$$_Weld$EnterpriseProxy$.runInternalAction(Unknown Source) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.CommandBase.runInternalAction(CommandBase.java:2381) at deployment.engine.ear.bll.jar//org.ovirt.engine.core.bll.hostdeploy.AddVdsCommand.lambda$executeCommand$3(AddVdsCommand.java:219) at org.ovirt.engine.core.utils//org.ovirt.engine.core.utils.threadpool.ThreadPoolUtil$InternalWrapperRunnable.run(ThreadPoolUtil.java:96) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) at org.glassfish.javax.enterprise.concurrent//org.glassfish.enterprise.concurrent.ManagedThreadFactoryImpl$ManagedThread.run(ManagedThreadFactoryImpl.java:227) Looking at recent patches it might've been introduced by [4]. [1] https://jenkins.ovirt.org/job/ovirt-system-tests_network-suite-master/1470/ [2] https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/11211/ [3] https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/11211… [4] https://gerrit.ovirt.org/#/c/109995/

3 2

Re: [storage] how to find if a snapshot is in preview based on storage domain metadata only?
by Germano Veit Michel 02 Sep '20

02 Sep '20

On Wed, Sep 2, 2020 at 2:36 PM Germano Veit Michel <germano(a)redhat.com> wrote: > > > On Tue, Sep 1, 2020 at 5:39 PM Nir Soffer <nsoffer(a)redhat.com> wrote: > >> On Tue, Sep 1, 2020 at 2:27 AM Germano Veit Michel <germano(a)redhat.com> >> wrote: >> > >> > >> > >> > On Mon, Aug 31, 2020 at 5:00 PM Nir Soffer <nsoffer(a)redhat.com> wrote: >> >> >> >> On Mon, Aug 31, 2020 at 4:48 AM Germano Veit Michel < >> germano(a)redhat.com> wrote: >> >> > >> >> > >> >> > >> >> > On Sun, Aug 30, 2020 at 8:46 PM Nir Soffer <nsoffer(a)redhat.com> >> wrote: >> >> >> >> >> >> >> >> >> >> >> >> On Fri, Aug 28, 2020, 08:36 Germano Veit Michel <germano(a)redhat.com> >> wrote: >> >> >>> >> >> >>> >> >> >>> >> >> >>> On Fri, Aug 28, 2020 at 9:29 AM Nir Soffer <nsoffer(a)redhat.com> >> wrote: >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>> On Thu, Aug 27, 2020, 16:38 Tal Nisan <tnisan(a)redhat.com> wrote: >> >> >>>>> >> >> >>>>> >> >> >>>>> >> >> >>>>> On Fri, Aug 21, 2020 at 4:34 AM Germano Veit Michel < >> germano(a)redhat.com> wrote: >> >> >>>>>> >> >> >>>>>> Hi, >> >> >>>>>> >> >> >>>>>> Is there a reliable way to figure out if a snapshot is in >> preview only using information obtained from the storage domain metadata? >> >> >>>>>> I'm trying to find a way to distinguish a problematic snapshot >> chain (double parent) from a snapshot in preview in order to improve >> dump-volume chains. >> >> >>>>>> >> >> >>>>>> Currently dump-volume-chains throws an error >> (DuplicateParentError) if a snapshot is in preview for the image, as there >> is a 'Y' shape split in the chain >> >> >>>>>> with 2 volumes (previous chain + preview) pointing to a common >> parent: >> >> >>>>>> >> >> >>>>>> image: dff0a0c0-b731-4e5b-9f32-d97310ca40de >> >> >>>>>> >> >> >>>>>> Error: more than one volume pointing to the same >> parent volume e.g: (_BLANK_UUID<-a), (a<-b), (a<-c) >> >> >>>>>> >> >> >>>>>> Unordered volumes and children: >> >> >>>>>> >> >> >>>>>> - e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38 <- >> 5eb2b29d-82d6-4337-8511-3c86705d566e >> >> >>>>>> status: OK, voltype: LEAF, format: COW, >> legality: LEGAL, type: SPARSE, capacity: 1073741824, truesize: 1073741824 >> >> >>>>>> >> >> >>>>>> - e0475853-4514-4464-99e7-b185cce9b67d <- >> deceff83-9d88-4f87-8304-d5bf74d119b1 >> >> >>>>>> status: OK, voltype: LEAF, format: COW, >> legality: LEGAL, type: SPARSE, capacity: 1073741824, truesize: 1073741824 >> >> >>>>>> >> >> >>>>>> - e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38 <- >> e0475853-4514-4464-99e7-b185cce9b67d >> >> >>>>>> status: OK, voltype: INTERNAL, format: COW, >> legality: LEGAL, type: SPARSE, capacity: 1073741824, truesize: 1073741824 >> >> >>>>>> >> >> >>>>>> - 00000000-0000-0000-0000-000000000000 <- >> e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38 >> >> >>>>>> status: OK, voltype: INTERNAL, format: RAW, >> legality: LEGAL, type: PREALLOCATED, capacity: 1073741824, truesize: >> 1073741824 >> >> >>>>>> >> >> >>>>>> From the engine side it's easy, but I'd need to solve this >> problem using only metadata from the storage. >> >> >>>>>> >> >> >>>>>> The only thing I could think of is that one of the volumes >> pointing to the common parent has voltype LEAF. Any better ideas? >> >> >>>>> >> >> >>>>> don't think that there is any, Engine is the orchestrator and >> due to that the info is only in the database >> >> >>>> >> >> >>>> >> >> >>>> There is no good way, but you can look at the length of the >> chain, and the "ctime" value. >> >> >>>> >> >> >>>> For example if this was the original chain: >> >> >>>> >> >> >>>> a <- b <- c >> >> >>>> >> >> >>>> if we preview a: >> >> >>>> >> >> >>>> a <- b <- c >> >> >>>> a <- d >> >> >>>> >> >> >>>> You know that d is a preview volume. >> >> >>>> >> >> >>>> If we preview b, we will have two chains of same length: >> >> >>>> >> >> >>>> a <- b <- c >> >> >>>> a <- b <- d >> >> >>>> >> >> >>>> But the ctime value of d will be larger, since preview is created >> after >> >> >>>> the leaf was created. >> >> >>>> >> >> >>>> ctime is using time.time() so it is not affected by time zone >> changes >> >> >>>> but it may be wrong due to host time changes, so it is not >> reliable. >> >> >>>> >> >> >>>> Can you open a bug for this? >> >> >>> >> >> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1873382 >> >> >>> >> >> >>> I have a prototype working with some code I pasted in the >> bugzilla, but I don't think it's reliable and an overcomplication of what >> should be simple. >> >> >> >> >> >> >> >> >> I don't think the code in the bug is the way to handle this. >> >> >> >> >> >> It will be simpler and more useful to: >> >> >> 1. Find leaves >> >> >> 2. Follow the chain from each leaf, until the base (volume with no >> parent). >> >> >> 3. Display a tree instead of list, like lsblk. >> >> >> >> >> >> For example: >> >> >> >> >> >> dbf1e90c-41d5-4c2d-a8d2-15f2f04d3561 >> >> >> ├─ea6af566-922c-4ca2-af17-67f7cd08826c >> >> >> └─aa5643ef-8c74-4b28-91e0-8d45d6ee426b >> >> >> └─30c4f6d1-7f1d-470b-96ae-7594cf367dfa >> >> > >> >> > I like the idea of this visual representation, but it does not fix >> the problem. >> >> > >> >> > The problem is dump-volume-chains throwing incorrect errors in case >> there is a snapshot in preview. >> >> > >> >> > Error: more than one volume pointing to the same parent volume e.g: >> (_BLANK_UUID<-a), (a<-b), (a<-c) >> >> >> >> This error is wrong, you should remove it, and instead show the tree. >> >> >> >> > There is still a double parent on the representation above. So if >> the analysis is done (text output), there will >> >> > be an error detected no matter how we print it. If there is no way >> to distinguish a preview from a double parent >> >> > problem without leaving any doubt based only on storage metadata >> only then we can improve the >> >> > representation but ultimately the problem remains there. >> >> > >> >> > Ideally I'd like to keep DoubleParentError logic and detect Previews >> to eliminate the false errors. >> >> >> >> This is not possible now. >> >> >> >> > The analysis should be done in the image discrepancy tool on the >> engine, which has dump-volume-chains >> >> > output (json - no analysis) and the engine db. And we are already >> doing some basic checks there. Maybe >> >> > we should even move the entire analysis logic there and make >> dump-volume-chains just print and dump >> >> > data without doing analysis if the analysis cannot be done based on >> partial data. >> >> > >> >> > The main idea here was to simply stop false errors for those who >> look for them in dump-volume-chains >> >> > text output. >> >> > >> >> >> >> >> >> >> >> >> Users of the tool will have to check engine db to understand how to >> fix the disk. >> >> >> >> >> >> Even if it was easy to detect a volume in preview, how do you know >> which chain >> >> >> should be kept? Did it fail just after the user asked to commit the >> preview? >> >> > >> >> > >> >> > This tool is not used to diagnose and correct issues on its own. It >> is used for 2 things, but mainly the first: >> >> > a) Nice readable way to see volumes and their metadata, plus chain >> >> > b) Any obvious errors >> >> > >> >> > The duplicate parent is printing false problems during preview, >> breaking the tool for B. >> >> > >> >> > The main use is still A, use of dump-volume-chains is to stop >> collecting /dev/VG/metadata LV or *.meta files >> >> > and have this info for the volumes in the sosreport. >> >> > >> >> > I'm not aware of anyone using just the output of the tool to perform >> chain changes, every failure >> >> > also requires checking the DB too and most importantly the logs >> (unless rotated). >> >> > >> >> >> >> >> >> Storage format does not have a way to store info about the state of >> the disk, or make atomic >> >> >> changes like remove one chain when committing after a preview. This >> is also the reason we >> >> >> have trouble with removing snapshots. >> >> > >> >> > >> >> > Which means we cannot know for sure what is happening in the chain, >> right? >> >> > With this in mind, any suggestion to stop the false errors? >> >> >> >> Change the code to handle a tree instead of a list of volumes, error >> is gone. >> > >> > But then part of the validation is gone too. We open the possibility of >> validating trees, which are all invalid >> > except for the very specific case of a preview, which we have no data >> to determine for sure anyway. >> >> But the validation is incorrect. Trees are actually supported using >> preview, so >> failing and not showing the tree in dump-volume-chain is a bug. >> > Well, the tree is valid only if it is a snapshot preview and we have no > reliable way to determine if its a preview, > which means we cannot validate the tree reliably too. > > We could do the change, but then we swap one bug for another, from saying > all trees are errors to saying > non-preview trees are fine. False positive to false negative, not sure > which is preferable. > > If we can have a way to determine reliably if the chain is in preview, > then I totally agree it's worth > the effort of changing the logic. Otherwise I think it's not worth > changing right now. > > >> >> > There is not much that can be done as there is no reliable way to >> determine if the chain has a snapshot >> > in preview without several changes on engine and vdsm. And it's not >> worth implementing this, I'll close >> > the bug too. >> >> I think it is worth the time, so better leave this open. >> > Sure, no problem. I'll re-open it. > >> >> > Thanks for your help! >> > >> >> >> >> > >> >> > Since we cannot be sure of this based just on SD metadata, maybe the >> simplest is to remove the >> >> > duplicate parent error string and/or add some warning that it could >> be a snapshot in preview and just >> >> > print the unordered volumes. >> >> > >> >> > The improved visual representation could be handled separate from >> this. I've thought of something >> >> > similar in the past but found hard to print the volume metadata in a >> nice way (and we need to handle >> >> > big chains of several dozen snapshots). >> >> > >> >> > Thanks, >> >> > Germano >> >> > >> >> >> >> >> >> >> >> >> Nir >> >> >> >> >> >>> >> >> >>> >> >> >> >>

1 0

ovirt-engine has been tagged (ovirt-engine-4.4.3.1)
by Tal Nisan 01 Sep '20

01 Sep '20

1 0

[storage] how to find if a snapshot is in preview based on storage domain metadata only?
by Germano Veit Michel 01 Sep '20

01 Sep '20

Hi, Is there a reliable way to figure out if a snapshot is in preview only using information obtained from the storage domain metadata? I'm trying to find a way to distinguish a problematic snapshot chain (double parent) from a snapshot in preview in order to improve dump-volume chains. Currently dump-volume-chains throws an error (DuplicateParentError) if a snapshot is in preview for the image, as there is a 'Y' shape split in the chain with 2 volumes (previous chain + preview) pointing to a common parent: image: dff0a0c0-b731-4e5b-9f32-d97310ca40de Error: more than one volume pointing to the same parent volume e.g: (_BLANK_UUID<-a), (a<-b), (a<-c) Unordered volumes and children: - e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38 <- 5eb2b29d-82d6-4337-8511-3c86705d566e status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 1073741824, truesize: 1073741824 - e0475853-4514-4464-99e7-b185cce9b67d <- deceff83-9d88-4f87-8304-d5bf74d119b1 status: OK, voltype: LEAF, format: COW, legality: LEGAL, type: SPARSE, capacity: 1073741824, truesize: 1073741824 - e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38 <- e0475853-4514-4464-99e7-b185cce9b67d status: OK, voltype: INTERNAL, format: COW, legality: LEGAL, type: SPARSE, capacity: 1073741824, truesize: 1073741824 - 00000000-0000-0000-0000-000000000000 <- e6c7bec0-53c6-4729-a4a0-a9b3ef2b8c38 status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL, type: PREALLOCATED, capacity: 1073741824, truesize: 1073741824 From the engine side it's easy, but I'd need to solve this problem using only metadata from the storage. The only thing I could think of is that one of the volumes pointing to the common parent has voltype LEAF. Any better ideas? Thanks, Germano

3 8