- Devel - oVirt List Archives

[hyperv] hvinfo: command line tool to get the HyperV enlightements status from within the guest
by Francesco Romani 12 Mar '19

12 Mar '19

Hi all, lately I've been involved again in hyperv support. I was tasked to help improve the testability of the hyperv guest configuration. Hyperv support is a set of optimizations that libvirt/qemu offer to improve the runtime behaviour (stability, performance) of Windows guets. See for example: https://libvirt.org/formatdomain.html#elementsFeatures oVirt does support them (see for example https://github.com/oVirt/vdsm/blob/master/lib/vdsm/virt/libvirtxml.py#L243) and will keep supporting them because they are a key feature for windows guests. Up until now the easiest (only?) way to check if a hyperv optmization was really enabled was to inspect the libvirt XML and/or the QEMU command line flags But we wanted to have another check. Enter hvinfo: https://github.com/fromanirh/hvinfo hvinfo is a simple tool that decodes CPUID informations according to the publicly-available HyperV specs (https://github.com/MicrosoftDocs/Virtualization-Documentation/tree/live/tlfs) and report what the guest sees. It takes no arguments - just run it!-, it requires no special privileges and emits easy to consume JSON. It is designed to help and integrate into fully automated CI/QA. Being a commandline tool, is hard to give a "screenshot", so let me just report sample output (admin privileges not actually required) Windows PowerShell Copyright (C) Microsoft Corporation. All rights reserved. PS C:\Users\admin> cd .\Downloads\ PS C:\Users\admin\Downloads> .\hvinfo.exe { "HyperVsupport": true, "Features": { "GuestDebugging": false, "PerformanceMonitor": false, "PCPUDynamicPartitioningEvents": true, "HypercallInputParamsXMM": false, "VirtualGuestIdleState": false, "HypervisorSleepState": false, "NUMADistanceQuery": false, "TimerFrequenciesQuery": false, "SytheticMCEInjection": false, "GuestCrashMSR": false, "DebugMSR": false, "NPIEP": false, "DisableHypervisorAvailable": false, "ExtendedGvaRangesForFlushVirtualAddressList": false, "HypercallOutputReturnXMM": false, "SintPollingMode": false, "HypercallMsrLock": false, "UseDirectSyntheticTimers": false }, "Recommendations": { "HypercallAddressSpaceSwitch": false, "HypercallLocalTLBFlush": false, "HypercallRemoteTLBFlush": false, "MSRAPICRegisters": true, "MSRSystemReset": false, "RelaxedTiming": true, "DMARemapping": false, "InterruptRemapping": false, "X2APICMSR": false, "DeprecatingAutoEOI": false, "SyntheticClusterIPI": false, "ExProcessorMasks": false, "Nested": false, "INTForMBECSyscalls": false, "NestedEVMCS": false, "SyncedTimeline": false, "DirectLocalFlushEntire": false, "NoNonArchitecturalCoreSharing": false, "SpinlockRetries": 8191 } } PS C:\Users\admin\Downloads> Caveat: the name of the features are the same of the spec, so we need mappings for oVirt flags, libvirt flags and so on. For example libvirt xml domain.features.hyperv.relaxed[state="on"] maps to hvinfo json Features.Recommendations.RelaxedTiming=true Feel free to test it and report any issue Bests, -- Francesco Romani Senior SW Eng., Virtualization R&D Red Hat IRC: fromani github: @fromanirh

2 1

ovirt-engine has been tagged (ovirt-engine-4.3.2.1)
by Tal Nisan 12 Mar '19

12 Mar '19

1 0

vdsm has been tagged (v4.30.11)
by Milan Zamazal 11 Mar '19

11 Mar '19

3 3

unboundid-ldapsdk-4.0.10 is now available for testing
by Sandro Bonazzola 11 Mar '19

11 Mar '19

On Fedora 28 we have 4.0.7. On Fedora 30 we had 4.0.9. The new releases 4.0.10 will be soon available within repositories for Fedora >= 30 and includes several bug fixes and enhancements. You can see release notes for 4.0.10 here: https://github.com/pingidentity/ldapsdk/releases In oVirt this package is required by ovirt-engine-extension-aaa-ldap. If you're going to test the package, please provide karma at https://bodhi.fedoraproject.org/updates/unboundid-ldapsdk-4.0.10-1.fc30 Martin, Ravi, let me know if you see value in backporting this version to Fedora 28 and EL7 for oVirt 4.3 consumption. 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

[ OST Failure Report ] [ oVirt 4.3 (vdsm-jsonrpc-java) ] [ 10-3-19 ] [ Upgrade Suite ]
by Liora Milbaum 11 Mar '19

11 Mar '19

Link and headline of suspected patches: Link to Job: http://jenkins.ovirt.org/job/ovirt-4.3_change-queue-tester/153/ Link to all logs: (Relevant) error snippet from the log: <error> [36m # 001_upgrade_engine.test_initialize_engine: [0m [0m [0m [36m * Copy /home/jenkins/workspace/ovirt-4.3_change-queue-tester/ovirt-system-tests/upgrade-from-prevrelease-suite-4.3/upgrade-engine-answer-file.conf to lago-upgrade-from-prevrelease-suite-4-3-engine:/tmp/answer-file-post: [0m [0m [0m [36m * Copy /home/jenkins/workspace/ovirt-4.3_change-queue-tester/ovirt-system-tests/upgrade-from-prevrelease-suite-4.3/upgrade-engine-answer-file.conf to lago-upgrade-from-prevrelease-suite-4-3-engine:/tmp/answer-file-post: [32mSuccess [0m (in 0:00:00) [0m [36m * Collect artifacts: [0m [0m [0m [36m ~ [Thread-8] Copy from lago-upgrade-from-prevrelease-suite-4-3-engine:/tmp/otopi* to /dev/shm/ost/deployment-upgrade-from-prevrelease-suite-4.3/default/test_logs/001_upgrade_engine.test_initialize_engine-20190307160642/lago-upgrade-from-prevrelease-suite-4-3-engine/_tmp_otopi*: [31mERROR [0m (in 0:00:00) [0m [36m - [Thread-8] lago-upgrade-from-prevrelease-suite-4-3-engine: [31mERROR [0m (in 0:00:00) [0m [36m * Collect artifacts: [31mERROR [0m (in 0:00:01) [0m [36m # 001_upgrade_engine.test_initialize_engine: [31mERROR [0m (in 0:00:49) [0m [36m # Results located at /dev/shm/ost/deployment-upgrade-from-prevrelease-suite-4.3/001_upgrade_engine.py.junit.xml [0m [36m@ Run test: 001_upgrade_engine.py: [31mERROR [0m (in 0:00:49) [0m [31mError occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 383, in do_run self.cli_plugins[args.ovirtverb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 184, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 549, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 560, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 107, in do_ovirt_runtest raise RuntimeError('Some tests failed') RuntimeError: Some tests failed [0m </error> -- *Liora Milbaum* Senior Principal Software Engineer RHV/CNV DevOps EMEA VIRTUALIZATION R&D T: +972-54-6560051 <https://red.ht/sig>

3 2

[ OST Failure Report ] [ oVirt master (ovirt-engine) ] [ 10-03-19 ] [ verify_glance_import ]
by Liora Milbaum 10 Mar '19

10 Mar '19

Link and headline of suspected patches: Link to Job: http://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13310/ Link to all logs: (Relevant) error snippet from the log: <error> [36m@ Run test: 004_basic_sanity.py: [0m [0m [0m nose.config: INFO: Ignoring files matching ['^\\.', '^_', '^setup\\.py$'] [36m # verify_glance_import: [0m [0m [0m [31m * Unhandled exception in <function <lambda> at 0x7f9f147cbed8> Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/testlib.py", line 234, in assert_equals_within res = func() File "/home/jenkins/workspace/ovirt-master_change-queue-tester/ovirt-system-tests/basic-suite-master/test-scenarios/004_basic_sanity.py", line 1153, in <lambda> lambda: api.disks.get(disk_name).status.state == 'ok', AttributeError: 'NoneType' object has no attribute 'status' [0m [36m * Collect artifacts: [0m [0m [0m [36m ~ [Thread-4] Copy from lago-basic-suite-master-engine:/tmp/otopi* to /dev/shm/ost/deployment-basic-suite-master/default/test_logs/004_basic_sanity.verify_glance_import-20190307161910/lago-basic-suite-master-engine/_tmp_otopi*: [31mERROR [0m (in 0:00:00) [0m [36m - [Thread-4] lago-basic-suite-master-engine: [31mERROR [0m (in 0:00:00) [0m [36m * Collect artifacts: [31mERROR [0m (in 0:00:02) [0m [36m # verify_glance_import: [31mERROR [0m (in 0:00:02) [0m [36m # Results located at /dev/shm/ost/deployment-basic-suite-master/004_basic_sanity.py.junit.xml [0m [36m@ Run test: 004_basic_sanity.py: [31mERROR [0m (in 0:00:02) [0m [31mError occured, aborting Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 383, in do_run self.cli_plugins[args.ovirtverb].do_run(args) File "/usr/lib/python2.7/site-packages/lago/plugins/cli.py", line 184, in do_run self._do_run(**vars(args)) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 549, in wrapper return func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/lago/utils.py", line 560, in wrapper return func(*args, prefix=prefix, **kwargs) File "/usr/lib/python2.7/site-packages/ovirtlago/cmd.py", line 107, in do_ovirt_runtest raise RuntimeError('Some tests failed') RuntimeError: Some tests failed [0m </error> -- *Liora Milbaum* Senior Principal Software Engineer RHV/CNV DevOps EMEA VIRTUALIZATION R&D T: +972-54-6560051 <https://red.ht/sig>

2 1

[ OST Failure Report ] [ oVirt Master (ovirt-engine-nodejs-modules) ] [ 27-02-2019 ] [ 002_bootstrap.add_vm2_lease ]
by Dafna Ron 10 Mar '19

10 Mar '19

Hi, We have a failure on the project in basic suite, master branch. The recent failure was in patch: https://gerrit.ovirt.org/#/c/98087/1 - Add pre-seed for ovirt-web-ui CQ is pointing at the below as the root cause (which was merged a while back): https://gerrit.ovirt.org/#/c/97491/ - Add pre-seed for ovirt-web-ui Can you please check the issue as it seems both patches are changing the same thing and the project seem to be broken since https://gerrit.ovirt.org/#/c/97491/3 Latest failure: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13171/ Logs: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/13171/artifa… errors from logs: Engine: 2019-02-27 13:37:28,479-05 ERROR [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [74283e25] Transaction rolled-back for command 'org.ovirt.engine.core.bll.UpdateVmCommand'. 2019-02-27 13:37:28,483-05 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default task-1) [74283e25] EVENT_ID: USER_FAILED_UPDATE_VM(58), Failed to update VM vm2 (User: admin@inter nal-authz). 2019-02-27 13:37:28,485-05 INFO [org.ovirt.engine.core.bll.UpdateVmCommand] (default task-1) [74283e25] Lock freed to object 'EngineLock:{exclusiveLocks='[vm2=VM_NAME]', sharedLocks='[3500eb82-e5e2-4e24-b41c-ea 02d9f6adee=VM]'}' 2019-02-27 13:37:28,485-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (default task-1) [74283e25] method: runAction, params: [UpdateVm, VmManagementParametersBase:{commandId='340 59769-05b9-429e-8356-f6b9b9953f55', user='admin', commandType='UpdateVm', vmId='3500eb82-e5e2-4e24-b41c-ea02d9f6adee'}], timeElapsed: 6618ms 2019-02-27 13:37:28,486-05 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (default task-1) [] Operation Failed: [] 2019-02-27 13:37:28,579-05 DEBUG [org.ovirt.engine.core.common.di.interceptor.DebugLoggingInterceptor] (EE-ManagedThreadFactory-engineScheduled-Thread-85) [] method: get, params: [e29c0ba1-464c-4eb4-a8f2-c6933d9 9969a], timeElapsed: 3ms vdsm: 2019-02-27 13:37:21,987-0500 INFO (jsonrpc/1) [vdsm.api] FINISH lease_info error=No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee from=::ffff:192.168.201.4,43920, flow_id=117dec74-ad59-4b12-8148-b2c130337c10, task_id=9c297d41-0aa7-4c74-b268-b710e666bc6c (api:52) 2019-02-27 13:37:21,988-0500 ERROR (jsonrpc/1) [storage.TaskManager.Task] (Task='9c297d41-0aa7-4c74-b268-b710e666bc6c') Unexpected error (task:875) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 882, in _run return fn(*args, **kargs) File "<string>", line 2, in lease_info File "/usr/lib/python2.7/site-packages/vdsm/common/api.py", line 50, in method ret = func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/hsm.py", line 3702, in lease_info info = dom.lease_info(lease.lease_id) File "/usr/lib/python2.7/site-packages/vdsm/storage/sd.py", line 674, in lease_info return vol.lookup(lease_id) File "/usr/lib/python2.7/site-packages/vdsm/storage/xlease.py", line 553, in lookup raise NoSuchLease(lease_id) NoSuchLease: No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee 2019-02-27 13:37:21,988-0500 INFO (jsonrpc/1) [storage.TaskManager.Task] (Task='9c297d41-0aa7-4c74-b268-b710e666bc6c') aborting: Task is aborted: u'No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee' - code 100 (task:1181) 2019-02-27 13:37:21,988-0500 ERROR (jsonrpc/1) [storage.Dispatcher] FINISH lease_info error=No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee (dispatcher:87) Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/vdsm/storage/dispatcher.py", line 74, in wrapper result = ctask.prepare(func, *args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 108, in wrapper return m(self, *a, **kw) File "/usr/lib/python2.7/site-packages/vdsm/storage/task.py", line 1189, in prepare raise self.error NoSuchLease: No such lease 3500eb82-e5e2-4e24-b41c-ea02d9f6adee

5 9

ovirt-vmconsole-1.0.6-3.fc28.noarch: Non-fatal POSTUN scriptlet failure
by Nir Soffer 10 Mar '19

10 Mar '19

When updating Fedora 28 host with ovirt-release-master repo, I see this error: Running scriptlet: ovirt-vmconsole-1.0.6-3.fc28.noarch 143/251 libsemanage.semanage_module_key_set_name: Name /usr/share/selinux/packages/ovirt-vmconsole/ovirt_vmconsole.pp is invalid. semodule: Failed on /usr/share/selinux/packages/ovirt-vmconsole/ovirt_vmconsole.pp! warning: %postun(ovirt-vmconsole-1.0.6-3.fc28.noarch) scriptlet failed, exit status 1 Non-fatal POSTUN scriptlet failure in rpm package ovirt-vmconsole Non-fatal POSTUN scriptlet failure in rpm package ovirt-vmconsole I did not try to use it, I don't know if we have a real issue. Looks like we need to either fix the issue or silence the warnings. Nir

2 1

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

09 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 06-03-2019 on project ovirt-ansible-vm-infra due to missing jtk2 package. this issue is now fixed with patch: https://gerrit.ovirt.org/#/c/98304/ *CQ-4.3*: RED (#1) Last job to fail is for project imgbased. the failure is due to the random failures we have been having from test add_vm2_lease. this issue is currently debated in the list. New repo and packages were updated by Galit due to failure in CQ for missing packages: https://gerrit.ovirt.org/#/c/98312/ *CQ-Master:* RED (#1) We were failing this week due to missing packages which was fixed by: https://gerrit.ovirt.org/#/c/98304/ We also had two regressions which were fixed by: https://gerrit.ovirt.org/#/c/98317/ and by https://gerrit.ovirt.org/#/c/98371/ All projects are currently passing Current running jobs for 4.2 [1] and master [2] can be found here: [1] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.2_change-qu… [2] 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 1

ovirt and AMD virtualization bug
by Hetz Ben Hamo 09 Mar '19

09 Mar '19

Hi, I've done some research on a bug which I found on the AMD Zen/Zen+ based CPU's. Apparently, when using nested virtualization, the CPU doesn't expose the "monitor" CPU flag. While other virtualization solutions (Xen, ESXi, Hyper-V) don't care about this issue and let you run with nested without any problem, oVirt doesn't let you launch or create any VM and it complains that this "monitor" CPU flag is missing. Since QEMU/KVM cannot do anything about it, I was wondering if the ovirt dev team could ignore this flag please. Thanks

2 1