ViPR SRM: missing LVM Physical Volumes in reports for Linux hosts

Article Number: 525094 Article Version: 3 Article Type: Break Fix



ViPR SRM,ViPR SRM 3.7,ViPR SRM 4.0,ViPR SRM 4.1,ViPR SRM 4.2

The RSH collector doesn’t correctly collect LVM information on some Linux host. As a result, there are inconsistencies in LVM reports regarding LV and PV numbers and names.

The “/sbin/lvs -o lv_name,vg_name,devices” command displays multiple PVs for some LVs if the LVM is configured that way. E.g.

LV VG Devices

root rpool /dev/sda2(0)

root rpool /dev/sda2(1920)

swap rpool /dev/sda2(768)



data_LV host_VG /dev/mapper/VPLEX.09fc(0),/dev/mapper/VPLEX.09fd(0)

Notice that LV data_LV has 2 devices/PVs listed. Currently, the LunMappingDetection.pl script used to do discovery on hosts cannot handle multiple PVs per LV.

This problem is fixed in SRM v 4.3

Jira SRS-38372

Related:

  • No Related Posts

7023490: os-release inconsistencies in SLES for SAP Applications

There are no fixes involved. This document is merely to provide information on what to expect in the os-release file depending on the installed version.

Fresh installs of SLES for SAP Applications produce the following os-release syntax and products.d contents:-

————————————————————————————————————————————

# cat /etc/os-release

NAME=”SLES”

VERSION=”12″

VERSION_ID=”12″

PRETTY_NAME=”SUSE Linux Enterprise Server 12″

ID=”sles”

ANSI_COLOR=”0;32″

CPE_NAME=”cpe:/o:suse:sles:12″

/etc/products.d # ls -l

total 16

-rw-r–r– 1 root root 2705 Oct 14 2014 SLES.prod

-rw-r–r– 1 root root 2839 Apr 23 2015 SLES_SAP.prod

lrwxrwxrwx 1 root root 13 Apr 3 15:41 baseproduct -> SLES_SAP.prod

-rw-r–r– 1 root root 1598 Oct 2 2014 sle-ha.prod

——————————————————

# cat /etc/os-release

NAME=”SLES_SAP”

VERSION=”12-SP1″

VERSION_ID=”12.1.0.1″

PRETTY_NAME=”SUSE Linux Enterprise Server for SAP Applications 12 SP1″

ID=”sles_sap”

ANSI_COLOR=”0;32″

CPE_NAME=”cpe:/o:suse:sles_sap:12:sp1″

/etc/products.d # ls -l

total 8

-rw-r–r– 1 root root 2854 Mar 15 2017 SLES_SAP.prod

lrwxrwxrwx 1 root root 13 Apr 3 15:05 baseproduct -> SLES_SAP.prod

——————————————————

# cat /etc/os-release

NAME=”SLES_SAP”

VERSION=”12-SP2″

VERSION_ID=”12.2″

PRETTY_NAME=”SUSE Linux Enterprise Server for SAP Applications 12 SP2″

ID=”sles_sap”

ANSI_COLOR=”0;32″

CPE_NAME=”cpe:/o:suse:sles_sap:12:sp2″

/etc/products.d # ls -l

total 8

-rw-r–r– 1 root root 3080 Mar 30 2017 SLES_SAP.prod

lrwxrwxrwx 1 root root 13 Apr 3 13:11 baseproduct -> SLES_SAP.prod

——————————————————

# cat /etc/os-release

NAME=”SLES”

VERSION=”12-SP3″

VERSION_ID=”12.3″

PRETTY_NAME=”SUSE Linux Enterprise Server 12 SP3″

ID=”sles”

ANSI_COLOR=”0;32″

CPE_NAME=”cpe:/o:suse:sles_sap:12:sp3″

/etc/products.d # ls -l

total 8

-rw-r–r– 1 root root 2972 Jul 24 2017 SLES_SAP.prod

lrwxrwxrwx 1 root root 13 Apr 3 12:31 baseproduct -> SLES_SAP.prod

——————————————————

# cat /etc/os-release

NAME=”SLES”

VERSION=”15″

VERSION_ID=”15″

PRETTY_NAME=”SUSE Linux Enterprise Server 15″

ID=”sles”

ID_LIKE=”suse”

ANSI_COLOR=”0;32″

CPE_NAME=”cpe:/o:suse:sles:15″

linux-mpxw:~ #


/etc/products.d # ls -l

total 28

-rw-r–r– 1 root root 3185 May 30 05:23 SLES_SAP.prod

lrwxrwxrwx 1 root root 13 Oct 31 11:46 baseproduct -> SLES_SAP.prod

-rw-r–r– 1 root root 3197 May 30 05:23 sle-ha.prod

-rw-r–r– 1 root root 1892 May 30 05:23 sle-module-basesystem.prod

-rw-r–r– 1 root root 2264 May 30 05:23 sle-module-desktop-applications.prod

-rw-r–r– 1 root root 2315 May 30 05:23 sle-module-sap-applications.prod

-rw-r–r– 1 root root 2351 May 30 05:23 sle-module-server-applications.prod

——————————————————

This leaves us with the question ‘How do we identify the ‘base product’ of a server?”.

The correct way to do this is is by examining the contents of /etc/product.d directory (and look at which product file the link ‘baseproduct’ is pointing too).

Related:

  • No Related Posts

14.0 symcfgd completely wedges RHEL 7.6 hosts

I need a solution

Environment: SEP 14.0.2332-0100 on RHEL 7.6

Synopsis: RHEL 7.6 was released. When a host is updated to 7.6 (FWIW the first kernel to come with RHEL 7.6 is 3.10.0-957) and either the host is rebooted or the symcfgd service is restarted, the host completely wedges, silently, and is unusable.

Repeatable Steps:

  1. Update to RHEL 7.6
  2. Reboot. Your host will wedge as it comes up.
  3. Reboot to single user mode to avoid /etc/rc3.d scripts related to SEP
  4. Build new SEP kernel modules via build.sh
  5. Run /etc/rc3.d/S21autoprotect by hand. Runs fine. Kernel modules load.
  6. Run /etc/rc3.d/S22symcfgd by hand and the host immediately wedges and starts flashing keyboard LEDs.

Short-term Workaround: For us, for now, is to reboot the host and choose an older 7.5 kernel when the kernel selection menu is displayed. As new kernel package updates come around, let alone ones with required security fixes, this will not be possible.

0

Related:

  • No Related Posts

Invalid Login Issue on MCS Provisioned Linux Machines with Winbind

To fix this issue on SUSE 12.3, you downgrade the version of samba on your template machine using the following command:

sudo zypper in -f samba-4.6.7+git.51.327af8d0a11-3.12.1

After this, update your machine catalog using the new master image.

On RHEL 7.4, you need to create a new template machine, then use the following command to restrict the package version:

echo ‘7.4’ >/etc/yum/vars/releasever

If your system is not registered or using other repos, you can install specific version of samba and lock it with yum version lock.

yum install yum-plugin-versionlock

yum install samba-winbind-clients-4.6.2-12.el7_4.x86_64

yum versionlock samba*

If there are other packages fail to install due to this version of samba, you need to install their lower versions accordingly.

Update on RHEL 7 Platform

RHEL team has fixed this issue in their latest samba package: 4.7.1-9.el7_5. However, after upgrading to this samba version, you will still get invalid login error. To solve this issue, in the template machine, you need to add a line in /var/xdl/mcs/mcs_util.sh, in function join_domain(), find the line:

tdbtool ${SAMBA_SECRETS} store SECRETS/MACHINE_PASSWORD/${WORKGROUP} "${PASSWORD}" 2>&1 >> "$logFile"

add a line below:

tdbtool ${SAMBA_SECRETS} store "SECRETS/MACHINE_SEC_CHANNEL_TYPE/${WORKGROUP}" "2000"

After this, create a new snapshot of the template machine and update machine catalog using this snapshot.

Related:

  • No Related Posts

Multipathing Overview for XenServer 6.2, 6.5, and 7.0


Contents

Overview

This article provides a generic overview of multipathing for Citrix XenServer 6.2, 6.5, and 7.0. For information about multipathing in XenServer 7.1 and later, see the Citrix XenServer Administrator Guide.

Basic Multipath Configuration

Dynamic multipathing support is available for Fibre Channel and iSCSI storage repositories (SRs). By default, multipathing uses round robin mode load balancing, so both routes will have active traffic on them during normal operation. You can enable or disable storage multipathing in XenCenter using the Multipathing tab on the server’s Properties dialog.

Before you enable multipathing:

  • Verify that multiple targets are available on your storage server.
  • The server must be placed in Maintenance Mode; this ensures that any running virtual machines with virtual disks in the affected storage repository are migrated before the changes are made.
  • Multipathing must be configured on each host in the pool. All cabling and, in case of iSCSI, subnet configurations must match the corresponding NICs on each host. For example, all NIC 3s must be configured to use the same subnet.

For more information about multipathing, see the Configuring iSCSI Multipathing Support for XenServer guide and the XenServer Administrator’s Guide.

To Enable or disable Multipathing using XenCenter

The following section contains instructions on enabling and disabling Multipathing using XenCenter.

  1. In the XenCenter Resources pane, select the server and then put it into Maintenance Mode. There may be a short delay while XenCenter migrates any active virtual machines and unplugs the existing storage. If the server is a pool master, it will be disconnected and may disappear from the Resources pane temporarily while a new pool master is assigned. When the server reappears in the Resources pane with the icon, continue to the next step.

User-added image

  1. On the General tab, click Properties and then click on the Multipathing tab.
  2. To enable multipathing, select the Enable multipathing on this server check box. To disable multipathing, clear the check box.

User-added image

  1. Click OK to apply the new setting and close the dialog box. There is a short delay while XenCenter saves the new storage configuration.
  2. Take the server out of Maintenance Mode: select the server in the Resources pane, right-click, and then click Exit Maintenance Mode.

To Enable or Disable Multipath Using the xe CLI

  1. Stop all the VMs which are using virtual disks on the SRs, so that the SRs can be unplugged.

This can be done by suspending VMs, shutting down VMs or migrating VMs to a different host

2. Unplug the PBDs related to such SRs for safety purposes. For every such SR:

Find the PBD related to the particular SR:
# xe sr-list uuid=<sr-uuid> params=all
Unplug the PBD:
# xe pbd-unplug uuid=<pbd_uuid>



3. Change multipath setting for the host setting the host’s other-config:multipathing parameter:

Run the following command to enable Multipath:
# xe host-param-set other-config:multipathing=true uuid=host_uuid

# xe host-param-set other-config:multipathhandle=dmp uuid=host_uuid
Run the following command to disable Multipath
# xe host-param-set other-config:multipathing=false uuid=host_uuid



4. Plug the PBDs back in:

# xe pbd-plug uuid=<pbd_uuid>

  • Repeat steps 1-4 for each server in the pool.
Advanced Multipath Configuration

Redundant Disk Array Controller (RDAC) Configuration (XenServer 6.2 only)

RDAC configuration is required by many storage vendors. This configuration is related to IBM DS4xxx, however you can try it on other storage where RDAC is required.

Important: This configuration may not work for certain storage types and is mostly experimental.

We recommend that you configure and test RDAC multipathing before placing your XenServer hosts into production.

The following section provides an example using IBM storage:

  1. Find out vendor and product type.
  2. The vendor option is usually the manufacturer, such as IBM.
  3. The product number can be found by using several tools or by asking the manufacturer. For example, if you have Qlogic Fibre Channel HBA you can use the “scli” tool to query the target and find out the product id.

    # scli -t

    Note: If “scli” is not in your path, you can find it at the following location: /opt/QLogic_Corporation/QConvergeConsoleCLI/scli
  4. Add the device into the devices section in the /etc/multipath.conf file. There are already some device sections included. Just add the new device at the beginning or the end of the existing section. The section should look like the following example. Note that there could be additional device sections within the devices section as shown in the following example:

    devices {

device {

vendor “IBM”

product “1815”

prio_callout “/sbin/mpath_prio_rdac /dev/%n”

path_grouping_policy group_by_prio

failback immediate

path_checker rdac

hardware_handler “1 rdac”

user_friendly_names no

}

}

  1. Reload the multipath configuration. See the “Reload Multipath Configuration” section for more information.
  2. Show the multipath information. See the “Show multipath information” section for more information.
  3. Enable the mppVhda driver. Some storage devices require the use of the mppVhba driver, which is not enabled by default. Most of the IBM storage that requires RDAC need the driver to be enabled.
  4. Note: You can use wild cards in the product if the product option is too long. For example, “1723*”

Asymmetric Logical Unit Access (ALUA) for iSCSI Devices

Refer to the blog on XenServer 6.5 and Asymmetric Logical Unit Access (ALUA) for iSCSI Devices for information.

Reload Multipath Configuration

Reload multipath configuration on each XenServer in the pool after any change to the /etc/multipath.conf file. Run the following command:

# service multipathd restart

Testing and Troubleshooting

Show Multipath Information

Run the following command to show the current multipath topology:

# multipath -l

# multipath -ll

Run the following command to show the verbosity and print all paths and multipaths:

# multipath -v 2

User-added image

Run the following command to refresh information what is supplied by previous commands:

# multipath -v 3

Note: In some cases, multipath -ll displays all the paths correctly and XenCenter may not display all paths that are connected. In such scenarios follow the instruction in the section “Refresh Multipath information in XenCenter”.

Refresh Multipath Information in XenCenter

If you notice that multipath -ll displays all the paths correctly and XenCenter shows you that some paths are not connected, you can refresh the information by running the following script:

# /opt/xensource/sm/mpathcount.py

iSCSI – Testing and Troubleshooting Commands

Check open-iscsi service status:

# service open-iscsi status

Restart open-iscsi service:

# service open-iscsi restart

Discover targets at given IP address:

# iscsiadm -m discovery -t sendtargets -p <ip_address_of_storage>

Log on to the target manually (The letter “l” stands for “logon”):

# iscsiadm -m node -T <iqn> -p <ip-address-of-the-storage> -l

See the disk and iSCSI ID in devices:

# ll /dev/disk/by-id/

You should be able to see the disk in this directory after a successful iSCSI logon. The long number is the SCSI ID. You can use it for sr-create or when manually creating PBD for iSCSI.

The following command provides a more concise output that includes the SCSI IDs.


# ll /dev/disk/by-scsid/

Log off the target (The letter “u” stands for “log off”):


# iscsiadm -m node -T <iqn> -p <ip-address-of-the-storage> -u

iSCSI – Not Every Path Available

You might experience an issue where only one path becomes active. Other paths are not connected. To resolve this issue, you can log on each path manually on the boot as explained in the following steps:

You already have one active path on IP address 192.168.30.1.

Discover the other paths, for example:

# iscsiadm -m discovery -t sendtargets -p 192.168.31.1

# iscsiadm -m discovery -t sendtargets -p 192.168.32.1

# iscsiadm -m discovery -t sendtargets -p 192.168.33.1

Test to logon the other paths, for example:

# iscsiadm -m node -T <iqn> -p 192.168.31.1 -l

# iscsiadm -m node -T <iqn> -p 192.168.32.1 -l

# iscsiadm -m node -T <iqn> -p 192.168.33.1 -l

Now you should be able to see all the paths active in XenCenter or by running the following command:

# multipath -l

Implement the logon command in /etc/rc.local on every server in the pool as follows:

# sleep 30

# iscsiadm -m node -T <iqn> -p 192.168.31.1 -l

# iscsiadm -m node -T <iqn> -p 192.168.32.1 -l

# iscsiadm -m node -T <iqn> -p 192.168.33.1 -l

Fibre Channel Commands

General Information about HBA and SCSI

To examine some simple information about the Fibre Channel HBAs in a machine

# systool -c fc_host -v

To look at verbose information regarding the SCSI adapters present on a system

# systool -c scsi_host -v

To see what Fibre Channel devices are connected to the Fibre Channel HBA cards

# systool -c fc_remote_ports -v -d

For Fibre Channel transport information

# systool -c fc_transport -v

For information on SCSI disks connected to a system

# systool -c scsi_disk -v

To examine more disk information including which hosts are connected to which disks

# systool -b scsi -v

Use the sg_map command to view more information about the SCSI map

# sg_map -x

To obtain driver information, including version numbers and active parameters

For Qlogic HBAs

# systool -m qla2xxx -v

For Emulex HBAs

# systool -m lpfc -v

Note: For more information about systool commands, see Red Hat Knowledgebase, Article ID: 9937 Why is the /proc/scsi/qla2xxx/ or /proc/scsi/lpfc/ directory missing in Red Hat Enterprise Linux 5 and what has replaced it?


Qlogic HBA

Rescan QLogic HBA for available LUNs:

# echo “- – -“ > /sys/class/scsi_host/host<number>/scan

(For more details see CTX120172 – How to Rescan the Qlogic Host Bus Adapter for New Logical Unit Numbers in XenServer)

Disks should appear in /dev/disk/by-id

# ll /dev/disk/by-id

Query Qlogic HBA for attached instances:

# scli -t

Query Qlogic HBA for LUNs

# scli -l <hba_instance_number_from_previous_command>

Removing HBA-based FC or iSCSI device entries

# echo “1” > /sys/class/scsi_device/<adapter>:<bus>:<target>:<lun>/device/delete


Emulex HBA

Utility for Emulex HBA:

# hbacmd

Display help to the command:

# hbacmd -h

Query Emulex HBAs:

# hbacmd listHBAs

List HBA attributes:

# hbacmd hbaattrib <wwpn_from_previous_command>

For example:

# hbacmd hbaattrib 10:00:00:00:c9:20:08:cc

List HBA port attributes:

# hbacmd portattrib <wwpn_from_previous_command>

For example:

# hbacmd portattrib 10:00:00:00:c9:20:08:cc

Note: If hbacmd is not in the path, you can find it at /usr/sbin/hbanyware/hbacmd

FAQ

Q: Do you support third-party handlers?

A: Citrix only supports default device-mapper (dmp) from XenServer 6.5 onwards. In addition to default device-mapper (dmp), XenServer 6.2 also supports DMP RDAC, and MPP RDAC for LSI compatible controllers.

Q: To what extent do you support multipathing configurations?

A: Citrix only supports default configurations. However, you might change /etc/multipath.conf configuration file according to your requirements, or to vendor-specific settings and then reload the multipath configuration as explained in “Reload Multipath Configuration” section.

Q: Do you support the PowerPath handler?

A: No.

Related:

  • No Related Posts

Troubleshooting guide for issues when GFS2 SR(Thin Provisioning) is being used in XenServer 7.6

Problem scenario 1: All hosts can ping each other, but creating a cluster is not possible.

  1. The clustering mechanism uses following specific ports. Please check if there are any firewalls or network configurations between the hosts in the pool are blocking these ports. Please ensure that these ports are open.
  • TCP: 8892, 21064.
  • UDP:5404,5405(not multicast)
  1. If you have configured HA in the pool, please disable the HA before enabling clustering.

Problem scenario 2: Cannot add a new host to the clustered pool.

  1. Please make sure the new host has following ports open.
  • TCP: 8892, 21064.
  • UDP:5404,5405(not multicast)
  1. Please make sure the new host can ping all hosts in the clustered pool.
  2. Please ensure no host is offline when a new host is trying to join the clustered pool.Ensure that the host has an IP address allocated on the NIC that will be joining the cluster network of the pool

Problem scenario 3: A host in the clustered pool is offline and it can’t be recovered. How to remove the host from the cluster?

You can mark a host as dead forcefully by below command:

xe host-declare-dead uuid=<host uuid>

If you need to mark multiple hosts as dead, you must include all of their <host uuid> in on single CLI invocation.

This above command removes the host from the cluster permanently and decreases the number of live hosts required for quorum.

Please note, once a host is marked as dead, it cannot be added back into the cluster. To add this host back into the cluster, you must do a fresh installation of XenServer on the host.


Problem scenario 4: Some members of the clustered pool are not joining cluster automatically.

  1. You can use following command to resync the members of the clustered pool to fix the issue.

xe cluster-pool-resync cluster-uuid=<cluster_uuid>

  1. You can run xcli diagnostic dbg on the problematic hosts and other hosts to confirm if the cluster information consists on those hosts.

Items to be checked from the command output:

  • id: node ID
  • addr: IP address used to communicates with other hosts
  • Cluster_token_timeout_ms: Cluster token timeout
  • Config_valid: if configuration is valid
Command output example:

xcli diagnostic dbg

{

is_running: true is_quorate: true num_times_booted: 1 token: (Value filtered) node_id: 1 all_members: [

{id: 3addr: [IPv4 192.168.180.222]

}{id: 2addr: [IPv4 192.168.180.221]

}{id: 1addr: [IPv4 192.168.180.220]

}] is_enabled: true saved_cluster_config: {

cluster_token_coefficient_ms: 1000 cluster_token_timeout_ms: 20000 config_version: 1 authkey: (Value filtered)

…etc…

config_valid: true
  1. In case above actions do not help, you may try a re-attaching GFS2 SR following below steps(These steps can also be used to recover from a situation where you end up with an invalid cluster configuration):
  1. ) Detach GFS2 SR from XenCenter or xe CL xe pbd-unplug uuid=<UUID of PBD> on each host
  2. ) Disable clustered pool from XenCenter or xe CL xe cluster-pool-destroy cluster-uuid=<cluster_uuid>
Or forcefully disable clustered pool by xe cluster-host-force-destroy uuid=<cluster_host> on each host
  1. ) Re-enable clustered pool from XenCenter or xe CL
xe cluster-pool-create network-uuid=<network_uuid> [cluster-stack=cluster_stack] [token-timeout=token_timeout] [token-timeout- coefficient=token_timeout_coefficient]
  1. ) Re-attach GFS2 SR from from XenCenter or xe CL xe pbd-plug uuid=<UUID of PBD> on each host

Problem scenario 5: A host in the clustered pool encountered into self-fencing loop.

In this case, you can start the host by adding “nocluster” option. To do this, connect to the hosts physical or serial console and edit the boot arguments in grub.

Example:

/boot/grub/grub.cfg

menuentry ‘XenServer’ {

search –label –set root root-oyftuj

multiboot2 /boot/xen.gz dom0_mem=4096M,max:4096M watchdog ucode=scan dom0_max_vcpus=1-16 crashkernel=192M,below=4G console=vga vga=mode-0x0311

module2 /boot/vmlinuz-4.4-xen root=LABEL=root-oyftuj ro nolvm hpet=disable xencons=hvc console=hvc0 console=tty0 quiet vga=785 splash plymouth.ignore-serial-consoles nocluster

module2 /boot/initrd-4.4-xen.img

}

menuentry ‘XenServer (Serial)’ {

search –label –set root root-oyftuj

multiboot2 /boot/xen.gz com1=115200,8n1 console=com1,vga dom0_mem=4096M,max:4096M watchdog ucode=scan dom0_max_vcpus=1-16 crashkernel=192M,below=4G

module2 /boot/vmlinuz-4.4-xen root=LABEL=root-oyftuj ro nolvm hpet=disable console=tty0 xencons=hvc console=hvc0 nocluster

module2 /boot/initrd-4.4-xen.img

Problem scenario 6: A pool master get restarted in a clustered pool.

For a cluster to have quorum, at least 50% of the hosts (rounding up) must be able to reach each other. For example in a 5 host pool, 3 hosts are required for quorum. In a 4 host pool, 2 hosts are required for quorum.

In a situation where the pool is evenly split (i.e. 2 groups of 2 hosts that can reach each other) then the segment with the lowest node id will stay up whilst the other half fences. You can find the node IDs of hosts by using the command xcli diagnostic dbg. Note that the pool master may not have the lowest node id.


Problem scenario 7: After a host is shut down forcibly in the clustered pool, all of pool has vanished.

If a host is shutdown non-forcefully then it will be temporarily removed from quorum calculations until it is turned back on. However you force shutdown a host or it loses power then it will still count towards quorum calculations. For example if you had a pool of 3 hosts and forcefully shutdown 2 of them the remaining host would fence as it would no longer have quorum.


Problem scenario 8: All of the hosts within the clustered pool get restarted at same time.

If number of contactable hosts in the pool is less than

  • even number of hosts in total: n/2
  • odd number of hosts in total: (n+1)/2

all hosts would be considered as not having quorum, hence all hosts would self-fence, and you would see all hosts restarted.

You may check following to get more information.

  • /var/opt/xapi-clusterd/boot-times to see if any boot occurred at an unexpected time.
  • Crit.log to check if there is any self-fencing message outputted.
  • XenCenter to check the notification of the timestamp you encountered the issue to see if self-fencing occurred.
  • dlm_tool status command output, check fence x at x x
example of a working case of dlm_tool status output
dlm_tool status

cluster nodeid 1 quorate 1 ring seq 4 4

daemon now 436 fence_pid 0

node 1 M add 23 rem 0 fail 0 fence 0 at 0 0

In case of collecting logs for debugging, please collect diagnostic information from all hosts in the cluster. In the case where a single host has self-fenced, the other hosts in the cluster are more likely to have useful information.

If the host is connected to XenCenter, from the menu select Tools > Server Status Report. Choose the all hosts to collect diagnostics from and click Next. Choose to collect all available diagnostics. Click Next. After the diagnostics have been collected, you can save them to your local system.

Or you can connect to the host console and use the xen-bugtool command to collect diagnostics.

Problem scenario 9: Error when changing the cluster settings

You might receive the following error message about an invalid token (“[[“InternalError”,”Invalid token”]]”) when updating the configuration of your cluster.

Resolve this issues by completing the following steps:

  1. (Optional) Backup the current cluster configuration by collecting an SSR with the xapi-clusterd and system log boxes ticked
  2. Use XenCenter to detach the GFS2 SR from the clustered pool
  3. From the CLI of any host in the cluster, force destroy the cluster: xe cluster-pool-force-destroy cluster-uuid=<uuid>
  4. Use XenCenter to re-enable clustering on your pool
  5. Use XenCenter to reattach the GFS2 SR to the pool

Related:

  • No Related Posts

ScaleIO: During upgrade of ScaleIO using Installation Manager, could not upgrade one SDS and cannot mark upgrade complete.

Article Number: 492097 Article Version: 3 Article Type: Break Fix



ScaleIO 2.0.1.1,ScaleIO 2.0.1,ScaleIO 2.0.0.3

scli –query_upgrade

Upgrade State: SDS Upgrade in Progress

List of Slave MDMs not yet upgraded:

0 Slave MDMs need to be upgraded in total

List of Tie-Breakers not yet upgraded:

0 Tie-Breakers need to be upgraded in total

List of SDSs not yet upgraded:

Protection Domain XXXXXXXX00000000 Name: domain1

SDS ID: XXXXXXXX00000066 Name: SDS-NAME State: Connected, Joined IP: 10.XX.AA.YY,10.XX.BB.YY,10.XX.CC.ZZ,10.XX.DD.ZZ Port: 7072 Version: 2.0.7536

1 SDSs need to be upgraded in this Protection Domain

1 SDSs need to be upgraded in total

rpm -qa | grep -i lia returned the version 2.0-8005.0 on the hosts that were working fine while it returned version 2.0.7536 on the problem SDS.

conf.txt file in LIA folder on another working host looks like this:-

lia_os_name=Red Hat 6

lia_token=20XXXXXXXXXX8a514dcdXXXXXXXXXXe360b4d481fd8914ada4d423XXXXXXXXXX

lia_trusted_ips=10.XX.16.75,10.XX.48.75,10.XX.64.11,10.XX.80.11,

lia_enable_ssl=1

lia_os_name=Red Hat 6

lia_random_salt0=8743045861133485256

lia_random_salt1=5837306391004997796

lia_random_salt2=3521831530911843826

lia_random_salt3=4495017059265088122

lia_id=844747788145816xxxx

lia_uploaded_lia_file_name=EMC-ScaleIO-lia-2.0-8005.0.el6.x86_64.rpm

While on the problem node SDS-NAME it has the following contents:-

lia_token=07XXXXXXXXXX99e6e7d0XXXXXXXXXXe360b4d481fd8914ada4d423XXXXXXXXXX

lia_enable_ssl=1

lia_os_name=Red Hat 6

lia_random_salt0=5415108760675224659

lia_random_salt1=4913954319432838823

lia_random_salt2=7563602494799338285

lia_random_salt3=1087635055679016365

lia_id=66319802521xxxxx

1. Manually upgrade LIA to the newer version

rpm -Uvh EMC-ScaleIO-lia-2.0-8005.0.el6.x86_64.rpm

2. Navigate to the folder /opt/emc/scaleio/lia/bin and run the following scripts to restart lia:-

./delete_service.sh

./create_service.sh

3. Make sure lia is running:-

ps -ef | grep lia

4. Navigate to the folder /opt/emc/scaleio/lia/bin and run the command:-

./update_conf_bin 7 lia_trusted_ips <list of the trusted IPs> 1

Example

./update_conf_bin 7 lia_trusted_ips 10.XX.16.75,10.XX.48.75,10.XX.64.11,10.XX.80.11 1

5. Navigate to the folder /opt/emc/scaleio/lia/conf and run the command “cat conf.txt” and validate that now you see the below line:-

lia_trusted_ips=10.XX.16.75,10.XX.48.75,10.XX.64.11,10.XX.80.11

6. Navigate to the folder /opt/emc/scaleio/lia/bin and run the following scripts to restart lia:-

./delete_service.sh

./create_service.sh

7. Make sure lia is running:-

ps -ef | grep lia

8. Enter the SDS in the maintenance mode:-

scli –enter_maintenance_mode –sds_name SDS-NAME

9. Wait for any rebuild/rebalance activity to finish.

10. Upgrade the SDS package on host eurdtp1siob15 using the rpm command :-

rpm -Uvh EMC-ScaleIO-sds-2.0-<BUILD>.0.elX.x86_64.rpm

11. Restart the SDS service. This can be done by either “pkill sds” or navigate to the folder /opt/emc/scaleio/sds/bin and run the following scripts to restart sds:-

./delete_service.sh

./create_service.sh

12. Verify the SDS package:-

rpm -qa | grep -i sds

13. Exit maintenance mode (run the command from the Master MDM)

scli –exit_maintenance_mode –sds_name SDS-NAME

14. Finalize the upgrade using scli command

scli –finalize_upgrade

Related:

ScaleIO: Are multipath devices supported as SDS devices in ScaleIO?

Article Number: 487270 Article Version: 6 Article Type: Break Fix



ScaleIO 1.32.6,ScaleIO 1.32.5,ScaleIO 2.0.0,ScaleIO 2.0.0.1

  • Are multipath devices supported as SDS devices in ScaleIO?
  • Are FC SAN LUNs supported?
  • Is RAID 10 or Raid 1 or Raid 5 supported?
  • Is device mapper supported?

Multipath devices are not supported to use as SDS devices with ScaleIO. You can find this mentioned here in the 1.32.6 release notes:

https://support.emc.com/docu70732_ScaleIO-1.32.6-Release-Notes.pdf?language=en_US

“Multipath devices cannot be added as SDS devices.”

One of the reasons for this is ScaleIO looks for a signature at the beginning of each disk. It will try to use all disks that it sees such as raw (/dev/sd*), dm-* and even /dev/mapper/mpath* if it sees them. Even if successfully adding them, on reboot or restarting the SDS service, it will find two or more devices with the same signature, and will leave them down to avoid corruption.

The ScaleIO SDS service can only use local devices, not fiber attached array devices or anything else that will have multiple paths to the device.

Q. Are FC SAN Luns supported?

Ans. No. ScaleIO only supports using disks that are local.

Q. Is RAID 10 or Raid 1 or Raid 5 supported?

Ans. No. We support single disk RAID 0, which is handled by the local RAID controller.

Q. Is device mapper supported?

Ans. Device mapper is supported on the SDC (client) side. When in use on the SDS node, as long as device mapper isn’t presenting multiple block devices where the same signature could be seen (as described above), this will work.

Related:

  • No Related Posts

Unisphere for VMAX: Unable to install Unisphere for VMAX on RHEL 7.3

Article Number: 501427 Article Version: 3 Article Type: Break Fix



Unisphere for VMAX 8.4.0

Customer unable to upgrade or install Unisphere for VMAX 8.4.0.4 on RHEL 7.3 host:

Customer unable to install Unisphere for VMAX v. 8.4 on RHEL 7.3 host

[root@/tmp]# ./UNIVMAX_V8.4.0.4_LINUX_X86_64.bin

Preparing to install

Extracting the JRE from the installer archive…

Unpacking the JRE…

Extracting the installation resources from the installer archive…

Configuring the installer for this system’s environment…

Launching installer…

=======================================================

Installer User Interface Mode Not Supported

Unable to load and to prepare the installer in console or silent mode.

=======================================================

Customer has a working host that is identical to this configuration where this installation was successful.

Customer has performed a host reboot and issue persists.

Customer was able to uninstall/revert to SE/Uni 8.3 with no issues.

Appropriate libraries are installed/present.

Ulimit -n set to 4096.

=====

UNIX team made customization done to the hosts after standard install of RHEL v. 7.3

=======

Upgrade from 8.3

New Install Unisphere for VMAX v. 8.4 on RHEL v. 7.3



this is temporary resolution:

install the kit after setting to “$DISPLAY= ” as shown below.

# export DISPLAY=

# ./UNIVMAX_V8.4.0.4_LINUX_X86_64.bin -i console

NOTE: It is host specific issue

Related:

  • No Related Posts

7023373: SMT – Error: Unable to request next job: 500 Access to ‘http’ URIs has been disabled

This document (7023373) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 11

SUSE Linux Enterprise Server 12
SUSE Linux Enterprise Server 15

Subscription Management Tool

Situation

The SMT (Subscription Management Tool) server is reporting the following error message related to the jobs:

Error: Unable to request next job: 500 Access to ‘http’ URIs has been disabled-

The above error will also show on the Client when the smt-agent command is launched manually.

Resolution

A configuration file must be changed on the Client so the first step is to create a backup copy of the file:

– On SUSE Linux Enterprise Server (SLES) 11 based Clients run:

# cp -p /etc/suseRegister.conf /etc/suseRegister.conf.BCK

– On SLES 12 and 15 based Clients run:

# cp -p /etc/SUSEConnect /etc/SUSEConnect.BCK

Then edit the file and change “http” for “https” (without the quotation marks) in the “url” line, so after the change the line should look as follows:

– On SLES 11 based Clients:

url=https://<YOUR-SMT-FQDN-HERE>/center/regsvc

– On SLES 12 and 15 based Clients:

url: https://<YOUR-SMT-FQDN-HERE>/

Save the changes and exit the editor.

Finally run the smt-agent command on the Client to check if the error is still showing up:

# smt-agent

If working the above command will not show any output.

Cause

Communication via HTTP for the SMT servers jobs is disabled by default, hence the error. All communications must be only via HTTPS and cannot be changed to work with HTTP.
The registration of the Client was done using HTTP or the configuration file was changed manually to use HTTP, verify the procedure and commands being used to register Clients against the SMT server and be sure to always use the SMT’s FQDN (Fully Qualified Domain Name) and HTTPS instead of HTTP.

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.

Related: