5:54 a.m.
Bob Doolittle <bob@...> writes:
On 11/21/2013 12:57 PM, Itamar Heim wrote:
> On 11/21/2013 07:38 PM, Bob Doolittle wrote:
>>
>> On 11/21/2013 12:00 PM, Itamar Heim wrote:
>>> On 11/21/2013 06:32 PM, Bob Doolittle wrote:
>>>> Yay!
>>>>
>>>> Congratulations to all of the oVirt team.
>>>>
>>>> I am having trouble locating upgrade instructions, however. There's
>>>> nothing in the release notes.
>>>>
>>>> I discovered through trial-and-error that running
"engine-setup"
again
>>>> handles upgrade of the Engine.
>>>>
>>>> But I don't know how to upgrade my RH 6.4 KVM host. When I try to
run
>>>> "yum update" it fails due to dependency errors notably in:
>>>> glusterfs
>>>> qemu
>>>> vdsm
>>>>
>>>
>>> can you please include the yum output log?
>>
>> Sorry yes. Attached are three outputs. First my repolist. Then yum
>> update with no options, and yum update with --skip-broken (so you can
>> see the lurking issues masked by the first failure).
>>
>> It appears that the glusterfs issue is due to a newer version offered
by
>> rhel-x86_64-server-6: glusterfs-3.4.0.36rhs-1.el6.x86_64.
This has
>> dependencies which conflict with the version provided by ovirt-stable
>> (and glusterfs-epel).
>>
>> It looks like there was a large update to the Red Hat repo last night
>> that has caused conflicts with ovirt-stable.
>>
>> Note I can get it to the point where it's willing to install packages
if
>> I specify --skip-broken and also --exclude
vdsm-python-4.12.1, but
>> that's a bit too scary for me without checking first.
>
> oh, you may caught rhel repo in middle of a refresh - try again in a
> few hours first, but could be the refresh may cause an issue we'd need
> to resolve.
Not sure why I'm the only person reporting this (am I the only person
who runs RH 6 on their KVM hosts who has tried upgrading??), but the
problem has not resolved.
What's the next step? Does it need a bug opened?
Let me know if I can provide any more information.
Thanks,
Bob
>
>>
>> Thanks,
>> Bob
>>
>>>
>>>> and also to a multilib version error due to vdsm-python 4.12 and
4.13.
>>>>
>>>> What's the proper upgrade procedure for a Host?
>>>>
>>>> Thanks,
>>>> Bob
>>>>
>>>> On 11/21/2013 10:43 AM, Kiril Nesenko wrote:
>>>>> The oVirt development team is very happy to announce the general
>>>>> availability of oVirt 3.3.1 as of November 21th 2013. 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.4
>>>>> (or similar).
>>>>>
>>>>> See release notes [1] for a list of the new features and bug fixed.
>>>>>
>>>>> [1] http://www.ovirt.org/OVirt_3.3.1_release_notes
>>>>>
>>>>> - Kiril
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users@...
>>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users@...
>>>> http://lists.ovirt.org/mailman/listinfo/users
>>>
>>
>
I'am experiencing same exact issue with upgrade on RHEL 6.4 and vdsm for
oVirt installed.
However, I did a little searching, and for me it seems it is like this:
vds requires these glsuterfs packages to have the latest version:
glusterfs
glusterfs-api
glusterfs-cli
glusterfs-fuse
glusterfs-libs
In RHEL repository are these packages are with version 3.4.0.36rhs-
1.el6.x86_64 EXCEPT for glusterfs-cli, which RHEL repo doesn't have at all.
oVirt repo has all those packages with version 3.4.0-8.el6.x86_64, which is
older than RHEL repo packages.
Hence, there is conflict. During vdsm update or even installation on RHEL
6.4 it tries to install the latest of all those packages. Looks likes this:
glusterfs-3.4.0.36rhs-1.el6.x86_64
glusterfs-api-3.4.0.36rhs-1.el6.x86_64
glusterfs-fuse-3.4.0.36rhs-1.el6.x86_64
requires: glusterfs-libs-3.4.0.36rhs-1.el6.x86_64
glusterfs-cli-3.4.0-8.el6.x86_64
requires: glusterfs-libs-3.4.0-8.el6.x86_64
While this is not fixed, in my opinion, ovirt installation from repository
on RHEL 6.4 is essentially broken.