11:05 p.m.
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
9:31 a.m.
New subject: [ovirt-announce] [ANN] oVirt 3.4.4 Release is now available
On 23/09/14 23:05, Sandro Bonazzola wrote:
First, thanks for the new release, but I have one objection to make:
Hidden in the release notes we find:
BZ 1139000 - CVE-2014-3573 ovirt-engine-backend: oVirt Engine: XML
eXternal Entity (XXE) flaw in backend module
So I'd like to discuss if security fixes should not be highlighted
somewhat more?
I'd expect the following:
a) Mention at least that CVEs where fixed in this release in the
announcement.
b) a category "security patches" (or similar) in the release notes
where these fixes get listed.
c) This new category should be at the top of the release notes.
What do you think?
--
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:51 p.m.
New subject: Release notes / announcements and security fixes
Il 24/09/2014 09:31, Sven Kieske ha scritto:
On 23/09/14 23:05, Sandro Bonazzola wrote:
> [1] http://www.ovirt.org/OVirt_3.4.4_Release_Notes
First, thanks for the new release, but I have one objection to make:
Thanks for the highlight, changed subject for making this more visible.
Hidden in the release notes we find:
BZ 1139000 - CVE-2014-3573 ovirt-engine-backend: oVirt Engine: XML
eXternal Entity (XXE) flaw in backend module
So I'd like to discuss if security fixes should not be highlighted
somewhat more?
I'd expect the following:
a) Mention at least that CVEs where fixed in this release in the
announcement.
b) a category "security patches" (or similar) in the release notes
where these fixes get listed.
c) This new category should be at the top of the release notes.
What do you think?
Make sense.
Updated 3.4.4 Release notes as per points b and c.
http://www.ovirt.org/OVirt_3.4.4_Release_Notes
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
3:48 p.m.
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
4:05 p.m.
Il 24/09/2014 15:48, Daniel Helgenberger ha scritto:
Thanks Sandro,
upgrading went really well and my datacenter is running 3.4.4 just fine.
Nice to read that :-)
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
As far as I know, that bug is on ioprocess package which doesn't exist in 3.4.
CCing some people, maybe then can answer you.
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
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
4:14 p.m.
Hello Sandro,
this is the upstream 'working' bug, the original bug was flagged
duplicate and posted for the 3.4 branch:
https://bugzilla.redhat.com/show_bug.cgi?id=1124451
Cheers
On 24.09.2014 16:05, Sandro Bonazzola wrote:
Il 24/09/2014 15:48, Daniel Helgenberger ha scritto:
> Thanks Sandro,
>
> upgrading went really well and my datacenter is running 3.4.4 just fine.
>
Nice to read that :-)
> 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
As far as I know, that bug is on ioprocess package which doesn't exist in 3.4.
CCing some people, maybe then can answer you.
> 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
4:22 p.m.
On 24/09/14 16:14, Daniel Helgenberger wrote:
Hello Sandro,
this is the upstream 'working' bug, the original bug was flagged
duplicate and posted for the 3.4 branch:
https://bugzilla.redhat.com/show_bug.cgi?id=1124451
Cheers
Well so there went something wrong:
if this is a regression within 3.4 it should get fixed also in that
branch..
--
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
4:52 p.m.
Il 24/09/2014 16:14, Daniel Helgenberger ha scritto:
Hello Sandro,
this is the upstream 'working' bug, the original bug was flagged
duplicate and posted for the 3.4 branch:
https://bugzilla.redhat.com/show_bug.cgi?id=1124451
The bugs was opened against 3.4 and targeted to 3.6.
Then it has been identified as a duplicate of a bug on ioprocess for 3.5 and fixed.
Looks like assignee did not mark this for being backported to 3.4.z.
Other than that, waiting for assignee reply to the thread.
Cheers
On 24.09.2014 16:05, Sandro Bonazzola wrote:
> Il 24/09/2014 15:48, Daniel Helgenberger ha scritto:
>> Thanks Sandro,
>>
>> upgrading went really well and my datacenter is running 3.4.4 just fine.
>>
> Nice to read that :-)
>
>
>> 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
> As far as I know, that bug is on ioprocess package which doesn't exist in 3.4.
> CCing some people, maybe then can answer you.
>
>
>> 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
>>>
>
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
4:58 p.m.
On 24.09.2014 16:52, Sandro Bonazzola wrote:
Il 24/09/2014 16:14, Daniel Helgenberger ha scritto:
> Hello Sandro,
>
> this is the upstream 'working' bug, the original bug was flagged
> duplicate and posted for the 3.4 branch:
> https://bugzilla.redhat.com/show_bug.cgi?id=1124451
The bugs was opened against 3.4 and targeted to 3.6.
Then it has been identified as a duplicate of a bug on ioprocess for 3.5 and fixed.
Looks like assignee did not mark this for being backported to 3.4.z.
Thanks for the
info Sandro.
IMHO this is a major issue and *should* be backported if possible to
3.4.x (right now I have a cron job restarting vdsmd once a week). I'll
add a comment on BZ to make sure ;)
Other than that, waiting for assignee reply to the thread.
> Cheers
>
>
> On 24.09.2014 16:05, Sandro Bonazzola wrote:
>> Il 24/09/2014 15:48, Daniel Helgenberger ha scritto:
>>> Thanks Sandro,
>>>
>>> upgrading went really well and my datacenter is running 3.4.4 just fine.
>>>
>> Nice to read that :-)
>>
>>
>>> 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
>> As far as I know, that bug is on ioprocess package which doesn't exist in
3.4.
>> CCing some people, maybe then can answer you.
>>
>>
>>> 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
7:29 p.m.
On Wed, Sep 24, 2014 at 02:58:59PM +0000, Daniel Helgenberger wrote:
On 24.09.2014 16:52, Sandro Bonazzola wrote:
> Il 24/09/2014 16:14, Daniel Helgenberger ha scritto:
>> Hello Sandro,
>>
>> this is the upstream 'working' bug, the original bug was flagged
>> duplicate and posted for the 3.4 branch:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1124451
> The bugs was opened against 3.4 and targeted to 3.6.
> Then it has been identified as a duplicate of a bug on ioprocess for 3.5 and fixed.
> Looks like assignee did not mark this for being backported to 3.4.z.
Thanks for the info Sandro.
IMHO this is a major issue and *should* be backported if possible to
3.4.x (right now I have a cron job restarting vdsmd once a week). I'll
add a comment on BZ to make sure ;)
Toni can correct me, but I believe that he reprorted
Bug 1124451 - vdsm leaks memory
on a setup using ioprocess; that's why I've marked it as a dup of
Bug 1130045 - Very high memory consumption
Apparently, we have another memory leak, besides the one(s) instroduced
in the 3.5 branch. It's not a new one - certainly not new to 3.4.4.
I think it would be best to report a fresh one, with a precise vdsm
version, and further info I requested in a parallel thread.
Regards,
Dan.
4:37 p.m.
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
4:47 p.m.
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
5:24 p.m.
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
8:25 a.m.
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
1:18 a.m.
On Tue, Sep 23, 2014 at 11:05 PM, Sandro Bonazzola <sbonazzo(a)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=sha...
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
3518
days inactive
3524
days old
14 comments
6 participants
participants (6)
-
Bob Doolittle -
Dan Kenigsberg -
Daniel Helgenberger -
Gianluca Cecchi -
Sandro Bonazzola -
Sven Kieske