VDSM Hook to modify passthrough devices
by Michal Mocnak
Hello,
i've set up gpu passthrough with RTX2080 consumer grade card properly. But need to add rom file param into libvirt XML. I wrote vdsm hook which is quite easy but i've found a problem that even i put the hook into before_vm_start event those passthrough devices are not present at that time in the XML.
I couldn't find anything on docs about when those devices are ready in the XML and which event i should use. Thank you so much !!
Cheers
-michal
3 years, 2 months
[VDSM] Test pass, build fail during cleanup
by Nir Soffer
We seem to have an issue in the CI, starting this week.
All tests pass, but creating coverage report fail:
+ generate_combined_coverage_report
+ pushd tests
~/tests ~
+ pwd
/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests
+ ls .coverage-gluster .coverage-lib .coverage-network .coverage-nose
.coverage-storage .coverage-virt
.coverage-gluster
.coverage-lib
.coverage-network
.coverage-nose
.coverage-storage
.coverage-virt
+ python3 -m coverage combine .coverage-gluster .coverage-lib
.coverage-network .coverage-nose .coverage-storage .coverage-virt
No usable data files
Coverage.py warning: Couldn't read data from
'/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/.coverage-gluster':
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x96 in position
106: invalid start byte
Coverage.py warning: Couldn't read data from
'/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/.coverage-lib':
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x96 in position
106: invalid start byte
Coverage.py warning: Couldn't read data from
'/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/.coverage-network':
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x96 in position
106: invalid start byte
Coverage.py warning: Couldn't read data from
'/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/.coverage-nose':
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x96 in position
106: invalid start byte
Coverage.py warning: Couldn't read data from
'/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/.coverage-storage':
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x96 in position
106: invalid start byte
Coverage.py warning: Couldn't read data from
'/home/jenkins/workspace/vdsm_standard-check-patch/vdsm/tests/.coverage-virt':
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x96 in position
106: invalid start byte
This looks like a bug in coverage, or maybe we use the wrong version
of this tool?
+ teardown
+ res=1
+ '[' 1 -ne 0 ']'
+ echo '*** err: 1'
*** err: 1
Additionally, we have this very strange error:
+ teardown_storage
+ python3 tests/storage/userstorage.py teardown
python3: can't open file 'tests/storage/userstorage.py': [Errno 2] No
such file or directory
This error is impossible, since tests/storage/userstorage.py is part
of the source.
Is it possible that some other code has deleted the source while a
build was running?
+ echo 'WARNING: Ingoring error while tearing down user storage'
WARNING: Ingoring error while tearing down user storage
We were careful not to fail the build because this issue, but it failed because
coverage report could not be created.
There are multiple instance of this issue:
- https://jenkins.ovirt.org/job/vdsm_standard-check-patch/26107//artifact/c...
- https://jenkins.ovirt.org/job/vdsm_standard-check-patch/26103//artifact/c...
- https://jenkins.ovirt.org/job/vdsm_standard-check-patch/26102//artifact/c...
I think Eyal reported another instance, but I cannot find it now.
2 weeks ago we updated pytest and pytest-cov to latest version, but we did
not see this issue in the CI when we tested the change:
https://gerrit.ovirt.org/c/vdsm/+/112604
And CI was fine since then, so this may not be related, unless this is
a regression
in latest coverage or pytest-cov.
Nir
3 years, 2 months
OST on Stream
by Michal Skrivanek
There seems to be multiple issues really
1) First it fails on “unknown state” of ovirt-engine-notifier service. Seems the OST code is not handling service states well and just explodes
2) Either way, the problem is it's stopped. It should be running
3) if you start it manually it gets to the engine-config test and restarts engine. It explodes here again, apparently same reason as #1
4) host installation fails - didi’s https://gerrit.ovirt.org/#/c/ovirt-engine/+/113101/ is fixing it
5) verify_engine_notifier fails when we try to stop it. it’s not running due to #2 and it explodes anyway due to #1
rest seems to work fine except few more #1 issues, so that’s good…
Marcin, can you please prioritize #1? Martin, any idea about notifier?
Thanks,
michal
3 years, 2 months
Re: [ovirt-users] Re: [ANN] oVirt 4.4.4 is now generally available
by Benny Zlotnik
On Tue, Dec 22, 2020 at 6:33 PM Konstantin Shalygin <k0ste(a)k0ste.ru> wrote:
>
> Sandro, FYI we are not against cinderlib integration, more than we are upgrade 4.3 to 4.4 due movement to cinderlib.
>
> But (!) current Managed Storage Block realization support only krbd (kernel RBD) driver - it's also not a option, because kernel client is always lagging behind librbd, and every update\bugfix we should reboot whole host instead simple migration of all VMs and then migrate it back. Also with krbd host will be use kernel page cache, and will not be unmounted if VM will crash (qemu with librbd is one userland process).
>
There was rbd-nbd support at some point in cinderlib[1] which
addresses your concerns, but it was removed because of some issues
+Gorka, are there any plans to pick it up again?
[1] https://github.com/Akrog/cinderlib/commit/a09a7e12fe685d747ed390a59cd42d0...
> So for me current situation look like this:
>
> 1. We update deprecated OpenStack code? Why, Its for delete?.. Nevermind, just update this code...
>
> 2. Hmm... auth tests doesn't work, to pass test just disable any OpenStack project_id related things... and... Done...
>
> 3. I don't care how current cinder + qemu code works, just write new one for linux kernel, it's optimal to use userland apps, just add wrappers (no, it's not);
>
> 4. Current Cinder integration require zero configuration on oVirt hosts. It's lazy, why oVirt administrator do nothing? just write manual how-to install packages - oVirt administrators love anything except "reinstall" from engine (no, it's not);
>
> 5. We broke old code. New features is "Cinderlib is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production".
>
> 6. Oh, we broke old code. Let's deprecate them and close PRODUCTION issues (we didn't see anything).
>
>
> And again, we are not hate new cinderlib integration. We just want that new technology don't break all PRODUCTION clustes. Almost two years ago I write on this issue https://bugzilla.redhat.com/show_bug.cgi?id=1539837#c6 about "before deprecate, let's help to migrate". For now I see that oVirt totally will disable QEMU RBD support and want to use kernel RBD module + python os-brick + userland mappers + shell wrappers.
>
>
> Thanks, I hope I am writing this for a reason and it will help build bridges between the community and the developers. We have been with oVirt for almost 10 years and now it is a crossroads towards a different virtualization manager.
>
> k
>
>
> So I see only regressions for now, hope we'll found some code owner who can catch this oVirt 4.4 only bugs.
>
I looked at the bugs and I see you've already identified the problem
and have patches attached, if you can submit the patches and verify
them perhaps we can merge the fixes
3 years, 2 months
