- Devel - oVirt List Archives

[Engine-devel] GWT Dev Mode unbearably slow in WebAdmin
by Greg Sheremeta 22 Mar '14

22 Mar '14

Has anyone else noticed that GWT Dev Mode is unbearably slow for WebAdmin? On my machine, it's to the point where I might as well rebuild the entire application for every change and not bother with Dev Mode. Pages take 4 or 5 minutes to render. Sometimes after 5 minutes, I just give up, close everything, and rebuild the app. For now, I want to see if others have this issue. If we confirm that it's widespread, we can discuss ways to mitigate. Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

5 14

[Engine-devel] Small suggestions for engine-log-collector
by Vojtech Szocs 22 Mar '14

22 Mar '14

Hi guys, based on my testing during last week's oVirt 3.4 RC test day [1], I have a couple of small suggestions for engine-log-collector: 1, in /etc/ovirt-engine/logcollector.conf - I think there's typo: #key-file=/etc/pki/engine/keys/engine_id_rsa should be: #key-file=/etc/pki/ovirt-engine/keys/engine_id_rsa 2, to force password-based ssh auth, one has to do this: engine-log-collector -k "" because running this: engine-log-collector -k returns error message: error: -k option requires an argument however, help for -k option mentions *supplying* the argument: If a identity file is not supplied the program will prompt for a password. so either the help text should mention empty string, or -k option should allow missing argument (this was my initial understanding according to help text) Since these are just small things, I'm wondering if I should create RFE or if Keith/others can say if they are relevant. Thanks, Vojtech [1] http://etherpad.ovirt.org/p/3.4-testday-3

3 7

Re: [Engine-devel] [Users] centralized Logging engine and hypervisor
by Sven Kieske 20 Mar '14

20 Mar '14

Am 20.03.2014 11:04, schrieb Martin Perina: > > > > I didn't try it, but some info can be found in this thread: > > http://stackoverflow.com/questions/10400263/jboss-as-7-configure-logging-to… Thanks for the link, for documentation purposes, I'll post my findings here to, so if someone needs this in the future, feel free to use it: Here is a custom implemented syslog handler for jboss 7.1: http://randomtekkstuff.blogspot.de/2013/03/jboss-as-7-syslog-handler.html I will test this out, once I found the jboss module directory.. In the meantime: Would ovirt-devs consider it save to "sideload" my own jboss module? I know this will get painful to maintain once I want to upgrade so I'm already asking: Is there a chance as a first step to include a custom syslog handler jboss module into ovirt (for jboss < 7.2) ? Later this could get expanded to easily allow to use syslog.. -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen

2 3

[Engine-devel] hosted engine in 3.4
by Jiri Moskovcak 20 Mar '14

20 Mar '14

Hi, I was testing the hosted-engine in 3.4 and ran into some troubles, so I'm going to share the results to get some help (or ideas how to fix those problems) Minor: 1. You need to have some MAC address with static ip and FQDN, otherwise you have to change /etc/hosts at least for the first part of the setup - I think the setup wizard should be improved to do this workaround automatically 2. When the VM install is complete I would expect the setup wizard to install the engine to the VM automatically - which at least in my case - doesn't happen - I found a mallformed fedora-virt-prerelease.repoo file on the installed vm, which might be the cause: https://bugzilla.redhat.com/show_bug.cgi?id=1075963 Major: 1. once I managed to install the engine to the vm it tried to add the host it was running on to the engine and it failed with a message "Host compatibility version doesn't match the cluster compatibility version", and then it marked the host as non operational which killed the vm with the engine, so the engine actually committed suicide... - the host and the engine were installed from the same repo, so I guess the incompatibility was caused by the CPU family, and even if I made the mistake I think the engine should be a bit more clever and not kill itself --Jirka

5 12

[Engine-devel] [ANN] oVirt 3.4.0 Second Release Candidate is now available
by Sandro Bonazzola 20 Mar '14

20 Mar '14

The oVirt team is pleased to announce that the 3.4.0 Second Release Candidate is now available for testing. Release notes and information on the changes for this update are still being worked on and will be available soon on the wiki[1]. Please ensure to follow install instruction from release notes if you're going to test it. The existing repository ovirt-3.4.0-prerelease has been updated for delivering this release candidate and future refreshes until final release. An oVirt Node iso will also be available soon. We decided to postpone Final Release by one week in order to properly test the bugs fixed since last Release Candidate. Help us make this the best release ever, testing it yourself! [1] http://www.ovirt.org/OVirt_3.4.0_release_notes -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 1

[Engine-devel] Vms search issue
by Moti Asayag 19 Mar '14

19 Mar '14

Hi, As a result of patch "core : Search VMs based on MAC address" [1] The same vm is returned by the search query as the number of its nics. I'd suggest to revert this patch and not introduce a join between vnics to vm_static vms: first, it won't return the expected result when a vm has more than a signle nic, second due to adding great impact on that view. As an alternative, I'd suggest utilizing the join in the search-engine with vm_interface_view. See SearchObjectAutoCompleter: // vms - vm network interface addJoin(SearchObjects.VM_OBJ_NAME, "vm_guid", SearchObjects.VM_NETWORK_INTERFACE_OBJ_NAME, "vm_guid"); So the query will look like: "vms: vnic.MAC = 'xx:xx:xx:xx:xx:xx'" [1] http://gerrit.ovirt.org/#/c/25805 Regards, Moti

2 1

[Engine-devel] migration of VM, which protocol actually works?
by aditya mamidwar 18 Mar '14

18 Mar '14

i wanted to learn about the modules so that i could understand how the engine POSTS and sends data to the backend sql database and other scripts to perform various options. for e.g i need to know which code actually collects the storage path for the ISO s during ISCSI storage domain setup. also how the hosts, clusters and data centers are made and stored at the backend. if i want to add a new UI that bypasses some of these complicated tasks (again for personal understanding), will I be able to do that. Also i would like to mention that am working on making a little changes to how the ISCSI protocol works.. My another doubt is: when are the NFS/ISCSI/FC protocols actually used in ovirt. like what part of the VM running state? are their purpose limited to just copying the ISO from the storage center to the path required by the Host. Are the protocols them self responsible for sending and getting data during VM execution on a node. The concept of node and migration has left me a little confused. since each node can run multiple VMs , so during the running/execution of the VM , do the network protocols actully work, if not , then how is that achieved. if yes, again my question arises, which module should i focus on regarding this issue. thanks -- -Aditya Mamidwar

2 1

Re: [Engine-devel] Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine
by Doron Fediuck 17 Mar '14

17 Mar '14

----- Original Message ----- > From: "Yedidyah Bar David" <didi(a)redhat.com> > To: "Doron Fediuck" <dfediuck(a)redhat.com> > Cc: "Sandro Bonazzola" <sbonazzo(a)redhat.com>, "Jiri Moskovcak" <jmoskovc(a)redhat.com> > Sent: Sunday, March 16, 2014 12:28:27 PM > Subject: Re: Bug 1076530 – engine shouldn't kill the vds running the VM with the hosted engine > > Might be better to discuss this on bugzilla. > Bugzilla is not a mailing list. Moving to engine-devel. > ----- Original Message ----- > > From: "Doron Fediuck" <dfediuck(a)redhat.com> > > To: "Sandro Bonazzola" <sbonazzo(a)redhat.com> > > Cc: "Yedidyah Bar David" <didi(a)redhat.com>, "Jiri Moskovcak" > > <jmoskovc(a)redhat.com> > > Sent: Sunday, March 16, 2014 12:01:51 PM > > Subject: Bug 1076530 – engine shouldn't kill the vds running the VM with > > the hosted engine > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1076530 > > > > Sandro, > > I think this would be solved by a better validation during setup / > > deployment. > > This can't be done during Validation in the otopi sense of the word. > At that point the engine does not exist yet and so we can't know what > versions it supports etc. > Why not? You have the vdsm supported versions in a file (dsaversion IIRC) and you should be able to get the relevant engine info before or after deploying the DB. > It might be possible (didn't check) to check the versions right before > trying to add the host to the cluster. This means we do not want to > abort (as we can do during Validation if something does not pass it). > What can we do? Perhaps offer a few options: > 1. Do abort (will do mostly what happens today) > 2. Let the user try to manually fix, probably by trying to change > the compatibility version of the cluster, and then try adding the > host again > 3. Try to fix ourselves (same) and try adding again > 4. Best would be to someone upgrade libvirt and reconfigure vdsm. > Not sure that's easy or even possible at this stage, where VM is > running and we do not want to loose it. > > Thinking about this again, I am not sure the current behavior is that > bad. "Fixing" by re-installing with the correct versions is probably > way simpler than fixing after installation is (mostly) complete. > > > > > I'm not keen on adding hosted-engine logic into the engine code. > > Not sure about that. Not that it would help much, because the root > problem will still have to be solved, but in principle it might be > a good thing if the engine knows that killing some host will kill itself, > and so try harder to not do that and just leave it in some zombie, > requires-manual-action state. This is obviously more important during > normal operation than during installation. > -- > Didi >

3 7

[Engine-devel] Source code unerstanding
by aditya mamidwar 16 Mar '14

16 Mar '14

Hey, is there a simpler way to know which code is responsible for which module of the engine. is there a documentation maintained. or how can identify the files which are important for me. -- -Aditya Mamidwar

4 3

[Engine-devel] adding scripts
by aditya mamidwar 15 Mar '14

15 Mar '14

I want to commit changes to the engine by adding some bash scripts. the scripts should be invoked once a button or tab is selected in the webadmin portal by the user. can someone guide on achieving this. -- -Aditya Mamidwar

3 2