Bug 1420604

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

See https://bugzilla.redhat.com/show_bug.cgi?id=1422144#c1 for additional details about the backup and restore flow.

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

See https://bugzilla.redhat.com/show_bug.cgi?id=1431635#c0 for prerequisites for avoiding SPM issues while completing a backup and restore (or migration) operation.

Lucy, just finished the customer facing KCS solution we talked about:

https://access.redhat.com/solutions/2998291

Lucy, could you review the KCS? If it's good enough you we can link it in the docs, saving some time. Or even move the contents to the Docs and just put the link to the docs in the KCS.

And since this also works in 4.0.7, maybe 4.0 docs also deserve it?

Thanks, Germano! And sorry for the delay.

I'm assigning this one to Byron for review. Byron, can you review the KBase against our current procedures to see how extensive the updates might be?

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

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

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

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

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

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

Adding another duplicate: bug 1505798

This one is a request for instructions on restoring storage as part of this flow.

Moving to the Documentation component and removing targets to allow the docs team to review and re-triage this request.

Targeting at 4.3, to be reviewed together with bug 1482710 as part of the overall content strategy for SHE backup and restore.

Rescoping this for the 4.2 stream, given the high priority.

Assigning to Tahlia for review. Tahlia, we'll review this in the context of 4.2 only, so it should follow on logically from your GA work on the deployment changes.

Setting the requires_doc_text flag to - since docs bugs don't get release notes.

Hi, 
I'd like to add some note to the restore procedure of the environment with several SDs and one of them is iscsi. If the restore process is running on the re-provisioned host , it probably will fail with STORAGE_DOMAIN_UNREACHABLE error . To prevent this after re-provisioning the host the user must update the /etc/iscsi/initiatorname.iscsi with the right value before the restore process starting.

(In reply to Polina from comment #90)
> Hi, 
> I'd like to add some note to the restore procedure of the environment with
> several SDs and one of them is iscsi. If the restore process is running on
> the re-provisioned host , it probably will fail with
> STORAGE_DOMAIN_UNREACHABLE error . To prevent this after re-provisioning the
> host the user must update the /etc/iscsi/initiatorname.iscsi with the right
> value before the restore process starting.

This just in the case where iSCSI target doesn't accept every connection but filters them according to initiators ACL, right?

(In reply to Simone Tiraboschi from comment #91)

> 
> This just in the case where iSCSI target doesn't accept every connection but
> filters them according to initiators ACL, right?

right. here is the yaml definition for iscsi:

iscsi_server: "10.35.162.66"
target_id: "iqn.2009-01.com.kaminario:storage.k2.22612"

storages:
  ...
  iscsi_0:
    state: present
    iscsi:
      target: "{{ target_id }}"
      address: "{{ iscsi_server }}"
      lun_id: 20024f40058540070
      override_luns: True

(In reply to Polina from comment #90)
> Hi, 
> I'd like to add some note to the restore procedure of the environment with
> several SDs and one of them is iscsi. If the restore process is running on
> the re-provisioned host , it probably will fail with
> STORAGE_DOMAIN_UNREACHABLE error . To prevent this after re-provisioning the
> host the user must update the /etc/iscsi/initiatorname.iscsi with the right
> value before the restore process starting.

This is really important note, user have to understand that iSCSI mapping should be updated for the hosts, hence initiator iqn must be the same as was mapped on iSCSI target, or changed to new iqn accordingly.

Thanks, I'll add it in.

I have no objections.
Moving to verified.
Please reopen if there will be some additional data needed to be inserted or open a separate documentation bug on it.

Verified. Waiting to merge.

Async with package ovirt-hosted-engine-setup-2.2.32-1 is now public with https://access.redhat.com/errata/RHBA-2018:3630

Content is approved by SME, QE, and docs QA.
 

Now published at: 

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html-single/self-hosted_engine_guide/#Migrating_from_a_Standalone_Manager_to_a_Self-hosted_Engine

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html-single/self-hosted_engine_guide/#Backing_up_and_Restoring_a_Self-hosted_Engine

https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.2/html-single/self-hosted_engine_guide/#Recovering_a_Self-hosted_Engine


Thank you very much to everyone who worked on and contributed to this.