XCP-ng
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Register
    • Login

    "SR_BACKEND_FAILURE_47"

    Scheduled Pinned Locked Moved Management
    11 Posts 3 Posters 607 Views 3 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D Offline
      dewalddk
      last edited by

      Good Day,

      After about 50 threads online I'm hitting a wall with "SR_BACKEND_FAILURE_47".

      Currently there are 4 Hosts (All Masters), 18/24 VM's Online. 95% of the hosts are situated on a HP Datastore.

      I'm getting the 47 error on various places but the biggest concern currently is one of the hosts are failing to make a connection to the Datastore/ISCSI, therefore none of its VM's are starting.

      The backend connection from the Host to the Datastore has no issues (Authentication, Connection etc) but its like the front end of the host just fails to connect. Have tried a few options of detaching and adding it back and reach the same spot.

      All 3 other hosts are able to access the ISCSI and work just fine, al bit also receiving a few 47 error on other occasions e.g Creating Snapshots.

      Hope someone can direct me into a path to get the VM's going.

      If possible I can also start the VM's on a different host, I see them on the datastore but with the host not being able to bring the VM's online the migration option fails, so not sure what other option there are?

      Would appreciate any support.

      T 1 Reply Last reply Reply Quote 0
      • olivierlambertO Offline
        olivierlambert Vates 🪐 Co-Founder CEO
        last edited by

        Hi,
        On top of my head:

        1. I would check if your iSCSI session is still up on all hosts (eg with iscsiadm)
        2. When you say "host failing to make connection to the datastore", can you be more explicit? What kind of errors? Have you looked at the SMlog on the host in question?
        3. The troubleshooting order is always from basic connectivity (ping) to higher level (iscsi connected OK, then VDI creation OK etc.). This is helpful to seek at which point something goes wrong
        4. Also, knowing your XCP-ng version will help 🙂
        D 1 Reply Last reply Reply Quote 0
        • D Offline
          dewalddk @olivierlambert
          last edited by

          @olivierlambert Thanks for your response:

          1. getting the below:

          discovery.startup = manual
          discovery.type = sendtargets
          discovery.sendtargets.address = 10.50.12.15
          discovery.sendtargets.port = 3260
          discovery.sendtargets.auth.authmethod = None
          discovery.sendtargets.auth.username = <empty>
          discovery.sendtargets.auth.password = <empty>
          discovery.sendtargets.auth.username_in = <empty>
          discovery.sendtargets.auth.password_in = <empty>
          discovery.sendtargets.timeo.login_timeout = 15
          discovery.sendtargets.use_discoveryd = No
          discovery.sendtargets.discoveryd_poll_inval = 30
          discovery.sendtargets.reopen_max = 5
          discovery.sendtargets.timeo.auth_timeout = 45
          discovery.sendtargets.timeo.active_timeout = 30
          discovery.sendtargets.iscsi.MaxRecvDataSegmentLength = 3276

          1. The iSCSI shows disconnected on all the hosts, and when trying to manually connect we receive that BACKEND_Failure 47/46.

          2. Connectivity seems perfect both interfaces are pingable (multipath), also on the Datastore its the connections are listed.

          Strangely I can add the iscsi as a new datastore then it appears empty, without picking up any previous data. I then removed the newly created one as to not overwrite any data on the MSA.

          It also shows all the VM's listed on the datastore when browsing the iSCSI storage.

          4 Version XOA 5.94.2

          1 Reply Last reply Reply Quote 0
          • olivierlambertO Offline
            olivierlambert Vates 🪐 Co-Founder CEO
            last edited by

            🤔 Weird. Likely unrelated, but you are using an old version of XOA by the way

            D 1 Reply Last reply Reply Quote 0
            • D Offline
              dewalddk @olivierlambert
              last edited by

              @olivierlambert Hi Oliver, looks like we made progress to get to a point where the hosts identifies the ISCSi/LUN's, just cant cant get it attached:

              e6ba48a6-183d-4c7c-a4ce-52176e5ed764-image.png

              D 1 Reply Last reply Reply Quote 0
              • D Offline
                dewalddk @dewalddk
                last edited by

                @dewalddk XOA is now on : 5.98.1

                D 1 Reply Last reply Reply Quote 0
                • D Offline
                  dewalddk @dewalddk
                  last edited by dewalddk

                  @dewalddk have tried a few command clearing the ISCSI and using the Centre, but everything fails. Pick up the LUN but when attaching wants to start on a clean Storage pool rather then the old existing one

                  a6253def-28ff-44fd-81e2-69d7dfec78ba-image.png

                  1 Reply Last reply Reply Quote 0
                  • D Offline
                    dewalddk
                    last edited by

                    3edd7ef5-4b6c-4c24-ae69-9699f9d7e9d4-image.png

                    1 Reply Last reply Reply Quote 0
                    • olivierlambertO Offline
                      olivierlambert Vates 🪐 Co-Founder CEO
                      last edited by

                      Probably worth looking at SMlog to get more details of this rvgstats failed. It's like a iSCSI multipath bad configuration or something weird with the iSCSI target, just for this host 🤔

                      1 Reply Last reply Reply Quote 0
                      • T Offline
                        Toshinori-Hayashi @dewalddk
                        last edited by

                        @dewalddk
                        Hi

                        In my case, this error occurred because I had a duplicate iSCSI device name.
                        Even if the iqn is different, xcp-ng will throw an error if the device name is duplicated.

                        enjoy

                        1 Reply Last reply Reply Quote 1
                        • olivierlambertO Offline
                          olivierlambert Vates 🪐 Co-Founder CEO
                          last edited by

                          Oh that's great! Nice catch 🙂 How did you find the root cause?

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post