- Devel - oVirt List Archives

=?utf-8?q?=5Bovirt-devel=5D?=(reddit) 2 months with oVirt review
by Sandro Bonazzola 13 Feb '19

13 Feb '19

Hi, thanks to Greg for sharing the link to https://www.reddit.com/r/homelab/comments/ahq29c/2_months_with_ovirt_review/ This is a very constructive feedback from community, let's see what can be done for improving on the highlighted parts. 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>

2 1

[ OST Failure Report ] [ oVirt Master (ovirt-engine) ] [ 13-02-2019 ] [ 001_initialize_engine.initialize_engine ]
by Dafna Ron 13 Feb '19

13 Feb '19

Hi, we are failing on project ovirt-engine in master branch on initialize engine Change suspected: https://gerrit.ovirt.org/#/c/95743/8 - core: Remove unused field VdsStatic.vdsStrength setup log is here: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/12864/artifa… full logs are here: https://jenkins.ovirt.org/job/ovirt-master_change-queue-tester/12864/artifa… Can you please check the issue? Thanks, Dafna <error> INSERT INTO gluster_config_master(config_key, config_description, minimum_supported_cluster, config_possible_values, config_feature) values('use_meta_volume', 'Meta volume for the geo-replication session', '3.5', 'false;true', 'geo_replication'); ************************** INSERT 0 1 2019-02-13 09:03:04,406-0500 Saving custom users permissions on database objects... ********* QUERY ********** copy ( select count(*) from pg_available_extensions where name = 'uuid-ossp' and installed_version IS NOT NULL ) to stdout with delimiter as '|'; ************************** 2019-02-13 09:03:04,906-0500 dbfunc_psql_die --file=/usr/share/ovirt-engine/dbscripts/upgrade/04_00_0000_set_version.sql ********* QUERY ********** select 4000000; ************************** 4000000 2019-02-13 09:03:05,534-0500 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.executeRaw:863 execute-result: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20190213090242-msviji.log', '-c', 'apply'], rc=1 2019-02-13 09:03:05,534-0500 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:921 execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20190213090242-msviji.log', '-c', 'apply'] stdout: 2019-02-13 09:03:05,535-0500 DEBUG otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema plugin.execute:926 execute-output: ['/usr/share/ovirt-engine/dbscripts/schema.sh', '-s', 'localhost', '-p', '5432', '-u', 'engine', '-d', 'engine', '-l', '/var/log/ovirt-engine/setup/ovirt-engine-setup-20190213090242-msviji.log', '-c', 'apply'] stderr: FATAL: Operation aborted, found duplicate version: 04030790 2019-02-13 09:03:05,535-0500 ERROR otopi.plugins.ovirt_engine_setup.ovirt_engine.db.schema schema._misc:435 schema.sh: FATAL: Operation aborted, found duplicate version: 04030790 2019-02-13 09:03:05,535-0500 DEBUG otopi.context context._executeMethod:142 method exception Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132, in _executeMethod method['method']() File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-setup/ovirt-engine/db/schema.py", line 437, in _misc raise RuntimeError(_('Engine schema refresh failed')) RuntimeError: Engine schema refresh failed 2019-02-13 09:03:05,536-0500 ERROR otopi.context context._executeMethod:151 Failed to execute stage 'Misc configuration': Engine schema refresh failed 2019-02-13 09:03:05,562-0500 DEBUG otopi.plugins.otopi.debug.debug_failure.debug_failure debug_failure._notification:100 tcp connections: id uid local foreign state pid exe <error>

2 3

Recovering from power failure
by Sandro Bonazzola 13 Feb '19

13 Feb '19

Moving the discussion to devel list on this scenario. Il giorno mar 12 feb 2019 alle ore 11:16 Hetz Ben Hamo <hetz(a)hetz.biz> ha scritto: > Hi, > > Well, there is a severe bug that I complained about it on 4.2 (or 4.1? I > don't remember) and it's regarding "yanking the power cable". > Basically I'm performing a simple test: kill all hosts immediately to > simulate a power loss without UPS. > > For this test I have 2 nodes, and 4 storage domains: hosted_storage (that > was setup during the HE installation), 1 iSCSI domain, 1 NAS domain and 1 > ISO domain. > > After all the nodes loose power, I power them on and the following > procedure happens: > 1. The node with HE finishes booting, and it takes few minutes until the > HE is up. > 2. When the HE is up, all the storage domains comes back to life as online > and VM's with high availability starting to boot. > 3. Few minutes later, *all* (with the exception of hosted_storage) > storage domains are going down > 4. After about 5 minutes, all the other storage domains which went down, > are coming up, but by then, and VM's without high availability that are not > hosted on hosted_storage remains down, you'll need to power them manually > back. > > This whole procedure takes about 15-25 minutes after booting the nodes, > and this issue is always repeatable, just kill the power to the nodes, > power them up again and see for yourself. > > The solution would be to change the code and if a storage domain is up - *leave > it up*, skip the check. > > Tal, Nir, what do you think about this? > Thanks > > > On Tue, Feb 12, 2019 at 11:56 AM Sandro Bonazzola <sbonazzo(a)redhat.com> > wrote: > >> Hi, >> We are planning to release the first candidate of 4.3.1 on February >> 20th[1] and the final release on February 26th. >> Please join us testing this release candidate right after it will be >> announced! >> We are going to coordinate the testing effort with a public Trello board >> at https://trello.com/b/5ZNJgPC3 >> You'll find instructions on how to use the board there. >> >> If you have an environment dedicated to testing, remember you can setup a >> few VMs and test the deployment with nested virtualization. >> To ease the setup of such environment you can use Lago ( >> https://github.com/lago-project) >> >> The oVirt team will monitor the Trello board, the #ovirt IRC channel on >> irc.oftc.net server and the users(a)ovirt.org mailing list to assist with >> the testing. >> >> [1] >> https://www.ovirt.org/develop/release-management/releases/4.3.z/release-man… >> >> -- >> >> SANDRO BONAZZOLA >> >> MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV >> >> Red Hat EMEA <https://www.redhat.com/> >> >> sbonazzo(a)redhat.com >> <https://red.ht/sig> >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >> oVirt Code of Conduct: >> https://www.ovirt.org/community/about/community-guidelines/ >> List Archives: >> https://lists.ovirt.org/archives/list/users@ovirt.org/message/URIGV3LPTE2RO… >> > -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

3 2

another video
by Hetz Ben Hamo 12 Feb '19

12 Feb '19

Hi, This is part 2 of converting VM's from ESXI/vCenter to oVirt 4.3. Feel free to share Link: https://www.youtube.com/watch?v=zDLgAZmOkNs BTW, it looks like even when you attach the virtio-win.iso in the conversion window, it still doesn't actually add the drivers. Imagine my surprise when I found it while I was recording the video ;) Thanks

1 0

[OST failure] he-node-ng_suite_master
by Ales Musil 11 Feb '19

11 Feb '19

Hi, the he-node-ng_suite_master is with [1]: STDERR <https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_sta…>Error: ovirt-hosted-engine-setup conflicts with ovirt-engine-appliance-4.4-20190206.1.el7.x86_64 <https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_sta…>Cannot upload enabled repos report, is this client registered? <https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_sta…> <https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_sta…> - STDERR <https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_sta…>Error: ovirt-hosted-engine-setup conflicts with ovirt-engine-appliance-4.4-20190206.1.el7.x86_64 <https://jenkins.ovirt.org/blue/organizations/jenkins/ovirt-system-tests_sta…>Cannot upload enabled repos report, is this client registered? Does anyone know how to solve this? Thank you. Regards, Ales [1] https://jenkins.ovirt.org/job/ovirt-system-tests_standard-check-patch/3133/ -- ALES MUSIL Associate Software Engineer - rhv network Red Hat EMEA <https://www.redhat.com/> amusil(a)redhat.com IM: amusil <https://red.ht/sig>

2 1

Running Vdsm on Python 3
by Milan Zamazal 11 Feb '19

11 Feb '19

Hi, there have been efforts by different Vdsm developers to port Vdsm to Python 3. I've joined the efforts recently and I focused on the aim to make Vdsm running (not necessarily working correctly initially) on Python 3, in order to better understand all the related problems and to test Python 3 compatibility (among other) on a running Vdsm instance. I can currently start Vdsm on Python 3, although it can't communicate with clients yet (such as Engine), see below. FWIW, here is what I had to do to make Vdsm at least installable and startable with Python 3. I use Fedora 28 as the platform. The primary reason is that ovirt.org provides for Fedora 28 all the non-Vdsm oVirt packages needed to run Vdsm on the host. Direct host installation doesn't work for me yet with Python 3. It might be a nice next goal but there is an added complexity in requiring proper support in all the related oVirt packages, not just Vdsm. It's better to have a basically working Vdsm first. So I had installed the host with Python 2 Vdsm and then upgraded Vdsm to Python 3 version. One non-Vdsm Python package required by Vdsm and not yet ported to Python 3 is sanlock-python. There is an ongoing work on Python 3 port at https://pagure.io/fork/mcsontos/sanlock/commits/dev-mcsontos-python3. I didn't know about it so I used my own hack that made sanlock Python module at least importable on Python 3. Let's discuss it on sanlock-devel. Regarding Vdsm itself, there are several areas to fix. First, there are compatibility problems in Python code. I started making some fixes in a patch series starting with https://gerrit.ovirt.org/97019. Please note there are other Python 3 patches by other Vdsm developers. I hope that once we branch out 4.3, we can start merging the patches to master quickly and better coordinate our efforts. Then there are other changes to Vdsm needed, which I don't have patches for (just my ugly private hacks): - All the /usr/bin/python2 shebangs must be replaced with /usr/bin/python3. We should find a good way to solve and automated that, perhaps as part of the installation process depending on Python version selected. - configure.ac must be adjusted: + AM_PATH_PYTHON([3.6]) + AC_PATH_PROG([PYTHON_CONFIG], [python3-config]) + AX_PYTHON_MODULE([six], [fatal], python3) It should be easy to make a patch for that. - The following changes in vdsm.spec.in are needed: + Dependencies on Python packages must be adjusted. + python3_sitelib must be used instead of python_sitelib for Python 3. + Byte compiled files are placed into __pycache__ subdirectories by Python 3 and they must be installed. It would be nice to have patches for that so that we can build Python 3 rpm's easily. That's it at the moment. Most compatibility problems in Python code are easy to fix once they are identified. One important exception is bytes versus strings -- that's going to be delicate. The bytes versus strings problem is very present in communication code -- such as vdsm/rpc/http.py, vdsm/sslutils.py, etc. While strings constants are typically used in the code, the communication means work with bytes. This mismatch prevents Vdsm from communicating with the clients, so it would be very useful if someone could look at it and fix the code (one of the harder parts would probably be to decide where to keep bytes and where to already convert them to strings). HTH. As more people are involved in porting Vdsm to Python 3, it might be useful to coordinate all the efforts here, to avoid duplicate work, to share findings and to speed up the process. Thanks, Milan

4 4

Re: [ovirt-users] Re: Is it possible to customize web-ui/User Portal/VM Portal?
by Greg Sheremeta 09 Feb '19

09 Feb '19

On Thu, Feb 7, 2019 at 12:59 PM Brian T <deliciouscardboard18(a)gmail.com> wrote: > > Cool! We're actually in the process of overhauling consoles for VM > Portal. > > We currently have Windows RDP in the Admin Portal, and we are actively > > working on it for VM Portal. Here are some screens from the design: > > > > We also have SPICE (thick client) fully implemented in both portals, > thick > > client VNC in both portals, novnc (web-based) in Admin, and novnc coming > > very soon in VM Portal (4.3.2 at the latest, but I hope 4.3.1) as part of > > the overhaul. > > > > Also, would you mind please reviewing the designs we have so far? I'm > > interested in others' opinions, especially someone who has already been > > thinking about this. > > That's awesome to hear! We were wondering why novnc was an Admin only > feature and why 'Console' in VM Portal felt sparse. Looking at these > designs, this is kinda what I was going to go for anywho haha, with support > for other RDP solutions. > > > Is Mechdyne TGX much different than Windows RDP, SPICE, and VNC? If so, > > what is the use case for using that over Windows RDP / SPICE / VNC? > > Mechdyne TGX is an TDP solution that offers significantly higher frame > rates (60+ frames per second) and resolution (We can hit 4k resolution); to > our understanding, Windows RDP and SPICE cannot hit those numbers. For the > average workstation user, SPICE is sufficient! We have some users that are > heavily invested in simulation and potentially VR, so a close recreation in > terms of frame rate and resolution is needed and Mechdyne TGX supports > this. You can read more about this here: > https://tgxremotedesktop.com/tgx-features/ > > Thanks for the background. We've been mostly focused on Nvidia virtualization for this use case. With this, the client actually gets a vGPU. https://docs.nvidia.com/grid/latest/grid-vgpu-release-notes-red-hat-el-kvm/… > I guess this leads into my next question... > > Is it possible to configure how console.rdp is created in VM Portal or > achieve parity between how it's created in VM Portal and Admin Portal? When > you open up the console.rdp file created in Admin portal, under where "full > address:s:", the IPv4 address is listed. However, when you open the > console.rdp file created in VM Portal, under where "full address:s", it > takes the VM name instead of something like the IPv4 address or even the > FQDN of the VM. Currently, someone wrote a bash script to grep out the > "full address:s" value and use it alongside TGX, but this doesn't work on > the VM Portal due to the value being set to the VM Name. The workaround is > to register the VM name in our DNS so that it will resolve with an IPv4 > address, but I feel that this is a poor solution. > I just tested it and I get the name from both portals -- actually, the .rdp files were identical for me, both with and without guest agent running. What version of ovirt are you using? > > My suggestion is for the console.rdp generated in VM Portal, instead of > using the VM Name, use either the FQDN or the IPv4 address. I can see the > counterargument that this will expose the FQDN/IP address to the user. > There wasn't an intent to hide fqdn or ip from the user. And the rdp file ideally will contain the fqdn. https://github.com/oVirt/ovirt-web-ui/blob/master/src/saga/console/rdpBuild… ^ that line means, use fqdn if available, if not, fall back to host name (... and hostname is kinda useless without, like you mentioned, DNS hacks -- so that's arguably a bug or at least needs improvement) Do you have the guest agent installed and running on your Windows machines? Without it, fqdn isn't reported, and the .rdp file then only contains the hostname because of the fallback: full address:s:win81-scan But with the agent running, I get my fqdn full address:s:win81-scan.lan And then the rdp works as expected. Guest tools iso: https://plain.resources.ovirt.org/pub/ovirt-4.3/iso/oVirt-toolsSetup/4.3-1.… Re: the security concern, nah, both fqdn and ip are shown right in VM Portal -- see screenshot here: https://github.com/oVirt/ovirt-web-ui So that's no problem. > > And I would certainly love for you to help test it out as we're nearing > > completion, at the least. If you want to code, we would love to have you > :) > > I'd love to help! Problem is, I guess I'm trying to start from 0 and I'm > not sure HOW to start developing for web-ui or even WebAdmin. How would you > suggest setting up? > Admin portal is much more difficult and I'll spare you for now, but VM Portal is simple. git clone git@github.com:oVirt/ovirt-web-ui.git and then follow the instructions at https://github.com/oVirt/ovirt-web-ui/blob/master/DEVELOPERS.md while developing, we typically run: """ Development mode A primary goal of VM Portal is a quick development cycle (change-build-deploy-check). The project uses webpack-dev-server to accomplish this. To start the server: ENGINE_URL=https://[my.ovirt.instance]/ovirt-engine/ yarn start """ [cc'ing devel] So, if you wanted to implement TGX alongside what we're doing with the other console enhancements, I think it would work very similarly to the existing RDP flow. Scan the ovirt-web-ui for the RDP code, specifically rdpBuilder.js here: https://github.com/oVirt/ovirt-web-ui/tree/master/src/saga/console I guess you would need your custom file with the right port, and whatever else TGX needs. > Let me know if you have any further questions and thank you for taking the > time to respond! > Glad to help. Let me know how it goes. Greg > _______________________________________________ > Users mailing list -- users(a)ovirt.org > To unsubscribe send an email to users-leave(a)ovirt.org > Privacy Statement: https://www.ovirt.org/site/privacy-policy/ > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/FCZMWR4ODZJ7P… > -- GREG SHEREMETA SENIOR SOFTWARE ENGINEER - TEAM LEAD - RHV UX Red Hat NA <https://www.redhat.com/> gshereme(a)redhat.com IRC: gshereme <https://red.ht/sig>

1 0

[Ovirt] [CQ weekly status] [08-02-2019]
by Dafna Ron 08 Feb '19

08 Feb '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 (#2) We have no current failures. Last failed job was for ovirt-provider-ovn due to build-artiacts job on Feb 6. the issue was resolved and ovirt-provider passed the same day. *CQ-Master:* GREEN (#1) There are no current issues in master CQ During the week we had 3 issues: 1. packages were missing from several repose. this was reposlved by a patch submitted by Galit on Monday. 2. we had a missing ovirt-web-ui as the package that we were testing was too old. as the project had no V2 configuration it was manually added. Greg however, added the project to CQ and a new package was already built and passed CQ. 3. Regression in test add_direct_lun was causing ovirt-engine project to fail. Patch causing failure: https://gerrit.ovirt.org/#/c/97075/ - core: disallow creating disks of size 0 Patch fixing regression: https://gerrit.ovirt.org/#/c/97622/ - core: skip disk size validation for lun disks The patch passed CQ and we have package: https://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-… 4.3.0.5-0.0.master.20190207124642.git415c7e8.el7.noarch.rpm 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 0

imageio proxy and engine dev setup
by Fedor Gavrilov 08 Feb '19

08 Feb '19

Hi, It seems to be rather difficult to have development setup for the engine with imageio proxy. engine-setup script never asks about it, running it again with --reconfigure-optional-components changes nothing and answers file contains no mention of imageio (thus, https://bugzilla.redhat.com/show_bug.cgi?id=1446094 does not look to be fixed for dev setups). There is no package to install separately either. Quite confused now. Do you happen to know what am I missing? Fedor Gavrilov

4 15

4.3 Branching
by Anton Marchukov 08 Feb '19

08 Feb '19

Hello All. Since oVirt 4.3.0 released are we ready to branch master into 4.3? Thanks. -- Anton Marchukov Team Lead - Release Management - RHV DevOps - Red Hat

4 9