[ANN] oVirt 3.4.4 Release is now available
The oVirt development team is pleased to announce the general availability of oVirt 3.4.4 as of Sep 23th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere. oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar). This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed. The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system if you're upgrading from an older release. Please refer to release notes [1] for Installation / Upgrade instructions. Please note that mirrors will need a couple of days before being synchronized. If you want to be sure to use latest rpms and don't want to wait for the mirrors, you can edit /etc/yum.repos.d/ovirt-3.4.repo commenting the mirror line and removing the comment on baseurl line. A new oVirt Live ISO will be available too[2]. [1] http://www.ovirt.org/OVirt_3.4.4_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.4/iso/ovirt-live-el6-3.4.4.iso -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
Thanks Sandro, upgrading went really well and my datacenter is running 3.4.4 just fine. I suppose [1] is still in this release? Any change this will be backported from 3.5? Cheers! [1] https://bugzilla.redhat.com/show_bug.cgi?id=1130045 On 23.09.2014 23:06, Sandro Bonazzola wrote:
The oVirt development team is pleased to announce the general availability of oVirt 3.4.4 as of Sep 23th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere.
oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar).
This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed.
The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system if you're upgrading from an older release. Please refer to release notes [1] for Installation / Upgrade instructions.
Please note that mirrors will need a couple of days before being synchronized. If you want to be sure to use latest rpms and don't want to wait for the mirrors, you can edit /etc/yum.repos.d/ovirt-3.4.repo commenting the mirror line and removing the comment on baseurl line.
A new oVirt Live ISO will be available too[2].
[1] http://www.ovirt.org/OVirt_3.4.4_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.4/iso/ovirt-live-el6-3.4.4.iso
-- Daniel Helgenberger m box bewegtbild GmbH P: +49/30/2408781-22 F: +49/30/2408781-10 ACKERSTR. 19 D-10115 BERLIN www.m-box.de www.monkeymen.tv Geschäftsführer: Martin Retschitzegger / Michaela Göllner Handeslregister: Amtsgericht Charlottenburg / HRB 112767
Cool! However, the instructions for upgrading a Hosted Engine setup look suspiciously out of date and divergent from the instructions for upgrading standalone engine (e.g. you never run engine-setup??). Is this page accurate: http://www.ovirt.org/Hosted_Engine_Howto#Upgrade_Hosted_Engine I just fixed a bunch of egregious typos on the page myself - all of the hosted-engine invocation lines were incorrect (e.g. "hosted-engine --set-maintenance=global" instead of the now-corrected syntax: "hosted-engine --set-maintenance --mode=global"). This makes me somewhat cautious about the rest of the page content I'm afraid. Is it accurate to say that when upgrading a Hosted Engine setup you basically just upgrade the packages (while carefully orchestrating which services are up at the time), and never run engine-setup? If that page *is* accurate, why is engine-setup required for upgrading a standalone engine? Thanks, Bob On 09/23/2014 05:05 PM, Sandro Bonazzola wrote:
The oVirt development team is pleased to announce the general availability of oVirt 3.4.4 as of Sep 23th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere.
oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar).
This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed.
The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system if you're upgrading from an older release. Please refer to release notes [1] for Installation / Upgrade instructions.
Please note that mirrors will need a couple of days before being synchronized. If you want to be sure to use latest rpms and don't want to wait for the mirrors, you can edit /etc/yum.repos.d/ovirt-3.4.repo commenting the mirror line and removing the comment on baseurl line.
A new oVirt Live ISO will be available too[2].
[1] http://www.ovirt.org/OVirt_3.4.4_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.4/iso/ovirt-live-el6-3.4.4.iso
Il 24/09/2014 16:37, Bob Doolittle ha scritto:
Cool!
However, the instructions for upgrading a Hosted Engine setup look suspiciously out of date and divergent from the instructions for upgrading standalone engine (e.g. you never run engine-setup??).
Is this page accurate: http://www.ovirt.org/Hosted_Engine_Howto#Upgrade_Hosted_Engine
I just fixed a bunch of egregious typos on the page myself - all of the hosted-engine invocation lines were incorrect (e.g. "hosted-engine --set-maintenance=global" instead of the now-corrected syntax: "hosted-engine --set-maintenance --mode=global").
thanks!
This makes me somewhat cautious about the rest of the page content I'm afraid.
Is it accurate to say that when upgrading a Hosted Engine setup you basically just upgrade the packages (while carefully orchestrating which services are up at the time), and never run engine-setup?
No, the engine must be updated as for a standalone engine by running the same update procedure: - enable the new repo if needed (3.3 -> 3.4 or 3.4 -> 3.5) - yum update - engine-setup
If that page *is* accurate, why is engine-setup required for upgrading a standalone engine?
engine-setup is needed in order to upgrade the engine. I've updated a bit http://www.ovirt.org/Hosted_Engine_Howto#Upgrade_Hosted_Engine, hopefully should answer your questions.
Thanks, Bob
On 09/23/2014 05:05 PM, Sandro Bonazzola wrote:
The oVirt development team is pleased to announce the general availability of oVirt 3.4.4 as of Sep 23th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere.
oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar).
This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed.
The existing repository ovirt-3.4 has been updated for delivering this release without the need of enabling any other repository, however since we introduced package signing you need an additional step in order to get the public keys installed on your system if you're upgrading from an older release. Please refer to release notes [1] for Installation / Upgrade instructions.
Please note that mirrors will need a couple of days before being synchronized. If you want to be sure to use latest rpms and don't want to wait for the mirrors, you can edit /etc/yum.repos.d/ovirt-3.4.repo commenting the mirror line and removing the comment on baseurl line.
A new oVirt Live ISO will be available too[2].
[1] http://www.ovirt.org/OVirt_3.4.4_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.4/iso/ovirt-live-el6-3.4.4.iso
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On 09/24/2014 10:47 AM, Sandro Bonazzola wrote:
Il 24/09/2014 16:37, Bob Doolittle ha scritto:
If that page *is* accurate, why is engine-setup required for upgrading a standalone engine? engine-setup is needed in order to upgrade the engine. I've updated a bit http://www.ovirt.org/Hosted_Engine_Howto#Upgrade_Hosted_Engine, hopefully should answer your questions.
I am using Fedora 19 for host and engine. When I try to follow these instructions I get to the point of restarting VDSM on the host, and get: # service vdsm restart Redirecting to /bin/systemctl restart vdsm.service Failed to issue method call: Unit vdsm.service failed to load: No such file or directory. See system logs and 'systemctl status vdsm.service' for details. VDSM was still running, but systemctl did not think so: # systemctl stop vdsm Failed to issue method call: Unit vdsm.service not loaded. So instead at that point I shut down the engine (init 0) and rebooted the engine-hosting host. Things came up cleanly at that point. -Bob
Il 24/09/2014 17:24, Bob Doolittle ha scritto:
On 09/24/2014 10:47 AM, Sandro Bonazzola wrote:
Il 24/09/2014 16:37, Bob Doolittle ha scritto:
If that page *is* accurate, why is engine-setup required for upgrading a standalone engine? engine-setup is needed in order to upgrade the engine. I've updated a bit http://www.ovirt.org/Hosted_Engine_Howto#Upgrade_Hosted_Engine, hopefully should answer your questions.
I am using Fedora 19 for host and engine.
When I try to follow these instructions I get to the point of restarting VDSM on the host, and get:
# service vdsm restart Redirecting to /bin/systemctl restart vdsm.service Failed to issue method call: Unit vdsm.service failed to load: No such file or directory. See system logs and 'systemctl status vdsm.service' for details.
VDSM was still running, but systemctl did not think so:
# systemctl stop vdsm Failed to issue method call: Unit vdsm.service not loaded.
So instead at that point I shut down the engine (init 0) and rebooted the engine-hosting host.
Things came up cleanly at that point.
Thanks for the update, please note that the service is "vdsmd.service" not "vdsm.service". It may be possible that "systemctl reload vdsmd.service" is needed before "systemctl restart vdsmd.service"
-Bob
-- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com
On Tue, Sep 23, 2014 at 11:05 PM, Sandro Bonazzola <sbonazzo@redhat.com> wrote:
The oVirt development team is pleased to announce the general availability of oVirt 3.4.4 as of Sep 23th 2014. This release solidifies oVirt as a leading KVM management application and open source alternative to VMware vSphere.
oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 (or similar).
This release of oVirt includes numerous bug fixes. See the release notes [1] for a list of the new features and bugs fixed.
[snip]
[1] http://www.ovirt.org/OVirt_3.4.4_Release_Notes [2] http://resources.ovirt.org/pub/ovirt-3.4/iso/ovirt-live-el6-3.4.4.iso
Hello, I have just updated to 3.4.4 an oVirt all-in-one environment based on 3.4.1 and Fedora 19 . All went ok, especially for the previously dramatic update of reports/dwh parts. good job! I have some comments for the release notes: 1) the version I had to update was 3.4.1 3.4.1-1.fc19 in the release notes there is only mention for upgrade from 3.4.0 and in that case to remove ovirt-release package after installing ovirt-release34 So in my situation the user is not so confident about how to proceed. Infact in my case I already had ovirt-release34 installed. I only needed to update it. $ rpm -qa ovirt-release\* ovirt-release34-1.0.1-1.noarch I got same output using install or directly using update # yum localinstall http://resources.ovirt.org/pub/yum-repo/ovirt-release34.rpm Resolving Dependencies --> Running transaction check ---> Package ovirt-release34.noarch 0:1.0.1-1 will be updated ---> Package ovirt-release34.noarch 0:1.0.3-1 will be an update # yum update ovirt-release34 Resolving Dependencies --> Running transaction check ---> Package ovirt-release34.noarch 0:1.0.1-1 will be updated ---> Package ovirt-release34.noarch 0:1.0.3-1 will be an update So my workflow was the second one ad it seems more intuitive. It could be written that in case of 3.4.x with x>0 one only needs the yum update part 2) engine-setup Following the instrucitons to run yum update "ovirt-engine-setup*" when you run engine-setup, actually you are prompted to update also reports and dwh before proceeding, if you had them before, as it was my case: ... [ INFO ] Checking for product updates... Setup has found updates for some packages, do you wish to update them now? (Yes, No) [Yes]: [ INFO ] Checking for an update for Setup... An update for the Setup packages ovirt-engine-reports-setup ovirt-engine-dwh-setup was found. Please update that package by running: "yum update ovirt-engine-reports-setup ovirt-engine-dwh-setup" and then execute Setup again. [ ERROR ] Failed to execute stage 'Environment customization': Please update the Setup packages SO it should be written, if one had reports configured before, to run also # yum update ovirt-engine-reports-setup ovirt-engine-dwh-setup Resolving Dependencies --> Running transaction check ---> Package ovirt-engine-dwh-setup.noarch 0:3.4.1-1.fc19 will be updated ---> Package ovirt-engine-dwh-setup.noarch 0:3.4.4-0.1.fc19 will be an update ---> Package ovirt-engine-reports-setup.noarch 0:3.4.1-1.fc19 will be updated ---> Package ovirt-engine-reports-setup.noarch 0:3.4.4-0.1.fc19 will be an update Or it could also be modified the previous command adding a * in the middle yum update "ovirt-engine-*setup*" (actually better to split in two commands in my opinion) NOTE: My reports are ok if I select the reports link in the main page of portals But if I go in webadmin portal and then select "dashboard" near the top right events tab, I get a "page not found error" see https://drive.google.com/file/d/0BwoPbcrMv8mvWTdFOGJuekZmbEk/edit?usp=sharin... I never used this "dashboard" link before, so I don't know exactly what it should provide to the user. When I click on dashoard I see this in /var/log/httpd/ssl_request_log [30/Sep/2014:01:12:29 +0200] 192.168.1.101 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "POST /ovirt-engine/webadmin/GenericApiGWTService HTTP/1.1" 196 [30/Sep/2014:01:12:30 +0200] 127.0.0.1 TLSv1 AES256-SHA "POST /ovirt-engine/services/get-session-user HTTP/1.1" 14 [30/Sep/2014:01:12:30 +0200] 127.0.0.1 TLSv1 AES256-SHA "POST /ovirt-engine/services/get-session-user HTTP/1.1" 14 [30/Sep/2014:01:12:30 +0200] 127.0.0.1 TLSv1 AES256-SHA "POST /ovirt-engine/services/get-session-user HTTP/1.1" 14 [30/Sep/2014:01:12:30 +0200] 127.0.0.1 TLSv1 AES256-SHA "POST /ovirt-engine/services/get-session-user HTTP/1.1" 14 [30/Sep/2014:01:12:30 +0200] 192.168.1.101 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "POST /ovirt-engine-reports/flow.html?viewAsDashboardFrame=true HTTP/1.1" 2239 [30/Sep/2014:01:12:30 +0200] 127.0.0.1 TLSv1 AES256-SHA "POST /ovirt-engine/services/get-session-user HTTP/1.1" 14 [30/Sep/2014:01:12:30 +0200] 127.0.0.1 TLSv1 AES256-SHA "POST /ovirt-engine/services/get-session-user HTTP/1.1" 14 [30/Sep/2014:01:12:30 +0200] 192.168.1.101 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "POST /ovirt-engine-reports/flow.html?viewAsDashboardFrame=true HTTP/1.1" 2239 [30/Sep/2014:01:12:34 +0200] 192.168.1.101 TLSv1.2 ECDHE-RSA-AES128-GCM-SHA256 "POST /ovirt-engine/webadmin/GenericApiGWTService HTTP/1.1" 196 Nothing in engine.log and nothing in /var/log/ovirt-engine-reports/jasperserver.log I don't know where to find for more info... Gianluca
participants (4)
-
Bob Doolittle -
Daniel Helgenberger -
Gianluca Cecchi -
Sandro Bonazzola