- Devel - oVirt List Archives

[QE] oVirt Live re-based on EL7 for oVirt 3.6
by Sandro Bonazzola 06 Feb '15

06 Feb '15

Hi, oVirt Live has been rebased on EL7 for oVirt 3.6. An initial ISO is available here: http://resources.ovirt.org/pub/ovirt-master-snapshot-static/iso/ovirt-live-… Nightly build will be always available here: http://jenkins.ovirt.org/job/ovirt_live_create_iso/ Help with testing and bugfix is welcome! -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

Help with issues with migration
by David Caro 04 Feb '15

04 Feb '15

--KscVNZbUup0vZz0f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! Upstream phoenix lab has stabilized, but after the outages we are finding s= ome issues probably caused by it. One of them is that th vm migration is not working, ew have two hosts srv05= and srv06, and we want to migrate vms from 06 to 05 but we find those errors on vdsm on 05: Feb 04 02:56:50 ovirt-srv05 vdsm[5170]: vdsm vm.Vm WARNING vmId=3D`434152= 76-a7bf-4c86-b0e9-70a5f6d39a40`::Unknown type found, device: '{'device': 'u= nix', 'alias': 'channel0', 'type': 'channel', 'address': {'bus': '0', 'cont= roller': '0', 'type': 'virtio-serial', 'port': '1'}}' found Feb 04 02:56:50 ovirt-srv05 vdsm[5170]: vdsm vm.Vm WARNING vmId=3D`434152= 76-a7bf-4c86-b0e9-70a5f6d39a40`::Unknown type found, device: '{'device': 'u= nix', 'alias': 'channel1', 'type': 'channel', 'address': {'bus': '0', 'cont= roller': '0', 'type': 'virtio-serial', 'port': '2'}}' found Feb 04 02:56:50 ovirt-srv05 vdsm[5170]: vdsm vm.Vm WARNING vmId=3D`434152= 76-a7bf-4c86-b0e9-70a5f6d39a40`::Unknown type found, device: '{'device': 's= picevmc', 'alias': 'channel2', 'type': 'channel', 'address': {'bus': '0', '= controller': '0', 'type': 'virtio-serial', 'port': '3'}}' found Feb 04 02:56:50 ovirt-srv05 vdsm[5170]: vdsm vm.Vm ERROR vmId=3D`43415276= -a7bf-4c86-b0e9-70a5f6d39a40`::Alias not found for device type graphics dur= ing migration at destination host After that sanlock complains: Feb 04 02:56:50 ovirt-srv05 sanlock[1055]: 2015-02-04 02:56:50-0700 1453 = [1055]: cmd 9 target pid 6479 not found but it seems that the vm is starting up: Feb 04 02:56:50 ovirt-srv05 systemd[1]: Starting Virtual Machine qemu-el6= -vm03-phx-ovirt-org. -- Subject: Unit machine-qemu\x2del6\x2dvm03\x2dphx\x2dovirt\x2dorg.scope= has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel --=20 -- Unit machine-qemu\x2del6\x2dvm03\x2dphx\x2dovirt\x2dorg.scope has begu= n starting up. Feb 04 02:56:50 ovirt-srv05 systemd-machined[5642]: New machine qemu-el6-= vm03-phx-ovirt-org. -- Subject: A virtual machine or container has been started -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel --=20 -- The virtual machine qemu-el6-vm03-phx-ovirt-org with its leader PID 64= 79 has been -- started is now ready to use. Feb 04 02:56:50 ovirt-srv05 systemd[1]: Started Virtual Machine qemu-el6-= vm03-phx-ovirt-org. -- Subject: Unit machine-qemu\x2del6\x2dvm03\x2dphx\x2dovirt\x2dorg.scope= has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel --=20 -- Unit machine-qemu\x2del6\x2dvm03\x2dphx\x2dovirt\x2dorg.scope has fini= shed starting up. --=20 -- The start-up result is done. But it shuts down: Feb 04 02:56:51 ovirt-srv05 systemd-machined[5642]: Machine qemu-el6-vm03-p= hx-ovirt-org terminated. -- Subject: A virtual machine or container has been terminated -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel --=20 -- The virtual machine qemu-el6-vm03-phx-ovirt-org with its leader PID 64= 79 has been -- shut down. Feb 04 02:56:51 ovirt-srv05 vdsm[5170]: vdsm vm.Vm ERROR vmId=3D`43415276= -a7bf-4c86-b0e9-70a5f6d39a40`::Failed to start a migration destination vm Traceback (most recent call last): File "/usr/share/vdsm/virt/vm.py"= , line 2298, in _startUnderlyingVm self._completeIncomingMigration= () File "/usr/share/vdsm/virt/vm.py"= , line 4107, in _completeIncomingMigration self._incomingMigrationFinished= =2EisSet(), usedTimeout) File "/usr/share/vdsm/virt/vm.py"= , line 4160, in _attachLibvirtDomainAfterMigration raise MigrationError(e.get_erro= r_message()) MigrationError: Domain not found: n= o domain with matching uuid '43415276-a7bf-4c86-b0e9-70a5f6d39a40' Feb 04 02:56:51 ovirt-srv05 vdsm[5170]: vdsm root WARNING File: /var/lib/= libvirt/qemu/channels/43415276-a7bf-4c86-b0e9-70a5f6d39a40.com.redhat.rhevm= =2Evdsm already removed Feb 04 02:56:51 ovirt-srv05 vdsm[5170]: vdsm root WARNING File: /var/lib/= libvirt/qemu/channels/43415276-a7bf-4c86-b0e9-70a5f6d39a40.org.qemu.guest_a= gent.0 already removed Feb 04 02:56:51 ovirt-srv05 vdsm[5170]: vdsm vm.Vm WARNING vmId=3D`434152= 76-a7bf-4c86-b0e9-70a5f6d39a40`::trying to set state to Down when already D= own Any ideas? Thanks! Though --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: 82-62605 --KscVNZbUup0vZz0f Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU0fKyAAoJEEBxx+HSYmnD2ncH/1mKX22wzX5xmd6k2F/dVlWg ZY7NrN5YEFjkjLpECkTnD+1/HzoAy72PXvitsnwiEn1vQFp87g6QJQFz4dgFyoXt S/fRFtAERisaMvVUWk1H78HnMSsW9KwNFrYq4StAO87ctp55Jjm62hEPp5ysoCFY qb570Bt6fB+XoLQENvvxtxIc3OoeBS0MCjhoW6QeHmhbC7yV3LdyBt6A95NFgE8x CaBNIyErNwgtTvT+wdgE8XhRSU2eHrdYSGK0sq7c8AVWGi4qa+oZ6PYGnkulazUi jDVF8zVGYjQ22sWgsMTOybhRL0AW90PRx3TnnwvmJ3VWSyko35091YFOA7ISOVo= =ZerK -----END PGP SIGNATURE----- --KscVNZbUup0vZz0f--

2 2

[Event] 2015 oVirt Asia Workshop
by Brian Proffitt 04 Feb '15

04 Feb '15

As oVirt strives to become the best open source and comprehensive data center virtualization management suite, and its community rapidly evolves and grows, one of the ways its vibrant community connects is through our Global Workshops. The events are conducted solely to introduce new users and veteran oVirt admins to new features and new techniques found in oVirt, as well as provide a forum for our users to connect directly with the development team behind oVirt. With that in mind, we are pleased to announce that registration is now open for the 2014 oVirt Workshop! The next 2015 oVirt workshop will be co-located with the FOSSAsia in Singapore on March 14, 2015. This workshop is designed to encourage collaboration in our community, lay the foundation for best practices in oVirt use, convey end-user stories, and help answer questions about the project from both a developer and user's perspective. For more information, and to register for the event, visit the Workshop page[1] today! [1] http://www.ovirt.org/Asia_Workshop_Mar_2015 -- Brian Proffitt Community Liaison oVirt Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC

1 0

[QE] oVirt 3.6.0 nightly build testing
by Sandro Bonazzola 04 Feb '15

04 Feb '15

Hi, I've been asked to start the discussion about testing 3.6.0 nightly builds. Once http://gerrit.ovirt.org/37384 will be merged or manually applied on the testing host, 3.6 cluster compatibility will be enabled on the following distributions: Fedora 21: no special instructions for this distribution, should work out of the box. Fedora 20: requires virt-preview repository. you can find the .repo file[1] in the virt-preview home[2]. AN update to ovirt-release-master rpm will enable the repository by default, it will be available probably tomorrow. RHEL / CentOS 7.1: not yet released, but once they'll be out they'll support 3.6 cluster compatibility RHEL / CentOS <= 7.0 won't have 3.6 cluster compatibility. [1] https://fedorapeople.org/groups/virt/virt-preview/fedora-virt-preview.repo [2] https://fedorapeople.org/groups/virt/virt-preview/ -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

3 3

[QE][ACTION REQUIRED] oVirt 3.6.0 status
by Sandro Bonazzola 04 Feb '15

04 Feb '15

Hi, here's an update on 3.6 status on integration / rel-eng side ACTION: Feature proposed for 3.6.0 must now be collected in the 3.6 Google doc [1] and reviewed by maintainers. Finished the review process, the remaining key milestones for this release will be scheduled. For reference, external project schedules we're tracking are: Fedora 22: 2015-05-19 Fedora 20 End Of Life: 2015-06-19 (1 month after Fedora 22 release) Foreman 1.8.0: 2015-03-01 GlusterFS 3.7: 2015-04-29 OpenStack Kilo: 2015-04-30 QEMU 2.3.0: 2015-03-27 The tracker bug for 3.6.0 [2] currently shows no blockers. There are 548 bugs [3] targeted to 3.6.0. Excluding node and documentation bugs we have 506 bugs [4] targeted to 3.6.0. oVirt 3.6 cluster compatibility status in nightly builds: VDSM patch introducing 3.6 compatibility[5] has not been merged yet, waiting for CentOS and RHEL 7.1 to be released for getting libvirt support. CentOS and RHEL 6.z won't have 3.6 compatibility by design [6]. Fedora 20 won't have 3.6 compatibility level since virt maintainers are going to maintain latest libvirt rpms only in latest stable Fedora release (currently Fedora 21). There's no point in providing Fedora 20 packages on oVirt side since Fedora 20 will go EOL before oVirt 3.6.0 GA. Fedora 21 will be able to support 3.6 compatibility once VDSM patch[5] will be merged. Fedora 22 may not be able to support VDSM at all since it will run Python 3 instead of Python 2 as default python interpreter[7], so more work will be needed there. [1] http://goo.gl/9X3G49 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1155425 [3] https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_release%3A3.6.0%… [4] http://goo.gl/ZbUiMc [5] http://gerrit.ovirt.org/37384 [6] http://lists.ovirt.org/pipermail/users/2014-September/027421.html [7] https://fedoraproject.org/wiki/Releases/22/ChangeSet -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

[QE][ACTION REQUIRED] oVirt 3.5.2 RC status
by Sandro Bonazzola 04 Feb '15

04 Feb '15

Hi, We're going to start composing oVirt 3.5.2 RC on *2015-02-25 08:00 UTC* from 3.5 branch. Maintainers: - Please be sure that 3.5 snapshot allow to create VMs before *2015-02-24 15:00 UTC* - Please be sure that no pending patches are going to block the release before *2015-02-24 15:00 UTC* - If any patch must block the RC release please raise the issue as soon as possible. A release management entry has been added for tracking the schedule of 3.5.2 [0] A bug tracker [1] has been created and currently has no open blockers. There are still 43 bugs [2] targeted to 3.5.2. Excluding node and documentation bugs we still have 35 bugs [3] targeted to 3.5.2. Maintainers / Assignee: - Please add the bugs to the tracker if you think that 3.5.2 should not be released without them fixed. - Please update the target to 3.5.3 or later for bugs that won't be in 3.5.2: it will ease gathering the blocking bugs for next releases. - Please fill release notes, the page has been created here [4] Community: - If you're testing oVirt 3.5 nightly snapshot, please add yourself to the test page [5] [0] http://www.ovirt.org/OVirt_3.5.z_Release_Management#oVirt_3.5.2 [1] http://bugzilla.redhat.com/1186161 [2] http://goo.gl/crVJPH [3] http://goo.gl/2qTZZU [4] http://www.ovirt.org/OVirt_3.5.2_Release_Notes [5] http://www.ovirt.org/Testing/oVirt_3.5.2_Testing -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

1 0

please test and give karma to novnc on epel6
by Sandro Bonazzola 04 Feb '15

04 Feb '15

Hi, a new package restoring novnc on epel6 has been pushed: https://admin.fedoraproject.org/updates/novnc-0.4-9.el6 Please help testing and giving karma. Thanks, -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 7

otopi missing from f19 master snapshot repo
by Greg Sheremeta 03 Feb '15

03 Feb '15

I noticed that there is no otopi available in http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/fc19/noarch/ I didn't see it in any of the f19 master repos, actually. I had to install otopi from the fc20 repo. Not sure if this is intentional. Thanks, Greg Greg Sheremeta Red Hat, Inc. Sr. Software Engineer, RHEV Cell: 919-807-1086 gshereme(a)redhat.com

2 1

Using travis yaml files to specify dependencies and tests
by David Caro 03 Feb '15

03 Feb '15

--oLBj+sq0vYjzfsbl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi everyone! After talking a bit with some of you, I think that we can start planning a common build and dependency declaration for tests for the ovirt products, to improve and automate most of the ci process and maintenance. Current status: =3D=3D Dependencies Right now we have 4 types of dependencies: * test dependencies * tarball/srcrpm build dependencies * rpm build dependencies * installation dependencies The last two are managed from the spec files through rpm/yum dependency systems. But the first ones are managed manually on the jobs on jenkins or puppet manifests. What separates it from the code that actually requires them and adds an extra layer of maintenance and synchronization between the code, the jenkins jobs and the puppet repository. =3D=3D Builds We started using autotools to build most of the projects, but it's not a global methodology and even being used on some projects, you need to tune the run for each of them, specifying different variables and running some side scripts. =3D=3D Tests Some projects use make check to run some of the tests, some tests are totally outside the code and run only in jenkins jobs. Some possible improvements: =3D=3D Tests/builds Using shell scripts: We talked before in another thread to create some generic script to build the artifacts for the product and to run the tests, namely we talked about having 3 executables (bash scripts probably) at the root of each project, that should not require any parameters: ./build-artifacts This should generate any artifacts to be archives (isos, rpms, debs, tarballs, ...) and leave them at ./exported-artifacts/ directory, for the build system to collect, removing any previous artifacts if needed. ./check_patch Runs all the tests required for any new patchset in gerrit, for non-merged changes, should be fast to run to get feedback easily ./check_merge Runs all the tests for any change that is going to be merged (right now we are not using gates, so it actually after merge, but the idea is to use this as gate for any merge to the repo). This can be more resource hungry than check_path. That way it will let you use easily any framework that you want to use for your project, but still let it be easy to maintain in the global ci/build system (you can use pip, tox, maven, gradle, autotools, make, rake, ...). This will not allow at first running tests in parallel in jenkins, but we can in the future add that possibility (for example, allowing the user to define more than one check script, like check_patch.mytest1 and check_patch.mytest2 and make jenkins run them in parallel). I started a POC of this process here [1] Using travis yaml files: Using a travis compliant yaml file [2]. That will be less flexible than the above solution and will not allow you to run tests in parallel, though it will let you use travis at any point to offload our ci if needed. =3D=3D Dependencies Using plain text files: Similar to the above scripts solution, I though of adding an extra file, with the same name, to declare the dependencies to run that script. Adding a suffix in case of different requirements for different distros (matching facter fact strings), for example: ./build-artifacts.req Main requirements file, used if no more specific one found. With a newline separated list of packages to install on the environment (jenkins will take care of which package manager to use). ./build-artifacts.req.fc20 Specific requirements for fc20 environment, replaces the general one if present. And the same for the other scripts (check_patch and check_merge). Using travis yaml file: Using a travis compliant yaml file with some extensions to declare the different dependencies for each type and os/distro. That will allow you to have only one extra file in your repo, though you'd have to duplicate some of the requirements as travis only has ubuntu and forces you to run scripts to install dependencies. What do you think? Do you have any better idea? ps. About using an external repository to store the scripts/requirements for the code. The issue with this is that it forces you to bind a code change in the code repo, to a script/dependency change in the scripts repo, and that adds a lot of extra maintenance and source of issues and failures. If you know a way of doing it like that without all the fuss, I'd love to hear it. For example, imagine that you have vdsm and the dependencies are in another repo, now you send a patch to vdsm that requires you to run a specific pep8 version to pass the patch tests, so you have to change the script repo to add that dependency, but doing that you will brake all the other patches tests because they require the older pep8 version, so you have to somehow specify in the vdsm patch that you require a specific commit from the scripts repo to be tested with... Having both in the same repo, allows you to do the code change and the dependency/script change in the same patchset, and test it right away with the correct scripts/deps. It also binds together code and tests to some point, what is nice to have in a product view, because you know for each version which tests it passed and have a better idea of the possible failures for that version. [1] http://gerrit.ovirt.org/#/admin/projects/repoman [2] http://docs.travis-ci.com/ --=20 David Caro Red Hat S.L. Continuous Integration Engineer - EMEA ENG Virtualization R&D Tel.: +420 532 294 605 Email: dcaro(a)redhat.com Web: www.redhat.com RHT Global #: 82-62605 --oLBj+sq0vYjzfsbl Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUvnkrAAoJEEBxx+HSYmnD2f0H/1t40fR3h4Tlae891vmiPyYv zxfTY6SlW0CJkSEis2ED2KZTkQZwQ6clfK+aRdGzSXL0mtUL9wr3Kk1/+i4tMQD/ 5gqjP9Hc7HoMzDDvIRIvBdBm3fDgnvChkqr8xbRG1l4LIDGgDH2AE9uhkEClHpqV CdhwrYGAU9DCBcB1kINZqKPn7q42nR1fkvl2ItIlJ6eRpY51bf6PNIW2INNvVB7V 3LMkO9E2Y1uen61HZ5A7MvQ58vaJJjxM4seCrcdkbAEtHxbtPxVAEG7mXlpZBcH6 EbT1KfLAyghRcpdGxa5PsAQRHcrTre+sKhsi17fI8JZBhJVmAfdbHd2iEhMlqZ8= =LXWV -----END PGP SIGNATURE----- --oLBj+sq0vYjzfsbl--

4 6

reporting and removing unmanaged networks after deprecating org.ovirt.engine.core.common.action.VdcActionType#SetupNetworks
by Martin Mucha 03 Feb '15

03 Feb '15

Hi, I'd like to discuss how to properly report unmanaged networks and how to ask for their removal after org.ovirt.engine.core.common.action.VdcActionType#SetupNetworks is removed. We thought about several possibilities and so far the best one is following one. Reporting unmanaged networks on specific nic: ——————————————————————————————————————————————— We'd like to return new collection under: GET http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks returning (reporting) unmanaged networks like this: <unmanaged_networks> <unmanaged_network> <nic_name>...</nic_name> <unmanaged_network_name>...</unmanaged_network_name> <vland_id>...</vland_id> </unmanaged_network> <unmanaged_network> ... </unmanaged_network> </unmanaged_networks> Removing unmanagedNetworks: ————————————————————————————— DELETE http://localhost:8080/api/hosts/{id}/nics/{id}/unmanagednetworks/{unmanaged… ======================= any ideas, hints, complaints, recommendations, confirmations are welcomed. Martin.

3 2