This RFE is about adding a way to support migration of RHEV-H host from RHEV 3 to RHEV 4 while keeping local storage domains.
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
Fabian - if this is going to make it for 4.0, please ensure it has an exception or blocker flags.
Moving out until we see a request for this.
Adding Maor from Engine side into the loop.
Still encounter this bug in redhat-virtualization-host-4.0-20161116.1.x86_64.liveimg.squashfs. Test version: 1.RHEV-H/RHEV-M 3.6: RHEV Hypervisor - 7.2 - 20161022.0.el7ev Red Hat Enterprise Virtualization Manager Version: 3.6.9.2-0.1.el6 2. RHV-H/RHV-M 4.0.5: redhat-virtualization-host-4.0-20161116.1.x86_64.liveimg.squashfs imgbased-0.8.10-0.1.el7ev.noarch kernel-3.10.0-514.el7.x86_64 Red Hat Virtualization Manager Version: 4.0.5.5-0.1.el7ev Test steps: I tested according to comment#4 steps, focus on step #11: "#11 In the Storage Tab, select the data (imported domain) and go to sub-tab 'Vm Import' and select the vm and click import (It should import the vm and disk)" Actual result: In step#11, there is no vm in sub-tab 'Vm Import' Expected result: In step#11, there should be vm in sub-tab 'Vm Import', and can be import successfully. So this bug is not fix in redhat-virtualization-host-4.0-20161116.1
This bug is not fixed completely in RHVH-4.1-20170109.0-RHVH-x86_64-dvd1.iso, so I will assign this bug. Below is detailed information. Test version: 1.RHEV-H/RHEV-M 3.6: rhevh-7.3-20161028.1.el6ev.iso Red Hat Enterprise Virtualization Manager Version: 3.6.9.2-0.1.el6 2. RHV-H 4.1/RHV-M 4.0: RHVH-4.1-20170109.0-RHVH-x86_64-dvd1.iso imgbased-0.9.2-0.1.el7ev.noarch kernel-3.10.0-514.2.2.el7.x86_64 Red Hat Virtualization Manager Version: 4.0.6.3-0.1.el7ev Test steps: I tested according to comment#4 , focus on step #11: "#11 In the Storage Tab, select the data (imported domain) and go to sub-tab 'Vm Import' and select the vm and click import (It should import the vm and disk)" Actual result: In step#11, there is no vm in sub-tab 'Vm Import' Expected result: In step#11, there should be vm in sub-tab 'Vm Import', and can be import successfully.
Created attachment 1239757 [details] local-import-storage-from36-to-41
Created attachment 1239779 [details] host4.1_log
Created attachment 1239780 [details] engine4.1_log
Created attachment 1239781 [details] engine3.6_log
Created attachment 1239834 [details] engine3.6_log for migration
It works well with a fresh RHEVM3.6 and RHVM4.0 Below is detailed information. > > - rhev-hypervisor7-7.3-20170110.1.iso > > - redhat-virtualization-host-4.1-20170104.0.x86_64.liveimg.squashfs Test version: 1.RHEV-H/RHEV-M 3.6: - rhev-hypervisor7-7.3-20170110.1.iso - Red Hat Enterprise Virtualization Manager Version: 3.6.9.2-0.1.el6 2. RHV-H 4.1/RHV-M 4.0: - redhat-virtualization-host-4.1-20170104.0.x86_64.liveimg.squashfs - imgbased-0.9.2-0.1.el7ev.noarch - kernel-3.10.0-514.2.2.el7.x86_64 - Red Hat Virtualization Manager Version: 4.0.6.3-0.1.el7ev Test steps: I tested according to comment#4 , and can import vm successful. So I will VERIFY this bug once it changes to ON_QA status.
(In reply to Huijuan Zhao from comment #29) > It works well with a fresh RHEVM3.6 and RHVM4.0 > > Below is detailed information. > > > > - rhev-hypervisor7-7.3-20170110.1.iso > > > - redhat-virtualization-host-4.1-20170104.0.x86_64.liveimg.squashfs > > Test version: > 1.RHEV-H/RHEV-M 3.6: > - rhev-hypervisor7-7.3-20170110.1.iso > - Red Hat Enterprise Virtualization Manager Version: 3.6.9.2-0.1.el6 > 2. RHV-H 4.1/RHV-M 4.0: > - redhat-virtualization-host-4.1-20170104.0.x86_64.liveimg.squashfs > - imgbased-0.9.2-0.1.el7ev.noarch > - kernel-3.10.0-514.2.2.el7.x86_64 > - Red Hat Virtualization Manager Version: 4.0.6.3-0.1.el7ev > > Test steps: > I tested according to comment#4 , and can import vm successful. > > So I will VERIFY this bug once it changes to ON_QA status. Great! Thanks a lot for your feedback! Moving to ON_QA, so you can move to verified.
But for the unclean rhevm3.6/4.0, maybe import failed just like comment 12 and comment 24, so I think we should Doc this to guide users using clean rhevm3.6/4.0 to complete migration.
I will verify this bug according to Comment 29, but please have a glance of comment 31 when doc this bug. Thanks!
Could you please let me know whether this bug has any impact on documentation other than writing Release Notes. Is there not a need to document this procedure in the the documentation?
(In reply to emma heftman from comment #33) > Could you please let me know whether this bug has any impact on > documentation other than writing Release Notes. > Is there not a need to document this procedure in the the documentation? I believe would be good to have such steps available in our documentation.
(In reply to emma heftman from comment #33) > Could you please let me know whether this bug has any impact on > documentation other than writing Release Notes. > Is there not a need to document this procedure in the the documentation? Yes, I also agree that including this information in documentation would be best.
Douglas, can you please clarify whether this bug provides the actual documentation, or whether it is simply testing the workflow.
(In reply to emma heftman from comment #36) > Douglas, can you please clarify whether this bug provides the actual > documentation, or whether it is simply testing the workflow. I believe this is a real documentation.
Emma, I do not understand the question. Comment 4 explains how the upgrade should take place, and this is later tested. Comment 4 should be rendered in a more general way (e.g. without specific release versions), and placed in RHV documentation. HTH.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Douglas, is this ready to move to ON_QA?
(In reply to Ryan Barry from comment #55) > Douglas, is this ready to move to ON_QA? yes
There is bug 1451112 in RHVH-4.1.2(RHVH-4.1-20170506.0), I will verify this bug after bug 1451112 is resolved.
Douglas, according to comment 29, comment 31 and comment 32, QE have already verified this bug. But there is new bug 1451112 related this bug now, and its Target Milestone is 4.1.3, so should we verify this bug first? Thanks!
(In reply to Huijuan Zhao from comment #58) > Douglas, according to comment 29, comment 31 and comment 32, QE have already > verified this bug. > But there is new bug 1451112 related this bug now, and its Target Milestone > is 4.1.3, so should we verify this bug first? > > Thanks! Yes, if possible, please wait the bz#1451112. Thanks!
(In reply to Douglas Schilling Landgraf from comment #59) > Yes, if possible, please wait the bz#1451112. > Thanks Douglas. So could you please change the Target Milestone to Ovirt-4.1.3 and change the status to MODIFIED?
Move back to Modify status due to no 4.1.3 build available for QE testing at present. Thanks.
What is the difference from bug #1421437? Is the docs team aware that the flow is not working? Can we make sure we test the flow Emma created?
(In reply to Yaniv Lavi from comment #62) > What is the difference from bug #1421437? > Is the docs team aware that the flow is not working? > Can we make sure we test the flow Emma created? This is the original bug, Emma created one for doc team. @Huijuan Zhao, could you please verify using the oficial documentation from Emma in the bug#1421437? @Emma, could you please point the last draft/doc to Huijuan Zhao? Thanks!
(In reply to Douglas Schilling Landgraf from comment #63) > This is the original bug, Emma created one for doc team. > > @Huijuan Zhao, could you please verify using the oficial documentation from > Emma in the bug#1421437? > > @Emma, could you please point the last draft/doc to Huijuan Zhao? Sure, Douglas. I will verify this bug later due to other higher priority task. Thanks!
(In reply to Huijuan Zhao from comment #65) > (In reply to Douglas Schilling Landgraf from comment #63) > > This is the original bug, Emma created one for doc team. > > > > @Huijuan Zhao, could you please verify using the oficial documentation from > > Emma in the bug#1421437? > > > > @Emma, could you please point the last draft/doc to Huijuan Zhao? > > Sure, Douglas. I will verify this bug later due to other higher priority > task. > Thanks! Here's a link to the latest documentation: http://file.tlv.redhat.com/~eheftman/bz1421437/html-single/#Upgrading_RHVH_Local_Storage
(In reply to Douglas Schilling Landgraf from comment #63) > This is the original bug, Emma created one for doc team. > > @Huijuan Zhao, could you please verify using the official documentation from > Emma in the bug#1421437? Hi, I have test this bug according to the official documentation from Emma as follows: Test version: RHEV-H 3.6 ->rhev-hypervisor7-7.3-20170425.0.el7 RHV-H 4.1 ->redhat-virtualization-host-4.1-20170609.2.x86_6 Step to test: Strictly follow the documentation (http://file.tlv.redhat.com/~eheftman/bz1421437/html-single/#Upgrading_RHVH_Local_Storage) Actual results: The VMs could be imported and could run up again, and the original configuration is kept Additional info: When coming to import VMs under VM Import tab on RHEVM, error about MAC conflict will output, you have to choose to reassign the MAC address so that we could successfully import VMs upon local storage So, according to this result, I thinks this bug is fixed on redhat-virtualization-host-4.1-20170609.2.x86_6, I will change status into VERIFIED Thanks!
Douglas and Emma, please note the "Additional info" in comment 67, I am not sure whether we should add this message to doc. Thanks!
(In reply to Huijuan Zhao from comment #68) > Douglas and Emma, please note the "Additional info" in comment 67, I am not > sure whether we should add this message to doc. Thanks! I added it to the documentation for 4.1. Thanks!