Stopping and starting the VMs on 3.6 NGN works fine but this ruins our goal anyway, ie. migration without big impact.

The version "RHEL - 3.6 - 0.2.el7" comes directly from host.getHostOs(). Can you execute `vdsClient -s 0 getVdsCaps` and check what is reported there?

Created attachment 1256004 [details]
vdsClient -s 0 getVdsCaps

Yep, as I assumed:

operatingSystem = {'name': 'RHEL', 'release': '0.2.el7', 'version': '3.6'}

This does not look right and RHEL 3.6 is really lower than RHEL 6 as far as scheduler is concerned :) So we need to send this bug to whoever is responsible for the host version detection.

mperina, isn't it a dup of another ngn-related bug we've discussed?

(In reply to Dan Kenigsberg from comment #8)
> mperina, isn't it a dup of another ngn-related bug we've discussed?

Yes, from the description above it seems to me it's caused by BZ1368364. This is the 1st time we see that there are worse consequences than displaying bad version in webadmin ...

Created attachment 1256766 [details]
caps.py

Hi Jiri, 
 
Could you please test the caps.py attached in your ngn 3.6?

I would recommend the following:

  - Grab current operatingSystem data
    # vdsClient -s 0 getVdsCaps | grep operatingSystem

  - Backup current caps.py 
    # cp /usr/share/vdsm/caps.py /usr/share/vdsm/caps.py.bkp

  - Replace caps.py
    # cp /path/new/caps.py /usr/share/vdsm/caps.py

  - Restart vdsmsd 
    # systemctl restart vdsmd.service

  - Grab new operatingSystem and compare with the old one
    # vdsClient -s 0 getVdsCaps | grep operatingSystem

  - Try again the vm migration

Thanks!

(In reply to Douglas Schilling Landgraf from comment #11)
> Hi Jiri, 
>  
> Could you please test the caps.py attached in your ngn 3.6?
> 
> I would recommend the following:
> 
>   - Grab current operatingSystem data
>     # vdsClient -s 0 getVdsCaps | grep operatingSystem

# vdsClient -s 0 getVdsCaps | grep operatingSystem
        operatingSystem = {'name': 'RHEL', 'release': '0.2.el7', 'version': '3.6'}

>   - Backup current caps.py 
>     # cp /usr/share/vdsm/caps.py /usr/share/vdsm/caps.py.bkp
> 
>   - Replace caps.py
>     # cp /path/new/caps.py /usr/share/vdsm/caps.py
> 
>   - Restart vdsmsd 
>     # systemctl restart vdsmd.service
> 
>   - Grab new operatingSystem and compare with the old one
>     # vdsClient -s 0 getVdsCaps | grep operatingSystem

]# vdsClient -s 0 getVdsCaps | grep operatingSystem
        operatingSystem = {'name': 'RHEL', 'release': '0.2.el7', 'version': '7.3'}

>   - Try again the vm migration

works fine.

> 
> Thanks!

ok, based on #13

redhat-virtualization-host-image-update-placeholder-3.6-0.2.el7.noarch

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1211

Had this problem too.

First installed the latest 4.0 series like 4.0.7

But then checked in your document that 7.3 based is not supported with 3.5 cluster
(see https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Installation_Guide/Host_Compatibility_Matrix.html table 8.1)

So installed first 4.0 hypervisor. And got this weird problem because it presented itself as version "4.0".

This quick hack solved the problem:

      caps['operatingSystem'] = osinfo.version()
+     caps['operatingSystem']['version'] = "7.2"

I do understand that you there in RH are protecting people from themselves which makes me frustrated because have been doing this work before most of you there have even been born. (pun intended)

This problem should have been fixed long long time ago.