Bug 1421437 - [Docs][RFE][Admin][Upgrade] Document upgrade of Red Hat Virtualization Hypervisor hosts with local storage from version 3.6 to 4.x
Summary: [Docs][RFE][Admin][Upgrade] Document upgrade of Red Hat Virtualization Hyperv...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: Documentation
Version: 4.1.0
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: ovirt-4.1.2
: ---
Assignee: Emma Heftman
QA Contact: Byron Gravenorst
URL:
Whiteboard:
: 1441664 (view as bug list)
Depends On: 1376454 1451112
Blocks: 1320556
TreeView+ depends on / blocked
 
Reported: 2017-02-12 10:42 UTC by Emma Heftman
Modified: 2019-05-07 13:11 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-26 15:09:13 UTC
oVirt Team: Docs
Target Upstream Version:


Attachments (Terms of Use)
local-on-host screenshot (36.02 KB, image/png)
2017-05-17 15:07 UTC, Douglas Schilling Landgraf
no flags Details

Description Emma Heftman 2017-02-12 10:42:25 UTC
According to documentation in https://bugzilla.redhat.com/show_bug.cgi?id=1376454

Comment 1 Yaniv Lavi 2017-02-21 12:59:57 UTC
What is the RFE about? Want it new and need to be documented?
It is not clear from the original bug.

Comment 2 Emma Heftman 2017-02-21 16:11:22 UTC
(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.

Comment 3 Douglas Schilling Landgraf 2017-02-22 18:56:52 UTC
(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.

Comment 4 Douglas Schilling Landgraf 2017-02-22 19:00:15 UTC
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

Comment 5 Yaniv Lavi 2017-02-27 13:52:55 UTC
I don't understand the flow is looks like a manager migration process, not a RHV-H upgrade at all.

Comment 6 Douglas Schilling Landgraf 2017-02-27 19:34:51 UTC
(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.

Comment 7 Yaniv Lavi 2017-03-01 09:50:40 UTC
(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?

Comment 8 Douglas Schilling Landgraf 2017-03-03 20:05:52 UTC
(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.

Comment 9 Yaniv Lavi 2017-03-07 12:52:37 UTC
I don't think there is anything to add to docs here.
Closing.

Comment 10 Marina Kalinin 2017-04-02 15:15:10 UTC
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.

Comment 11 Emma Heftman 2017-04-03 06:59:48 UTC
Yaniv
Can you please reopen this bug as it seems that there is a demand for this information.

Comment 12 Douglas Schilling Landgraf 2017-04-03 15:25:07 UTC
(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.

Comment 13 Yaniv Lavi 2017-04-06 08:53:17 UTC
I am looking for a flow I can read and understand.
Please work on the steps, so it will be clearer and post them.

Comment 14 Douglas Schilling Landgraf 2017-04-10 15:23:19 UTC
(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

Comment 15 Marina Kalinin 2017-04-10 18:09:42 UTC
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.

Comment 16 Emma Heftman 2017-04-12 10:19:35 UTC
(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.

Comment 17 Yaniv Lavi 2017-04-24 07:27:08 UTC
(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.

Comment 18 Yaniv Lavi 2017-04-24 07:41:34 UTC
*** Bug 1441664 has been marked as a duplicate of this bug. ***

Comment 19 Emma Heftman 2017-05-09 07:29:33 UTC
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)"

Comment 21 Douglas Schilling Landgraf 2017-05-11 22:14:37 UTC
(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.

Comment 22 Huijuan Zhao 2017-05-12 07:56:05 UTC
(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!

Comment 23 Emma Heftman 2017-05-15 09:36:34 UTC
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

Comment 24 Huijuan Zhao 2017-05-15 09:49:35 UTC
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.

Comment 25 Emma Heftman 2017-05-15 10:10:52 UTC
Douglas, please confirm that when creating the new Data Center for Local Storage, the compatibility level should be 4.x. (and not 3.6)

Comment 26 Emma Heftman 2017-05-15 12:54:49 UTC
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.

Comment 29 Douglas Schilling Landgraf 2017-05-15 20:30:14 UTC
(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.

Comment 30 Douglas Schilling Landgraf 2017-05-15 20:38:54 UTC
(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'

Comment 32 Emma Heftman 2017-05-17 12:43:05 UTC
(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?

Comment 33 Emma Heftman 2017-05-17 12:50:33 UTC
(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'

Comment 37 Douglas Schilling Landgraf 2017-05-17 15:07:25 UTC
Created attachment 1279744 [details]
local-on-host screenshot

Comment 38 Douglas Schilling Landgraf 2017-05-17 15:08:08 UTC
(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.

Comment 40 Emma Heftman 2017-05-18 13:21:59 UTC
(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?

Comment 46 Emma Heftman 2017-06-05 10:55:32 UTC
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

Comment 47 Yaniv Lavi 2017-06-05 11:29:01 UTC
(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.

Comment 48 Emma Heftman 2017-06-05 12:46:07 UTC
(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.

Comment 49 Yaniv Lavi 2017-06-05 13:14:11 UTC
(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.

Comment 50 Emma Heftman 2017-06-05 14:15:07 UTC
(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.

Comment 51 Douglas Schilling Landgraf 2017-06-05 20:20:11 UTC
(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.

Comment 52 Emma Heftman 2017-06-06 10:22:48 UTC
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?

Comment 53 Emma Heftman 2017-06-06 13:04:22 UTC
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

Comment 54 Huijuan Zhao 2017-06-06 13:35:53 UTC
(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".

Comment 55 Douglas Schilling Landgraf 2017-06-06 19:43:23 UTC
(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.

Comment 56 Douglas Schilling Landgraf 2017-06-06 19:52:28 UTC
(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.

Comment 57 Emma Heftman 2017-06-07 07:36:15 UTC
(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?

Comment 58 Emma Heftman 2017-06-07 08:45:34 UTC
(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.

Comment 59 Huijuan Zhao 2017-06-07 08:55:28 UTC
(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".

Comment 60 Douglas Schilling Landgraf 2017-06-07 12:58:40 UTC
(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.

Comment 61 Byron Gravenorst 2017-06-15 00:06:21 UTC
Reviewed and verified.

Comment 65 Emma Heftman 2017-06-22 15:54:17 UTC
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.

Comment 66 Byron Gravenorst 2017-06-26 04:31:12 UTC
Reviewed and verified the MR.


Note You need to log in before you can comment on or make changes to this bug.