can you try with latest build? 3.6.1-4?
adding sandro to see if there is a known issue

also, i don't think "yum update" is the right way to upgrade.
you should run engine-setup, or only yum update rhevm-setup and then engine-setup.

yum correctly protected the system by being broken by an update.
rhevm-reports-3.5.5-2.el6ev.noarch  and rhevm-backend-3.5.6.2-0.1.el6ev.noarch are version locked because for properly updating them you should run engine-setup.

vdsm-jsonrpc-java = 1.1.5-1.el6ev is available as an update but if yum updates it, it will break rhevm-backend-3.5.6.2-0.1.el6ev.noarch so the requirement in rhevm-backend-3.5.6.2 is correctly requiring vdsm-jsonrpc-java < 1.1.0.

jasperreports-server-pro = 6.0.1-1.el6ev is available as an update but if yum updates it, it will break rhevm-reports-3.5.5-2.el6ev.noarch so  the requirement in rhevm-reports-3.5.5 is correctly requiring jasperreports-server-pro < 5.6.0.

In order to perform the update you can either:

yum update --skip-broken and then run engine-setup
or:

yum update "rhevm-setup*"
engine-setup
yum update

(In reply to Eyal Edri from comment #6)
> also, i don't think "yum update" is the right way to upgrade.
> you should run engine-setup, or only yum update rhevm-setup and then
> engine-setup.

Following steps 2->5 https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html/Installation_Guide/sect-Upgrading_to_Red_Hat_Enterprise_Virtualization_3.5.html:
# yum update
# yum update rhevm-setup
# engine-setup

I've also seen this dependency issue, but it might be WA by changing the upgrade work flow as follows:
# yum update rhevm-setup
# yum update
# engine-setup

From the perspective of general OS updates, dependency on RHEL component yet looks problematic.

(In reply to Nikolai Sednev from comment #10)
> From the perspective of general OS updates, dependency on RHEL component yet
> looks problematic.

I'd like to clarify.

The correct upgrade procedure is:

1. Have an existing system with whatever version available in your z-stream.
2. Run yum update if you want. 
3. Add repos of next version.
4. yum update the setup packages.
5. engine-setup
6. yum update

In particular:
A. We do not (try to) support running 'yum update' between (3.) and (4.).
B. Meaning, if you decide you want to upgrade, you have to do that in one shot. Not add repos and then do other stuff.

If you find the above problematic, please suggest another flow (which still accepts the current use of versionlock, which is a different issue). In particular, there might be some yum option/plugin/whatever that will allow running 'yum update' and still keep all deps/conflicts satisfied, *including* versionlock. Never researched this, and not sure what hooks are available to yum plugins - if versionlock is able to affect also the list of packages to be upgraded, both before and after dependency resolution, and not merely prevent an update once the list is computed, it might be possible. You might open this as a bug/rfe on yum (or dnf).

(In reply to Yedidyah Bar David from comment #11)
> (In reply to Nikolai Sednev from comment #10)
> > From the perspective of general OS updates, dependency on RHEL component yet
> > looks problematic.
> 
> I'd like to clarify.
> 
> The correct upgrade procedure is:
> 
> 1. Have an existing system with whatever version available in your z-stream.
> 2. Run yum update if you want. 
> 3. Add repos of next version.
> 4. yum update the setup packages.
> 5. engine-setup
> 6. yum update
> 
> In particular:
> A. We do not (try to) support running 'yum update' between (3.) and (4.).
> B. Meaning, if you decide you want to upgrade, you have to do that in one
> shot. Not add repos and then do other stuff.
> 
> If you find the above problematic, please suggest another flow (which still
> accepts the current use of versionlock, which is a different issue). In
> particular, there might be some yum option/plugin/whatever that will allow
> running 'yum update' and still keep all deps/conflicts satisfied,
> *including* versionlock. Never researched this, and not sure what hooks are
> available to yum plugins - if versionlock is able to affect also the list of
> packages to be upgraded, both before and after dependency resolution, and
> not merely prevent an update once the list is computed, it might be
> possible. You might open this as a bug/rfe on yum (or dnf).

It's perfectly fine as long as we're aligned to the documented upgrade scenario, which currently not quite correct.
The only improvement which I can see here is to make an engine upgrade procedure available via WEBUI of the engine, just like it's possible to upgrade FW version for network devices, once it's available from local source or online, it will ensure correct upgrade procedure as it'll be executed by in background automatically, once done, engine will come back online.

(In reply to Nikolai Sednev from comment #12)
> 
> It's perfectly fine as long as we're aligned to the documented upgrade
> scenario, which currently not quite correct.

That's iiuc the current scope of current bug.

> The only improvement which I can see here is to make an engine upgrade
> procedure available via WEBUI of the engine, just like it's possible to
> upgrade FW version for network devices, once it's available from local
> source or online, it will ensure correct upgrade procedure as it'll be
> executed by in background automatically, once done, engine will come back
> online.

Not sure this aligns well with the current architecture, as engine-setup runs as root (and in many cases needs that) while the engine runs as a regular user.

See also bug 951799.

Hi Didi,
   So my understanding is that the upgrade workflow should be:

1. Have an existing system with whatever version available in your z-stream.
2. Add repos of next version.
3. yum update the setup packages.
4. engine-setup
5. remove repos of the old version
6. yum update

Please confirm if this is correct and applies to all upgrade procedures from 3.1 to 3.6 Beta.

Kind regards,
Julie

(In reply to Julie from comment #14)
> Hi Didi,
>    So my understanding is that the upgrade workflow should be:
> 
> 1. Have an existing system with whatever version available in your z-stream.
> 2. Add repos of next version.
> 3. yum update the setup packages.
> 4. engine-setup
> 5. remove repos of the old version
> 6. yum update
> 
> Please confirm if this is correct and applies to all upgrade procedures from
> 3.1 to 3.6 Beta.
> 
> Kind regards,
> Julie

This work flow was correct and successful for me while I performed RHEVM3.4(3.4.5-0.3)->RHEVM3.5(3.5.6.2-0.1)->RHEVM3.5(3.5.7-0.1)->RHEVM3.6(3.6.1.3-0.1).

The same work flow should work also for 3.1.

(In reply to Julie from comment #14)
> Hi Didi,
>    So my understanding is that the upgrade workflow should be:
> 
> 1. Have an existing system with whatever version available in your z-stream.
> 2. Add repos of next version.
> 3. yum update the setup packages.
> 4. engine-setup
> 5. remove repos of the old version
> 6. yum update
> 
> Please confirm if this is correct and applies to all upgrade procedures from
> 3.1 to 3.6 Beta.

Yes, afaik.

I don't know well <=3.2.

There were significant changes to implementation in 3.3 (for the engine) and 3.4 (for dwh/reports). Otherwise the principle was kept as above.

Assigning Tahlia as the QA contact.

Tahlia - could you take a look at the changes for this bug?

*** Bug 1305097 has been marked as a duplicate of this bug. ***

Documentation available at:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6-Beta/html-single/Upgrade_Guide/index.html#Upgrading_to_Red_Hat_Enterprise_Virtualization_Manager_3.6

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.5/html-single/Installation_Guide/index.html#Upgrading_to_Red_Hat_Enterprise_Virtualization_Manager_3.5

Moving 'requires_doc_text' to '-' and clearing 'Doc Text' field. The instructions for upgrade have been updated in the documentation.