According to documentation in https://bugzilla.redhat.com/show_bug.cgi?id=1376454
What is the RFE about? Want it new and need to be documented? It is not clear from the original bug.
(In reply to Yaniv Dary from comment #1) > What is the RFE about? Want it new and need to be documented? > It is not clear from the original bug. In comment 18 of the original bug, Douglas provides the steps for "migrating" from 3.6 to 4.0 or 4.1. This is the issue that we discussed in terms of the terminology. You asked that this be described as reinstall and restore.
(In reply to Yaniv Dary from comment #1) > What is the RFE about? Want it new and need to be documented? > It is not clear from the original bug. Please let me know if comment#2 address your question.
Emma, please note that QE suggested more detailed steps for iscsi (includes login steps instead of just mention "Login to storage and import") in comment 26: https://bugzilla.redhat.com/show_bug.cgi?id=1376454#c26 thanks
I don't understand the flow is looks like a manager migration process, not a RHV-H upgrade at all.
(In reply to Yaniv Dary from comment #5) > I don't understand the flow is looks like a manager migration process, not a > RHV-H upgrade at all. Yes, we can call manager migration or, in other words, 'storage migration from 3.6 to 4.0'. This test scenario involves: 3.6, 4.0, RHEV-H and RHV-H. That's the reason of this bug report, test such scenario with RHEV-H and RHVH. Basically, users 'de-attach' the storage domain from 3.6 with legacy RHEV-H and attach it in 4.0 with RHV-H and should work out of box. Let's keep in mind it's not live migration although, it requires maint. window, but users might want to prepare a second environment with 4.0 series and during the migration window use such approach and in case of failure, re-active the storage in the old environment (3.6). If you prefer, we can rename the topic. Please let me know your thoughts.
(In reply to Douglas Schilling Landgraf from comment #6) > (In reply to Yaniv Dary from comment #5) > > I don't understand the flow is looks like a manager migration process, not a > > RHV-H upgrade at all. > > Yes, we can call manager migration or, in other words, 'storage migration > from 3.6 to 4.0'. This test scenario involves: 3.6, 4.0, RHEV-H and RHV-H. > That's the reason of this bug report, test such scenario with RHEV-H and > RHVH. > > Basically, users 'de-attach' the storage domain from 3.6 with legacy RHEV-H > and attach it in 4.0 with RHV-H and should work out of box. Let's keep in > mind it's not live migration although, it requires maint. window, but users > might want to prepare a second environment with 4.0 series and during the > migration window use such approach and in case of failure, re-active the > storage in the old environment (3.6). If you prefer, we can rename the > topic. Please let me know your thoughts. So this has nothing to do with node. It's testing data storage domain import from 3.6 directly to 4.0/4.1?
(In reply to Yaniv Dary from comment #7) > (In reply to Douglas Schilling Landgraf from comment #6) > > (In reply to Yaniv Dary from comment #5) > > > I don't understand the flow is looks like a manager migration process, not a > > > RHV-H upgrade at all. > > > > Yes, we can call manager migration or, in other words, 'storage migration > > from 3.6 to 4.0'. This test scenario involves: 3.6, 4.0, RHEV-H and RHV-H. > > That's the reason of this bug report, test such scenario with RHEV-H and > > RHVH. > > > > Basically, users 'de-attach' the storage domain from 3.6 with legacy RHEV-H > > and attach it in 4.0 with RHV-H and should work out of box. Let's keep in > > mind it's not live migration although, it requires maint. window, but users > > might want to prepare a second environment with 4.0 series and during the > > migration window use such approach and in case of failure, re-active the > > storage in the old environment (3.6). If you prefer, we can rename the > > topic. Please let me know your thoughts. > > So this has nothing to do with node. > It's testing data storage domain import from 3.6 directly to 4.0/4.1? I have tested against node and it worked.
I don't think there is anything to add to docs here. Closing.
Douglas / Emma, Please help me understanding the status of this bug. Looking into Upgrade Guide for 4.1, I do not see anything on this subject: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1-beta/html/upgrade_guide/ Looking into the Admin Guide, as the current title suggests, I do not see anything there either: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1-beta/html/administration_guide/ Looking into this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c42 I see it is closed current release as well. I am not sure where this information has gone and how we can use it. I do believe the information requested in this bug is extremely helpful and needed for our customers. Please clarify.
Yaniv Can you please reopen this bug as it seems that there is a demand for this information.
(In reply to Marina from comment #10) > Douglas / Emma, > > Please help me understanding the status of this bug. > Looking into Upgrade Guide for 4.1, I do not see anything on this subject: > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1- > beta/html/upgrade_guide/ > > Looking into the Admin Guide, as the current title suggests, I do not see > anything there either: > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1- > beta/html/administration_guide/ > > Looking into this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c42 > I see it is closed current release as well. > > I am not sure where this information has gone and how we can use it. I do > believe the information requested in this bug is extremely helpful and > needed for our customers. Please clarify. Marina, I agree that document how to migrate local storage (bz#1320556) to customers is important, as in such scenarios we cannot live migrate the vms. For cases with non local storage, is preferable to live migrate, i.e: from 3.5 -> 3.6 -> 4.0 and then 4.1 instead of migrate storage. For more info: https://bugzilla.redhat.com/show_bug.cgi?id=1421098#c15 However, making available how to migrate storage from 3.6 to 4.0 with example in our documentation (probably not in the upgrade chapters to avoid confusion with live migrate approach) might be useful as it's difficult to determine all users needs but it's important to have the knowledge available. More info: https://bugzilla.redhat.com/show_bug.cgi?id=1376454 Finally, it's PM decision how we should proceed. Let's wait his decision.
I am looking for a flow I can read and understand. Please work on the steps, so it will be clearer and post them.
(In reply to Yaniv Dary from comment #13) > I am looking for a flow I can read and understand. > Please work on the steps, so it will be clearer and post them. Migration flow 3.6 to 4: https://bugzilla.redhat.com/show_bug.cgi?id=1421098#c15 Local storage from 3.6 to 4: https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c4 https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c6 Storage migration 3.6 to 4: https://bugzilla.redhat.com/show_bug.cgi?id=1376454#c26
Emma, Looking deeper, I understand there are 2 different scenarios that we are trying to document and should appear in the Upgrade Guide for 4.1: 1. "Upgrading RHEVH 3.6 to RHVH-Next 4.x"[*] The instructions are here: https://bugzilla.redhat.com/show_bug.cgi?id=1376454#c26 (Note: we should not separate different storage domain types in the upgrade instructions, IMO.) 2. "Upgrading environments with RHEVH 3.5 (RHEL 6 based) to RHV-Next 4.x"[*] https://bugzilla.redhat.com/show_bug.cgi?id=1421098#c0 And the instructions are available here: https://bugzilla.redhat.com/show_bug.cgi?id=1421098#c15 [*] Note: my wording is just a suggestion and probably should be reviewed before adding to the docs. 3. In addition, the following bug seem not to be relevant anymore, cause it is talking about migration to RHEVH 3.6. And at this point RHEVH 3.6 should not be an (recommended) option for any customer. Thus, I suggest to ignore it and close wontfix: https://bugzilla.redhat.com/show_bug.cgi?id=1290340#c24 4. Lastly, there is a totally separate upgrade scenario for hosts with local storage and it is covered in a separate bug: https://bugzilla.redhat.com/show_bug.cgi?id=1320556 Please review and ask Douglas(Eng) or Huijuan Zhao(QA) for detailed steps. Yaniv Dary(PM) for better wording, if unsure yourself.
(In reply to Marina from comment #15) > Emma, > > Looking deeper, I understand there are 2 different scenarios that we are > trying to document and should appear in the Upgrade Guide for 4.1: > > 1. > "Upgrading RHEVH 3.6 to RHVH-Next 4.x"[*] > The instructions are here: > https://bugzilla.redhat.com/show_bug.cgi?id=1376454#c26 > (Note: we should not separate different storage domain types in the upgrade > instructions, IMO.) > > 2. > "Upgrading environments with RHEVH 3.5 (RHEL 6 based) to RHV-Next 4.x"[*] > https://bugzilla.redhat.com/show_bug.cgi?id=1421098#c0 > > And the instructions are available here: > https://bugzilla.redhat.com/show_bug.cgi?id=1421098#c15 > > [*] Note: my wording is just a suggestion and probably should be reviewed > before adding to the docs. > > 3. > In addition, the following bug seem not to be relevant anymore, cause it is > talking about migration to RHEVH 3.6. And at this point RHEVH 3.6 should not > be an (recommended) option for any customer. Thus, I suggest to ignore it > and close wontfix: > https://bugzilla.redhat.com/show_bug.cgi?id=1290340#c24 > > 4. > Lastly, there is a totally separate upgrade scenario for hosts with local > storage and it is covered in a separate bug: > https://bugzilla.redhat.com/show_bug.cgi?id=1320556 > > Please review and ask Douglas(Eng) or Huijuan Zhao(QA) for detailed steps. > Yaniv Dary(PM) for better wording, if unsure yourself. Thanks Marina. Currently this bug is assigned to rhv doc team, so not sure who will be working on it, but I really appreciate your input.
(In reply to Douglas Schilling Landgraf from comment #14) > (In reply to Yaniv Dary from comment #13) > > I am looking for a flow I can read and understand. > > Please work on the steps, so it will be clearer and post them. > > Migration flow 3.6 to 4: > https://bugzilla.redhat.com/show_bug.cgi?id=1421098#c15 This will covered in another bug. > > Local storage from 3.6 to 4: > https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c4 > https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c6 This is new and I'll make the RFE on this topic. > > Storage migration 3.6 to 4: > https://bugzilla.redhat.com/show_bug.cgi?id=1376454#c26 This has nothing new.
*** Bug 1441664 has been marked as a duplicate of this bug. ***
Hi Douglas, I have a couple of questions for the following procedure. 1. From what I can see, the instructions start with After RHV is installed...can you confirm that a customer can upgrade straight from 3.6 to 4.1 using the standard upgrade instructions, and then continue from here if they have local storage. i.e. this section describes only the migration of the local storage? 2. Is there any need for a customer to go to 4.0 at any stage before migrating to 4.1? This is the procedure that will be covered by this bug. "Users that contain local storage environment are able to migrate from RHEV Hypervisor 3.6 to RHV Hypervisor 4. Tip: In case advanced installation (kickstart) is used to redeploy the machine with RHV 4, keep in mind to not overwrite your data, example: To autoinstall and avoid erase any file in /dev/sdb, use the following in the kickstart: "clearpart --all --drives=sda" * After RHV Hypervisor is installed (*Keep in mind to leave your local storage data intact) Create directory /data to recover your previous environment #2 mkdir /data Mount the previous local storage in /data #3 mount /dev/sdX1 /data Set permissions to /data #4 chown -R 36:36 /data chmod -R 0755 /data To automount the partition in /data (in case the server requires a reboot), use the following example: Example: # blkid | grep -i sdX1 /dev/sdX1: UUID="a81a6879-3764-48d0-8b21-2898c318ef7c" TYPE="ext4" # vi /etc/fstab UUID="a81a6879-3764-48d0-8b21-2898c318ef7c" /data ext4 defaults 0 0 Importing the local storage into RHVM: #5 Create DataCenter for Local Storage #6 Create Cluster for Local Storage #7 On Storage Tab, use a different dir than /data to create your initial local storage for later import your previous environment, example: /localfs On RHV Hypervisor: mkdir -p /localfs chown 36:36 /localfs chmod -R 0755 /localfs On RHV-M add the local storage in the Storage Tab: Name: localfs Path: /localfs #9 After localfs storage is UP, let's import the existing local storage: Storage tab, Import Domain Name: Data Storage type: Local on Host Path: /data Confirm the following: """ Storage Domain(s) are already attached to a Data Center. Approving this operation might cause data corruption if both Data Centers are active. """ To active your data storage: In the datacenter tab, go to storage sub-tab and active the data storage domain just imported (Data and local-fs should be UP) To import the virtual machines: 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) Finally, after virtual machines and disks were imported and tested, in the datacenter tab you can put the localfs storage in maintenance (as it won't be used)"
(In reply to Emma Heftman from comment #19) > Hi Douglas, I have a couple of questions for the following procedure. > 1. From what I can see, the instructions start with After RHV is > installed...can you confirm that a customer can upgrade straight from 3.6 to > 4.1 using the standard upgrade instructions, and then continue from here if > they have local storage. i.e. this section describes only the migration of > the local storage? > Few points: - From RHV-H perspective is required a fresh install, there is no upgrade way from RHEV-Hypervisor 3.6 to RHV-Hypersivor 4. - These instructions are related to local storage only. - I was able to migrate from 3.6 to 4.1 (RHVM/RHVH) or from 3.6 to 4.0 (RHVM/RHVH) @Huijuan Zhao, could you please also confirm QA tested without any issue migration from 3.6 to 4.0 (RHVM/RHVH) and 3.6 to 4.1 (RHVM/RHVH)? Related to bz: https://bugzilla.redhat.com/show_bug.cgi?id=1320556 > 2. Is there any need for a customer to go to 4.0 at any stage before > migrating to 4.1? From my tests, I didn't see any requirement. > > This is the procedure that will be covered by this bug. > > "Users that contain local storage environment are able to migrate from RHEV > Hypervisor 3.6 to RHV Hypervisor 4. 'are able to migrate ++the local storage++ from RHEV Hypervisor 3.6 to RHV Hypervisor 4' > > Tip: In case advanced installation (kickstart) is used to redeploy the > machine with RHV 4, keep in mind to not overwrite your data, example: > > To autoinstall and avoid erase any file in /dev/sdb, use the following in > the kickstart: > > "clearpart --all --drives=sda" > > > * After RHV Hypervisor is installed (*Keep in mind to leave your local > storage data intact) > > Create directory /data to recover your previous environment > #2 mkdir /data > > Mount the previous local storage in /data > #3 mount /dev/sdX1 /data > > Set permissions to /data > #4 chown -R 36:36 /data > chmod -R 0755 /data > > > To automount the partition in /data (in case the server requires a reboot), > use the following example: > > Example: > # blkid | grep -i sdX1 > /dev/sdX1: UUID="a81a6879-3764-48d0-8b21-2898c318ef7c" TYPE="ext4" > > # vi /etc/fstab > UUID="a81a6879-3764-48d0-8b21-2898c318ef7c" /data ext4 > defaults 0 0 > > > Importing the local storage into RHVM: > > #5 Create DataCenter for Local Storage > #6 Create Cluster for Local Storage > #7 On Storage Tab, use a different dir than /data to create your initial > local storage for later import your previous environment, example: /localfs > > On RHV Hypervisor: > mkdir -p /localfs > chown 36:36 /localfs > chmod -R 0755 /localfs > > On RHV-M add the local storage in the Storage Tab: > Name: localfs > Path: /localfs > > #9 After localfs storage is UP, let's import the existing local storage: > > Storage tab, Import Domain > > Name: Data > Storage type: Local on Host > Path: /data > > > Confirm the following: > """ > Storage Domain(s) are already attached to a Data Center. Approving this > operation might cause data corruption if both Data Centers are active. > """ > > To active your data storage: > In the datacenter tab, go to storage sub-tab and active the data storage > domain just imported (Data and local-fs should be UP) > > To import the virtual machines: > 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) > > Finally, after virtual machines and disks were imported and tested, in the > datacenter tab you can put the localfs storage in maintenance (as it won't > be used)" Minor comment above, but, I think it's pretty sane. For sure, we can double check after it's done and before ship into the official documentation.
(In reply to Douglas Schilling Landgraf from comment #21) > Few points: > > - From RHV-H perspective is required a fresh install, there is no upgrade > way from RHEV-Hypervisor 3.6 to RHV-Hypersivor 4. > > - These instructions are related to local storage only. > > - I was able to migrate from 3.6 to 4.1 (RHVM/RHVH) > or from 3.6 to 4.0 (RHVM/RHVH) > > @Huijuan Zhao, could you please also confirm QA tested without any issue > migration from 3.6 to 4.0 (RHVM/RHVH) and 3.6 to 4.1 (RHVM/RHVH)? > > Related to bz: > https://bugzilla.redhat.com/show_bug.cgi?id=1320556 Douglas, I still encountered the issue that no VM available to import when migrate from 3.6 to 4.1 (RHVM/RHVH), same as https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c12. QE will setup a fresh rhvm 4.1, and test this scenario again later, will update here once done. Thanks!
Douglas, I have a question about stage 4, which is: To automount the partition in /data (in case the server requires a reboot), use the following example: Can you please clarify what you mean by "in case the server requires a reboot" When should the customer use the mount command and when should they do an automount- i.e. in which scenario will the server require a reboot? Thanks, Emma
Douglas, QE tested migration from 3.6 to 4.0 (RHVM/RHVH) successful, but migration from 3.6 to 4.1 (RHVM/RHVH) failed (I will send ENV info via email). 1. Migration from 3.6 to 4.0 (RHVM/RHVH) successful: Test version: From: rhevh-7.3-20170425.0.el6ev.iso (RHEVM Version: 3.6.11-0.1.el6) To: redhat-virtualization-host-4.0-20170307.0 (RHVM Version: 4.0.7.4-0.1.el7ev) Test steps: Same as https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c4 Small notes: QE used USB for testing, so in RHEV-H 3.6 #2, should be: mount /dev/mapper/xxxx0:0p1 /data/images/rhev Test results: Can migrate VM from 3.6 to 4.0 (RHVM/RHVH) successful. 2. Migration from 3.6 to 4.1 (RHVM/RHVH) failed: Test version: From: rhevh-7.3-20170425.0.el6ev.iso (RHEVM Version: 3.6.11-0.1.el6) To: redhat-virtualization-host-4.1-20170512.0 (RHVM Version: 4.1.2.2-0.1.el7) Test steps: Same as https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c4 Small notes: QE used USB for testing, so in RHEV-H 3.6 #2, should be: mount /dev/mapper/xxxx0:0p1 /data/images/rhev Actual results: In Phase 2 step #9, Import Domain failed. It reports failed in rhvm UI: Failed to attach Storage Domain huzhao_data to Data Center huzhao_intel. (User: admin@internal-authz) Expected results: In Phase 2 step #9, should import Domain successful, and after it can migrate VM successful.
Douglas, please confirm that when creating the new Data Center for Local Storage, the compatibility level should be 4.x. (and not 3.6)
Douglas, and another question ;) When defining the path, both when creating the storage domain and when importing the previous storage domain, you say to define /localfs or /data as the path, but in the window, the example given includes the domain: E.g.: myserver.mydomain.com:/my/local/path Please clarify exactly how the path should be defined.
(In reply to Emma Heftman from comment #23) > Douglas, I have a question about stage 4, which is: > > To automount the partition in /data (in case the server requires a reboot), > use the following example: > > Can you please clarify what you mean by "in case the server requires a > reboot" > > When should the customer use the mount command and when should they do an > automount- i.e. in which scenario will the server require a reboot? > Let's say the server requires a new kernel update and a reboot is required to load the new kernel, if there is no automount, the second disk won't mount in /localfs automatically. Based on that, I believe we must update the doc and show the example of automount in /localfs instead of /data (Of course applies to /data too) but as /data is temporary domain it's not required to do automount but might worth mention.
(In reply to Douglas Schilling Landgraf from comment #29) > (In reply to Emma Heftman from comment #23) > > Douglas, I have a question about stage 4, which is: > > > > To automount the partition in /data (in case the server requires a reboot), > > use the following example: > > > > Can you please clarify what you mean by "in case the server requires a > > reboot" > > > > When should the customer use the mount command and when should they do an > > automount- i.e. in which scenario will the server require a reboot? > > > > Let's say the server requires a new kernel update and a reboot is required > to load the new kernel, if there is no automount, the second disk won't > mount in /localfs automatically. > > Based on that, I believe we must update the doc and show the example of > automount in /localfs instead of /data (Of course applies to /data too) but > as /data is temporary domain it's not required to do automount but might > worth mention. Sorry, from your comment#19, /data is the correct one to be mounted automatically. So, no need to change. Hopefully, I explained why we need the automatically mount. (In reply to Emma Heftman from comment #26) > Douglas, and another question ;) > > When defining the path, both when creating the storage domain and when > importing the previous storage domain, you say to define /localfs or /data > as the path, but in the window, the example given includes the domain: > > E.g.: myserver.mydomain.com:/my/local/path > > Please clarify exactly how the path should be defined. Users must select 'Local FS on Host' in Storage Type (when importing), so it will show an empty box for typing the path and no 'E.g.: myserver.mydomain.com:/my/local/path'
(In reply to Douglas Schilling Landgraf from comment #30) > (In reply to Douglas Schilling Landgraf from comment #29) > > (In reply to Emma Heftman from comment #23) > > > Douglas, I have a question about stage 4, which is: > > > > > > To automount the partition in /data (in case the server requires a reboot), > > > use the following example: > > > > > > Can you please clarify what you mean by "in case the server requires a > > > reboot" > > > > > > When should the customer use the mount command and when should they do an > > > automount- i.e. in which scenario will the server require a reboot? > > > > > > > Let's say the server requires a new kernel update and a reboot is required > > to load the new kernel, if there is no automount, the second disk won't > > mount in /localfs automatically. > > > > Based on that, I believe we must update the doc and show the example of > > automount in /localfs instead of /data (Of course applies to /data too) but > > as /data is temporary domain it's not required to do automount but might > > worth mention. > > Sorry, from your comment#19, /data is the correct one to be mounted > automatically. So, no need to change. > > Hopefully, I explained why we need the automatically mount. > > > (In reply to Emma Heftman from comment #26) > > Douglas, and another question ;) > > > > When defining the path, both when creating the storage domain and when > > importing the previous storage domain, you say to define /localfs or /data > > as the path, but in the window, the example given includes the domain: > > > > E.g.: myserver.mydomain.com:/my/local/path > > > > Please clarify exactly how the path should be defined. > > Users must select 'Local FS on Host' in Storage Type (when importing), so it > will show an empty box for typing the path and no 'E.g.: > myserver.mydomain.com:/my/local/path' Douglas, do you mean "Local on Host"? I don't see a Local FS on Host option in the window?
(In reply to Douglas Schilling Landgraf from comment #30) > (In reply to Douglas Schilling Landgraf from comment #29) > > (In reply to Emma Heftman from comment #23) > > > Douglas, I have a question about stage 4, which is: > > > > > > To automount the partition in /data (in case the server requires a reboot), > > > use the following example: > > > > > > Can you please clarify what you mean by "in case the server requires a > > > reboot" > > > > > > When should the customer use the mount command and when should they do an > > > automount- i.e. in which scenario will the server require a reboot? > > > > > > > Let's say the server requires a new kernel update and a reboot is required > > to load the new kernel, if there is no automount, the second disk won't > > mount in /localfs automatically. > > > > Based on that, I believe we must update the doc and show the example of > > automount in /localfs instead of /data (Of course applies to /data too) but > > as /data is temporary domain it's not required to do automount but might > > worth mention. > > Sorry, from your comment#19, /data is the correct one to be mounted > automatically. So, no need to change. > > Hopefully, I explained why we need the automatically mount. I understood the scenario of the kernel being updated, but I'm not sure whether that scenario is connected to the migration, or if you're saying that the host may need restarting as part of the new installation that was performed, in which case wouldn't they have restarted already after the installation? > > (In reply to Emma Heftman from comment #26) > > Douglas, and another question ;) > > > > When defining the path, both when creating the storage domain and when > > importing the previous storage domain, you say to define /localfs or /data > > as the path, but in the window, the example given includes the domain: > > > > E.g.: myserver.mydomain.com:/my/local/path > > > > Please clarify exactly how the path should be defined. > > Users must select 'Local FS on Host' in Storage Type (when importing), so it > will show an empty box for typing the path and no 'E.g.: > myserver.mydomain.com:/my/local/path'
Created attachment 1279744 [details] local-on-host screenshot
(In reply to Emma Heftman from comment #32) > (In reply to Douglas Schilling Landgraf from comment #30) > > (In reply to Douglas Schilling Landgraf from comment #29) > > > (In reply to Emma Heftman from comment #23) > > > > Douglas, I have a question about stage 4, which is: > > > > > > > > To automount the partition in /data (in case the server requires a reboot), > > > > use the following example: > > > > > > > > Can you please clarify what you mean by "in case the server requires a > > > > reboot" > > > > > > > > When should the customer use the mount command and when should they do an > > > > automount- i.e. in which scenario will the server require a reboot? > > > > > > > > > > Let's say the server requires a new kernel update and a reboot is required > > > to load the new kernel, if there is no automount, the second disk won't > > > mount in /localfs automatically. > > > > > > Based on that, I believe we must update the doc and show the example of > > > automount in /localfs instead of /data (Of course applies to /data too) but > > > as /data is temporary domain it's not required to do automount but might > > > worth mention. > > > > Sorry, from your comment#19, /data is the correct one to be mounted > > automatically. So, no need to change. > > > > Hopefully, I explained why we need the automatically mount. > > > > > > (In reply to Emma Heftman from comment #26) > > > Douglas, and another question ;) > > > > > > When defining the path, both when creating the storage domain and when > > > importing the previous storage domain, you say to define /localfs or /data > > > as the path, but in the window, the example given includes the domain: > > > > > > E.g.: myserver.mydomain.com:/my/local/path > > > > > > Please clarify exactly how the path should be defined. > > > > Users must select 'Local FS on Host' in Storage Type (when importing), so it > > will show an empty box for typing the path and no 'E.g.: > > myserver.mydomain.com:/my/local/path' > > Douglas, do you mean "Local on Host"? I don't see a Local FS on Host option > in the window? Please see the local-on-host screenshot attached.
(In reply to Douglas Schilling Landgraf from comment #38) > (In reply to Emma Heftman from comment #32) > > (In reply to Douglas Schilling Landgraf from comment #30) > > > (In reply to Douglas Schilling Landgraf from comment #29) > > > > (In reply to Emma Heftman from comment #23) > > > > > Douglas, I have a question about stage 4, which is: > > > > > > > > > > To automount the partition in /data (in case the server requires a reboot), > > > > > use the following example: > > > > > > > > > > Can you please clarify what you mean by "in case the server requires a > > > > > reboot" > > > > > > > > > > When should the customer use the mount command and when should they do an > > > > > automount- i.e. in which scenario will the server require a reboot? > > > > > > > > > > > > > Let's say the server requires a new kernel update and a reboot is required > > > > to load the new kernel, if there is no automount, the second disk won't > > > > mount in /localfs automatically. > > > > > > > > Based on that, I believe we must update the doc and show the example of > > > > automount in /localfs instead of /data (Of course applies to /data too) but > > > > as /data is temporary domain it's not required to do automount but might > > > > worth mention. > > > > > > Sorry, from your comment#19, /data is the correct one to be mounted > > > automatically. So, no need to change. > > > > > > Hopefully, I explained why we need the automatically mount. > > > > > > > > > (In reply to Emma Heftman from comment #26) > > > > Douglas, and another question ;) > > > > > > > > When defining the path, both when creating the storage domain and when > > > > importing the previous storage domain, you say to define /localfs or /data > > > > as the path, but in the window, the example given includes the domain: > > > > > > > > E.g.: myserver.mydomain.com:/my/local/path > > > > > > > > Please clarify exactly how the path should be defined. > > > > > > Users must select 'Local FS on Host' in Storage Type (when importing), so it > > > will show an empty box for typing the path and no 'E.g.: > > > myserver.mydomain.com:/my/local/path' > > > > Douglas, do you mean "Local on Host"? I don't see a Local FS on Host option > > in the window? > > Please see the local-on-host screenshot attached. Douglas, the screenshot shows Local on Host, which is what I also see, and also shows the example beneath the Export Path field showing that the path includes a domain..so I'm going back to my original questions: 1. The option is Local on Host rather than Local FS on Host? 2. Should the path contain the domain?
Hi Douglas Byron is currently reviewing the documentation as has asked whether at the beginning of this procedure "We are running RHV 4.1 (4.1 Manager) with a RHEV-H 3.6 Host using local storage. Also, we are running in 3.6 compatibility mode for the data center and cluster." My understanding was that we are in 4.x compatibility mode, but please could you please clarify this point? Thanks a lot, Emma
(In reply to Emma Heftman from comment #46) > Hi Douglas > Byron is currently reviewing the documentation as has asked whether at the > beginning of this procedure > "We are running RHV 4.1 (4.1 Manager) with a RHEV-H 3.6 Host using local > storage. Also, we are running in 3.6 compatibility mode for the data center > and cluster." > > My understanding was that we are in 4.x compatibility mode, but please could > you please clarify this point? > > Thanks a lot, Emma You can't be since 3.6 hypervisor doesn't expose 4.x compatibility. You can only be running in a 3.6 compatibility and after the reinstall of the host, you move to 4.x.
(In reply to Yaniv Dary from comment #47) > (In reply to Emma Heftman from comment #46) > > Hi Douglas > > Byron is currently reviewing the documentation as has asked whether at the > > beginning of this procedure > > "We are running RHV 4.1 (4.1 Manager) with a RHEV-H 3.6 Host using local > > storage. Also, we are running in 3.6 compatibility mode for the data center > > and cluster." > > > > My understanding was that we are in 4.x compatibility mode, but please could > > you please clarify this point? > > > > Thanks a lot, Emma > > You can't be since 3.6 hypervisor doesn't expose 4.x compatibility. > You can only be running in a 3.6 compatibility and after the reinstall of > the host, you move to 4.x Just to clarify, part of the instructions include creating a new Data Center so I would like confirmation that the new DC should be created with 4.1 compatibility mode - which is what I understood from the storage team.
(In reply to Emma Heftman from comment #48) > > Just to clarify, part of the instructions include creating a new Data Center > so I would like confirmation that the new DC should be created with 4.1 > compatibility mode - which is what I understood from the storage team. Not sure why a new DC is required and not using the existing cluster with a changed compatibility to 4.x. Maybe I'm missing something.
(In reply to Yaniv Dary from comment #49) > (In reply to Emma Heftman from comment #48) > > > > Just to clarify, part of the instructions include creating a new Data Center > > so I would like confirmation that the new DC should be created with 4.1 > > compatibility mode - which is what I understood from the storage team. > > Not sure why a new DC is required and not using the existing cluster with a > changed compatibility to 4.x. Maybe I'm missing something. Douglas, please confirm which data center/cluster compatibility levels are used before and during the procedure and confirm why a new DC is created rather than reusing an existing DC and changing the compatibility level.
(In reply to Emma Heftman from comment #50) > (In reply to Yaniv Dary from comment #49) > > (In reply to Emma Heftman from comment #48) > > > > > > Just to clarify, part of the instructions include creating a new Data Center > > > so I would like confirmation that the new DC should be created with 4.1 > > > compatibility mode - which is what I understood from the storage team. > > > > Not sure why a new DC is required and not using the existing cluster with a > > changed compatibility to 4.x. Maybe I'm missing something. > > > > Douglas, please confirm which data center/cluster compatibility levels are > used before and during the procedure and confirm why a new DC is created > rather than reusing an existing DC and changing the compatibility level. Create a new datacenter and cluster, is required for new and fresh RHVM 4 environments, not upgraded ones. Otherwise, changing the compatibility is enough as Yaniv shared. In fresh environments, creating the DC in 4.1 and Cluster compat. 4.1 is okay for importing local storage from 3.6.
Thanks Douglas. Another couple of questions please... 1. When you say: "Initially, we assume, the users already have installed RHVH 4, registered and approved it in the RVHM." So when you say register, are you referring them to registering to subscriptions? When exactly should they click Approve? 2. Aren't we missing some steps to add the host to the manager? If yes, this can only be done after they have created the data center, as described here: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html-single/installation_guide/#Adding_a_Hypervisor So when exactly should this be done in our procedure?
Hi Huijan Could you please let me know what button needs to be clicked to confirm this message that appears when importing the local storage domain: Storage Domain(s) are already attached to a Data Center. Approving this operation might cause data corruption if both Data Centers are active. Thanks a lot. Emma
(In reply to Emma Heftman from comment #53) > Hi Huijan > Could you please let me know what button needs to be clicked to confirm this > message that appears when importing the local storage domain: > > > Storage Domain(s) are already attached to a Data Center. Approving this > operation might cause data corruption if both Data Centers are active. > > > Thanks a lot. Emma Hi Emma, Did you encounter this message when run the step #9 of https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c4 ? If yes, please click "ok".
(In reply to Emma Heftman from comment #52) > Thanks Douglas. Another couple of questions please... > 1. When you say: > > "Initially, we assume, the users already have installed RHVH 4, registered > and approved it in the RVHM." > > So when you say register, are you referring them to registering to > subscriptions? When exactly should they click Approve? I am referring to exactly these steps ('Adding a hypervisor'): https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/ html-single/installation_guide/#Adding_a_Hypervisor > > 2. Aren't we missing some steps to add the host to the manager? If yes, this > can only be done after they have created the data center, as described here: > > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/ > html-single/installation_guide/#Adding_a_Hypervisor > > So when exactly should this be done in our procedure? This is the step of 'registering' the hypervisor.
(In reply to Douglas Schilling Landgraf from comment #55) > (In reply to Emma Heftman from comment #52) > > Thanks Douglas. Another couple of questions please... > > 1. When you say: > > > > "Initially, we assume, the users already have installed RHVH 4, registered > > and approved it in the RVHM." > > > > So when you say register, are you referring them to registering to > > subscriptions? When exactly should they click Approve? > As we are registering/adding the hypervisor from Engine side, don't need the Approve button. It's deprecated to register/add the hypervisor to Engine from hypervisor side but still possible, in that method require approval. Just for context: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Installation_Guide/Using_the_Hypervisor.html In other words, the link you shared is enough, no approval button required.
(In reply to Douglas Schilling Landgraf from comment #56) > (In reply to Douglas Schilling Landgraf from comment #55) > > (In reply to Emma Heftman from comment #52) > > > Thanks Douglas. Another couple of questions please... > > > 1. When you say: > > > > > > "Initially, we assume, the users already have installed RHVH 4, registered > > > and approved it in the RVHM." > > > > > > So when you say register, are you referring them to registering to > > > subscriptions? When exactly should they click Approve? > > > > As we are registering/adding the hypervisor from Engine side, don't need the > Approve button. It's deprecated to register/add the hypervisor to Engine > from hypervisor side but still possible, in that method require approval. > > Just for context: > https://access.redhat.com/documentation/en-US/ > Red_Hat_Enterprise_Virtualization/3.6/html/Installation_Guide/ > Using_the_Hypervisor.html > > In other words, the link you shared is enough, no approval button required. Thanks Douglas, but something is still not clear in this flow. The procedure for manually adding a host to the manager, requires them to select the Data Center, meaning it must already be defined. However, in our procedure, we only create the Data Center later on the procedure. So, don't we need to add the "Add a Host " step later in the procedure than where it currently is?
(In reply to Huijuan Zhao from comment #54) > (In reply to Emma Heftman from comment #53) > > Hi Huijan > > Could you please let me know what button needs to be clicked to confirm this > > message that appears when importing the local storage domain: > > > > > > Storage Domain(s) are already attached to a Data Center. Approving this > > operation might cause data corruption if both Data Centers are active. > > > > > > Thanks a lot. Emma > > Hi Emma, > > Did you encounter this message when run the step #9 of > https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c4 ? > If yes, please click "ok". It appears in step 9 of the same instructions, within the procedure itself.
(In reply to Emma Heftman from comment #58) > (In reply to Huijuan Zhao from comment #54) > > (In reply to Emma Heftman from comment #53) > > > Hi Huijan > > > Could you please let me know what button needs to be clicked to confirm this > > > message that appears when importing the local storage domain: > > > > > > > > > Storage Domain(s) are already attached to a Data Center. Approving this > > > operation might cause data corruption if both Data Centers are active. > > > > > > > > > Thanks a lot. Emma > > > > Hi Emma, > > > > Did you encounter this message when run the step #9 of > > https://bugzilla.redhat.com/show_bug.cgi?id=1320556#c4 ? > > If yes, please click "ok". > > It appears in step 9 of the same instructions, within the procedure itself. So please click "ok".
(In reply to Emma Heftman from comment #57) > (In reply to Douglas Schilling Landgraf from comment #56) > > (In reply to Douglas Schilling Landgraf from comment #55) > > > (In reply to Emma Heftman from comment #52) > > > > Thanks Douglas. Another couple of questions please... > > > > 1. When you say: > > > > > > > > "Initially, we assume, the users already have installed RHVH 4, registered > > > > and approved it in the RVHM." > > > > > > > > So when you say register, are you referring them to registering to > > > > subscriptions? When exactly should they click Approve? > > > > > > > As we are registering/adding the hypervisor from Engine side, don't need the > > Approve button. It's deprecated to register/add the hypervisor to Engine > > from hypervisor side but still possible, in that method require approval. > > > > Just for context: > > https://access.redhat.com/documentation/en-US/ > > Red_Hat_Enterprise_Virtualization/3.6/html/Installation_Guide/ > > Using_the_Hypervisor.html > > > > In other words, the link you shared is enough, no approval button required. > > Thanks Douglas, but something is still not clear in this flow. > > The procedure for manually adding a host to the manager, requires them to > select the Data Center, meaning it must already be defined. However, in our > procedure, we only create the Data Center later on the procedure. > So, don't we need to add the "Add a Host " step later in the procedure than > where it currently is? Yes.
Reviewed and verified.
The 4.0 updated documentation is available on the Customer Portal. Upgrade Guide: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.0/html-single/upgrade_guide/#Upgrading_RHVH_Local_Storage Administration Guide: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.0/html-single/administration_guide/ 4.1 updates will soon be available.
Reviewed and verified the MR.
The updated documentation for 4.1 is also now available on the Customer Portal: Upgrade Guide: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html-single/upgrade_guide/#Upgrading_RHVH_Local_Storage Administration Guide: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.1/html-single/administration_guide/#sect-Preparing_and_Adding_Local_Storage