Please upgrade ovirt infrastructure to oVirt 4.1

Description

We're going to release 4.1 rc on Monday, please consider upgrading our
infra to it.


Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

Activity

Show:

Sandro Bonazzola February 10, 2017 at 12:26 PM

confirmed, current status is ok for me.

Former user February 9, 2017 at 10:47 AM

Answers inline

why are you rebooting VMs?

To apply hardware changes induced by the new cluster level.

is the DC level 4.1 already (should enable qcow2v3)? I assume not with 4.0 CL yet.

We have 10 datacenters (1 shared storage and 9 local storage) - 2 of the local storage ones are already bumped to 4.1 compatibility with all VMs rebooted

virtio-SCSI should bring a slight (invisible to the human eye) performance improvement, but should also enable you to enable DISCARD to reclaim space.

Didn't see any difference in storage load so far. Is not under heavy load currently, nor are we constrained in space to benefit from DISCARD.

Did you notice the Engine performing any better? I expect lower CPU usage and slightly improved UX performance. It's probably quite subjective if you had not measured it before (do you happen to have it monitored via collectd?)

I did not see serious UI performance issues in 4.0. The dashboard was loading up just fine and is doing so now. On server side I see the same levels of load after upgrade. Opening a VM "edit" dialog in the UI still takes 8 seconds so there's place for improvement still. This is the most common UI action for me personally and it's been slow forever.

I wonder if soft affinity could be beneficial for your workloads as well.

We use soft negative VM affinity on some cluster services for a couple of releases already. Didn't test host affinity: we don't really have a use for it as all hosts are the same.

Have you upgraded Python/Java/Ruby SDKs to 4.1? (relevant if you are using v4 API)

We have an old Foreman (v1.7) instance which stopped working via the API since we upgraded to 4.0 but that one is scheduled for decommissioning (and it's on el6 so not sure the new SDK was even released for it). Other than that there are no API consumers for this environment.

Yaniv Kaul February 8, 2017 at 9:11 PM

- thanks for the reports!

  • why are you rebooting VMs?

  • is the DC level 4.1 already (should enable qcow2v3)? I assume not with 4.0 CL yet.

  • virtio-SCSI should bring a slight (invisible to the human eye) performance improvement, but should also enable you to enable DISCARD to reclaim space.

  • Did you notice the Engine performing any better? I expect lower CPU usage and slightly improved UX performance. It's probably quite subjective if you had not measured it before (do you happen to have it monitored via collectd?)

  • I wonder if soft affinity could be beneficial for your workloads as well.

  • Have you upgraded Python/Java/Ruby SDKs to 4.1? (relevant if you are using v4 API)

Former user February 8, 2017 at 2:07 PM

engine-phx.ovirt.org updated to 4.1.0.4 successfully. One of the local DCs with vdsm-4.19.4 moved to 4.1 compatibility level successfully, 19 VMs running on it rebooted and working fine so far.

please confirm if it's OK to close this request now or you'd like to wait till all clusters are at 4.1 compat level and all ~200 VMs are rebooted?

Former user February 8, 2017 at 1:38 PM

Upgrade tested successfully on live DB dump taken from yesterdays backup.
I believe we're good to go for the upgrade. We'll stay at 4.0 compatibility level on the Production DC until we have more data on BZ#1419924 and avoid using HA leases until BZ#1408982 is fixed.

Done

Details

Assignee

Reporter

Priority

Created January 21, 2017 at 4:40 AM
Updated February 28, 2017 at 2:33 PM
Resolved February 14, 2017 at 12:44 PM