October 2019 - Devel - oVirt List Archives

ovirt-engine has been tagged (ovirt-engine-4.3.7.1)
by Tal Nisan 30 Oct '19

30 Oct '19

1 0

CentOS builds fail because cbs.centos.org/repos/virt7-kvm-common-testing/{x86_64/ppc64le} not found
by Nir Soffer 30 Oct '19

30 Oct '19

We have failing imageio builds, seems that the centos virt7-kvm-common-testing is broken. ppc64le: https://cbs.centos.org/repos/virt7-kvm-common-testing/ppc64le/os/repodata/r…: [Errno 14] HTTPS Error 404 - Not Found https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/1611/artif… x86_64: https://cbs.centos.org/repos/virt7-kvm-common-testing/x86_64/os/repodata/re…: [Errno 14] HTTPS Error 404 - Not Found https://jenkins.ovirt.org/job/ovirt-imageio_standard-check-patch/1611/artif… Patch: https://gerrit.ovirt.org/c/101788/ Sandro, can you check this? Nr

2 1

[vdsm] Standard patch check broken by Black formatter for network stuff
by Vojtech Juranek 29 Oct '19

29 Oct '19

Hi, standard patch check tests for vdsm are broken due to Black formatter check failure (see e.g. [1]): Oh no! 10:16:24 6 files would be reformatted, 164 files would be left unchanged. 10:16:24 ERROR: InvocationError for command /home/jenkins/workspace/ vdsm_standard-check-patch/vdsm/.tox/black/bin/black -l 79 -S --check ./lib/ vdsm/network/ ./tests/network (exited with code 1) Can someone take a look and fix it? I did a quick check and wasn't able to find any recent commit which should cause this failure:-( Thanks Vojta [1] https://jenkins.ovirt.org/job/vdsm_standard-check-patch/13396

3 2

OST: Failing migrations on el8
by Milan Zamazal 29 Oct '19

29 Oct '19

Hi, I looked at the failing migrations in OST on el8, when running basic-suite-master with https://gerrit.ovirt.org/#/c/103888/31. The migration fails even before started, when Vdsm tries to talk to the remote Vdsm and can't reach it. Indeed, there seems to be a networking problem between the hosts: [root@lago-basic-suite-master-host-1 ~]# ping -c 1 lago-basic-suite-master-host-0 PING lago-basic-suite-master-host-0(lago-basic-suite-master-host-0.lago.local (fd8f:1391:3a82:201::c0a8:c902)) 56 data bytes From lago-basic-suite-master-host-1 (fd8f:1391:3a82:200::c0a8:c899): icmp_seq=1 Destination unreachable: Address unreachable Regards, Milan

5 5

Errors while building ovirt-engine master on fedora 29
by Kaustav Majumder 29 Oct '19

29 Oct '19

Hi, I am currently facing this error while building ovirt-engine master (commit da774d861d5a593666932f6e678f5383222ed8d5) on fedora 29. *[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.0:compile (default-compile) on project ovirt-checkstyle-extension: Fatal error compiling: invalid flag: --release -> [Help 1]* full build log here: https://pastebin.com/rJA5PHWu -- Thanks, Kaustav Majumder

3 6

Automatic snapshots
by Joost Evertse 29 Oct '19

29 Oct '19

Hello everyone, We run a large number of virtual desktops on RHEV and we use the snapshot mechanism occasionally. Would it be possible to create automatic snapshots when VM’s are started and when they are stopped? My gut feeling says this would be a bad idea, because taking snapshots does not guarantee anything, but I have the task of exploring the option. If needed, I would change source code to create something and contribute it. Currently I have taken a look at - the vdsm hook mechanism, but that seems to be aimed at the VM lifecycle, not operations like starting and stopping an instance. - the ovirt-agent hooks , but they also seem to be useful when migrating a VM The goal of the snapshot is to have a backup-backup, just handy when dealing with malfunctions inside a VM workstation, it does not have to be perfect. Maybe I can create scripts to enable functionality in a different (existing) place, but I am a bit reluctant to create unnecessary scripting because that creates admin overhead. Maybe from an architectural point of view automatic snapshots is just a plain wrong idea, not sure. What are your thoughts about this? With kind regards, Joost Evertse

1 0

IMPORTANT: OST is now gated.
by Ehud Yonasi 29 Oct '19

29 Oct '19

Hey everyone, OST project is now enabled for patch gating. What is the meaning of this? 1. The gating process will start when Code-Review +2, CI +1 and Verified +1 labels are turned on. 2. Every patch before merging will have to pass the following suites: - *oVirt-master* *oVirt-4.3* basic_suite basic_suite upgrade-from-release upgrade-from-release upgrade-from-prevrelease 3. Patches should no longer be manually merged in OST, they will be merged automatically when passing the gate. *NOTE: *Maintainers are still able to merge manually, but it is not recommended if the gate is not passing. *NOTE:* For additional information regarding the gating I've sent FAQ mail - 'Patch Gating summary + FAQ' Regards, Ehud.

4 4

Re: [ovirt-users] Host-passthrough CPU and migration
by Strahil 27 Oct '19

27 Oct '19

Ah... Never thought I can switch it to 'Auto'. Actually it makes sense - we can't be sure if all nodes in cluster are the same - like my case. Now all VMs are in Auto mode. Thanks for the clarification, Sharon. Best Regards, Strahil NikolovOn Oct 27, 2019 17:30, Sharon Gratch <sgratch(a)redhat.com> wrote: > > Hi, > > The "manual migration" option is only a default value. You can change the migration mode to "automatic" mode if you prefer. > > Details: > When you enable Host CPU Pass-Through for a VM then the migration default value is auto set to "manual migration" in UI because it's not sure if this VM should be automatically migrated as part of internal events (such as load balancing policies or host turning into maintenance mode), without letting the user controlling it. > > Sometimes there are few destination hosts to migrate to and we want to let the user controlling that since performance may decrease or migration may fail. > > But if you are sure that the cluster contains hosts with identical cpu model and identical number of sockets, threads and cores as the source host, and you don't mind that VM will be migrated whenever required, then you can definitely change the migration value to "Allow manual and automatic migration". > > Thanks, > Sharon > > On Sun, Oct 20, 2019 at 2:42 AM Strahil Nikolov <hunter86_bg(a)yahoo.com> wrote: >> >> Hello Community,Dev, >> >> does anyone know why only "Manual Migration" allows passing through the CPU from the Host to the VM ? >> >> In many environments, the Clusters are having the same CPU model in order to avoid any issues. Have you observed any issues with that ? >> >> Best Regards, >> Strahil Nikolov >> _______________________________________________ >> Users mailing list -- users(a)ovirt.org >> To unsubscribe send an email to users-leave(a)ovirt.org >> Privacy Statement: https://www.ovirt.org/sit

1 0

Host-passthrough CPU and migration
by Strahil Nikolov 27 Oct '19

27 Oct '19

Hello Community,Dev, does anyone know why only "Manual Migration" allows passing through the CPU from the Host to the VM ? In many environments, the Clusters are having the same CPU model in order to avoid any issues. Have you observed any issues with that ? Best Regards,Strahil Nikolov

2 1

[oVirt] [CQ weekly status] [26-10-2019]
by Dusan Fodor 26 Oct '19

26 Oct '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.3*: GREEN (#1) Last failure was on 25-10 for ovirt-host due to dependency issue. Patch ( 104248 <https://gerrit.ovirt.org/104248>) is pending to fix this. *CQ-Master:* YELLOW (#1 Last failure was on 25-10 caused by known, random add storage domain failure (test issue). Current running jobs for 4.3 [1] and master [2] can be found here: [1] https://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-4.3_change-q… [2] http://jenkins.ovirt.org/view/Change%20queue%20jobs/job/ovirt-master_change… Have a nice week! Dusan ------------------------------------------------------------------------------------------------------------------- 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) _______________________________________________ Devel mailing list -- devel(a)ovirt.org To unsubscribe send an email to devel-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/devel@ovirt.org/message/YCNCKRK3G4EJX…

1 0