- Devel - oVirt List Archives

vdsm has been tagged (v4.30.13)
by Milan Zamazal 08 Apr '19

08 Apr '19

1 0

VDSM and safelease
by Sandro Bonazzola 05 Apr '19

05 Apr '19

Hi, I stumbled upon safelease package, introduced in oVirt 3.6. I realigned the spec file with Fedora Rawhide: https://gerrit.ovirt.org/#/c/99123/ and then I stopped working on it and decided to open a thread here. safelease package is required in vdsm. I searched for the home page for this package since it moved and found: https://ovirt.org/develop/developer-guide/vdsm/safelease.html This says that sanlock is meant to obsolete safelease. I'm assuming that safelease was used in 3.6 and replaced later by sanlock then kept for backward compatibility. In 4.3 we dropped support for 3.6 level clusters, is this package still needed? If it's still needed, why is it requiring: # Numactl is not available on s390[x] and ARM %ifnarch s390 s390x %{arm} Requires: numactl %endif %ifarch x86_64 Requires: python2-dmidecode Requires: dmidecode Requires: virt-v2v %endif while nothing of above packages seems to be used within the source code of this package? Currently listed maintainers for this package are: Saggi Mizrahi (doesn't seems to be in oVirt project anymore) Yaniv Bronhaim (doesn't seems to be in oVirt project anymore) Yoav Kleinberger (doesn't seems to be in oVirt project anymore) Any thought? -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

7 13

Suspend resume and DHCP
by Dominik Holler 04 Apr '19

04 Apr '19

Hello, would you help me to understand if the dhcp client in an oVirt guest should refresh his dhcp configuration after the guest is resumed? If this is the case, how this should be triggered? The reason why I ask is, that if a VM suspends on a first host, and resumes on a second one, libvirt's nwfilter losses the IP address of the guest, which means that the guest is not reachable until he refreshes dhcp config, if the clean-traffic filter with CTRL_IP_LEARNING=dhcp is used. This scenario might happen in OST basic-suite-master and basic-suite-4.3 in verify_suspend_resume_vm0. Thanks Dominik

4 4

ovirt-engine has been tagged (ovirt-engine-4.3.3.2)
by Tal Nisan 03 Apr '19

03 Apr '19

1 0

[ OST Failure Report ] [ oVirt master (ovirt-engine) ] [ 22-03-2019 ] [004_basic_sanity.hotplug_cpu ]
by Dafna Ron 02 Apr '19

02 Apr '19

Hi, We are failing ovirt-engine master on test 004_basic_sanity.hotplug_cpu looking at the logs, we can see that the for some reason, libvirt reports a vm as none responsive which fails the test. CQ first failure was for patch: https://gerrit.ovirt.org/#/c/98553/ - core: Add display="on" for mdevs, use nodisplay to override But I do not think this is the cause of failure. Adding Marcin, Milan and Dan as well as I think it may be netwrok related. You can see the libvirt log here: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13516/artifa… you can see the full logs here: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13516/artifac… Evgheni and I confirmed this is not an infra issue and the problem is ssh connection to the internal vm Thanks, Dafna error: 2019-03-22 15:08:22.658+0000: 22068: warning : qemuDomainObjTaint:7521 : Domain id=3 name='vm0' uuid=a9443d02-e054-40bb-8ea3-ae346e2d02a7 is tainted: hook-script 2019-03-22 15:08:22.693+0000: 22068: error : virProcessRunInMountNamespace:1159 : internal error: child reported: unable to set security context 'system_u:object_r:virt_content_t:s0' on '/rhev/data-center/mnt/blockSD/91d97292-9ac3-4d77-a152-c7ea3250b065/images/e60dae48-ecc7-4171-8bfe-42bfc2190ffd/40243c76-a384-4497-8a2d-792a5e10d510': No such file or directory 2019-03-22 15:08:28.168+0000: 22070: error : qemuDomainAgentAvailable:9133 : Guest agent is not responding: QEMU guest agent is not connected 2019-03-22 15:08:58.193+0000: 22070: error : qemuDomainAgentAvailable:9133 : Guest agent is not responding: QEMU guest agent is not connected 2019-03-22 15:13:58.179+0000: 22071: error : qemuDomainAgentAvailable:9133 : Guest agent is not responding: QEMU guest agent is not connected

8 17

oVirt Survey 2019 results
by Sandro Bonazzola 02 Apr '19

02 Apr '19

Thanks to the 143 participants to oVirt Survey 2019! The survey is now closed and results are publicly available at https://bit.ly/2JYlI7U We'll analyze collected data in order to improve oVirt thanks to your feedback. As a first step after reading the results I'd like to invite the 30 persons who replied they're willing to contribute code to send an email to devel(a)ovirt.org introducing themselves: we'll be more than happy to welcome them and helping them getting started. I would also like to invite the 17 people who replied they'd like to help organizing oVirt events in their area to either get in touch with me or introduce themselves to users(a)ovirt.org so we can discuss about events organization. Last but not least I'd like to invite the 38 people willing to contribute documentation and the one willing to contribute localization to introduce themselves to devel(a)ovirt.org. Thanks! -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

How write OpenID Connect clients
by du_hongyu＠yeah.net 31 Mar '19

31 Mar '19

hi， I write a OpenID Connect clients follow https://github.com/cqcmdwym/passport-oidc-example https://bugzilla.redhat.com/show_bug.cgi?id=1416491 I fixed passport.use('oidc', new OidcStrategy({ issuer: 'https://10.110.128.120:443/ovirt-engine/sso/openid', authorizationURL: 'https://10.110.128.120:443/ovirt-engine/sso/openid/authorize', tokenURL: 'https://10.110.128.120:443/ovirt-engine/sso/openid/token', userInfoURL: 'https://10.110.128.120:443/ovirt-engine/sso/openid/userinfo', clientID: 'openid-test', clientSecret: '34bACHKj8VN1WOImGUKphzE4fPk3WPvAaKlQFsrQ79g', callbackURL: 'http://10.110.128.195:3000/authorization-code/callback', scope: 'openid ovirt-app-portal ovirt-app-admin ovirt-app-api ovirt-ext=token:password-access ovirt-ext=auth:sequence-priority ovirt-ext=token:login-on-behalf ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search ovirt-ext=token-info:validate ovirt-ext=revoke:revoke-all' error： id token not issued by correct OpenID provider - expected: https://10.110.128.120:443/ovirt-engine/sso/openid | from: https://10.110.128.120:443 Error: id token not issued by correct OpenID provider - expected: https://10.110.128.120:443/ovirt-engine/sso/openid | from: https://10.110.128.120:443 at /home/duhy/workSpace/nodejs/duhy/passport-oidc-example/node_modules/passport-openidconnect/lib/strategy.js:113:62 at /home/duhy/workSpace/nodejs/duhy/passport-oidc-example/node_modules/oauth/lib/oauth2.js:209:7 at passBackControl (/home/duhy/workSpace/nodejs/duhy/passport-oidc-example/node_modules/oauth/lib/oauth2.js:134:9) at IncomingMessage.<anonymous> (/home/duhy/workSpace/nodejs/duhy/passport-oidc-example/node_modules/oauth/lib/oauth2.js:157:7) at IncomingMessage.emit (events.js:194:15) at endReadableNT (_stream_readable.js:1125:12) at process._tickCallback (internal/process/next_tick.js:63:19) Regards Hongyu Du

1 0

Failed to restart vdsmd due to kdump.service
by Eyal Shenitzky 31 Mar '19

31 Mar '19

Hi, Does someone ever encountered on failure to restart vdsmd due to the following issue: # journalctl -xe Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com kdumpctl[8926]: kexec: failed to load kdump kernel Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com kdumpctl[8926]: Starting kdump: [FAILED] Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com systemd[1]: kdump.service: Main process exited, code=exited, status=1/FAILURE Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com systemd[1]: kdump.service: Failed with result 'exit-code'. Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com systemd[1]: Failed to start Crash recovery kernel arming. -- Subject: Unit kdump.service has failed -- Defined-By: systemd -- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit kdump.service has failed. -- -- The result is failed. Mar 28 14:46:46 dhcp-0-221.tlv.redhat.com audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=kdump comm="systemd" exe="/usr/lib/systemd/systemd" > Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com sudo[9143]: root : problem with defaults entries ; TTY=pts/0 ; PWD=/root/git/qemu/build ; USER=root ; Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: USER_ACCT pid=9143 uid=0 auid=0 ses=1 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="root" exe="/usr/b> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com sudo[9143]: root : TTY=pts/0 ; PWD=/root/git/qemu/build ; USER=root ; COMMAND=/usr/bin/chcon --reference=/usr/bin/qemu-xxx /u> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: USER_CMD pid=9143 uid=0 auid=0 ses=1 msg='cwd="/root/git/qemu/build" cmd=6368636F6E202D2D7265666572656E63653D2F75737> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: CRED_REFR pid=9143 uid=0 auid=0 ses=1 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sud> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com sudo[9143]: pam_systemd(sudo:session): Cannot create session: Already running in a session Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com sudo[9143]: pam_unix(sudo:session): session opened for user root by root(uid=0) Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: USER_START pid=9143 uid=0 auid=0 ses=1 msg='op=PAM:session_open grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limi> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com sudo[9143]: pam_unix(sudo:session): session closed for user root Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: USER_END pid=9143 uid=0 auid=0 ses=1 msg='op=PAM:session_close grantors=pam_keyinit,pam_limits,pam_keyinit,pam_limit> Mar 28 14:47:15 dhcp-0-221.tlv.redhat.com audit[9143]: CRED_DISP pid=9143 uid=0 auid=0 ses=1 msg='op=PAM:setcred grantors=pam_env,pam_fprintd acct="root" exe="/usr/bin/sud> lines 2486-2509/2509 (END) # systemctl status vdsmd.service ● vdsmd.service - Virtual Desktop Server Manager Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Thu 2019-03-28 14:46:45 IST; 5min ago Process: 9059 ExecStopPost=/usr/libexec/vdsm/vdsmd_init_common.sh --post-stop (code=exited, status=0/SUCCESS) Process: 9048 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh --pre-start (code=exited, status=1/FAILURE) Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: vdsmd.service: Service hold-off time over, scheduling restart. Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: vdsmd.service: Scheduled restart job, restart counter is at 5. Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: Stopped Virtual Desktop Server Manager. Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: vdsmd.service: Start request repeated too quickly. Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: vdsmd.service: Failed with result 'exit-code'. Mar 28 14:46:45 dhcp-0-221.tlv.redhat.com systemd[1]: Failed to start Virtual Desktop Server Manager. Occurred to me on a Fedora 28 virtual machine that runs on rhel 7.6 host. Thanks -- Regards, Eyal Shenitzky

3 3

[Ovirt] [CQ weekly status] [29-03-2019]
by Dafna Ron 29 Mar '19

29 Mar '19

Hi, This mail is to provide the current status of CQ and allow people to review status before and after the weekend. Please refer to below colour map for further information on the meaning of the colours. *CQ-4.2*: GREEN (#1) Last CQ job failure on 4.2 was 25-03-2019 on project ovirt-ansible-hosted-engine-setup due missing polkit package. *CQ-4.3*: RED (#1) failures in 4.3 and master this week were caused by two issues: 1. we have had random failures on 4 different tests which we are working on debugging with Marcin, Martin and several more people. this has been disruptive this week but did not cause any delays as I was re-triggering failed projects to insure they have their packages buit in tested. Currently we suspect api issue or changes to poastgres are causing the failures 2. we had libcgroup-tools package missing which cause failures for all projects in initialize engine. I merged a patch to fix the issue and provide the package. *CQ-Master:* RED (#1) We have had the same issues as in 4.3 this week. Current running jobs for 4.2 [1], 4.3 [2] and master [3] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change-q… [3] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Happy week! Dafna ------------------------------------------------------------------------------------------------------------------- COLOUR MAP Green = job has been passing successfully ** green for more than 3 days may suggest we need a review of our test coverage 1. 1-3 days GREEN (#1) 2. 4-7 days GREEN (#2) 3. Over 7 days GREEN (#3) Yellow = intermittent failures for different projects but no lasting or current regressions ** intermittent would be a healthy project as we expect a number of failures during the week ** I will not report any of the solved failures or regressions. 1. Solved job failures YELLOW (#1) 2. Solved regressions YELLOW (#2) Red = job has been failing ** Active Failures. The colour will change based on the amount of time the project/s has been broken. Only active regressions would be reported. 1. 1-3 days RED (#1) 2. 4-7 days RED (#2) 3. Over 7 days RED (#3)

1 0

OST: add_master_storage_domain failed, Could not find hosts that are up in DC test-dc
by Yedidyah Bar David 28 Mar '19

28 Mar '19

Hi all, I want to verify [1]. So I ran the manual job, basic suite 4.3 [2]. It failed [3] with $subject. Right before that, verify_add_hosts did succeed, and took 59 seconds. I gave a brief look at the code of verify_add_hosts, and it checks that at least one host is UP. The patch [1] *might* have caused ansible-host-deploy to take longer, still not sure. In any case, ansible-host-deploy finished at 05:48:45 [5], 14 seconds before verify_add_hosts finished at 09:48:59 [4]. Can it be, that a host is considered UP (from the POV of verify_add_hosts), but is still not ready for creating storage? Also, host-1, at the point when OST was killed and collected logs, was right after finishing host-deploy, and didn't start ansible-host-deploy yet, according to engine.log. But host-0 should have been enough, I think. Thanks, [1] https://gerrit.ovirt.org/99000 [2] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… [3] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… [4] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… [5] https://jenkins.ovirt.org/view/oVirt%20system%20tests/job/ovirt-system-test… -- Didi

3 3